[OpenSIPS-Users] Trouble with forked calls and rtpengine

[Bogdan-Andrei Iancu]

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