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?
Cheers,
Victor
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
