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