[OpenSIPS-Users] B2B logic with forked calls

Wed Dec 22 08:18:26 UTC 2021

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 <bogdan at 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 at f-proxy opensips]$ opensips -V
> version: opensips 3.2.3 (x86_64/linux)
>
>
> ср, 6 окт. 2021 г. в 12:18, Bogdan-Andrei Iancu <bogdan at 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.pozniak at 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 at 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 at 192.168.27.123>;tag=3a8gNpgZQ89pj
>>> To: <sip:qq2s92mnbrda at 192.168.27.84>
>>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>>> CSeq: 40949963 INVITE
>>> Contact: <sip:mod_sofia at 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 at 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 at 192.168.27.126:5060
>>> From: "VOIP" <sip:5009 at 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 at 192.168.27.123>
>>> Privacy: none
>>> Content-Disposition: session
>>> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>>> Contact: <sip:5009 at 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 at 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 at 192.168.27.123>;tag=3a8gNpgZQ89pj
>>> To: <sip:qq2s92mnbrda at 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 at 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 at 192.168.27.123
>>> >;tag=94fd20254e546fee730f360cf9860800
>>> Call-ID: B2B.331.6374211.1631007510
>>> To: sip:qq2s92mnbrda at 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 at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
> --
>
> BR,
> Denys Pozniak
>
>
>
>

-- 

BR,
Denys Pozniak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20211222/8b81d490/attachment.html>