<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:164177607;
mso-list-type:hybrid;
mso-list-template-ids:-1147113144 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">[1] - <a href="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</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Ben Newlin</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Users <users-bounces@lists.opensips.org> on behalf of Alex Balashov <abalashov@evaristesys.com><br>
<b>Date: </b>Monday, November 25, 2024 at 7:07</span><span style="font-size:12.0pt;font-family:"Arial",sans-serif;color:black"> </span><span style="font-size:12.0pt;color:black">AM<br>
<b>To: </b>OpenSIPS users mailling list <users@lists.opensips.org><br>
<b>Subject: </b>Re: [OpenSIPS-Users] To tag in the CANCEL issue<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt"> EXTERNAL EMAIL - Please use caution with links and attachments <br>
<br>
Well, the vendor is just mistaken. ;-) <br>
<br>
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.<br>
<br>
-- Alex<br>
<br>
> On Nov 25, 2024, at 1:16</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:11.0pt">am, nz deals <nzdealshelp@gmail.com> wrote:<br>
> <br>
> Thanks Alex.<br>
> 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.<br>
> 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.<br>
> <br>
> Regards,<br>
> Jason<br>
> <br>
> On Mon, 25 Nov 2024 at 17:46, Alex Balashov <abalashov@evaristesys.com> wrote:<br>
> Hi,<br>
> <br>
> 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.<br>
> <br>
> I suspect your theory of why the CANCEL is being rejected by the Cisco phone is not correct.<br>
> <br>
> -- Alex<br>
> <br>
> > On Nov 24, 2024, at 10:42</span><span style="font-size:11.0pt;font-family:"Arial",sans-serif"> </span><span style="font-size:11.0pt">pm, nz deals <nzdealshelp@gmail.com> wrote:<br>
> > <br>
> > Does anyone have any thoughts or input on this?<br>
> > <br>
> > Thanks<br>
> > <br>
> > Regards,<br>
> > Jason<br>
> > <br>
> > On Mon, 18 Nov 2024 at 10:20, nz deals <nzdealshelp@gmail.com> wrote:<br>
> > Hi Community<br>
> > I’m encountering a strange issue with CANCEL requests in my opensips 3.4.2 setup. Here’s the scenario:<br>
> > • My carrier sends the initial INVITE without a tag in the To header, which I forward to a Cisco phone.<br>
> > • The Cisco phone responds with a 180 Ringing message, which includes a tag in the To header.<br>
> > • 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.<br>
> > 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.<br>
> > 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.<br>
> > Has anyone experienced a similar issue or found a way to fix this? Any guidance would be greatly appreciated.<br>
> > <br>
> > Thanks<br>
> > <br>
> > Regards,<br>
> > Jason<br>
> > _______________________________________________<br>
> > Users mailing list<br>
> > Users@lists.opensips.org<br>
> > <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">
https://url.us.m.mimecastprotect.com/s/KLMlCn5NzWHG7G6mXC9fWHJ0Gsj?domain=lists.opensips.org</a><br>
> <br>
> -- <br>
> Alex Balashov<br>
> Principal Consultant<br>
> Evariste Systems LLC<br>
> Web: <a href="https://evaristesys.com">
https://url.us.m.mimecastprotect.com/s/Z4wyCo26OWCXrXKvDfzhOHpwgC1?domain=evaristesys.com</a><br>
> Tel: +1-706-510-6800<br>
> <br>
> <br>
> _______________________________________________<br>
> Users mailing list<br>
> Users@lists.opensips.org<br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">
https://url.us.m.mimecastprotect.com/s/KLMlCn5NzWHG7G6mXC9fWHJ0Gsj?domain=lists.opensips.org</a><br>
> _______________________________________________<br>
> Users mailing list<br>
> Users@lists.opensips.org<br>
> <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">
https://url.us.m.mimecastprotect.com/s/KLMlCn5NzWHG7G6mXC9fWHJ0Gsj?domain=lists.opensips.org</a><br>
<br>
-- <br>
Alex Balashov<br>
Principal Consultant<br>
Evariste Systems LLC<br>
Web: <a href="https://evaristesys.com">
https://url.us.m.mimecastprotect.com/s/Z4wyCo26OWCXrXKvDfzhOHpwgC1?domain=evaristesys.com</a><br>
Tel: +1-706-510-6800<br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
Users@lists.opensips.org<br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>