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.
----- 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
