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.

Ben Newlin

From: Users <users-boun...@lists.opensips.org> on behalf of John Quick 
<john.qu...@smartvox.co.uk>
Date: Wednesday, February 17, 2021 at 9:58 AM
To: 'OpenSIPS users mailling list' <users@lists.opensips.org>
Subject: Re: [OpenSIPS-Users] To-tag value in ACK
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.
However, Teams has returned different To-tags in the 180 Ringing and in the 183 
Session Progress and 200 OK.

This appears to be common behaviour for Teams as I can see the same thing in 
the SIP trace for a completely different customer.

Teams uses different To-tags when it responds to an INVITE as follows:
SBC             <------>          Teams
INVITE   -->
<--  100 Trying        no To-tag
<--  180 Ringing        To-tag A
<--  180 Ringing        To-tag B
<--  180 Ringing        To-tag C
<--  183 Sess.Prog.   To-tag D
<--  200 OK               To-tag D

Is this compliant with the RFC's?

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.

John Quick
Smartvox Limited



_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to