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 <[email protected]> on behalf of Ben Newlin <[email protected]> Date: Monday, November 25, 2024 at 10:02āÆAM To: OpenSIPS users mailling list <[email protected]> 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 <[email protected]> on behalf of Alex Balashov <[email protected]> Date: Monday, November 25, 2024 at 7:07āÆAM To: OpenSIPS users mailling list <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > Does anyone have any thoughts or input on this? > > > > Thanks > > > > Regards, > > Jason > > > > On Mon, 18 Nov 2024 at 10:20, nz deals <[email protected]> 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 > > [email protected] > > 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 > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users> > _______________________________________________ > Users mailing list > [email protected] > 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
