Paul The issues can be solved, no doubt, in the manner you have described. I am wondering, though, if it will be useful to specify some guidance or rule in the specifications.
Sure, every UPDATE will carry session-timer info and its 200 OK will restart the timer. Sure, we can delay the sending of the UPDATE, if that is what the spec requires. All these have some implications in the imlementation and not having to do these have corresponding implications. For example, the UPDATE that is sent on Session-Expiry has a different meaning when it elicits a non-200 response than the UPDATE that fails when it is sent for a SDP negotiation. In one case, the timer has fired and the non-receipt of a 200 with timer headers indicates end of timer functionality. The non-200 received for the offer/answer UPDATE sent when a session timer is still running does not affect the session timer if it elicits a non-200 response. Only if it gets a 200 responses with session timer headers does the session timer get reset. Otherwise the timer continues to run and will eventually send a UPDATE on expiry. I agree that, unless the transport is reliable, it is not a good thing to send a request before the previous one has completed. Otherwise, the race condition may cause the first request to be rejected as "out of sequence". But this is not a issue with a reliable transport. Queueing up a request involves additional oversight of making a decision of whether other events have occured by the time it is possible to send it and how those events possibly preclude or modify the queued request. More possible race conditions to watch for and handle. Another thing that concerns me is that an UPDATE sent with Session Timer and SDP may fail due to a problem with the session timer or a problem in the offer. One failure can cause the request to fail on both counts. This implies that the UAC has to sort this out and decide if it should retry them separately? I have this sense that there is a lacuna here and the UPDATE and Session-Timer specs appear to be independent and not in synchrony. I am not totally convinced it is merely an implementation issue. Regards Venkat -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Kyzivat Sent: Thursday, September 26, 2002 4:57 PM To: Arunachalam Venkatraman Cc: Sani Tripathy; Sip-Implementors (E-mail) Subject: Re: [Sip-implementors] Processing Update without SDP when an Update is pending Sorry for the delay - I've been away. I believe the restriction to one UPDATE in progress at a time is necessary to guarantee that both parties in a dialog deterministically have a consistent understanding of what the state of the dialog is. I haven't thought it through carefully, but I suspect that if you start interleaving these you can end up with differences of opinion about the dialog state. You say the SDP-less UPDATE is different, but I don't agree. Of course it doesn't cause an offer/answer exchange. But both it and an SDP-carrying UPDATE do revise the session timer, so there is still a problem. I also don't understand why this is important to you. Any time you send an UPDATE to send an offer you should also use it to refresh the session timer. Then use an SDP-less UPDATE if you only need to refresh the session timer. I guess there may be a slight delay if you have initiated session timer refresh, and then discover that you need to send an offer. If so, you need to delay the sending of the offer until the refresh completes. But that should happen quickly. Beyond this, what is the issue? Paul Arunachalam Venkatraman wrote: > > Paul > As a UAC, > If an Update has been sent without SDP to refresh the timer and then another > even occurs before the 200 Ok to the Update has been received, that > necessitates an Offer-Answer negotiation, can another UPDATE be sent with an > SDP or should the request be queued pending the 200 OK to the previous > UPDATE? > > As a UAS, > is it expected to accept an Update with an SDP if there is no other offer > pending in either direction, but an Update is pending without SDP, for > refreshing the timer. The previous Update wihtout SDP may have been received > or sent by the UAS. > > Now, is it necessary to send a 500 with Retry-After if an Update with SDP is > received when a UPDATE without SDP has not been yet sent a final response? > Is it necessary to send a 500 with Retry-After if an Update without SDP is > received when a UPDATE with SDP has not been yet sent a final response? > > It seems pointless to send a 500 in the above cases because they do not > really pose a conflict. However, the UPDATE draft seems to recommend doing > this? > > I am wondering if the the UPDATE draft should be modified to accomodate the > use of UPDATE without SDP? > > As I see it, first the UPDATE draft was written to support offer-answer and > laid down rules assuming UPDATE will always carry a SDP, since it was > invented for that purpose. > Then Session-Timer draft was modified to allow UPDATE also for refreshing > timer. In this draft, two items appeared that is sort of at-odds with the > UPDATE spec. One is RECOMMENDING sending UPDATE for refresh and other is > without SDP and the other is RECOMMENDING not sending a SDP in that UPDATE. > > So, these give rise to questions above as well as Sani's questions. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Kyzivat > Sent: Wednesday, September 18, 2002 8:08 PM > To: Sani Tripathy > Cc: Sip-Implementors (E-mail) > Subject: Re: [Sip-implementors] Processing Update without SDP when an > Update is pending > > Sani, > > I don't think this is legal. But it also shouldn't be necessary. An UPDATE > without SDP is a good way to update the session timer if that is all you > need to do. But if you are sending an UPDATE for some reason you should take > the opportunity to use it to refresh the session timer as well. > > I posted a similar question about this some time ago but using reINVITE. > There was a response from Brett Tate, but no other discussion that I recall. > As I read the spec, I believe that an UPDATE or reINVITE that doesn't > mention the session timer actually causes the session timer to be cancelled, > leaving the session without a timer. But the language is sufficiently > obscure that it would be good to get a clarification. Brett agreed wrt > reINVITE. I have attached the older messages. > > Paul > > > Sani Tripathy wrote: > > > > My question is : Is it possible to send Update without any offer when a > re-invite or Update having an offer is pending? > > > > According to Session-Timer -- draft-ietf-sip-session-timer-09.txt, Update > is recommended to be used as the refresher request instead of a re-invite. > It is recommended that Update used for refresh should not have SDP. > > > > Update draft suggests that > > "if the UPDATE is being sent after the completion of the initial > INVITE transaction, > > it cannot be sent if the caller has generated or received offers in a > re-INVITE or > > UPDATE which have not been answered. " > > This is justified when Update is used only for offer-answer purpose, but > can be overridden while being used for session timer. > > > > Thanks, > > Sani > > > > > > > > _______________________________________________ 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
