[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05
Jonathan wrote, in part:
> You might still end up rejecting PRACK, which you'd generally prefer to
> avoid. My proposal is to incorporate Gonzalos suggestion.
Could I ask you to be a little more clear on the exact proposed change here.
I think I've heard two suggestions in Gonzalo's emails:
1) that the UAS be prohibited from sending an UPDATE until it has
received the PRACK from a 1xx containing an answer
2) that PRACK never contain an offer SDP (or was it any SDP?)
Point #1 is difficult, since answers contained in 200(Ok) to UPDATE
are not positively acknowledged. I believe the following two cases
should be considered identical:
--INVITE (offer)---> --UPDATE (offer)--->
X-183 (answer)--- X-200 (answer)---
<--UPDATE (offer)--- <--UPDATE (offer)---
-----491-----------> -----491----------->
Thus there will always be the case (lost 200 to UPDATE) where one
side thinks an offer is pending and the other thinks it has been
answered. Error 491 will resolve it. Forcing the UAS to wait for
the PRACK solves one but not the other.
While prohibiting an offer in a PRACK will work (but is an efficiency
tradeoff), we need to allow an answer to be in the PRACK when the
offer is contained in a 1xx reliable provisional response. Otherwise
we have UPDATEs with answers, and that is a mess.
As for the efficiency argument -- could someone from 3GPP state whether
offers are currently sent in PRACKs? If so, is it a problem to change?
Bill Marshall
wtm@research.att.com
-----original message-----
Date: Sun, 17 Mar 2002 23:30:21 -0500
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
To: William Marshall <wtm@research.att.com>
Cc: sip@ietf.org
Subject: Re: LC comment on update-01, was Re: [Sip] Question on manyfolks 05
William Marshall wrote:
>
> Gonzalo wrote:
> > A PRACK for a 1xx response that contained an answer can contain an
> offer
> > (as stated in the draft), because the UAS will not generate an UPDATE
> > until it receives the PRACK... therefore, in that situation, there is
> > not a chance of having a glare condition... it is OK as it is
> specified.
>
> I'm still a little confused about this. I don't see where the
> restriction
> is written that the UAS MUST NOT generate a new offer until its answer
> is acknowledged -- only that it send the answer before a new offer.
Right, this is not written at this time, although I believe it should
be.
>
> There are four separate drafts that interact in making the rules:
>
> in offer-answer-02, section 8
> At any point during the session, either participant MAY issue a new
> offer to modify characteristics of the session. ...
> in 2543bis-09, section 13.2.1
> If the initial offer is in an INVITE, the answer MUST be in a reliable
> non-failure message from UAS back to UAC which is correlated to that
> INVITE. ...
> in 100rel-06, section 5
> If the INVITE contained an offer, the UAS MAY generate an answer in a
> reliable provisional response. ... If the UAC receives a reliable
> provisional response with an answer, it MAY generate an additional
> offer in the PRACK. If the UAS receives a PRACK with an offer, it
> MUST place the answer in the 2xx to the PRACK.
> in update-01, section 6.1.1
> ... for the callee: If the UPDATE is being sent before the completion
> of the INVITE transaction, and the initial INVITE contained an offer,
> the UPDATE annot be sent unless the callee has generated an answer
> in a reliable provisional response, and has not sent or received
> other UPDATE requests containing offers that have not been answered.
>
> It seems to me that a perfectly valid sequence is
> --- INVITE (offer) --->
> <-- 183 (answer) ------
> --- PRACK (offer) \
> <-- UPDATE (offer) ----
> \--
> and at this point there is glare.
Correct.
>
> The 100rel draft now requires the UAS to respond to the offer in the
> PRACK with an answer in the 200 (OK).
>
> The nearest text which is close to this case is update-01 section 6.2.1
> If an UPDATE is received that contains an offer, and the UAS has
> generated an offer (presumably in an UPDATE of its own) to which it
> has not yet received an answer, the UAS MUST reject the UPDATE with a
> 491 response.
>
> This text in 6.2.1 should be generalized to cover this additional glare
> case, by requiring the UAC to respond to an UPDATE request with a 491
> if it has an outstanding offer pending in a PRACK. I'd suggest:
> If an UPDATE is received that contains an offer, and the receiver has
> generated an offer to which it has not yet received an answer, the
> UPDATE MUST be rejected with a 491 response.
You might still end up rejecting PRACK, which you'd generally prefer to
avoid. My proposal is to incorporate Gonzalos suggestion.
> An editorial nit in update-01, section 6.1.1 final paragraph should
> reference section 14.1 of RFC BBBB, not section 4.1.
Fixed.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PH: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip