16 Aug
2017
16 Aug
'17
11:32 a.m.
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.
16 Aug
16 Aug
12:25 p.m.
New subject: rtpengine : question about RTP/RTCP multiplexing (RFC 5761) and demultiplexing
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
12:32 p.m.
New subject: rtpengine : question about RTP/RTCP multiplexing (RFC 5761) and demultiplexing
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
2662
days inactive
2662
days old
2 comments
2 participants
participants (2)
-
Abdoul Osséni -
Sebastian Damm