Re: [OpenSIPS-Users] To-tag value in ACK
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 on behalf of John Quick Date: Wednesday, February 17, 2021 at 9:58 AM To: 'OpenSIPS users mailling list' 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 Tryingno To-tag <-- 180 RingingTo-tag A <-- 180 RingingTo-tag B <-- 180 RingingTo-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
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 Tryingno To-tag <-- 180 RingingTo-tag A <-- 180 RingingTo-tag B <-- 180 RingingTo-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
Re: [OpenSIPS-Users] To-tag value in ACK
Thank you Donat. You have confirmed my suspicions. The reference to the section in the RFC is very useful. John Quick Smartvox Limited Tel: +44-1727-221221 > From: Donat Zenichev > Sent: 03 February 2021 09:57 > To: john.qu...@smartvox.co.uk; OpenSIPS users mailling list > > Cc: Johan De Clercq > Subject: Re: [OpenSIPS-Users] To-tag value in ACK > > Good day John, > it looks like your own deduction is absolutely right! > > 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, > 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. > Which will not be correlated with the dialog is being established (the one in > the early stage you are talking about). > > 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). > If you change at least a To tag in the subsequent request (in-dialog request) > for the same dialog/call branch, > then the remote side will likely fail to match it to a needed dialog > (transaction check). > > Please see this section of RFC 3261 to understand the concept: > https://tools.ietf.org/html/rfc3261#section-19.3 > > I hope I was clear enough and you find my response useful. > Have a nice day! > ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] To-tag value in ACK
Good day John, it looks like your own deduction is absolutely right! 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, 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. Which will not be correlated with the dialog is being established (the one in the early stage you are talking about). 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). If you change at least a To tag in the subsequent request (in-dialog request) for the same dialog/call branch, then the remote side will likely fail to match it to a needed dialog (transaction check). Please see this section of RFC 3261 to understand the concept: https://tools.ietf.org/html/rfc3261#section-19.3 I hope I was clear enough and you find my response useful. Have a nice day! On Tue, Feb 2, 2021 at 6:50 PM John Quick wrote: > Johan, > Thanks for your comment, but in this instance the problem is something > very subtle. > OpenSIPS is acting as a Proxy, not as an endpoint. So the Contact header > in the ACK contains the address of the UAC. > 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. > > 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. > Doing an A-B comparison, the only obvious difference I could identify was > in the order of the headers. > 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. > > So then I looked at values in the 200 OK to see if they were the same in > the ACK: > The R-URI in the ACK is the same as the Contact in the 200 OK, including > parameters. > The From tag is identical in both > 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. > > My question is about the To tag. Should it be the same in the ACK as it > was in the 200 OK? > > John Quick > Smartvox Limited > Tel: +44-1727-221221 > > > > From: Johan De Clercq > > Sent: 02 February 2021 14:42 > > To: John Q ; OpenSIPS users mailling list < > users@lists.opensips.org> > > Subject: Re: [OpenSIPS-Users] To-tag value in ACK > > > > is contact an fqdn ? > > If not, look no further. > > > ___ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Best regards, Donat Zenichev ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] To-tag value in ACK
Johan, Thanks for your comment, but in this instance the problem is something very subtle. OpenSIPS is acting as a Proxy, not as an endpoint. So the Contact header in the ACK contains the address of the UAC. 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. 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. Doing an A-B comparison, the only obvious difference I could identify was in the order of the headers. 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. So then I looked at values in the 200 OK to see if they were the same in the ACK: The R-URI in the ACK is the same as the Contact in the 200 OK, including parameters. The From tag is identical in both 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. My question is about the To tag. Should it be the same in the ACK as it was in the 200 OK? John Quick Smartvox Limited Tel: +44-1727-221221 > From: Johan De Clercq > Sent: 02 February 2021 14:42 > To: John Q ; OpenSIPS users mailling list > > Subject: Re: [OpenSIPS-Users] To-tag value in ACK > > is contact an fqdn ? > If not, look no further. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] To-tag value in ACK
is contact an fqdn ? If not, look no further. Op di 2 feb. 2021 om 15:06 schreef John Quick : > I am seeing a problem in calls made to MS Teams via OpenSIPS configured as > an SBC. > The usual INVITE, 180, 183, 200 OK sequence looks okay, but the ACK request > is not accepted by MS Teams. > When I say "not accepted", I mean an ACK is sent to the Teams Proxy, but > Teams responds after 30 seconds with BYE, reason is: > "Call Controller timed out while waiting for acknowledgement" > > I am able to compare the sip trace for the failing call with a very similar > call scenario on another Teams system that works. > The only explanation I can suggest is that the UAC did not use the same > value for the To-tag as it received in the 200 OK. > Could this explain why Teams is failing to match it against the previous > dialogue? > > John Quick > Smartvox Limited > Web: www.smartvox.co.uk > > > ___ > 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
[OpenSIPS-Users] To-tag value in ACK
I am seeing a problem in calls made to MS Teams via OpenSIPS configured as an SBC. The usual INVITE, 180, 183, 200 OK sequence looks okay, but the ACK request is not accepted by MS Teams. When I say "not accepted", I mean an ACK is sent to the Teams Proxy, but Teams responds after 30 seconds with BYE, reason is: "Call Controller timed out while waiting for acknowledgement" I am able to compare the sip trace for the failing call with a very similar call scenario on another Teams system that works. The only explanation I can suggest is that the UAC did not use the same value for the To-tag as it received in the 200 OK. Could this explain why Teams is failing to match it against the previous dialogue? John Quick Smartvox Limited Web: www.smartvox.co.uk ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
