Sani, What I meant was a 200 ;). If you got a 200 for an intremediate invite (which was not the regular refresh invite and the one in which you added the session timer headers), that extends the timers. A regular 4xx (not a 422) does not figure in either the cancellation or extension of these timers, so your timer will keep running and not be reset/cancelled. When it expires, the last successful session desription would be used to send the refresh invite. This would not happen if a 200 came for an intermediate invite (which would have reset the timer).
----- Original Message ----- From: "Sani Tripathy" <[EMAIL PROTECTED]> To: "Medhavi Bhatia" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, July 25, 2002 2:32 PM Subject: RE: [Sip-implementors] SessionTimer survival after re-invite failure > > "I think the correct thing to do is to see if any of non-refresh > invites is able to refresh the session (only the 2xx). If not, > go ahead and send the refresh invite - which should succeed > anyway, as its identical to the original invite which set up the > session." > > What does only 2xx mean here? > If I interpreted your suggestion correctly, i.e. whether any non-refresh > invite can perform the refreshing, then this was discussed before and the > response is in red as below: > The question is what happens to the timer on both the UAs in this > case(received 4xx (408,488) to regular re-Invite with a refreshing purpose > as well)? When is the timer extended? > > > The refreshing Re-INVITE is sent every half of the the Session-Expiry > > timer. > > It is possible that just before the session expires, another > > re-INVITE(for > > codec change) may be sent for some other purpose. In that case,if we get > > a > > response we may restart the session timer instead of sending another > > re-invite for refreshing. > > Of course. That re-invite just needs to contain the appropriate session > timer headers and you can refresh the session. The spec does say that a > session refresh request is a regular request. > > > > > It may also be useful, if we can restart the Session-timer for each > > response > > or request received as the latest message solve the purpose of auditing > > (after the session timer negotiation). It will save from sending > > unnecessary > > messages(Re-INVITEs). > > Is it possible to do like this? > > Session refreshes are only performed by UPDATE and INVITE, not other > methods. > > -Jonathan R. > > > > ----- Original Message ----- > From: "Sani Tripathy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, July 25, 2002 12:43 PM > Subject: [Sip-implementors] SessionTimer survival after re-invite failure > > > > Suppose a session-timer of 30 minutes duration has been negotiated between > > two UAs. > > A session-expires value of 30 minutes was negotiated and UA1 is the > > refresher. > > UA1 starts a timer of value 15 minutes and UA2 starts a timer of value 30 > > minutes minus 10 seconds, as per the recommendations in the spec. > > > > Now 10 minutes after the first INVITE negotiation, UA1 sends a re-INVITE > > (not a timer refresh) to UA2 in order (to negotiate a codec change, put > > party on-hold etc.) and added the Session-Expires header with the same > value > > that was previously negotiated (30 minutes). > > > > For some reason, the re-INVITE was rejected with some 4xx/5xx response > > (something other than 408 and 481). > > What should the UAC do now? What happens to the previously negotiated > value > > of Session-Timer? > > As per my understanding, if the response to a re-INVITE with a > > Session-Expires header is not a 2xx with a session_expires header, the > > session timer is cancelled. Is this correct? > > > > If so, what should the UAC do to restore the session-timer? If it is a > 488, > > the UAC can retry with the originally negotiated SDP and succeed. If it is > > some other error, then what? > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Medhavi > > Bhatia > > Sent: Wednesday, July 24, 2002 11:12 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [Sip-implementors] SessionTimer behaviour for non-2xx (488) > > response to re-invite > > > > > > A refresh re-invite (identical in all respects to the original invite) > > should not receive a 488. You probably mean an actual re-invite > > which got used as a refresh re-invite. > > > > The solution would be to try the old invite to refresh the session again, > > and if it cannot be refreshed by a 2xx response, it will be terminated > > by either party. > > > > ----- Original Message ----- > > From: "Sani Tripathy" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, July 24, 2002 7:48 PM > > Subject: [Sip-implementors] SessionTimer behaviour for non-2xx (488) > > response to re-invite > > > > > > > I have following Session Timer related question: > > > > > > >From the following excerpts from section 10 of > > > draft-ietf-sip-session-timer-09, it seems session timer continues to run > > > even if a 422 is received. > > > "Note that only a 2xx response to a session > > > refresh request extends the session expiration. This means that a UA > > > could attempt a refresh, and receive a 422 response with a Min-SE > > > header field that contains a value much larger than the current > > > session interval. The UA will still need to send an session refresh > > > request before the session expiration (which has not changed), even > > > though this request will contain a value of the Session-Expires that > > > is much larger than the current session interval." > > > > > > > > > Scenario: Received non 2xx response to re-invite > > > How is the Session Timer managed when a non 2xx response to a refresher > > > re-invite is received/sent that does not terminate the call? > > > > > > In this case the the non 2xx response(e.g 488) does not terminate the > > call, > > > the call/session should continue. > > > > > > Only a 2xx response extends the session timer, then should a non-2xx > > > response terminate the session timer and re-negotiate it again. What > > should > > > be the actual behaviour? > > > > > > > > > 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 > > > > > > _______________________________________________ > > 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
