inline
Hi Paul/Harsha/Brett,
What I understood from the discussion is : If one
session timer negotiation is under process (received through INVITE ),
processing the another session timer offer received in UPDATE everytime
will affect the session-timer functionality of UAS. Is my understanding
correct?
[Brett] Yes; however it is also affected INVITE 200
response.
I have few more queries on this:
1) Suppose UAC sends INVITE with SDP offer and
Session-Expires value and receives SDP answer in 180. Now UAC sends
UPDATE with second SDP offer and Session-Expires header in it. Now if
UAS tries to send 200 OK for UPDATE with the SDP answer (for second
offer) without the Session-Expires does it not violate atomicity of
request processing as mentioned in section 8.2 of RFC 3261:
"
Note that request processing is atomic. If a request is
accepted, all state changes associated with it MUST be
performed. If it is rejected, all state changes MUST NOT
be performed."
??
[Brett] It does not violate the "atomic" rules that you
mention. And for clarity since you mention offer/answer stuff, the 180
with SDP must be sent using 100rel to avoid the UPDATE with SDP from
violating the offer/answer rules.
2) There is no mention of overlapping/ pending refresh
requests in the RFC 4028. How it should be handled? For example, what
should be done if an UPDATE is received while the another UPDATE refresh
request is under process at UAS ( when both requests have
Session-Expires values).?
[Brett] The answer is mostly within rfc3311 section 5.2.
For a glare type situation not specifically listed, responses like 491
or 500 with retry-after can be used although not required. Additionally
they are not needed if rfc4028 recommendations are followed.
3) How can the above issue (2) be handled in case of
early dialogs and confirmed dialogs?
[Brett] It UPDATE 200 response is returned, it is
handled per contents of the UPDATE 200 response.
4) Can UAS send the negative (4xx-5xx) response to the
UAC if it receives the UPDATE with Session-Expires in early dialog? [
here note that INVITE also requested session-timer by including the
Session-Expires header].
[Brett] As mentioned in prior emails, this is not a
reason to reject the UPDATE. However devices can reject whatever they
want to reject although they might not the like the interop/service
consequences.
5) Is there any RFC statement which says that "An
outstanding session-expires mechanism should not prevent another from
occurring." ?. If so, please let me know.
[Brett] No.
6) Can Session-Expires be added in early UPDATE? If yes,
then what is its purpose?
[Brett] It can be added to UPDATE basically anytime a
device chooses to add it. However what subsequently occurs is based
upon rfc4028, rfc3311, and rfc3261.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
