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

From: [email-masked]
Date: Wed, 24 Apr 2002 16:12:54 -0400

Hi,

>Determining whether a response is a
>retransmission is actually hard, and not needed.

Is this true that a UAC doesn't need to determine whether a response is a
retransmission or not?
If so, wouldn't the UAC repeat the same processing for duplicate responses
which would impact performance, especially when the response includes SDP?

Thanks,
YoungSun

                    Jonathan                                                                 
                    Rosenberg              To:     [email-masked]                   
                    <jdrosen@dynami        cc:     [email-masked], (bcc: Youngsun              
                    csoft.com>             Song/Telcordia)                                   
                                           Subject:     Re: [Sip] Matching responses to      
                    04/10/02 12:59         transactions (error in 9th draft?)                
                    AM                                                                       

[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

_______________________________________________
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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 01:45:46 -0400

> which would impact performance, especially when the response includes

No, there wouldn't need to be a repeat of the same processing. The state
machine for the client transaction tells you whether you need additional
processing. If a response matches the transaction, and the transaction
is in the completed state, you resend the ACK - thats it. The state
machine does not tell you to pass the response up to the TU, so no
further processing occurs. 

-Jonathan R.