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