Hello! Yes, that's right, the documentation did not indicate that TH should generate different Call-IDs for different incoming branches...
But now there is still an open question about the work of the B2B module. It just generates separate Call-IDs, but does not forward the SIP CANCEL message (I will share the trace in a private message). Happy upcoming holidays! вт, 21 дек. 2021 г. в 17:28, Bogdan-Andrei Iancu <bog...@opensips.org>: > Hi Denys, > > Doing TH with dialog does not provide you with different call-ids for each > branch. The TH (or changing) is done between in (caller) and out (callee) > sides. There is no doc stating that each branch will get a different > Call-ID (I hope :D). > > Best regards, > > Bogdan-Andrei Iancu > > OpenSIPS Founder and Developer > https://www.opensips-solutions.com > OpenSIPS eBootcamp 2021 > https://opensips.org/training/OpenSIPS_eBootcamp_2021/ > > On 12/14/21 2:13 PM, Denys Pozniak wrote: > > Hello! > > Bogdan, > I tested the combination of dialog + TH modules and found out that this > also does not work correctly if the incoming call was forked. > Outgoing legs have the same Call-ID and tag, although I would expect them > to be different. > > The configuration is exactly the same as in the > Documentation/Tutorials-Topology-Hiding > [root@f-proxy opensips]$ opensips -V > version: opensips 3.2.3 (x86_64/linux) > > > ср, 6 окт. 2021 г. в 12:18, Bogdan-Andrei Iancu <bog...@opensips.org>: > >> Hi Denys, >> >> Before diving into the B2B dark corners, I would strongly suggest to use >> OpenSIPS with dialog + topology hiding modules, rather than B2B. The B2B is >> not so friendly with parallel forking. >> >> And as time as you only need TH, dialog + TH is be best way to do it. >> >> Best regards, >> >> Bogdan-Andrei Iancu >> >> OpenSIPS Founder and Developer >> https://www.opensips-solutions.com >> OpenSIPS eBootcamp 2021 >> https://opensips.org/training/OpenSIPS_eBootcamp_2021/ >> >> On 9/7/21 2:14 PM, Denys Pozniak wrote: >> >> Adding a scheme of the current call-flow scenario maybe it is not >> completely clear from the previous message: >> >> FreeSWITCH --(1-call)--> Fork Proxy --(N-branches)--> SEMS --(N-calls)--> >> Edge Proxy ----> N-devices >> >> >> вт, 7 сент. 2021 г. в 12:57, Denys Pozniak <denys.pozn...@gmail.com>: >> >>> Hello! >>> >>> Our service delivery logic is as follows: >>> Each user has an internal extension, under which there are several >>> devices with their own identifier. >>> With an incoming call to such a subscriber, FreeSWITCH adds custom SIP >>> headers with these device identifiers. >>> Further on these fields the superior Proxy forks legs and then these >>> legs pass through the Sems to become completely separate calls. >>> >>> Now there is a task to replace Sems with OpenSIPS. >>> The script below works fine, but only if the incoming calls are not >>> forked >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *####### Routing Logic ######## route{ if (is_method("INVITE") && >>> !has_totag()) { b2b_init_request("top hiding"); exit; } >>> } route[b2b_logic_request] { b2b_pass_request(); exit; }* >>> >>> If there is a fork with an answer on some device, then OpenSIPS does not >>> forward the SIP CANCEL (Reason: SIP;cause=200;text="Call completed >>> elsewhere") to the rest and these devices keep ringing until timeout >>> (Reason: SIP;cause=480;text="NO_ANSWER") >>> Please help understand the nature of this behavior. >>> >>> version: opensips 3.2.2 (x86_64/linux) >>> >>> *Incoming SIP INVITE:* >>> 2021/09/07 11:38:30.737456 192.168.27.84:5060 -> 192.168.27.84:5080 >>> INVITE sip:qq2s92mnbrda@192.168.27.126:5060;transport=udp SIP/2.0 >>> Record-Route: >>> <sip:192.168.27.84;lr=on;ftag=3a8gNpgZQ89pj;did=8b.4a4;vst=AAAAAEcYQ0JfBhUaEEoOFQAAAAAAAAAAAAAJBjY-> >>> Record-Route: <sip:192.168.27.126;lr=on;did=8b01.a1d4> >>> Via: SIP/2.0/UDP >>> 192.168.27.84;branch=z9hG4bKcc18.ec9a363ccc70d07691e11293d160cca6.1 >>> Via: SIP/2.0/UDP >>> 192.168.27.126;branch=z9hG4bKcc18.accd8d8bac35ac66a172f6ce173c9a34.0 >>> Via: SIP/2.0/UDP >>> 192.168.27.123;received=192.168.27.123;rport=5060;branch=z9hG4bKavcjKF58g9D1e >>> Max-Forwards: 66 >>> From: "VOIP" <sip:5009@192.168.27.123>;tag=3a8gNpgZQ89pj >>> To: <sip:qq2s92mnbrda@192.168.27.84> >>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2 >>> CSeq: 40949963 INVITE >>> Contact: <sip:mod_sofia@192.168.27.123:5060> >>> Supported: timer, path, replaces >>> Allow-Events: talk, hold, conference, refer >>> Privacy: none >>> Content-Type: application/sdp >>> Content-Disposition: session >>> >>> *Outgoing SIP INVITE:* >>> 2021/09/07 11:38:30.737938 192.168.27.84:5080 -> 192.168.27.126:5060 >>> INVITE sip:qq2s92mnbrda@192.168.27.126:5060;transport=udp SIP/2.0 >>> Via: SIP/2.0/UDP 192.168.27.84:5080;branch=z9hG4bK6ddf.d88b07f2.0 >>> To: sip:qq2s92mnbrda@192.168.27.126:5060 >>> From: "VOIP" <sip:5009@192.168.27.123 >>> >;tag=94fd20254e546fee730f360cf9860800 >>> CSeq: 40949964 INVITE >>> Call-ID: B2B.331.6374211.1631007510 >>> Max-Forwards: 70 >>> Content-Length: 486 >>> User-Agent: OpenSIPS (3.2.2 (x86_64/linux)) >>> Content-Type: application/sdp >>> Supported: timer, path, replaces >>> P-Asserted-Identity: " VOIP" <sip:5009@192.168.27.123> >>> Privacy: none >>> Content-Disposition: session >>> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2 >>> Contact: <sip:5009@192.168.27.84:5080> >>> >>> *Incoming SIP CANCEL:* >>> 2021/09/07 11:38:33.593381 192.168.27.84:5060 -> 192.168.27.84:5080 >>> CANCEL sip:qq2s92mnbrda@192.168.27.126:5060;transport=udp SIP/2.0 >>> Via: SIP/2.0/UDP >>> 192.168.27.84;branch=z9hG4bKcc18.ec9a363ccc70d07691e11293d160cca6.1 >>> Max-Forwards: 66 >>> From: "VOIP" <sip:5009@192.168.27.123>;tag=3a8gNpgZQ89pj >>> To: <sip:qq2s92mnbrda@192.168.27.84> >>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2 >>> CSeq: 40949963 CANCEL >>> Content-Length: 0 >>> Reason: SIP;cause=200;text="Call completed elsewhere" >>> >>> *Outgoing SIP CANCEL by timeout (with 27 sec delay):* >>> 2021/09/07 11:39:01.100888 192.168.27.84:5080 -> 192.168.27.126:5060 >>> CANCEL sip:qq2s92mnbrda@192.168.27.126:5060;transport=udp SIP/2.0 >>> Via: SIP/2.0/UDP 192.168.27.84:5080;branch=z9hG4bK6ddf.d88b07f2.0 >>> From: "VOIP" <sip:5009@192.168.27.123 >>> >;tag=94fd20254e546fee730f360cf9860800 >>> Call-ID: B2B.331.6374211.1631007510 >>> To: sip:qq2s92mnbrda@192.168.27.126:5060 >>> CSeq: 40949964 CANCEL >>> Max-Forwards: 70 >>> Reason: SIP;cause=480;text="NO_ANSWER" >>> User-Agent: OpenSIPS (3.2.2 (x86_64/linux)) >>> Content-Length: 0 >>> >>> >>> >>> -- >>> >>> BR, >>> Denys Pozniak >>> >>> >>> >> >> -- >> >> BR, >> Denys Pozniak >> >> >> >> _______________________________________________ >> Users mailing >> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> > > -- > > BR, > Denys Pozniak > > > > -- BR, Denys Pozniak
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users