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