In case of UAC doing the refresh and sends an UPDATE without SDP to the UAS, what should UAS behave in this scenario, I am assuming that it will send a 200 OK without SDP if the session/dialog exist or send a 481 Call/Transaction does not exist on non existence of session/dialog (not considering all the error scenario's)
Is this assumption fine as the Session Timers RFC doesn't cover this behavior and UPDATE RFC doesn't cover session timers. Thanks Dutt Dutt Kalapatapu Veraz Networks -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nataraju A B Sent: Thursday, June 29, 2006 10:57 PM To: 'Harmeet Singh'; 'Paul Kyzivat' Cc: [email protected] Subject: Re: [Sip-implementors] re-INVITE without SDP / Session-Timers > 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
