This is an interesting protocol feature interaction issue IMHO. I would expect the session timer logic within the UAC, in this case, to first check to see if any transactions are in progress (for the specific dialog) prior to performing the session refresh. After all, the reINVITE transaction will provide an indication of "session liveness". The two protocol features can be implemented without detail knowledge of each other and still provide the desired functionality and remain compliant with the corresponding specifications. The session refresh can occur after, or in conjunction with the reINVITE transaction.
I would say the UAC mustn't send the UPDATE in your scenario (that is, comply with the intent of the UPDATE spec). And, as the spec says, a UAS should send back a 500 with a Retry-After if an UPDATE is received while processing an INVITE for the dialog. Regards, Bert Sean Riley wrote: > I am considering the SIP Session Timer draft, where you can send an Update > without SDP (instead of Re-Invite with SDP) to perform the heartbeat. If the > UAC sends a Re-Invite with SDP (maybe because of call hold), and the Session > Timer fires at the UAC before the Re-Invite final response is received, I am > wondering what should happen. > > Should the UAC send the Update request? I suspect so. If so, should the UAS > send back a 500 with Retry-After as the SIP specification maybe suggests, or > should it respond with the 200 OK. Since it does not interfere with > offer-answer, then it should be ok, but as you said, that word "final > response" in the quoted string has me wondering. > > -----Original Message----- > From: Bert Culpepper [mailto:[EMAIL PROTECTED]] > 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
