Hello All,
I read rtpengine can multiplex and demultiplex RTP/RTCP. Cf.https://github.com/sipwise/rtpengine
Example:
UAC -> Kamailio + rtpengine -> Asterisk
UAC and Asterisk don't support RFC 5761. Only rtpengine does.
Does this mean that uac must be compliance with RFC 5761 if I want multiplex and demultiplex RTP/RTCP between UAC and rtpengine?
Thanks.
Abdoul.
Hi,
On Wed, Aug 16, 2017 at 10:32 AM, Abdoul Osséni abdoul.osseni@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
Thank you. Abdoul.
2017-08-16 11:25 GMT+02:00 Sebastian Damm damm@sipgate.de:
Hi,
On Wed, Aug 16, 2017 at 10:32 AM, Abdoul Osséni abdoul.osseni@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
-
Abdoul Osséni -
Sebastian Damm