<html xmlns:v="urn:schemas-microsoft-com:vml" 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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:0 0 0 0 0 0 0 0 0 0;}
@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.EmailStyle21
{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;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</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">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. </span><span style="font-size:11.0pt;font-family:"Apple Color Emoji"">😊</span><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>
<p class="MsoNormal"><span style="font-size:11.0pt">Alex is correct that the CANCEL will not ever have a To-tag. The RFC is explicit [1]:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:11.0pt">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.<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">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.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><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>
<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>
<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 Ben Newlin <Ben.Newlin@genesys.com><br>
<b>Date: </b>Monday, November 25, 2024 at 10:02</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>
<div>
<table class="MsoNormalTable" border="1" cellspacing="0" cellpadding="0" style="border-collapse:collapse;border:none">
<tbody>
<tr>
<td style="border:solid #B60000 1.0pt;background:white;padding:.75pt .75pt .75pt .75pt">
<p class="MsoNormal"><b><span style="font-size:12.0pt;font-family:"Calibri",sans-serif;color:#B60000"> EXTERNAL EMAIL - Please use caution with links and attachments <o:p></o:p></span></b></p>
</td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:Helvetica"><o:p> </o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:Helvetica">
<hr size="0" width="100%" align="center">
</span></div>
</div>
<div>
<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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Ben Newlin</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></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</span><o:p></o:p></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></span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>