As I understand it we are talking about 2 separate ideas. The presence of changed or unchanged SDP in a re-INVITE is not really anything to do with whether the request is a session refresh request or not. It is the presence of the Session-Expires header (and Min-SE if necessary) that indicates this. If these headers are present, it is a session refresh request, if not, any existing session timer should be cancelled. The offer/answer exchange is independent of this and should be implemented according to RFCs 3261 & 3264. The unchanged session version is used to indicate that the SDP is unchanged. Just because most of the time this will probably be the case with session refreshes, it does not mean that it has to be the case - i.e. a session refresh request may contain a new offer if it chooses but then the re-INVITE has 2 purposes - session refresh and SDP re-negotiation.
As I have recently implemented the session timer in our SIP offering any corrections to my understanding gratefully received. Regards Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Harmeet Singh Sent: 29 June 2006 08:18 To: Erez Morabia Cc: [email protected] Subject: Re: [Sip-implementors] re-INVITE without SDP / Session-Timers I was pointing out that Re-Invite for session refresh should contain SDP negotiated earlier with same orgin value. This should indicate to UAS that this is a session refresh request. Quoting text from rfc: The same is true for an answer exchanged as a result of a session refresh request; if it has not changed, that MUST be indicated. 200 Ok should contain SDP for sure. I think we are in perfect agreement here. Only point we probably have not agreed upon is if origin value in session refresh SDP is same previously negotiated SDP, does it serves the purpose of indicating that this is a session refresh request. Thanks - Harmeet Singh On 6/29/06, Erez Morabia <[EMAIL PROTECTED]> wrote: > > Even if the re-INVITE is intended for refreshing, you can not know if it > is NOT for offer/answer re-negotiation as well. As we can not ignore (or > break) what RFC3261 defines, I think agree with Nataraju - the OK > message should contain SDP. > > Thanks, > Erez > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Harmeet > Singh > Sent: Wednesday, June 28, 2006 5:37 PM > To: [email protected] > Subject: Re: [Sip-implementors] re-INVITE without SDP / Session-Timers > > Please Refer to Section 7.4 rfc 2408 > > It is RECOMMENDED that the UPDATE request not contain an > offer [4], but a re-INVITE SHOULD contain one, even if the details of > the session have not changed. In that case, the offer MUST indicate > that it has not changed. In the case of SDP, this is accomplished by > including the same value for the origin field as did previous SDP > messages to its peer. The same is true for an answer exchanged as a > result of a session refresh request; if it has not changed, that MUST > be indicated. > > I would interpret that this is indication strong enough that such a > invite > is intended for refreshing session-timer. All more so if, > Session-Expires > header is present. > > Thanks > - Harmeet Singh > > On 6/28/06, Frank Shearar <[EMAIL PROTECTED]> wrote: > > > > "Nataraju Basavaraju" <[EMAIL PROTECTED]> wrote: > > > > > Comments inline... > > > > > > Regards, > > > Nataraju A.B. > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] on behalf of Erez > Morabia > > > Sent: Tue 6/27/2006 9:01 PM > > > To: [email protected] > > > Subject: [Sip-implementors] re-INVITE without SDP / Session-Timers > > > > > > Hi, > > > > > > Suppose, after a session was established using the offer/answer > model, > > > one of the UAs sends a re-INVITE without SDP. > > > > > > According to RFC3261, Section 14.1 (Modifying an Existing Session / > UAC > > > Behavior): > > > > > > "...Of course, a UAC MAY send a re-INVITE with no session > description, > > > in which case the first reliable non-failure response to the > re-INVITE > > > will contain the offer (in this specification, that is a 2xx > response)." > > > > > > This means that the OK message should contain SDP with the offer. > > > > > > Moreover, suppose that the UA that sent the empty re-INVITE supports > > > Session-Timers. > > > > > > Is there any case where the other UA (the one that receives the > empty > > > re-INVITE) will issue an OK message without SDP? For example, > suppose it > > > supports Session-Timers as well and maybe knows that this empty > > > re-INVITE is just for refresh an not for re-negotiation. > > > > > > [ABN] As of now, the INVITE/re-INVITE transaction always perform > > offer/answer negotiation. If the intension was to refresh the > > session-timer, > > just put the same SDP which initial INVITE carried. > > > AFAIK, right now there is no way though some option or parameter > which > > can > > tell the recepient of re-INVITE can be sure that the particular > request is > > for session-refresh or SDP re-negotiation or BOTH. > > > > But in particular you would leave the version field in the SDP's > origin > > unchanged, yes? > > > > frank > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > > -- > ---------------------------------------------------- > Harmeet Singh > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > -- ---------------------------------------------------- Harmeet Singh _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
