It could make implementation easier, if you rely on retransmissions. After
the first PRACK, a responder can just set up a retransmission automaton for
any additional responses. (I, however, follow the recommendation)
On the client side, I suppose you can just discard any out-of-sequence
reliable responses, relying on the fact that you will recognise a
retransmission when it does arrive in sequence. This saves storing and
managing out of sequence responses at the expense of potentially increased
traffic.
For maximum line efficiency, I reckon RPRs would have to be transmitted
immediately (except for the second one) and the client would have to store
and PRACK any out of sequence RPRs.
Barry Desborough
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 15 June 2001 13:50
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [Sip-implementors] 100 Reliablility...
Hi,
According to the 100rel-03 draft, a UAS may send
subsequent provisional responses (after receiving PRACK
for the first) without waiting for acknowledgements of
the previous RPR's. Sending RPR's in sequence (after each
is PRACK'ed) is only _RECOMMENDED_ in the draft.
This adds some complication to implementations. In
reality, will such a scenario occur often ? It would be
great if someone could cite some realistic example where
multiple RPR's would arrive in the above fashion. It would
help understand the necessity behind allowing the above
behaviour.
Best Regards,
Subhash.
_______________________________________________
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
