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
