Thank you for your response.
Section 16.10 says that a stateful proxy acts as an UAS for the CANCEL, so 8.2 applies. And 8.2.6 says that a tag MUST be added.
The text you quoted seems to be for responses forwarded upstream by a proxy.
So my question is still: What tag must be used for the CANCEL response?
My understanding is that a new tag, completely independent of any tag received in previous provisional responses received for the INVITE, should be generated and used.
Charles Eckel wrote:
Hi Marc,
Its close. According to RFC 3261, the 200 for the CANCEL should not have a tag.
1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response.
Cheers, Charles
Marc Petit-Huguenin wrote:
Hi,
Section 9.2 says that the To tag in a response to a CANCEL should be the same than the To tag in the response to the original request.
My understanding is that this rule only applies to an UAS, and not to a proxy, as a proxy can send multiple responses with different To tags.
Section 16.10 seems to support this, as it says that "[...] the element is acting as a user agent server as defined in Section 8.2." No words about reusing a previous To tag.
So my question is: Is this call-flow correct?
UAC Proxy | INVITE | |-------------->| | | | 100 tag=null | |<--------------| | | | 180 tag=a | |<--------------| | | | 180 tag=c | |<--------------| | | | CANCEL | |-------------->| | | | 200 tag=d | |<--------------| | | | 487 tag=a | |<--------------| | | | ACK | |-------------->| | |
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
