Bert I see the issue with the portion of the UPDATE spec that Sean has raised -
"A UAS that receives an UPDATE before it has generated a final response to a previous UPDATE or INVITE on the same dialog MUST return a 500 response to the new UPDATE, and MUST include a Retry-After field with a Retry-After header field with a randomly chosen value between 0 and 10 seconds." This conflicts with the following - 5.1 Sending an UPDATE The UPDATE request is constructed as would any other request within an existing dialog, as described in Section 12.2.1 of RFC BBBB. It MAY be sent for both early and confirmed dialogs. Although UPDATE can be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be used instead. The reference to sending UPDATE within an early dialog conflicts with the previous statement about how UPDATE is unacceptable, to a UAS, within an INVITE. Of course, one cannot send an UPDATE when an offer/answer exchange is pending. But one could send an UPDATE to initiate a new offer within an INVITE , if no offer or answer is pending. Right? Separately, The UPDATE spec RECOMMENDS agianst the use of UPDATE outside of a dialog. But there have been separate exchanges in the list about why this is not applicable for a session timer and how UPDATE is preferable to re-INVITE for a session timer refresh. Also, the session-timer draft says - A re-INVITE generated to refresh the session is a normal re-INVITE, and an UPDATE generated to refresh a session is a normal UPDATE. If a UAC knows that its peer supports the UPDATE method, it is RECOMMENDED that UPDATE be used instead of a re-INVITE. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bert Culpepper Sent: Tuesday, August 20, 2002 1:07 PM To: Sanjay Sinha Cc: Sean Riley; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Clarification on aspect of Update method. I believe the use of the term "final" in the first sentence of the quoted text is in fact misleading. The document otherwise seems consistent in that UPDATEs must not be sent (nor received) while a offer-answer exchange is pending (as Sanjay alludes to). A "final" response is one that is >= 200 in SIP. As far as rules for when SDP is not present in an UPDATE, I don't recall any defined use of UPDATE with some other message body. Regards, Bert Sanjay Sinha wrote: > Sean, > > It's because for an INVITE with offer answer in 18x (with Prack) > completes that initial offer/answer exchange and the UAS can process new > offers in UPDATE. > > Sanjay. > > Sean Riley wrote: > >> The Update method specification (draft-ietf-sip-update-02.txt) says the >> following: >> >> "A UAS that receives an UPDATE before it has generated a final >> response to a >> previous UPDATE or INVITE on the same dialog MUST return a 500 >> response to >> the new UPDATE, and MUST include a Retry-After field with a Retry-After >> header field with a randomly chosen value between 0 and 10 seconds." >> >> This suggests to us that a UAC would not be able issue an Update request >> (and have it processed) before a response to a previously issued >> Invite or >> Re-Invite request was received. However, the same specification >> illustrates >> an Update within an initial Invite for the purposes of early media >> establishment. This appears to us as a contradiction. >> >> We suspect this rule requires clarification. We like to know what the >> rules >> are for nesting Updates within Invites and Re-Invites, including >> considerations for when SDP is included, or not included with the Update >> request. >> >> Thanks, >> Sean R. >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ 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
