Re: [SR-Users] rtpengine : question about RTP/RTCP multiplexing (RFC 5761) and demultiplexing

2017-08-16 Thread Abdoul Osséni
Thank you.
Abdoul.


2017-08-16 11:25 GMT+02:00 Sebastian Damm :

> Hi,
>
> On Wed, Aug 16, 2017 at 10:32 AM, Abdoul Osséni 
> 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


Re: [SR-Users] rtpengine : question about RTP/RTCP multiplexing (RFC 5761) and demultiplexing

2017-08-16 Thread Sebastian Damm
Hi,

On Wed, Aug 16, 2017 at 10:32 AM, Abdoul Osséni  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