Thanks Brett for the information.
I have few more doubts on this:).
1) UAS restarts the session timer on receiving the UPDATE/reINVITE as a
session-refresh request once the call is established. However in case of early
dialog there is no session-timer running but a request has arrived at UAS
through UAC. In such a case (with SDP & 100rel & Session-Expires) is it valid
for UAS to honour the Session-Expires in the early UPDATE ( i.e., should UAS
renegotiate Session-timer)? Can it just not ignore the Session-Expires in early
UPDATE and send 200 OK for UPDATE without the including the Session-Expires
header?
[ I am still confused for this particular case. Please reconfirm even if
answered in previous mails. Actually the doubt is regarding inclusion of SE
header in 200 OK for early UPDATE]
2) In case of confirmed dialog if UAS gets UPDATE (but not, one more
reINVITE) with SE header while the UAS is processing reINVITE refresh request,
then should UAS send the 4xx-5xx response to such an UPDATE? [ As per the
discussion so far the answer to this question is NO. If it is otherwise please
let me know].
Thanks,
Praveen Dandin
Brett Tate <[EMAIL PROTECTED]> wrote:
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.
---------------------------------
Get the freedom to save as many mails as you wish. Click here to know how.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
