[OpenSIPS-Users] To tag in the CANCEL issue

Mon Nov 25 15:33:37 UTC 2024

Sorry, what I said below about OpenSIPS CANCEL processing is correct except for the admittedly crucial part about the To-tag being present in the CANCEL to the Vendor client. I must have not had enough coffee yet. 😊

Alex is correct that the CANCEL will not ever have a To-tag. The RFC is explicit [1]:

The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags.

This means if the INVITE did not have a To-tag (which an initial INVITE could not) then the CANCEL can also not have a To-tag. The Vendor’s assertion that the CANCEL must have one because they provided one in their 1xx response is not correct.

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Ben Newlin <Ben.Newlin at genesys.com>
Date: Monday, November 25, 2024 at 10:02 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] To tag in the CANCEL issue
 EXTERNAL EMAIL - Please use caution with links and attachments

________________________________
CANCELs are hop-by-hop, which means if it is being processed correctly then OpenSIPS will consume the CANCEL from the carrier without a To-tag and generate a new CANCEL to the Cisco client with a To-tag. The issue is that you are not properly “consuming” the CANCEL in OpenSIPS but instead are simply forwarding it.

A CANCEL is considered a sequential request, so it must be passed through the TM module to check if it matches an existing transaction. Take a look at the TM docs for t_check_trans [1]. It provides a reference example of proper CANCEL handling.

[1] - https://opensips.org/docs/modules/3.5.x/tm.html#func_t_check_trans<https://opensips.org/docs/modules/3.5.x/tm.html#func_t_check_trans>

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Alex Balashov <abalashov at evaristesys.com>
Date: Monday, November 25, 2024 at 7:07 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>
Subject: Re: [OpenSIPS-Users] To tag in the CANCEL issue
 EXTERNAL EMAIL - Please use caution with links and attachments

Well, the vendor is just mistaken. ;-)

CANCELs are generated internally by the proxy, since they're a hop-by-hop construct. You're going to have a hard time influencing their content on that level. The vendor's suggestion is, quite frankly, ludicrous.

-- Alex

> On Nov 25, 2024, at 1:16 am, nz deals <nzdealshelp at gmail.com> wrote:
>
> Thanks Alex.
> I raised this issue with Vendor support, and their suggestion was to include the To-tag in the CANCEL request, given that the 180 Ringing and 183 Session Progress responses from the Cisco phone include To-tags. Based on their feedback, they believe the absence of the To-tag in the CANCEL might be contributing to the rejection with a 481 Call/Transaction Does Not Exist error.
> From my observations, my SBC adheres to SIP standards, but since this behavior aligns with Vendor's recommendation and might help address the issue, I wanted to explore this approach as a potential workaround.
>
> Regards,
> Jason
>
> On Mon, 25 Nov 2024 at 17:46, Alex Balashov <abalashov at evaristesys.com> wrote:
> Hi,
>
> Initial INVITEs do not ever have a To-tag. So, the initial INVITE didn't have a To-tag, not because of any quirk or eccentricity, but because initial INVITEs aren't supposed to have To-tags. If the initial INVITE being CANCEL'd doesn't have a To-tag, the CANCEL shouldn't have a To-tag. The CANCEL should not have a To-tag.
>
> I suspect your theory of why the CANCEL is being rejected by the Cisco phone is not correct.
>
> -- Alex
>
> > On Nov 24, 2024, at 10:42 pm, nz deals <nzdealshelp at gmail.com> wrote:
> >
> > Does anyone have any thoughts or input on this?
> >
> > Thanks
> >
> > Regards,
> > Jason
> >
> > On Mon, 18 Nov 2024 at 10:20, nz deals <nzdealshelp at gmail.com> wrote:
> > Hi Community
> > I’m encountering a strange issue with CANCEL requests in my opensips 3.4.2 setup. Here’s the scenario:
> >     • My carrier sends the initial INVITE without a tag in the To header, which I forward to a Cisco phone.
> >     • The Cisco phone responds with a 180 Ringing message, which includes a tag in the To header.
> >     • When I send a CANCEL request, my carrier does not include the tag in the To header, and as a result, OpenSIPS also forwards the CANCEL to the Cisco phone without the tag.
> > Because of this, the Cisco phone responds with a 481 Call/Transaction Does Not Exist error, and the call remains active on the phone without being canceled.
> > I’ve tried modifying the CANCEL request to include the tag in the To header, but I wasn’t able to modify because the initial INVITE doesn’t have a tag in the To header.
> > Has anyone experienced a similar issue or found a way to fix this? Any guidance would be greatly appreciated.
> >
> > Thanks
> >
> > Regards,
> > Jason
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: https://evaristesys.com<https://evaristesys.com>
> Tel: +1-706-510-6800
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com<https://evaristesys.com>
Tel: +1-706-510-6800

_______________________________________________
Users mailing list
Users at lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20241125/dbb26ce9/attachment-0001.html>