> This is an often discussed topic but there is something fundamental I
> dont understand after looking through previous threads.
>
> The SIP spec says that in order to match a request to
> a response (sec 14.3):
Okay, I'm guessing this should have been 1.4.3. Looks
about right, anyway.
> All responses to a request contain the same values in
> the Call-ID, CSeq, To, and From fields (with the possible addition of
> a tag in the To field (section 10.43)).
This is not wrong, although I'd be inclined to include
branch parameter (if it exists) of topmost Via, so
as to extend this to proxies and *dons The Hat Of Controversy*
forking UAs.
> However for the cancel:
>
> The Request-URI, topmost Via, Call-ID, To, the numeric part of CSeq
> and From header fields in the CANCEL request are identical to those
> in the original request being cancelled, including tags. This allows
> a CANCEL request to be matched with the request it cancels.
>
> My question is:
>
> 1. Why can the Transaction identifier for the cancel not be
> computed in the same way as for the response matching?
Because of what I wrote above. The definition in 1.4.3
isn't enough for a forking proxy.
> 2. Why does the entire CSeq field (not just the sequence number)
> get used to compute the Transaction identifier in section 14.3
> (i.e. does it matter if I just use the sequence number)?
Well, it depends. If it means you're going to match the
response to a CANCEL to the INVITE transaction being cancelled,
then you need the entire CSeq; i.e., it's just ensuring that
responses to CANCELs don't get misinterpreted as responses
to the associated transaction.
- Jo.
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
