[OpenSIPS-Users] B2B logic with forked calls

Bogdan-Andrei Iancu bogdan at opensips.org
Tue Jan 4 07:26:12 UTC 2022


Hi Denys and A Happy New Year,

Let me check the pcap you PM'ed me.

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/22/21 10:18 AM, Denys Pozniak wrote:
> 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 
> <mailto: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  <https://www.opensips-solutions.com>
>     OpenSIPS eBootcamp 2021
>        https://opensips.org/training/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
>>
>>
>
>
>
> -- 
>
> BR,
> Denys Pozniak
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20220104/7ef1d436/attachment-0001.html>


More information about the Users mailing list