[OpenSIPS-Devel] [ opensips-Bugs-3316230 ] B2B and CANCEL transaction

Thu Mar 22 17:03:20 CET 2012

Bugs item #3316230, was opened at 2011-06-14 05:51
Message generated for change (Comment added) made by bogdan_iancu
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3316230&group_id=232389

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
>Group: trunk
>Status: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: Denis (iskatel1)
Assigned to: Bogdan-Andrei Iancu (bogdan_iancu)
Summary: B2B and CANCEL transaction

Initial Comment:
Hello!
There are two proxies of version 1.6.4.-2 which has been installed on the same server.
One proxy (proxy1) using B2B “top hiding” and located in /usr/local/sbc and using one signaling port 
Another proxy (proxy2) is just SIP proxy and located in /usr/local/opensips1.6.4/ and using another signaling port
Both proxies using the same ip address of the server
Call flow:
some UA – proxy1 – proxy2 – some gateway
When UA generate CANCEL then proxy1 does some strange things with FROM or TO uri headers (you can see it in attachment).  Because of this proxy2 cannot parse CANCEL properly and transaction in proxy2 cannot be canceled.
I found that this problem appears when I use append_hf() to add some header in local route of the proxy1 before sending INVITE to proxy2. Without this adding problem disappears.

----------------------------------------------------------------------

>Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-03-22 09:03

Message:
Hi all,

This was fixed in trunk / 1.8.0 - backport is a bit hard to do , so better
consider upgrading to 1.8.0

Regards,
Bogdan

----------------------------------------------------------------------

Comment By: Bogdan-Andrei Iancu (bogdan_iancu)
Date: 2012-03-19 09:09

Message:
Investigating possible fixes

----------------------------------------------------------------------

Comment By: a719719 (a719719)
Date: 2012-03-19 03:32

Message:
The user-agent issue is unrelated to the mangeling of messages. Fix for
that was:
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&sortby=date&revision=8766

The fix for the mangeling of messages is related to
http://opensips.svn.sourceforge.net/viewvc/opensips?view=revision&sortby=date&revision=8003
if i understand the comment of anca_vamanu correct but i am not able to
write the patch.

Question to the other reporters of this problem; did you find a workarround
to use append_hf() with B2B?

----------------------------------------------------------------------

Comment By: a719719 (a719719)
Date: 2012-03-05 09:18

Message:
This bug is also present in version 1.7.2.

It can be reproduced with this configuration file:
http://pastebin.freeswitch.org/18579
192.168.178.2 = softphone
192.168.178.28 = OpenSIPS 1.7.2
192.168.178.29 = Asterisk

There are two problems:

1. Mangled ACK: http://pastebin.freeswitch.org/18580
This problem occurs every 5-15 calls. I have no idea what is triggering it
and why it doesn't happen every call.

2. Mangled CANCEL and default User-Agent header in the CANCEL:
http://pastebin.freeswitch.org/18581
Only in the CANCEL request the default User-Agent header is present. This
happens every call.
The mangled CANCEL message is quite rare and i have no idea what is
triggering it.

----------------------------------------------------------------------

Comment By: Logan (jimlogan)
Date: 2011-12-12 10:36

Message:
I'm seeing the same thing.

 Reference: 

192.168.1.146 = Opensips Proxy 
192.168.1.145 = Opensips B2BUA 
10.2.3.245 = Carrier 

U 2011/12/01 22:51:11.558887 192.168.1.146:5060 -> 192.168.1.145:5090 
CANCEL sip:9993512125551212 at 192.168.1.145:5090 SIP/2.0. 
Via: SIP/2.0/UDP 192.168.1.146;branch=z9hG4bK2df7.78db1d81.0. 
From: "James Logan" <sip:8884442222 at 192.168.1.137>;tag=as06eabdcd. 
Call-ID: 40c30c6459b3eaa4683991082381cadb at 192.168.1.137. 
To: "12125551212" <sip:12125551212 at 192.168.1.146>. 
CSeq: 102 CANCEL. 
Max-Forwards: 70. 
User-Agent: Opensips. 
Content-Length: 0. 
. 

U 2011/12/01 22:51:11.559378 192.168.1.145:5090 -> 192.168.1.146:5060 
SIP/2.0 200 canceling. 
Via: SIP/2.0/UDP 192.168.1.146;branch=z9hG4bK2df7.78db1d81.0. 
From: "James Logan" <sip:8884442222 at 192.168.1.137>;tag=as06eabdcd. 
Call-ID: 40c30c6459b3eaa4683991082381cadb at 192.168.1.137. 
To: "12125551212"
<sip:12125551212 at 192.168.1.146>;tag=3330ae74b9cf9aed85afbc9203dd6238-715f 
CSeq: 102 CANCEL. 
Server: B2BUA. 
Content-Length: 0. 
. 

U 2011/12/01 22:51:11.559527 192.168.1.145:5090 -> 10.2.3.245:5060 
CANCEL ............i...............i.. SIP/2.0. 
Via: SIP/2.0/UDP 192.168.1.145:5090;branch=z9hG4bK5421.22999dd2.0. 
........B2B.256.3572553sip:+12125551212 at 10.2.3.245sip:8884442222 at 192.168.1.1379120d3`.....p..i...........................................q.i............

........ CANCEL. 
User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)). 
Max-Forwards: 70. 
User-Agent: Opensips. 
Init-CallID: 40c30c6459b3eaa4683991082381cadb at 192.168.1.137. 
Contact: <sip:192.168.1.145:5090>. 

----------------------------------------------------------------------

Comment By: Ryan Bullock (rrb3942)
Date: 2011-08-23 13:08

Message:
I am having the same issue. If I apply any changes to an Invite generated
from the b2bua and then a CANCEL is sent from ua, the opensips b2bua ends
up doing odd things to the CANCEL requests that it generates.

When not applying changes to the Invite the subsequent CANCEL will be
properly formatted, although it does not appear to respect the User-Agent
string set in the configuration.

----------------------------------------------------------------------

Comment By: Anca Vamanu (anca_vamanu)
Date: 2011-06-20 09:37

Message:
Hi Bogdan,

This bug fix requires further work in tm module, in local_route processing,
so as to update the shortcuts in tm when lumps are applied for headers
also. The fix that was committed last week solved this problem only when
body lumps were applied. 
Unfortunately, I don't have time to work on this, so I have removed the
assignation to me for this bug report.

Regards,
Anca

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=3316230&group_id=232389