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
