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