<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=us-ascii">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Yes, this is compliant as it occurs in cases of forked SIP messages. Each forked destination will respond with their own To tag. The client must be able to handle this. The UAC in your case is not compliant by using the original To tag
 value instead of the value in the 200 OK.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><span style="color:black">Ben Newlin </span><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<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 John Quick <john.quick@smartvox.co.uk><br>
<b>Date: </b>Wednesday, February 17, 2021 at 9:58 AM<br>
<b>To: </b>'OpenSIPS users mailling list' <users@lists.opensips.org><br>
<b>Subject: </b>Re: [OpenSIPS-Users] To-tag value in ACK<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">I took a fresh look at this case and found that the To-tag used in the ACK matches the To-tag that was in the first 180 Ringing.<br>
However, Teams has returned different To-tags in the 180 Ringing and in the 183 Session Progress and 200 OK.<br>
<br>
This appears to be common behaviour for Teams as I can see the same thing in the SIP trace for a completely different customer.<br>
<br>
Teams uses different To-tags when it responds to an INVITE as follows:<br>
SBC             <------>          Teams<br>
INVITE   --><br>
<--  100 Trying        no To-tag<br>
<--  180 Ringing        To-tag A<br>
<--  180 Ringing        To-tag B<br>
<--  180 Ringing        To-tag C<br>
<--  183 Sess.Prog.   To-tag D<br>
<--  200 OK               To-tag D<br>
<br>
Is this compliant with the RFC's?<br>
<br>
Unfortunately, the UAC used by my customer is responding to the 200 OK with an ACK that has To-tag A instead of To-tag D.<br>
<br>
John Quick<br>
Smartvox Limited<br>
<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></p>
</div>
</div>
</body>
</html>