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