[SR-Users] webrtc clients support using rtpengine

[Richard Fuchs]

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