Comments inline... Thanks & Regards, Nataraju A.B. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of Harmeet Singh > Sent: Thursday, June 29, 2006 12:07 PM > To: [email protected] > Subject: Re: [Sip-implementors] When to restart session timer?? > > Hi, > > I have another doubt regarding similar scenario; > > LOCAL REMOTE > <--------ESTABLISHED W/Session timer----> > > re-invite (refresh)----------> > <-----------4XX > > > Here, rfc 4028 says that any other failure response other than 408/ 481 > should be treated as directed in rfc 3261. > > My doubt here is upon getting failure response for session refresh, what is > the correct approach : > > 1. Local side waits for Session timer to expire and sends BYE. > 2. Local side sends BYE upon getting 4XX and kills the session timer. > [ABN] option 1 would be the correct one... (Assuming 4xx is other than 408/181) > > Thanks > - Harmeet Singh > > > > On 5/25/06, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > > > > > > Sweeney, Andrew (Andrew) wrote: > > > Thanks Paul, but the stack has stopped the old timer on the negative > > response so there is no timer running at all. Where/which RFC indicates that > > the old timer should still be running on a negative refresh response? > > > > Where is it that says the old timer should be stopped on the negative > > response? In general, if a reinvite fails then *everything* stays as it > > was - as if the reinvite was never done. (Except that CSeq has been > > updated.) > > > > I think the problem is your stack. > > > > Paul > > > > > Thanks > > > Andy > > > > > > -----Original Message----- > > > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, May 24, 2006 1:58 PM > > > To: Sweeney, Andrew (Andrew) > > > Cc: '[email protected]' > > > Subject: Re: [Sip-implementors] When to restart session timer?? > > > > > > > > > > > > > > > Sweeney, Andrew (Andrew) wrote: > > >> Sorry I should be more specific. > > >> > > >> If we send a re-invite and and get a negative response other than > > a 481, the spec says it is up to the app to keep decide on what to do with > > the call. At this time my reinvite timer is not automatically restarted but > > the original session is still up. If a BYE is sent from remote end now and > > it is lost the call will never get torn down because the refresh timer is > > not started. But the session timer spec seems to indicate that we only > > restart the timer on a final response of a 200 to the orignal refresh. > > > > > > I still don't see the problem. Presumably there is some proxy that > > > record-routed and needs this timer to know when/if to tear things down. > > > If your refresh failed, then the old timer keeps running until it > > > expires. That is true both for your UAC and for the proxy. When it > > > expires, the proxy will tear down whatever state it is responsible for. > > > And your UAC should do the same. It can send a BYE as well, but even > > > without it all is well. > > > > > > (And if there is no proxy that needs this there is no reason to use > > > session timer.) > > > > > >> I keep reading this and I know I am still not being clear. > > >> > > >> LOCAL REMOTE > > >> <--------ESTABLISHED W/Session timer----> > > >> > > >> re-invite (refresh)----------> > > >> <-----------480 > > >> > > >> Should the refresh timer start here? > > > > > > No. You can't restart the timer without mutual agreement to do so. The > > > old timer continues until it expires or a subsequent refresh request > > > succeeds. > > > > > >> <---BYE (lost) > > >> > > >> The problem is that the sip stack controls my session timer and my > > sip ack cannot restart it on a negative response. I want the stack to > > restart it. > > > > > > And it shouldn't. > > > > > > Paul > > > > > >> Andy > > >> > > >> > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > > >> Sent: Wednesday, May 24, 2006 11:55 AM > > >> To: Sweeney, Andrew (Andrew) > > >> Cc: '[email protected]' > > >> Subject: Re: [Sip-implementors] When to restart session timer?? > > >> > > >> > > >> Andrew, > > >> > > >> I don't get what is troubling you. It seems pretty clear to me that > > once > > >> a session timer is started, it should keep counting down until either > > it > > >> expires or another reinvite or update *completes*. If a reinvite or > > >> update completes, then any old timer is cancelled, and if the reinvite > > >> or update negotiated a new timer then it is started. Failed reinvites > > or > > >> updates don't affect an existing timer at all. > > >> > > >> Paul > > >> > > >> Sweeney, Andrew (Andrew) wrote: > > >>> Hi, > > >>> > > >>> I am trying to understand when a session timer should restart > > after a failed re-invite for session timer or re-invite for a transfer > > (updated SDP) > > >>> > > >>> The RFC's are not clear on this. > > >>> > > >>> Section 10 of RFC4028 is also quite clear about the session timer only > > being extended on receipt of a 2xx > > >>> response. > > >>> > > >>> But From 3261 section 14 > > >>> > > >>> During the session, either Alice or Bob may decide to change the > > >>> characteristics of the media session. This is accomplished by > > >>> sending a re-INVITE containing a new media description. This re- > > >>> INVITE references the existing dialog so that the other party knows > > >>> that it is to modify an existing session instead of establishing a > > >>> new session. The other party sends a 200 (OK) to accept the > > change. > > >>> The requestor responds to the 200 (OK) with an ACK. If the other > > >>> party does not accept the change, he sends an error response such > > as > > >>> 488 (Not Acceptable Here), which also receives an ACK. However, > > the > > >>> failure of the re-INVITE does not cause the existing call to fail - > > >>> the session continues using the previously negotiated > > >>> characteristics. Full details on session modification are in > > Section > > >>> 14. > > >>> .... > > >>> If a UA receives a non-2xx final response to a re-INVITE, the session > > >>> parameters MUST remain unchanged, as if no re-INVITE had been > > issued. > > >>> Note that, as stated in Section 12.2.1.2, if the non-2xx final > > >>> response is a 481 (Call/Transaction Does Not Exist), or a 408 > > >>> (Request Timeout), or no response at all is received for the re- > > >>> INVITE (that is, a timeout is returned by the INVITE client > > >>> transaction), the UAC will terminate the dialog. > > >>> > > >>> If a UAC receives a 491 response to a re-INVITE, it SHOULD start a > > >>> timer with a value T chosen as follows: > > >>> > > >>> 1. If the UAC is the owner of the Call-ID of the dialog ID > > >>> (meaning it generated the value), T has a randomly chosen > > value > > >>> between 2.1 and 4 seconds in units of 10 ms. > > >>> > > >>> 2. If the UAC is not the owner of the Call-ID of the dialog ID, > > T > > >>> has a randomly chosen value of between 0 and 2 seconds in > > units > > >>> of 10 ms. > > >>> > > >>> When the timer fires, the UAC SHOULD attempt the re-INVITE once > > more, > > >>> if it still desires for that session modification to take > > place. For > > >>> example, if the call was already hung up with a BYE, the re-INVITE > > >>> would not take place. > > >>> > > >>> The rules for transmitting a re-INVITE and for generating an ACK > > for > > >>> a 2xx response to re-INVITE are the same as for the initial INVITE > > >>> (Section 13.2.1). > > >>> > > >>> > > >>> Here is the section of RFC 4028 that says, UAC should retry > > session refresh if it receives an error response. > > >>> > > >>> If the session refresh request transaction times out or generates a > > >>> 408 or 481 response, then the UAC sends a BYE request as per > > Section > > >>> 12.2.1.2 of RFC 3261 <http://www.faqs.org/rfcs/rfc3261.html> > > [2]. If the session refresh request does not > > >>> generate a 2xx response (and, as a result, the session is not > > >>> refreshed), and a response other than 408 or 481 is received, the > > UAC > > >>> > > >>> SHOULD follow the rules specific to that response code and retry if > > >>> possible. For example, if the response is a 401, the UAC would > > retry > > >>> the request with new credentials. However, the UAC SHOULD NOT > > >>> continuously retry the request if the server indicates the same > > error > > >>> response. > > >>> > > >>> This seems to indicate to me that the session timer should be > > restarted for a failed re-invite. > > >>> > > >>> What is the recommended action. > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> Sip-implementors mailing list > > >>> [email protected] > > >>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > >>> > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > -- > ---------------------------------------------------- > Harmeet Singh > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
