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.
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?
Actually the 32s window lies between Success and Completed states and between
Confirmed and Completed states depending on whether an ACK was received before 6
retransmissions or not. I don't think the loop back in green is required for the
Success state, however it is required for the Proceeding state. I think John
would be the best person to clarify this.
The RFC2543bis(-02) clearly states "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 until it reaches T2
seconds."
To my understanding what this implies is that the server does not need to
retransmit for duplicate requests when it is in the Success state (after having
transmitted the first final response). In this state the respose retransmission
is triggered off by timer expiry which caps off at T2 and nothing else. After 7
packet transmissions we know this is 15.5 s. Therefore the time between the first
and last transmission is not 32 s in this case.
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.
-Gaurav
>
>
>
>
> Cheers,
> Victor
>
> _______________________________________________
> 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
