#384 B2B and CANCEL transaction

trunk
closed-fixed
modules (454)
7
2012-03-22
2011-06-14
Denis
No

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.

Discussion

1 2 > >> (Page 1 of 2)
  • Denis
    Denis
    2011-06-14

    cancel debug

     
    Attachments
    • assigned_to: nobody --> anca_vamanu
     
  • Anca Vamanu
    Anca Vamanu
    2011-06-20

    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

     
  • Anca Vamanu
    Anca Vamanu
    2011-06-20

    • assigned_to: anca_vamanu --> nobody
     
  • Ryan Bullock
    Ryan Bullock
    2011-08-23

    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.

     
  • Logan
    Logan
    2011-12-12

    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@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@192.168.1.137>;tag=as06eabdcd.
    Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
    To: "12125551212" <sip:12125551212@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@192.168.1.137>;tag=as06eabdcd.
    Call-ID: 40c30c6459b3eaa4683991082381cadb@192.168.1.137.
    To: "12125551212" <sip:12125551212@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@10.2.3.245sip:8884442222@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@192.168.1.137.
    Contact: <sip:192.168.1.145:5090>.

     
  • a719719
    a719719
    2012-03-05

    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.

     
    • assigned_to: nobody --> bogdan_iancu
     
  • Investigating possible fixes

     
1 2 > >> (Page 1 of 2)