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
