Ok, I understand this point now...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 ?
They will be the same if they are for the same dialog. If a proxy forks an initial INVITE (no to-tag) to multiple UASs, it is possible the UAC will see multiple 1xx responses with different to-tags (for different UASs). The CANCEL must must match the INVITE so that the proxy will fork the CANCEL to the same UASs.
and this one too...Once you receive a final response (200-OK), you can no longer CANCEL the INVITE because it has completed.
Ok, I did not though at the hop-by-hop aspect of 100 trying. Now I undesrtand I have a problem inCANCEL is for cancelling a pending INVITE transaction, not a dialog. One or more early dialogs might be terminated as a side effect of the CANCEL, but its purpose is to terminate the INVITE transaction. BYE is used to terminate a dialog (early or confirmed).
Also, 100 Trying responses do not have to-tags (because they are hop-by-hop), and the UAC can CANCEL the INVITE after receiving any 1xx response.
my UAS since I should be able to match the initial INVITE(and should not have toTag in 100, trying).
Note: when I receive the CANCEL, I already sent 200 ok (with toTag), and then, it means I have to keep both IDs (with and without toTag), ... this is not
very nice to implement.
In this case, you need to send BYE instread of CANCEL
Ok, everything is clear on the CANCEL now, thank you for your explanations.
Now, I STILL have a problem in PROTO Test-Suite: c07-sip since using ACK and /OR BYE. The client does not use
use the toTag for ACK and/or BYE, and I would be very happy if somebody from [EMAIL PROTECTED]
explain me how to do in order to actually use the teardown mechanism...
Regards, Thomas
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
