#384 B2B and CANCEL transaction

modules (454)

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.


  • Denis

    Denis - 2011-06-14

    cancel debug

  • Bogdan-Andrei Iancu

    • 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.


  • 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: = Opensips Proxy = Opensips B2BUA = Carrier

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

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

    U 2011/12/01 22:51:11.559527 ->
    CANCEL ............i...............i.. SIP/2.0.
    Via: SIP/2.0/UDP;branch=z9hG4bK5421.22999dd2.0.
    ........ CANCEL.
    User-Agent: OpenSIPS (1.7.1-notls (x86_64/linux)).
    Max-Forwards: 70.
    User-Agent: Opensips.
    Init-CallID: 40c30c6459b3eaa4683991082381cadb@
    Contact: <sip:>.

  • 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 = softphone = OpenSIPS 1.7.2 = 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.

  • Bogdan-Andrei Iancu

    • assigned_to: nobody --> bogdan_iancu
  • Bogdan-Andrei Iancu

    Investigating possible fixes

  • Bogdan-Andrei Iancu

    • priority: 5 --> 7
  • Bogdan-Andrei Iancu

    • milestone: 976384 --> trunk
    • status: open --> closed-fixed
  • Bogdan-Andrei Iancu

    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



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks