Thank you.
Abdoul.

2017-08-16 11:25 GMT+02:00 Sebastian Damm <d...@sipgate.de>:

> Hi,
>
> On Wed, Aug 16, 2017 at 10:32 AM, Abdoul Osséni <abdoul.oss...@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@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Reply via email to