[SR-Users] rtcp-mux policy for RTPengine module

[Yuriy Gorlichenko]

Looks like here is FreeSWITH fixes it from it's side with rtsp-mux=true.

As i said above - a=rtcp:<port> should present but should use same port
with m=audio.

I know that freeswith allows rtcp-mux, but asterisk, for example does not.

Thats why im asking how to handle this issue with  rtpengine if it possible.

On Oct 14, 2017 11:02 AM, "Sergey Safarov" <s.safarov at gmail.com> wrote:

> Please look one more example o SDP with rtcp-mux
>
>    ------------------------------------------------------------------------
>    INVITE sip:3000 at pbx.rcsnet.ru:5060 SIP/2.0
>    Via: SIP/2.0/UDP 91.103.196.12;rport;branch=z9hG4bK32SrX56KHZgya
>    Max-Forwards: 70
>    From: "" <sip:0000000000 at 91.103.196.12>;tag=3Z0mjUyp1matN
>    To: <sip:3000 at pbx.rcsnet.ru:5060>
>    Call-ID: e3be7793-cd5a-1235-d195-005056be15c6
>    CSeq: 108480740 INVITE
>    Contact: <sip:mod_sofia at 91.103.196.12:5060>
>    User-Agent: FreeSWITCH-mod_sofia/1.9.0+git~20170615T144716Z~5f5fb33ea9~64bit
>    Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
>    Supported: timer, path, replaces
>    Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
>    Content-Type: application/sdp
>    Content-Disposition: session
>    Content-Length: 670
>    X-FS-Support: update_display,send_info
>    Remote-Party-ID: <sip:0000000000 at 91.103.196.12>;party=calling;screen=yes;privacy=off
>
>    v=0
>    o=FreeSWITCH 1497607971 1497607972 IN IP4 91.103.196.12
>    s=FreeSWITCH
>    c=IN IP4 91.103.196.12
>    t=0 0
>    m=audio 25638 RTP/AVP 102 9 0 8 104 101
>    a=rtpmap:102 opus/48000/2
>    a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
>    a=rtpmap:9 G722/8000
>    a=rtpmap:0 PCMU/8000
>    a=rtpmap:8 PCMA/8000
>    a=rtpmap:104 telephone-event/48000
>    a=fmtp:104 0-16
>    a=rtpmap:101 telephone-event/8000
>    a=fmtp:101 0-16
>    a=rtcp-mux
>    a=rtcp:25638 IN IP4 91.103.196.12
>    a=ptime:20
>    m=video 23108 RTP/AVP 103
>    b=AS:1024
>    a=rtpmap:103 VP8/90000
>    a=rtcp-fb:103 ccm fir
>    a=rtcp-fb:103 ccm tmmbr
>    a=rtcp-fb:103 nack
>    a=rtcp-fb:103 nack pli
>    ------------------------------------------------------------------------
>
>
> Log https://freeswitch.org/jira/secure/attachment/26623/originate_log.txt
> Ticket https://freeswitch.org/jira/browse/FS-10400
>
> Sergey
>
>
>
> сб, 14 окт. 2017 г. в 0:13, Yuriy Gorlichenko <ovoshlook at gmail.com>:
>
>> Sorry:
>> small fix
>> webRTC clients accepts
>> a=rtcp:<port>
>> but port suppose should be same with
>> m=audio
>>
>> 2017-10-13 22:58 GMT+03:00 Yuriy Gorlichenko <ovoshlook at gmail.com>:
>>
>>> Hi all!
>>> Some time ago Chromium browser sets rtcpMuxPolicy: required by default
>>> (soon on Chrome 58)
>>> It means that webRTC based clients not accepts
>>> a=rtcp:31757
>>> And uses for RTP and RTCP multiplexing at one port
>>>
>>> Main trouble that i found: calls between original SIP client and webRTC
>>> client (SIP client is initiator of call)
>>>
>>> When sip client sends invite it has
>>> a=rtcp:33445
>>> Means it wants 2 different prots for RTCP and RTP
>>>
>>> As expected for this case webRTC client says 488 Not accessible here
>>> instead of 200 resonse
>>>
>>> I suppose rtpengine module should hept to handle it but i can not find
>>> any key how to do it
>>>
>>> I added form rtpengine_manage()
>>> rtcp-mux-offer and rtcp-mux-accept but it only adds "a=rtcp-mux"
>>> But not removes a=rtcp and ice cadidate prepeared for it.
>>>
>>> Suppose removing a=rtcp:12345 will gives just an issue for RTP session.
>>>
>>> Does rtpengine module have some keys for resole this issue?
>>>
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20171014/83d973b7/attachment-0001.html>