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
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to