[OpenSIPS-Users] Trouble with forked calls and rtpengine

[Robert Dyck]

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