<div dir="ltr"><div>Good day John,</div><div>it looks like your own deduction is absolutely right!</div><div><br></div><div>If we talk about the SIP protocol in terms of RFC 3261, then I guess it's clear that the acknowledgement which has a To tag,</div><div>which is different from the previously defined one (in 200 OK) of the same dialog, should be essentially considered as out of the dialog request.</div><div>Which will not be correlated with the dialog is being established (the one in the early stage you are talking about).</div><div><br></div><div>So that, it's known - "Call-ID" + "To tag" + "From tag" gives us a full uniqueness of certain dialog/call branch (in your case it looks like it's only one branch though).</div><div>If you change at least a To tag in the subsequent request (in-dialog request) for the same dialog/call branch,<br>then the remote side will likely fail to match it to a needed dialog (transaction check).</div><div><br></div><div>Please see this section of RFC 3261 to understand the concept:</div><div><a href="https://tools.ietf.org/html/rfc3261#section-19.3">https://tools.ietf.org/html/rfc3261#section-19.3</a></div><div><br></div><div>I hope I was clear enough and you find my response useful.</div><div>Have a nice day!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 2, 2021 at 6:50 PM John Quick <<a href="mailto:john.quick@smartvox.co.uk">john.quick@smartvox.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Johan,<br>
Thanks for your comment, but in this instance the problem is something very subtle.<br>
OpenSIPS is acting as a Proxy, not as an endpoint. So the Contact header in the ACK contains the address of the UAC.<br>
OpenSIPS identified itself earlier in the dialog using the correct FQDN in the topmost Record-Route header of the INVITE request and using TLS with a certificate whose subject name matches the FQDN.<br>
<br>
Like I said, I have been able to put this ACK side-by-side with the ACK in a similar case where the call works correctly.<br>
Doing an A-B comparison, the only obvious difference I could identify was in the order of the headers.<br>
For example, the Route header is before the Via headers in one case and after in the other. I don't believe this is important.<br>
<br>
So then I looked at values in the 200 OK to see if they were the same in the ACK:<br>
The R-URI in the ACK is the same as the Contact in the 200 OK, including parameters.<br>
The From tag is identical in both<br>
The To tag in the ACK is not the same as the To tag in the 200 OK, but in my sip trace for a call that worked okay, the To tag did not get changed.<br>
<br>
My question is about the To tag. Should it be the same in the ACK as it was in the 200 OK?<br>
<br>
John Quick<br>
Smartvox Limited<br>
Tel:  +44-1727-221221<br>
<br>
<br>
> From: Johan De Clercq <<a href="mailto:Johan@democon.be" target="_blank">Johan@democon.be</a>> <br>
> Sent: 02 February 2021 14:42<br>
> To: John Q <<a href="mailto:john.quick@smartvox.co.uk" target="_blank">john.quick@smartvox.co.uk</a>>; OpenSIPS users mailling list <<a href="mailto:users@lists.opensips.org" target="_blank">users@lists.opensips.org</a>><br>
> Subject: Re: [OpenSIPS-Users] To-tag value in ACK<br>
><br>
> is contact an fqdn ? <br>
> If not, look no further. <br>
<br>
<br>
_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr"><font style="background-color:rgb(255,255,255)" color="#0b5394">Best regards,<br></font></div><div dir="ltr"><font style="background-color:rgb(255,255,255)" color="#0b5394">Donat Zenichev<br><br></font></div></div></div></div></div></div></div></div>