inline.. Nataraju A B <[EMAIL PROTECTED]> wrote: 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) [Rama] If the reponse is some 4xx to a re-INVITE refresh (which means the other party has not accepted it,, not a 200 ok) what is the pt in waiting for the timer to expire and send BYE, rather than send it immediately. ----from 3261---- 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. ---- > > Thanks > - Harmeet Singh > > > > On 5/25/06, Paul Kyzivat 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 > > [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 --------------------------------- Do you Yahoo!? Next-gen email? Have it all with the all-new Yahoo! Mail Beta. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
