Hi, thanks for your response,
Bob Penfield wrote:
The CANCEL must have the same to-tag as the INVITE, not the 1xx response.I don't understand this point, 1xx response and 2xx response have the same toTag since they are in the same dialog ...
aren't they ?
The ACK will have the same to-tag as the final response to the INVITE (usually 487 for a cancelled INVITE).
RFC 3261, Section 9.1 states: The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags.
The CANCEL tags match the INVITE tags so that all branches (forks) for the INVITE are cancelled. CANCEL is not used to terminate an early dialog. To terminate a specific early dialog, BYE is used (see section 15).
but I need to be more precise: my scenario is the following:
UAC ------------------> SENDS INVITE (with callid=A, fromTag=B, and no toTag) ----------------> UAS
UAS ------------------> ANSWER 100 TRYING, then 200 OK (200 ok, with CallId=A, fromTag=B, and toTag=C) --------------> UAC
at this step, my UAS created a session with dialogID=ABC
now, *my UAC* decides to cancel this dialog, (this is *not* the UAS which cancels),
as stated in 12.2.1.1:"
The tag in the To header field of the request
MUST be set to the remote tag of the dialog ID.
"
my UAC MUST use the toTag=C...
UAC ------------------> SENDS CANCEL (callID=A, fromTag=B, toTag=C) -----------> UAS
my UAS is then able to get back the dialogID=ABC and match the session(dialog) to be cancelled.
For me, this is a very classical sequence... and I still do not see how an UAC could send a cancel without using the toTag....
Thomas
Dear all,
I am testing a SIP UAS, and I am using the PROTO Test-Suite: c07-sip to test the robustness this UAS.
Since my UAS create SIP dialogs when receiving PROTO INVITE PDUs, I use the "Connection Teardown mechanism" proposed by c07-sip java client. see
http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html#appendix-a
This mechanism allows to send CANCEL, then ACK PDUs after receiving 1xx or 2xx response(s) from my UAS. Indeed, receiving CANCEL and ACK in my UAS, should free the dialog. However, as stated in section 12.2.1.1 of RFC 3261, a SIP UAC MUST send a CANCEL/ACK using the To Tag given in the 1xx or 2xx response.
My UAS, and any other 3261-compliant UAS I tested actually respond 1xx, or 2xx (OK) with a To Tag, but the teardown mechanism of Test-Suite: c07-sip Java client does NOT use this To Tag to send subsequent requests (CANCEL and ACK). Thus, the UAS is unable to match the dialog ID of the INVITE (since dialogID = fromTag + callId +toTag), and is unable to release any dialog. It means the teardown mechanism is completely unuseful to actually teardown sessions in a UAS,... unless I misunderstood something.
I would be very interested to know how implementors have used Test-Suite: c07-sip, and especially, how they succeeded in using the teardown mechanism to release sessions in a UAS. (This test was used at last SIP Interoperability event in International SIP 2004, If some people present at this event could explain me...)
Thanks for advance
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
