Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 16 Mar 2006 23:33:19 +0100

Hi, 

> I went back over the 102 messages in this thread and
> did not hear any comments on my concrete proposals:
>
> - require RSeq to start at 1
	
>I do not understand how this really helps.  The queuing at UAS because
of 
>offer/answer rules (and ensuring dialog established) is still required.
And
>if I recall correctly, UPDATEs are now required instead of sending a
new
>offer within INVITE 18x/2xx.

>An offer or answer can only appear in INV/first rel18x or first rel
18x/PRACK.
>You can't have offers or answers in additional 18x responses, or with
my proposal PRACKs or PRACK responses. 
>The great simplification is that the UAS probably only needs to queue
at maximum a single response, and only if the FIRST 
>response (because it contains an offer or answer) is unacknowledged.

[CHH] What you say is not completely true. It IS said, that if the INV
does not contain an offer, the offer MUST come in the FIRST rel18x (a
rule I also think we should get rid of). But, if the INV does contain an
offer, it is nowhere said that the first rel18x must contain the answer.

>Are you wanting the UAC to queue out-of-order 18x's?
>
>No, the UAC just checks if an incoming provisional has a higher RSeq
than the last received RSeq.  The last received 
>provisional superceeds the previous ones.  (It does not affect the
offer/answer state). 

[CHH] This is similar to my proposal to indicate the first RSeq in the
INVITE. But, mandating the first value to be 1 is ok too.

> - only acknowledge the most recent provisional.
> if the UAS wants to send as new provisional that 
> completely replaces a previous one it can send
> immediately.  if the UAS wants to send a new
> provisional but wants acknowledgement of a previous
> one, it has to wait for the PRACK.
	
>I assume RSeq would still be checked so UAC is able to notice out of
order 
>provisional responses.

[CHH] What to you mean by "replace a provisional response"???

>It looks like this would impact the current offer/answer rules.  Are
you
>suggesting changes related to offer/answer within first 18x and/or
>subsequent 18x's?
>
>Even today, you cannot start a subsequent offer/answer exchange in a
subsequent 18x, so I'm not suggesting any new 
>offer/answer rules. 

[CHH] I agree that you should not be able to carry additional
offer/answers in subsequent 18x. However, as I said, I don't agree that
it is mandated to send an answer in the first rel18x, and I DO think we
should get rid of the rule by mandating an offer in the first rel18x (if
the INV didn't carry an offer).

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Mar 2006 14:16:39 -0500

> > I assume RSeq would still be checked so UAC is
> > able to notice out of order provisional responses.
> 

My interpretation is that the UAC no longer has to follow the rfc3262
requirement to drop 1xx responses which incremented by more than 1.  And if
the contents of the prior 1xx must not be ignored, the UAS must queue
subsequent 1xx until prior one is acknowledged.  The text basically shifts
the MUST burden of ensuring no ignored 1xx's to UAS instead of the UAC.

> [CHH] <snip> and I DO think we should get rid
> of the rule by mandating an offer in the first 
> rel18x (if the INV didn't carry an offer).

(I assume "by" was not intentional within the above text.)

This is a common non compliance because of vendors deploying draft versions
of the 100rel functionality.  And vendors which supported 100rel and haven't
implemented/upgraded to rfc3262 are currently required to deactivate 100rel
to avoid non compliance to offer/answer usages.  

I agree that the MUST should be reduce to a SHOULD.  I think the text was
added for clipping and 183 type reasons; and there are other reasons for it.
The functionality is useful; however it disables the UAS from reliably
sending a 18x unless able/willing to adhere to the offer/answer
requirements.