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
