Dear Gaurav,
Hi. I'm still waiting for Jonathan for the confirmation
on whether we need the loop back (in green) back to the success
state.
>
> What the STD seems to suggest is that though the server has retransmitted 6 times
> (and that's all it can retransmit) it should not affect state transition to
> Completed state until 32 s have elapsed. This is inline with the fact that the
> server must retain state info. until 32 s after having sent the first definitive
> response. So time taken for 7 transmissions and the duration for which state
> info. is retained are disjoint activities.
Anyway, I forgot to add in my previous email that in rfc2543bis01,
in section 10.1.2, it is mentioned that
' the 32s window is given y the maximum retransmission duration of
200-class responses using the default timers,.... '
This statement is however not present anymore in bis02. So guess we need
confirmation again from Jonathan on this.
Actually one more question that came out of my mind last night when I
was going through SIP papers again. In Henning's slide presentation on SIP
page 32 (last updated August 2000), it is mentioned that for SIP INVITE
reliability, the request is retransmitted after 0.5,1,2,4,4,4,4
seconds. Also in the paper in IPTel2000 'Predicting Internet Telephony
CallSetup Delay' by Tony Eyers and Henning (page 4), it is mentioned that
an INVITE message is retransmitted until te first provisional response is
received, first after 500ms, then again after one additional second, then
two seconds and finally every four seconds'. Aren't both statements
incorrect (if I may say so), since I always thought that the
retransmission for SIP INVITE (according to my understanding from
rfc2543bis02) goes like this (0.5 + 1 + 2 + 4 + 8 + 16 = 31.5s). Please
correct me if I'm wrong.
Thanks
Victor
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
