Bert On the session timer item, I meant to say The UPDATE spec RECOMMENDS agianst the use of UPDATE outside of a early dialog (ie. on a confirmed dialog). I was not as clear below.
This seemingly conflicts with the recommendation in the session-timer draft. But, since session timer does not require user confirmation, there is no issue here. I brought this point up since session-timer was discussed in this thread. I believe it is OK to send an UPDATE for refreshing a session-timer (with no offer in the UPDATE) while a re-INVITE has been received. It does not make much sense to send an UPDATE,if a re-INVITE has just been sent, since the session-timer can be refreshed using the re-INVITE itself regardless of why it is sent. But I think it is still OK to send an UPDATE before the re-INVITE has not been reponded to, if the UPDATE has no offer and is being used only to refresh the session timer. I would like to learn if I am missing something here. -----Original Message----- From: Bert Culpepper [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 4:21 PM To: Arunachalam Venkatraman Cc: Sean Riley; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Clarification on aspect of Update method. Hi, my comments below... Arunachalam Venkatraman wrote: > 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. > I believe "final response" should be replaced with "response that creates an early or confirmed dialog" (or something of the sort). This would resolve the inconsistancy I feel exists with the wording used in the quoted paragraph of Section 5.2. Given this change, there is no conflict with 5.1, nor with the behavior described in the rest of the specification. > > 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? > I agree. > > 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. > I see no problem here (a session timer refresh only applies to existing dialogs), and would use UPDATE for timer refresh myself as it requires one less message for the transaction. Best regards, Bert > > -----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 > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
