Thanks & Regards, Nataraju A.B. > -----Original Message----- > From: Dutt Kalapatapu [mailto:[EMAIL PROTECTED] > Sent: Friday, June 30, 2006 12:44 PM > To: Nataraju A B; Harmeet Singh; Paul Kyzivat > Cc: [email protected] > Subject: RE: [Sip-implementors] re-INVITE without SDP / Session-Timers > > 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. > [ABN] you are right, UPDATE is mainly used as a target-refresh request (but it can also carry the SDP). UPDATE without SDP, would do just the target-refresh (if the contact header value is different from that of one in initial INVITE request) and session-refresh operations.
> 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
