The RFC is not vague at all (see 9.1 Client Behavior):
The following procedures are used to construct a CANCEL request. 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 INVITE has no To tag and therefor CANCEL shall have no To tag.
-ovi
[EMAIL PROTECTED] wrote:
Hi,
Having somewhat of an interesting issue that appears to result from
vagueness of SIP RFC.
Issue is that if requester sent a SIP message and there is no ;tag on the
To: field, the UAS is supposed to add the tag and send it back, and
requester should use that value in all future references to this call.
Now, this causes problems in the following sequence of events, assuming
SER is doing stateful forwarding.
Requester SER UAS
INVITE->
<- 100 trying
INVITE->
<- 100 trying (with the new tag)
Now, note that at this point, the message with the new tag is 'consumed'
by ser, and requester remains oblivious to the new tag. (Yes, once 183
Ringing or OK comes through - requester will get the tag, but, if
requester needs to CANCEL the call, UAS requires the tag to be present -
and the CANCEL will fail).
So, what is the more appropriate thing to do?
Options as I see them:
a) I should make SER add a tag to the To: field if it is missing.
RFC is silent whether a proxy is allowed/required to add a tag to the To
field.
b) I should make SER do a stateless-forwarding of "100 Trying" messages.
This will result in client getting two acks (one stateful from SER, one
stateless from UAS), which I'm not sure is a correct thing.
Which one is the "right thing"?
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel
