> So, if a UA receives Re-Invite with Session-Expires and Origin Value of SDP > is unchanged, do you think it is in complaince with SIP standards if SIP UA > takes it as pure session refresh reques?. I think rfc 4208 suggests same > origin-value in SDP to reduce processing overhead at SIP UA for session > refresh requests. I think with same intent they recommend UPDATE > (preferrably without SDP) over Re-Invite. >
[ABN] that is true, but assume if the remote party does not support UPDATE then you have to rely on re-INVITE only. Yes, if the remote party supports UPDATE, then its preferred to use UPDATE over re-INVITE for session-refresh operation. > - Harmeet Singh > > On 6/29/06, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > > > > Steve - IMO you have it quite right. People should stop trying to > > classify an invite as to whether it is a session timer refresh (doing > > nothing else) or some other change to the session. You just can't do > > that. When you receive an invite, you cannot discern *why* it was done, > > and it may have been done for multiple purposes. You must just react to > > what it conveys. > > > > Paul > > > > Stephen Paterson wrote: > > > 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
