[OpenSIPS-Users] Trouble with forked calls and rtpengine

Thu Jan 27 11:57:07 UTC 2022

Hi, Robert!

Are you sure that via-branch=2 does not set different branches, and sets 
the same param as via-branch=1?
If you are going to use the extra_id_pv, you should make sure that you 
persist it over dialog, i.e. also provide it during sequential 
offer/answer/delete commands.

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 1/7/22 23:06, Robert Dyck wrote:
> Further more via-branch=2 on answer gives us the upstream via again and not
> ours.
> 
> On Friday, January 7, 2022 12:19:40 A.M. PST Bogdan-Andrei Iancu wrote:
>> Hi Robert,
>>
>> Are you doing parallel forking, right ? and keep in mind that via-branch
>> (after forking) is unique and consistent "per branch", so  you can rely
>> on that.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>
>> OpenSIPS Founder and Developer
>>     https://www.opensips-solutions.com
>> OpenSIPS eBootcamp 2021
>>     https://opensips.org/training/OpenSIPS_eBootcamp_2021/
>>
>> On 1/6/22 8:57 PM, Robert Dyck wrote:
>>> I am reaching out to the users out there to help me figure out why I get
>>> occasional call failures when it involves rtpengine and forked calls.
>>> Calls
>>> involving rtpengine but not forked are solid. For instance there is no
>>> problem with a call between a SIPified WEBRTC phone and some end of life
>>> device. WEBRTC has very strict requirements. ICE, DTLS and rtcmux are
>>> mandatory. These are unknown to some devices.
>>>
>>> I narrowed it down to forked calls. The documentation seems to suggest
>>> there are options for the offer command to deal with branches.
>>> Specifically the via- branch= variants. The auto option is mentioned in
>>> the documentation but it doesn't seem to be implemented in opensips. Then
>>> there is the 1 option for offers and the 2 option for answers. The 1/2
>>> option did not help. Looking a little closer at what it does, I can't see
>>> how it could have helped anyway. The branch parameter in the via header
>>> is not unique for the different branches. We have multiple callees but
>>> only one caller.
>>>
>>> Diving deeper a look at the rtpengine debug logs only confirmed my doubt
>>> about the usefulness of via branch parameter. Here is an example of a
>>> three way fork.
>>>
>>> First offer
>>> "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug"
>>> ], "replace": [ "session-connection", "origin" ], "transport-protocol":
>>> "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp",
>>> "via- branch": "z9hG4bK3119290", "received-from": [ "IP6",
>>> "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp",
>>> "command": "offer" }
>>> Jan  1 10:03:54 slim rtpengine[2517903]: NOTICE: [s25p40fpr5g0u52b96dp]:
>>> [core] Creating new call
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] getting monologue for tag 'as1g4gcnjp' in call
>>> 's25p40fpr5g0u52b96dp'
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] creating new monologue
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] tagging monologue with 'as1g4gcnjp'
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] create new "other side" monologue for viabranch z9hG4bK3119290
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] creating new monologue
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] tagging monologue with viabranch 'z9hG4bK3119290'
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] this= other=as1g4gcnjp
>>>
>>> Second offer
>>> "ICE": "remove", "direction": [ "ipv6", "ipv4-priv" ], "flags": [ "debug"
>>> ], "replace": [ "session-connection", "origin" ], "transport-protocol":
>>> "RTP/ AVP", "rtcp-mux": [ "demux" ], "call-id": "s25p40fpr5g0u52b96dp",
>>> "via- branch": "z9hG4bK3119290", "received-from": [ "IP6",
>>> "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp",
>>> "command": "offer" }
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] getting monologue for tag 'as1g4gcnjp' in call
>>> 's25p40fpr5g0u52b96dp'
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] found existing monologue
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] this= other=as1g4gcnjp
>>>
>>> Third offer
>>>
>>>    "ICE": "force", "DTLS-fingerprint": "sha-256", "direction": [
>>>    "ipv4-priv",
>>>
>>> "ipv4-ext" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace":
>>> [ "session-connection", "origin" ], "transport-protocol":
>>> "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id":
>>> "s25p40fpr5g0u52b96dp", "via-branch": "z9hG4bK3119290", "received-from":
>>> [ "IP6",
>>> "2001:569:7EB9:A400:8A42:A64E:CE7C:F58F" ], "from-tag": "as1g4gcnjp",
>>> "command": "offer" }
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] getting monologue for tag 'as1g4gcnjp' in call
>>> 's25p40fpr5g0u52b96dp'
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] found existing monologue
>>> Jan  1 10:03:54 slim rtpengine[2517903]: DEBUG: [s25p40fpr5g0u52b96dp]:
>>> [internals] this= other=as1g4gcnjp
>>>
>>> For the second and third offers the debug logs say  "found existing
>>> monologue". This tells me that the offers are considered to be unique.
>>> However to requirements for modifying the SDP are unique. The identical
>>> "via-branch": "z9hG4bK3119290"  appears in each offer.
>>>
>>> My theory is that the requirements for the three branches are being
>>> stacked on top of each because rtpengine considers them all to be a
>>> single offer. The theory seems to fit with what I have observed. The
>>> calls may or not fail. It seems to be influenced by the order of the
>>> branches and also which branch is actually answered. I get weird failures
>>> like rtc-mux being missing from the sdp when clearly it was submitted in
>>> the offer.
>>>
>>> Any ideas?
>>> Regards, Rob
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> 
> 
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users