[OpenSIPS-Users] Trouble with forked calls and rtpengine

Fri Jan 7 16:47:19 UTC 2022

Yes parallel forking.
The via-branch downstream is unique but via-branch=1 gets the upstream branch 
parameter.  That would be the caller or perhaps an outgoing proxy. via-
branch=2 would be empty. The via is added just before relaying downstream.

The debug logs from rtpengine show that the via-branch parameters for each 
branch is identical. Furthermore when rtpengine gets further branches it says 
"found existing monologue".

As an experiment I used via-branch=extra with extra-id being the branch index. 
This seems to work well for initial INVITES because rtpengine says "creating 
new monologue" for each branch. This often breaks subsequent INVITEs because 
they are always branch 0.

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