Jonathan wrote,
>>Lets say A and B are communicating. A sends a message M1 to B, and when B
>>receives this message, it responds with M2. Since M2 retransmits are
>>triggered by the receipt of M1, M1 must arrive in a timely fashion in order
>>to complete the transaction.
>>Its for this reason that non-INVITEs cap at T2; in that case, M1 is the
>>non-INVITE request, and M2 is the final response.
>>The situation also exists
>>for responses to INVITE. Here, though, M1 is the final response, and M2 is
>>the ACK.
Jonathan,
I was confused by the last part of your statement (The situation also....M2 is
the ACK.). Is my understanding correct that ACK following 200-600 Response are
not transmitted based on the timer expiry, but are retransmitted only if a
retransmission of the same response is received ?
Thanks
Ravi
Tekelec
Jonathan Rosenberg <[EMAIL PROTECTED]> on 05/29/2001 01:02:17 PM
To: "'Arunachalam Venkatraman'" <[EMAIL PROTECTED]>
cc: [EMAIL PROTECTED] (bcc: Ravi Ravishankar/Raleigh/TEKELEC)
Subject: [Sip-implementors] RE: Retransmission of reliable provisional response
> -----Original Message-----
> From: Arunachalam Venkatraman [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 18, 2001 9:26 PM
> To: Jonathan Rosenberg
> Cc: [EMAIL PROTECTED]
> Subject: Retransmission of reliable provisional response
>
>
> Jonathan
> RFC2543 specifies in Section 10.5.1 that a server should
> retransmit a final
> response with an interval that starts at T1 seconds and
> doubles after each
> subsequent packet until the response has been transmitted 7 times.
>
> RFC2543bis-02 specifies in Section 10.3.1 that a server
> should retransmit a
> final response with an interval that starts at T1 seconds and
> doubles for
> each subsequent packet until it reaches T2 seconds.
>
> Why was this change made? Just curious for the rationale.
Lets say A and B are communicating. A sends a message M1 to B, and when B
receives this message, it responds with M2. Since M2 retransmits are
triggered by the receipt of M1, M1 must arrive in a timely fashion in order
to complete the transaction.
Its for this reason that non-INVITEs cap at T2; in that case, M1 is the
non-INVITE request, and M2 is the final response. THe situation also exists
for responses to INVITE. Here, though, M1 is the final response, and M2 is
the ACK.
>
> The 03 version of the PRACK draft references the RFC 2543 and
> specifies that
> the retransmit interval be doubled until 96 seconds have
> elapsed from the
> first transmission. This makes a total of 9 transmissions (8
> retransmissions).
> Some questions on this -
> 1. Why such a large value of 96 seconds was chosen when the
> final response
> for INVITE itself completes in 32 seconds?
Just to add some buffer time to deal with very delayed PRACKs. This does
need to align better with bis, which says a total of seven messages. In that
case, a total of 32s elapses between the first provisional response and the
last. Thus, the timeout should be some value larger than 32s, say 40s. I'll
change that.
> 2. Why is the retransmission of the provisional response in
> the 03 draft of
> 100rel modeled on the RFC2543 and not the technique proposed
> in the bis02?
In this case, PRACK retransmits are *not* triggered by retransmits of the
provisional response, so that scenario above doesn't apply.
> 3. Will the 100 rel draft be revised to match the bis02 or
> later version of
> the RFC?
It needs to be updated with different timeout values, but it will not follow
the new bis02 behavior for final response retransmission caps of T2.
>
> I also suggest that Section 7 explicitly specify that it refers to
> Retransmission Interval Computation for Reliable provisional
> Responses (not
> PRACK) although this can be inferenced from the context.
OK, I fixed that.
Thanks,
Jonathan R.
---
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
