subject:"Re\: \[OpenSIPS\-Users\] B2B logic with forked calls"

Re: [OpenSIPS-Users] B2B logic with forked calls

2022-01-03 Thread Bogdan-Andrei Iancu


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 >:


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
mailto: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
mailto: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:


Record-Route: 
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

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-12-22 Thread Denys Pozniak

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 :

> 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 :
>
>> 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 :
>>
>>> 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:
>>> 
>>> Record-Route: 
>>> 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" ;tag=3a8gNpgZQ89pj
>>> To: 
>>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>>> CSeq: 40949963 INVITE
>>> Contact: 
>>> 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" >> >;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" 
>>> Privacy: none
>>> Content-Disposition: session
>>> X-Call-ID:

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-12-21 Thread Bogdan-Andrei Iancu


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 >:


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
mailto: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:


Record-Route: 
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" mailto:sip%3A5009@192.168.27.123>>;tag=3a8gNpgZQ89pj
To: mailto:sip%3Aqq2s92mnbrda@192.168.27.84>>
Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
CSeq: 40949963 INVITE
Contact: 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
 -> 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" mailto:sip%3A5009@192.168.27.123>>;tag=94fd20254e546fee730f360cf9860800
CSeq: 40949964 INVITE
Call-ID: B2B.331.6374211.1631007510

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-12-21 Thread Denys Pozniak

Hello!

Any update?

вт, 14 дек. 2021 г. в 14:13, Denys Pozniak :

> 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 :
>
>> 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 :
>>
>>> 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:
>>> 
>>> Record-Route: 
>>> 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" ;tag=3a8gNpgZQ89pj
>>> To: 
>>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>>> CSeq: 40949963 INVITE
>>> Contact: 
>>> 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" >> >;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" 
>>> Privacy: none
>>> Content-Disposition: session
>>> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>>> Contact: 
>>>
>>> *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" ;tag=3a8gNpgZQ89pj
>>> To: 
>>> 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" >> >;tag=94fd20254e546fee730f360cf9860800

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-12-14 Thread Denys Pozniak

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 :

> 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 :
>
>> 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:
>> 
>> Record-Route: 
>> 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" ;tag=3a8gNpgZQ89pj
>> To: 
>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>> CSeq: 40949963 INVITE
>> Contact: 
>> 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" > >;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" 
>> Privacy: none
>> Content-Disposition: session
>> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>> Contact: 
>>
>> *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" ;tag=3a8gNpgZQ89pj
>> To: 
>> 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" > >;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))
>>

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-10-06 Thread Bogdan-Andrei Iancu


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 >:


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:


Record-Route: 
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" mailto:sip%3A5009@192.168.27.123>>;tag=3a8gNpgZQ89pj
To: mailto:sip%3Aqq2s92mnbrda@192.168.27.84>>
Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
CSeq: 40949963 INVITE
Contact: 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
 -> 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" mailto:sip%3A5009@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" mailto:sip%3A5009@192.168.27.123>>
Privacy: none
Content-Disposition: session
X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
Contact: http://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" mailto:sip%3A5009@192.168.27.123>>;tag=3a8gNpgZQ89pj
To: mailto:sip%3Aqq2s92mnbrda@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"

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-09-21 Thread Denys Pozniak

Hello!
Sorry, but I need help with this issue.

вт, 7 сент. 2021 г. в 14:14, Denys Pozniak :

> 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 :
>
>> 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:
>> 
>> Record-Route: 
>> 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" ;tag=3a8gNpgZQ89pj
>> To: 
>> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>> CSeq: 40949963 INVITE
>> Contact: 
>> 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" > >;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" 
>> Privacy: none
>> Content-Disposition: session
>> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
>> Contact: 
>>
>> *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" ;tag=3a8gNpgZQ89pj
>> To: 
>> 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" > >;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
>
>
>

-- 

BR,
Denys Pozniak
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] B2B logic with forked calls

2021-09-07 Thread Denys Pozniak

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 :

> 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:
> 
> Record-Route: 
> 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" ;tag=3a8gNpgZQ89pj
> To: 
> Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
> CSeq: 40949963 INVITE
> Contact: 
> 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"  >;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" 
> Privacy: none
> Content-Disposition: session
> X-Call-ID: 33e8140a-8a62-123a-e1ba-001dd8b71cb2
> Contact: 
>
> *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" ;tag=3a8gNpgZQ89pj
> To: 
> 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"  >;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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

Re: [OpenSIPS-Users] B2B logic with forked calls

8 matches

Site Navigation

Mail list logo

Footer information