-----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
