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.
- 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.
So, was this reinvite a session timer refresh, or not?
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
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
