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?
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."
??
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).?
3) How can the above issue (2) be handled in case of early dialogs and
confirmed dialogs?
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].
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.
Thanks,
Praveen Dandin
Paul Kyzivat <[EMAIL PROTECTED]> wrote:
This isn't compatible with the current approach because in the current
approach *every* INVITE or UPDATE impacts the session timer, either by
renegotiating it or by turning it off.
Paul
Harsha. R wrote:
> Brett,
>
>> An outstanding session-expires mechanism should not prevent another from
>> occurring. However there is a potential for race conditions concerning
>> knowing if UPDATE sent/received prior to INVITE 200 response.
>
> Why cant this be addressed say using something like the SDP
> offer/answer semantics?
> a subsequent session refresh cant be made unless the previous request
> has been answered?
>
> Regards
> Harsha
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
---------------------------------
Bring your gang together - do your thing. Start your group.
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
