Hi Arunachalem, The only thing that comes to mind is that although it may make sense to send an UPDATE to refresh a session timer while a reINVITE is in progress for some other reason, it complicates protocol implementation (and the protocol element itself). The "rules" specified in the UPDATE spec work for the problem of modifying media characteristics prior to a dialog reaching the confirmed state. This was the primary motivation for the UPDATE mechanism (and has wide applicability). It just so happens that folks found it can be applied to session timer refreshes as well, without modification to the mechanism. Allowing the scenario described in this message thread would require a "special case" be allowed in the UPDATE spec (and all implementations) when its not used for media session modification. This will complicate the the UPDATE mechanism, for little gain. Something the IETF does not do. There are all kinds of problems with this special case when the UPDATE does carry a session description. Folks tend to like the minimum number of rules.
Regards, Bert Arunachalam Venkatraman wrote: > 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 > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
