[OpenSIPS-Users] B2B logic with forked calls
Bogdan-Andrei Iancu
bogdan at opensips.org
Tue Dec 21 15:28:17 UTC 2021
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
> <mailto: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 <https://www.opensips-solutions.com>
> OpenSIPS eBootcamp 2021
> https://opensips.org/training/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 <mailto: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
>> <http://192.168.27.84:5060> -> 192.168.27.84:5080
>> <http://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
>> <mailto:sip%3A5009 at 192.168.27.123>>;tag=3a8gNpgZQ89pj
>> To: <sip:qq2s92mnbrda at 192.168.27.84
>> <mailto:sip%3Aqq2s92mnbrda 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
>> <http://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
>> <http://192.168.27.84:5080> -> 192.168.27.126:5060
>> <http://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
>> <http://sip:qq2s92mnbrda@192.168.27.126:5060>
>> From: "VOIP" <sip:5009 at 192.168.27.123
>> <mailto:sip%3A5009 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
>> <mailto:sip%3A5009 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
>> <http://sip:5009@192.168.27.84:5080>>
>>
>> *Incoming SIP CANCEL:*
>> 2021/09/07 11:38:33.593381 192.168.27.84:5060
>> <http://192.168.27.84:5060> -> 192.168.27.84:5080
>> <http://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
>> <mailto:sip%3A5009 at 192.168.27.123>>;tag=3a8gNpgZQ89pj
>> To: <sip:qq2s92mnbrda at 192.168.27.84
>> <mailto:sip%3Aqq2s92mnbrda 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
>> <http://192.168.27.84:5080> -> 192.168.27.126:5060
>> <http://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
>> <mailto:sip%3A5009 at 192.168.27.123>>;tag=94fd20254e546fee730f360cf9860800
>> Call-ID: B2B.331.6374211.1631007510
>> To: sip:qq2s92mnbrda at 192.168.27.126:5060
>> <http://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 list
>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
>
>
> --
>
> BR,
> Denys Pozniak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20211221/68331ac7/attachment.html>
More information about the Users
mailing list