Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
As mentioned in one of my previous notes I use via-branch=extra and set the avp to $T_branch_idx. That solved my problem. I had doubts about sequential INVITEs because the index would always be 0 and the call may have been establihed with a different index. My testing with rtpenigine debug logs showed that after the totag gets installed by the initial answer, via-branch is ignored. So no problem. My concern now is with the documentation. via-branch=1 or 2 for answer do nothing for forked calls. Omitting via-branch accomplishes the same thing. Because with via-branch=1 the result is identical for each branch, rtpengine just overwrites whatever flags it has already received. In the documentation the bit about via-branch could be eliminated and opensips could arbitrarily set it to the branch index. It would work whether the call forked or not. If we actually wanted the via branch that opensips sends downstream we would need some mechanism that made it available to the script. The branch index is enough however so it's not worth the bother. In general, opensips has no interest in a transaction ID from an upstream node. It is only of interest to that node. On Friday, February 4, 2022 3:06:40 A.M. PST Răzvan Crainea wrote: > Hi, Robert! > > For a request, VIA 1 is always the previous hop - therefore, if you want > to have different offer messages, you need to use something else - my > proposal is to use the via-branch=3 and set the extra_avp to > $T_branch_idx. You can do the same thing for replies, and that should > cover all cases. > > Best regards, > > Răzvan Crainea > OpenSIPS Core Developer > http://www.opensips-solutions.com > > On 1/27/22 19:23, Robert Dyck wrote: > > Opensips adds its via ( with branch info ) after script processing but > > before forwarding. Opensips branch info is not available to the script > > when processing an INVITE. I have attached some text of an INVITE with > > rtpengine and with "offer via-branch=1". What rtpengine receives is the > > branch parameter added by the upstream node. The upstream node has no > > knowledge of any forking that may occur after lookup. > > > > The branch parameter is a legacy of rfc2543. That rfc stated that a > > forking > > proxy would add branch info in a via parameter called branch. This > > parameter could be added by any hop but is ignored. It was only > > meaningful in a response received by the forking proxy. > > > > Rfc3261 retained the via parameter name, I assume for compatibility. > > Rfc3261 was clear however that "branch" was now a transaction ID. This is > > only of interest to the node that added it in a request. Now in the case > > of a forking proxy the branch parameter has the dual role of being a > > transaction ID and a branch ID. Opensips does this by adding the branch > > index as a suffix to the transaction ID. > > > > The opensips script may not have access to the eventual transaction ID but > > the branch index is available. Passing the branch index to rtpengine > > causes it to create a different profile for each branch rather than > > stacking the profiles. That stacking was causing trouble for me. > > > > When rtpengine is simply providing a public address to relay media the > > stacking does not appear to have any consequence. However when mixing > > WEBRTC and non-WEBRTC stacking the profiles in a single entry in > > rtpengine gives inconsistent results. > > > > On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote: > >> Hi, Robert! > >> > >> Are you sure that via-branch=2 does not set different branches, and sets > >> the same param as via-branch=1? > >> If you are going to use the extra_id_pv, you should make sure that you > >> persist it over dialog, i.e. also provide it during sequential > >> offer/answer/delete commands. > >> > >> Best regards, > >> > >> > >> ___ > >> 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Hi, Robert! For a request, VIA 1 is always the previous hop - therefore, if you want to have different offer messages, you need to use something else - my proposal is to use the via-branch=3 and set the extra_avp to $T_branch_idx. You can do the same thing for replies, and that should cover all cases. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/27/22 19:23, Robert Dyck wrote: Opensips adds its via ( with branch info ) after script processing but before forwarding. Opensips branch info is not available to the script when processing an INVITE. I have attached some text of an INVITE with rtpengine and with "offer via-branch=1". What rtpengine receives is the branch parameter added by the upstream node. The upstream node has no knowledge of any forking that may occur after lookup. The branch parameter is a legacy of rfc2543. That rfc stated that a forking proxy would add branch info in a via parameter called branch. This parameter could be added by any hop but is ignored. It was only meaningful in a response received by the forking proxy. Rfc3261 retained the via parameter name, I assume for compatibility. Rfc3261 was clear however that "branch" was now a transaction ID. This is only of interest to the node that added it in a request. Now in the case of a forking proxy the branch parameter has the dual role of being a transaction ID and a branch ID. Opensips does this by adding the branch index as a suffix to the transaction ID. The opensips script may not have access to the eventual transaction ID but the branch index is available. Passing the branch index to rtpengine causes it to create a different profile for each branch rather than stacking the profiles. That stacking was causing trouble for me. When rtpengine is simply providing a public address to relay media the stacking does not appear to have any consequence. However when mixing WEBRTC and non-WEBRTC stacking the profiles in a single entry in rtpengine gives inconsistent results. On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote: Hi, Robert! Are you sure that via-branch=2 does not set different branches, and sets the same param as via-branch=1? If you are going to use the extra_id_pv, you should make sure that you persist it over dialog, i.e. also provide it during sequential offer/answer/delete commands. Best regards, ___ 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
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Opensips adds its via ( with branch info ) after script processing but before forwarding. Opensips branch info is not available to the script when processing an INVITE. I have attached some text of an INVITE with rtpengine and with "offer via-branch=1". What rtpengine receives is the branch parameter added by the upstream node. The upstream node has no knowledge of any forking that may occur after lookup. The branch parameter is a legacy of rfc2543. That rfc stated that a forking proxy would add branch info in a via parameter called branch. This parameter could be added by any hop but is ignored. It was only meaningful in a response received by the forking proxy. Rfc3261 retained the via parameter name, I assume for compatibility. Rfc3261 was clear however that "branch" was now a transaction ID. This is only of interest to the node that added it in a request. Now in the case of a forking proxy the branch parameter has the dual role of being a transaction ID and a branch ID. Opensips does this by adding the branch index as a suffix to the transaction ID. The opensips script may not have access to the eventual transaction ID but the branch index is available. Passing the branch index to rtpengine causes it to create a different profile for each branch rather than stacking the profiles. That stacking was causing trouble for me. When rtpengine is simply providing a public address to relay media the stacking does not appear to have any consequence. However when mixing WEBRTC and non-WEBRTC stacking the profiles in a single entry in rtpengine gives inconsistent results. On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote: > Hi, Robert! > > Are you sure that via-branch=2 does not set different branches, and sets > the same param as via-branch=1? > If you are going to use the extra_id_pv, you should make sure that you > persist it over dialog, i.e. also provide it during sequential > offer/answer/delete commands. > > Best regards, > INVITE sip:2@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.87:38268;branch=z9hG4bK24749ef66a21e2fd;rport Contact: Max-Forwards: 70 Proxy-Authorization: Digest username="4", realm="192.168.1.2", nonce="jzLa4gxOll83BD3v0WKZclEjjHyaJpxfmIWTVMw8WXcA", uri="sip:2@192.168.1.2", response="697304535675ddab4c8fec180eef338a", cnonce="fe5ab4853d24b69e", qop=auth, nc=0001, algorithm=MD5 To: From: ;tag=a331187bbb05d5eb Call-ID: 2a211cae7d8a4ec3 CSeq: 56918 INVITE User-Agent: baresip v1.1.0 (x86_64/linux) Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER Supported: gruu Content-Type: application/sdp Content-Length: 433 xlog Jan 27 08:24:27 [2683481] Invite with first via host 192.168.1.87 and branch ID z9hG4bK24749ef66a21e2fd xlog Jan 27 08:24:27 [2683481] profile is debug via-branch=1 SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid >From rtpengine log Jan 27 08:24:27 slim rtpengine[1623448]: DEBUG: [2a211cae7d8a4ec3]: ... : "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv6" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "2a211cae7d8a4ec3", "via-branch": "z9hG4bK24749ef66a21e2fd", "received-from": [ "IP4", "192.168.1.87" ], "from-tag": "a331187bbb05d5eb", "command": "offer" } ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Hi, Robert! Are you sure that via-branch=2 does not set different branches, and sets the same param as via-branch=1? If you are going to use the extra_id_pv, you should make sure that you persist it over dialog, i.e. also provide it during sequential offer/answer/delete commands. Best regards, Răzvan Crainea OpenSIPS Core Developer http://www.opensips-solutions.com On 1/7/22 23:06, Robert Dyck wrote: 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:
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
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 > > >
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
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
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
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": [
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
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
Re: [OpenSIPS-Users] Trouble with forked calls and rtpengine
Attached here is a prettier version of the three offers.>From opensips
Jan 1 10:03:57 [2670144] Invite with first via host 192.168.1.2 and branch ID
z9hG4bKd83e.3a8b6577.0
Jan 1 10:03:57 [2670144] WebRTC-legacy interworking
Jan 1 10:03:57 [2670144] The answer profile must be opposite of the offer
profile
Jan 1 10:03:57 [2670144] Setting RTP profile for answer to debug via-branch=2
SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin
DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid
Jan 1 10:03:57 [2670144] DBG:core:comp_scriptvar: str 29: in-iface=ipv4-priv
out-iface=ipv6
Jan 1 10:03:57 [2670144] Interfaces are in-iface=ipv4-priv out-iface=ipv6
Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=
Jan 1 10:03:57 [2670144] DBG:core:decode_mime_type: Decoding MIME type
for:[application/sdp]
Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=40
Jan 1 10:03:57 [2670144] DBG:core:parse_to_param: tag=as1g4gcnjp
Jan 1 10:03:57 [2670144] DBG:core:_parse_to: end of header reached, state=29
Jan 1 10:03:57 [2670144] DBG:core:_parse_to: display={"Guest"},
ruri={sip:7...@cwdrive.mooo.com}
Jan 1 10:03:57 [2670144] DBG:core:parse_headers: flags=4
Jan 1 10:03:57 [2670144] DBG:rtpengine:rtpe_function_call: proxy reply:
d3:sdp741:v=0
o=twinkle 2116263177 238598101 IN IP6 2001:569:7eb9:a400:223:7dff:feb8:d2b4
s=-
c=IN IP6 2001:569:7eb9:a400:223:7dff:feb8:d2b4
t=0 0
m=audio 35020 UDP/TLS/RTP/SAVPF 0 110
a=mid:0
a=rtpmap:0 PCMU/8000
a=rtpmap:110 telephone-event/8000
a=fmtp:110 0-15
a=sendrecv
a=rtcp:35021
a=setup:active
a=fingerprint:sha-256
D9:B5:31:EE:D5:88:EC:84:B7:D7:D6:C7:73:45:A3:09:3B:A4:32:0A:C0:B0:DC:28:56:4C:DB:03:22:0B:22:DE
a=ptime:20
a=ice-ufrag:ARYGxrUa
a=ice-pwd:jyP7JQCqLbW9wGFzL5ClW45SLj
a=ice-options:trickle
a=candidate:1wwouT4DYwT3ocfl 1 UDP 2130706431
2001:569:7eb9:a400:223:7dff:feb8:d2b4 35020 typ host
a=candidate:1wwouT4DYwT3ocfl 2 UDP 2130706430
2001:569:7eb9:a400:223:7dff:feb8:d2b4 35021 typ host
a=end-of-candidates
6:result2:oke
Notice from above --
Setting RTP profile for answer to debug via-branch=2 SDES-off ICE=force
UDP/TLS/RTP/SAVPF replace-session-connection replace-origin
DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid
rtcp-mux-required was passed to rtpengine but sdp from rtpengine did not
include it.
>From the caller web application
ac_webrtc.min.js:9 emit "peerconnection:setremotedescriptionfailed"
[error:DOMException: Failed to execute 'setRemoteDescription' on
'RTCPeerConnection': Failed to set remote answer sdp: The m= section with
mid='0' is invalid. RTCP-MUX is not enabled when it is required.]
>From rtpengine log
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",
[OpenSIPS-Users] Trouble with forked calls and rtpengine
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
