I don't know how to make this any clearer, but I will try:
All that session timer does is ensure that by time T there will be a reinvite or an UPDATE. It does not guarantee that there will ever be a reinvite whose sole purpose is to refresh the session timer. The recipients of the reinvite or update can't (and don't need to) tell if the reinvite was for the purpose of session timer refresh.
The presence of unchanged SDP in a reinvite does not convey any semantics about session timer - it means only that the sender chose not to change the SDP.
Conversely, the presence of changed SDP in a reinvite does not mean that the session timer is not to be refreshed.
It is quite possible that session timer is enabled, but that there are never any reinvites solely for the purpose of refreshing, because reinvites for other purposes occur with sufficient frequency to keep the timer refreshed.
And BTW, there is nothing magic about an unchanged o-line. All it really does is provide an optimized way of comparing the new SDP to the prior one. (If the two o-lines are equal it is presumed that the rest of the SDP is also equal.) Things should work eqaully well if the o-line changes but nothing else about the SDP does.
Paul
Uttam Kumar Sarkar wrote:
-----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 10:28 AM To: Uttam Kumar Sarkar Cc: 'Christer Holmberg (JO/LMF)'; 'Brett Tate'; 'Christina Zhao'; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] How to determine a Session Refresh Request (re-INVITE)?
Uttam Kumar Sarkar wrote:
If o-line of SDP has changed then it's for the session update. If the
o-line
has not changed in the re-INVITE since last session update then it's for
the
session timer re-INVITE.
Forget about session timer for a moment. Even without it, a UA in a dialog can send a reinvite with unchanged SDP at any time. This could be for a variety of reasons. Some that come to mind are:
- as a liveness check on the other end. Of course that is what
session timer is for too, but UAs can do it even without
session timer.
That is what is session timer. If it decides not to session timer re-INVITE, then it can send session update ( o-line's vesrion number will chnage)
- perhaps the sender has somehow forgotten the SDP of the other end and wants to get it again. (I admit this is a pretty lame excuse.)
Suppose we have a dialog between X and Y, session timer is enabled, and X is the refresher. The expected refresh time is TR.
At some earlier time T1 (T1 < TR) X becomes concerned that Y may be non-functional. (Perhaps X stops receiving media from Y.) In an attempt to verify this suspicion, and maybe recover from it, X sends a reinvite at time T1, including the unchanged SDP from the original invite. X includes a Session-Expires header to preserve the session timer.
Perhaps it happens that Y is a decomposed UA, using a separate media server. When it receives the reinvite, it does a diagnostic check on the media server and discovers a problem. So it assigns another media server, and then returns a response with a different SDP answer than was last used.
I think Y can change it's media. It's a response not a request.
So, was this reinvite a session timer refresh, or not?
Yes it's a response of session timer re-INVITE.
It doesn't matter. Either way, the recipient is under *no* obligation to also return unchanged SDP. What it can return is constrained only by RFC3264.
Paul
-----Original Message----- From: Christer Holmberg (JO/LMF) [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 26, 2004 2:31 AM To: 'Brett Tate'; 'Christina Zhao'; [EMAIL PROTECTED] Subject: RE: [Sip-implementors] How to determine a Session Refresh Request (re-INVITE)?
Hi,
You can indicate if any SDP information has been updated using the sess-version part of the SDP origin (o- line) parameter. It must be incremented if the SDP information has been updated.
Regards,
Christer Holmberg Ericsson Finland
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Brett Tate
Sent: 26. lokakuuta 2004 1:44
To: 'Christina Zhao'; [EMAIL PROTECTED]
Subject: RE: [Sip-implementors] How to determine a Session Refresh
Request(re-INVITE)?
Hi, I have another question regarding Session Timer:
If the refresher is uac, how can the uas determine the re-INVITE is for the purpose of session refresh? (assuming uas needs to tell the difference between a Session Refresh re-INVITE and other purpose re-INVITEs so that it can pursue different process. )
There could be re-INVITEs that are Target Refresh Request (RFC3261 12.2), and re-INVITEs that change SDP.
My idea is to determine by checking if the header part contains "Supported: timer", but I am not sure this condition is good enough.
SIP currently does not provide a very complete mechanism to communicate what
is trying to updated by a re-INVITE/UPDATE or what was successfully updated.
The receiver basically has to analyze the request for every header/body that
it willing to allow to be updated; and basically nothing should be updated
if a failure response is returned. The following thread provides a little
detail concerning the issue.
http://www1.ietf.org/mail-archive/web/sip/current/msg08077.html
Concerning your specific question, the RFC indicates that the origin line of
the SDP is used to indicate when the SDP changes. However a request to
update headers (Contact, Session-Expires, etcetera) and the SDP can occur at
the same time.
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
NOTE: This message, including any attachments, may include privileged, confidential and/or inside information. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it
from
your system. Thank you. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
NOTE: This message, including any attachments, may include privileged, confidential and/or inside information. Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
