> -----Original Message-----
> From: Gaurav Taneja [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, February 06, 2001 4:03 AM
> To: Victor Kueh
> Cc: Gaurav Taneja; Jonathan Rosenberg;
> [EMAIL PROTECTED]
> Subject: Re: [Sip-implementors] Question on reliability
>
>
>
>
> Victor Kueh wrote:
>
> > Dear Gaurav,
> >
> > > > received or the response has been transmitted seven times.
> > > >
> > > > Does that mean the response retransmission (0.5 + 1 + 2
> + 4 + 4 + 4 + 4 =
> > > > 19.5s) doesn't follow the 32s window?
> > >
> > > For reliable 2xx responses to INVITEs (not linked to the
> requests) it does
> > > not. Actually the window is 15.5 secs in this case since
> the max. number of
> > > packets transmitted is 7. Ideally speaking this should
> have been 16 secs.
> > >
> >
> > My mistake...I was doing the calculation according to the
> statement in
> > rfc2543bis01 where it is mentioned that 'the response has been
> > retransmitted seven times' instead of 'the response has
> been transmitted
> > seven times' in rfc2543bis02.
> >
> > However, what I still do not understand is that if you see
> Fig. 12. of
> > rfcbis02, there is still a 32s window between the success
> state to the
> > confirmed or confirmed state to the completed state.
> Actually I did asked
> > Jonathan R. many months ago about the 32 window, and he
> said the time
> > difference between the first and last final response sent
> by the UAS is
> > 32s. So what's the actual answer, 16s or 32s? If it is 16s,
> then Fig.12
> > has to be corrected, otherwise, if it 32 s, then the second
> paragraph of
> > 10.3.1 has to be corrected.
It is 16s now. Here is the story.
>From section 10.5.1 of rfc2543:
A server which transmits a provisional response should retransmit it
upon reception of a duplicate request. A server which transmits a
final response should retransmit it with an interval that starts at
T1 seconds, and doubles for each subsequent packet. Response
retransmissions cease when any one of the following occurs:
1. An ACK request for the same transaction is received;
2. a BYE request for the same call leg is received;
3. a CANCEL request for the same call leg is received and the
final response status was equal or greater to 300;
4. the response has been transmitted 7 times.
and from the matching paragraph in bis:
A server which transmits a provisional response should retransmit it upon
reception of a duplicate re-quest.
Aserver which transmits a final response should retransmit it with an
interval that starts at T1 seconds,
and doubles for each subsequent packet until it reaches T2 seconds. Response
retransmissions cease when
an ACK request is received or the response has been transmitted seven times.
The value of a final response
is not changed by the arrival of a BYE or CANCEL request.
Notice how in bis, the response timer doubles but caps at t2. Not the case
in rfc2543. I noticed this change myself recently. I believe Henning made
the change. My guess is that the reason has to do with the responsiveness in
the face of loss. Since ACK retransmissions are triggered by final
responses, the final responses can't slow down too much or it takes too long
to get an ACK. Its the same reason that non-INVITE requests cap off at T2;
response retransmissons are triggered on requests.
SO, doing the math, for rfc2543, seven packets contain 6 intervals between
them:
1/2 + 1 + 2 + 4 + 8 + 16 = 32s
And in bis:
1/2 + 1 + 2 + 4 + 4 + 4 = 16s
Its probably worth an annotation in this section to explain why this change
has been made (its backwards compatible), and where the 32 and 16 seconds
come from.
The implication is that the state machinery need only wait 16s (of course,
it can still wait 32s if it likes) if it implements the T2 cap.
>
> One more question of mine regarding the STD in Fig. 12 is why
> do we have a
> loop back (shown by green colour) to the success state with
> event 'INVITE'
> and message sent '2XX'. I thought that 2XX is ONLY
> retransmitted according
> to the timers rule (T1, T2) which is already accounted for by the loop
> back to the success state (shown by black colour) and not due to the
> reception of duplicate INVITE request?
No, even in success state 200 OK is retransmitted on a receipt of a
duplicate INVITE. This is to further enhance reliability. In most scenarios
it will never arrive, since a 1xx will have halted request retransmissions
before the final response is sent.
-Jonathan R.
---
Jonathan D. Rosenberg 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
[EMAIL PROTECTED] FAX: (973) 952-5050
http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
