16 Aug
2017
16 Aug
'17
5:32 a.m.
Thank you.
Abdoul.
2017-08-16 11:25 GMT+02:00 Sebastian Damm <damm(a)sipgate.de>de>:
Hi,
On Wed, Aug 16, 2017 at 10:32 AM, Abdoul Osséni <abdoul.osseni(a)gmail.com>
wrote:
Does this mean that uac must be compliance with
RFC 5761 if I want
multiplex
and demultiplex RTP/RTCP between UAC and
rtpengine?
I don't know whether I understand your question correctly, but the
options in rtpengine are "graceful". How rtpengine behaves depends on
what the client offered in the incoming SDP. So if your UAC isn't
capable of multiplexing, rtpengine won't force it into doing it.
Since Google changed their default to enable multiplexing in the
Chrome WebRTC implementation, we are using the following line for
converting audio between WebRTC and Asterisk:
WebRTC -> rtpengine -> Asterisk:
rtpengine_manage("force trust-address replace-origin
replace-session-connection ICE=remove RTP/AVP rtcp-mux-demux");
Asterisk -> rtpengine -> WebRTC:
rtpengine_manage("force trust-address replace-origin
replace-session-connection ICE=force RTP/SAVPF rtcp-mux-offer");
That makes rtpengine always send out rtp and rtcp on different ports
for audio going to Asterisk, and offers the multiplexing for audio
going to the WebRTC client. Still the client can choose whether it
wants to accept multiplexed traffic or receive it on two ports.
(BTW: Enabling this helped to dramatically reduce audio support issues
on WebRTC calls.)
Best Regards,
Sebastian
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users