GNOME Bugzilla – Bug 613248
[audiopayload] add property to control packet duration
Last modified: 2010-04-09 16:20:57 UTC
Created attachment 156462 [details] empathy log for a call with no sound. I have a polycom soundpoint phone connected to a public IP address using the account fargouser@opensips.org. When I make a call, I can hear sound from the phone's microphone to empathy on my laptop, but not from the microphone on my laptop to the phone. I'm still trying to work out what's causing this issue. I've been trying to debug this for a while, and noticed a few things: * Making a call to an echo service like echo@iptel.org works fine. * Calling the phone from my n900 works fine. * If I use wireshark's telephony->rtp menu and save the streams as .au files, it seems that empathy is sending sound exactly how it should (to the opensips.org server, much like how the n900 does it). * Sometimes, a call will work just fine with empathy. (It has been suggested that this might be the first call after a reboot or something) but as soon as it fails once, it will continue to fail no matter what you try. I'm using empathy from experimental, and farsight2 and telepathy-sofiasip from git (otherwise, sofiasip dies when you enable debugging, or empathy locks up when you try to make SIP calls) I have dumps of network traffic from a failing empathy and a working n900. I don't have any dumps from the phone. I will keep trying to add debugging information but this is really confusing me.
Created attachment 156463 [details] log from telepathy-sofiasip for call with no sound.
Okay, so killall pulseaudio will cause pulse to be restarted, and then you can make a few calls fine until the problem strikes again. I wonder if it might be a timing issue involving how long it takes pulse to grab/regrab the soundcard. If the phone takes nonzero time to initialise, and you have already started sending rtp packets, might this cause the phone to mis-parse the stream and assume you're sending it silence? I'm going to read the rtp RFC and glare at wireshark for a bit.
Turns out that these polycom phones only work if every RTP packets contains a multiple of 10ms of audio, anything else breaks. Unfortunately there is currently no way to indicate this requirements to the gstreamer rtp payloaders. TBH i wouldn't be surprised if more phones acted in this way, so it might not be a bad idea to by default use a multiple of 10ms of audio (at least for PCMU/PCMA). Olivier should have a proof of concept patch for this which we used to test against the polycom phone
Created attachment 158220 [details] [review] Make it possible to force buffers that are a multiple of X ns Here's a patch that adds a new property to GstBaseRtpAudioPayload to force output buffers to be an exact multiple of a specified duration. Then we can force it to 10ms when calling SIP phones and our lives will be happier!
Should we also set the default for pcma/pcmu to multiples of 10ms, just as a compatible default or do you want farsight to take care of that instead ?
That patch does indeed fix the problem. There is a separate problem which is causing sofiasip to not emit sending when receiving a call from the phone (I suspect that it might be a regression of https://bugs.freedesktop.org/show_bug.cgi?id=20842 but there are no regression tests for calls, and I never got around to writing one to prove it).
I moved the property to the base payloader (together with min/max-ptime) commit 1fa171d3960dea447283d6eda05e2ed96e602049 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Fri Apr 9 16:06:05 2010 +0200 audiopayload: add property to control packet duration Add a property to specify that the amount of data in a packet should be a multiple of ptime-multiple. See #613248 commit 66cc2faba736ae07bb8cf0e1804eea17c5ec6fe9 Author: Olivier Crête <olivier.crete@collabora.co.uk> Date: Fri Mar 26 19:00:47 2010 -0400 audiopayload: use ptime-multiple Based on patch by Olivier Crête <olivier.crete@collabora.co.uk> Fixes #613248
I don't think that property really make sense for video codecs or frame-based codecs, that why I put it in the Audio class.
Some audio payloaders don't extend from the audio base class because the audio base class does not handle all cases (only fixed frame sizes or sample sizes AFAIK)
Yes, but all of these have some kind of framing (Which may be variable size), so I don't think this property makes sense in these cases.