We need a preview of the downstream via which would be unique per branch. 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@lists.opensips.org > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users