Subject: Re: [Sip] Matching responses to transactions (error in 9th draft?)

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 10 Apr 2002 00:59:13 -0400

[email-masked] wrote:
> 
> Section 17.1.3 of the 9th draft of the SIP specification states the
> following:
> 
> "A response that matches a transaction matched by a previous response is
> 
>  considered to be a restransmission of that response."
> 
> This statement is preceded by two "matching rules", one about a matching
> 
> branch parameter in the topmost Via header and one about a matching
> request method in the CSeq.
> 
> Suppose that multiple responses are sent as the result of an INVITE.
> E.g.
> first a 183 Trying, then a 180 Ringing and then a 200 OK. All of these
> would match with the request, but according to the above statement, the
> 180 Ringing and the 200 OK would seem to be regarded as retransmissions
> of the 183 Trying. This can surely not be the intention.

Nope. This is an error in the spec. I think the right thing is to strike
the sentence entirely. The state machines are correct as defined, based
on the matching rules as defined. Determining whether a response is a
retransmission is actually hard, and not needed. Its not just the same
response code, since the same response could come from different
downstream UA. Its not a combination of response code and tags, since
the same UA could generate multiple provisional responses of the same
type (two 183, each with a different RSeq). 

Thanks for pointing this out.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip