On 12/18/14 13:38, Andrey Utkin wrote:
This works: call from sipml to linphone android: rtpengine: https://gist.github.com/krieger-od/bf8503fe7643c0571b58 kamailio: https://gist.github.com/krieger-od/c119d64af6edcde3fc46 ngrep: https://gist.github.com/krieger-od/cb5829be7a55a7acf9d3
This doesn't work: few seconds after answer, there's no media from remote subscriber, then linphone android agent hangs up; sipml hangs pretending being in call. rtpengine: https://gist.github.com/krieger-od/9eb120199ec99d1adcb4 kamailio: https://gist.github.com/krieger-od/26060c8d1d657458d9d2 ngrep: https://gist.github.com/krieger-od/d677864fcab8c508adde
Couple of things to try here...
In the second case, Firefox kept sending answers (200 OK) for no good reason. Check Firefox's debug log / JS console / whatever if there's any error or warnings messages.
Try running rtpengine with the --dtls-passive switch, even though that shouldn't make a difference after ICE went through (which it does).
Add rtcp-mux=demux to your rtpengine flags in your Kamailio config, should be safe to use everywhere.
It's curious that Firefox was using RTP/SAVPF as protocol in one call and UDP/TLS/RTP/SAVPF in another. I don't suspect that this would cause a problem, but it's worth trying to specify the protocol not as RTP/SAVPF but rather as transport-protocol=UDP/TLS/RTP/SAVPF. Note that in the case of answers, you don't need to specify any protocol at all.
In the third case, the audio stream was setup as a=sendonly, explaining the one-way audio. Probably caused by Firefox not being able to access the playback device.
Last but not least, try a different browser, either a newer version of Firefox (it's up to v34 I see), or Chrome.
As for the call teardown, it's Kamailio's responsibility (through the config) to let rtpengine know that the call has been terminated, for example when handling the BYE method. Otherwise you'll see timeouts in rtpengine. Even though the BYE should still be relayed to the other SIP end, causing the call to be hung up there.
cheers