Subject: Re: Provisional Response Draft (Was: SIP Supported Header)

From: [email-masked]
Date: Wed, 8 Mar 2000 10:42:49 +0530

I agree the algorithm is not complex - just that I was wondering does this
PRACK really require a special case of request response matching ? I am not
sure if we really gain much by having one response to many prov. responses
- are there practical cases where there are so may prov. responses in a
transaction that warrants a cumulative response to be specified ?

Regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems

igor> I think that processing cumulative PRACKs should be fairly
igor> straightforward: you just need to check the RAck value and stop
igor> retransmitting responses whose RSeq is lower or equal to the RAck you
igor> received. Accumulating PRACKs may be more tricky as you'd need to
take
igor> care not to linger too long as the other side might time out if it
does
igor> not see a PRACK within certain time interval. However, the draft does
igor> not require that you do such accumulation, you just need to be
prepared
igor> to receive PRACKs accumulated by someone else.

---

From: Igor Slepchin <[email-masked]>
Date: Wed, 08 Mar 2000 00:42:23 -0500

I think it's fairly hard to say at this time how widely reliable
provisional responses will be used and if there will appear any
widespread scenarios where such responses are sent in quick succession.
However, handling cumulative PRACKs seems to add little enough
complexity to keep them just in case they prove useful. I don't have a
very strong opinion on this, though. 

Also, note that you'll need special code to match PRACKs to responses
anyway; usual SIP call leg or request/response matching rules won't work
here.

---
Igor Slepchin