praveen dandin wrote:
> Hi all,
> One more query is added to the list of queries as compared to previous
> mail:)
>
> */praveen dandin <[EMAIL PROTECTED]>/* wrote:
>
> 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?
IMO the issues you raise were not considered during the development of
session timer, and it doesn't really address them. As a result there are
some ambiguities.
Session Timer was first specified a very long time ago, I think before
3261. But it also wasn't completed for a long time. It was retrofitted
with support for UPDATE before it became an RFC, but a lot of these
issues weren't appreciated.
As a result, we can speculate on the best way to handle these things,
but it may require a new RFC, or at least a BCP, to have any confidence
that these things work.
Normally in such a case I would just recommend that you try to avoid the
situation. Unfortunately its not really possible to avoid in this case.
In particular, if you start a session timer negotiation in an initial
invite, and then need to use UPDATE for additional o/a negotiation
before completion of that invite, then you can't really avoid this.
> 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."
> ??
Note that this isn't just a matter of whether UAC is using
Session-Expires. (IMO there are no good reasons for it ever to do so.)
But a proxy in the middle may include S-E, which then presents the same
issues.
I do think the UAC and UAS need to do the negotiation in the UPDATE, but
also in the INVITE. They will have to work hard to ensure that the
values negotiated are consistent. It would be very messy if the UPDATE
and the INVITE negotiated inconsistent values. (E.g. one agreeing on a
value less than the minimum agreed to in the other exchange.)
> 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).?
You could try using a 491 response, even if there is no o/a in the
UPDATE. I'm not certain that is entirely kosher, but I think it is at
least within the *spirit* of the 491 response.
> 3) How can the above issue (2) be handled in case of early dialogs
> and confirmed dialogs?
I think there is nothing more here that I haven't mentioned above.
> 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].
Certainly a 4xx/5xx may be returned. But it might have broader
consequences, such as killing the whole session. 491 is probably the
best if going this way.
For instance, if the UPDATE is in an early dialog and is also being used
for o/a, then rejecting it might well cause the call to fail.
> 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.
Not that I know of.
> *6) Can Session-Expires be added in early UPDATE? If yes, then what
> is its purpose?*
AFAIK this has not been specified, in either a positive or negative way.
My gut reaction is that it would be best not to do so with an UPDATE
that falls during an INVITE, whether it was an initial INVITE or a
reINVITE. But that flies in the face of the general logic that says
every INVITE or UPDATE renegotiates the session timeer. Its complicated
no matter which way you go.
This is an area that seems deserving of a new draft.
Paul
> 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.
>
> <http://in.rd.yahoo.com/tagline_groups_2/*http://in.promos.yahoo.com/groups>
>
>
> ------------------------------------------------------------------------
> Bring your gang together - do your thing. Start your group.
> <http://in.rd.yahoo.com/tagline_groups_2/*http://in.promos.yahoo.com/groups>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
