Hi Attila, I completely agree with whatever you have written. But from your earlier mail, I felt you did not mention the important thing of "both operations have to use the same methods". Hence I added more details... Otherwise what you said is perfectly CORRECT.
Thanks & Regards, Nataraju A B > >> [ABN] see, here you wanted to perform session-refresh, but you could not > >> do without SDP (at least o= line in SDP). That is the issue which is > >> leading confusion for many. > >> > > > My main point is that using session timer does not change any > of the normal rules for reINVITE or UPDATE. So, for *ANY* reINVITE > you have to use SDP anyway (even if not in the reINVITE, you > have to use it in the 200 OK and ACK). So this does not change > anything about normal RFC3261 reINVITE operation. > > > I would like to stick the following into people's heads > regarding session timers: > > 1. There is NOTHING special about reINVITEs and UPDATEs when > using session timers. They still follow the rules as defined > in RFC3261 and RFC3311. > > 2. There is NOTHING special about the SDP when using session timers. > There is only a recommended behaviour but it is not the SDP which > is really important to session timers. > > 3. The most important things are the session timer headers in > the reINVITE and UPDATE. > > > Nataraju, I know you understand it but others have been confused. > And there may be reasons for their confusion but let's not > discuss those for now - just tell me if I've said anything wrong. > I'd like to know. > > > Regards, > > Attila > > > >> -----Original Message----- > >> From: Nataraju A B [mailto:[EMAIL PROTECTED] > >> Sent: 30 June 2006 10:44 > >> To: Attila Sipos; 'Dutt Kalapatapu'; 'Harmeet Singh'; 'Paul Kyzivat' > >> Cc: [email protected] > >> Subject: RE: [Sip-implementors] re-INVITE without SDP / > >> Session-Timers > >> > >> > >> Comments inline... > >> > >> Thanks & Regards, > >> Nataraju A.B. > >> > >> > -----Original Message----- > >> > From: Attila Sipos [mailto:[EMAIL PROTECTED] > >> > Sent: Friday, June 30, 2006 2:58 PM > >> > To: Dutt Kalapatapu; Nataraju A B; Harmeet Singh; Paul Kyzivat > >> > Cc: [email protected] > >> > Subject: RE: [Sip-implementors] re-INVITE without SDP / > >> Session-Timers > >> > > >> > > >> > > >> > >> 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) > >> > > >> > It is standard SIP RFC3261 behaviour to send > >> > "200 OK" if the session exists and "481" if not. > >> > > >> > The session timers RFC and the update RFC do not have any impact on > >> > the basic laws stated in RFC3261. > >> > > >> > > >> > > >> > > >> > I think some people are very confused about session timers. > >> > > >> > I don't know if I can help clear this up but I will try... > >> > > >> > 1. Session Timers has nothing to do with SDP, it has to do with > >> re-INVITE's > >> > and UPDATE's. That is the important thing. Forget > >> about SDP when > >> considering > >> > the session timer - Session timers don't care about SDP. > >> > (I know I've just said the same thing 3 times here but this > >> > had to be emphasised!) > >> > > >> [ABN] it's not about relation between session-timers and SDP > >> negotiation. But same methods(re-INVITE/UPDATE) were used to do the > >> different operation... which is leading to all the confusion. > >> > > >> > 2. When considering session timers, some people think > >> there are only 2 > >> kinds of > >> > INVITEs and UPDATEs. Some people think that they can either: > >> > a. refresh the session > >> > or > >> > b. update media (change SDP) > >> > > >> > As a result, some people think you must send separate > >> re-INVITEs or > >> UPDATEs > >> > for the session timer and seperate re-INVITEs and > >> UPDATEs for media > >> updates. > >> > This is very inefficient! > >> > > >> > However, you can also have: > >> > c. update the media AND refresh the session !! > >> > > >> > So, make use of all re-INVITEs and UPDATEs to carry your session > >> timer headers > >> > for you. Then the timer will get reset each time you do > >> an UPDATE > >> or > >> > re-INVITE. > >> > > >> > > >> [ABN] yes doing both the operation in a single method would be > >> efficient, but we don't have any alternative to do it > >> differently also. > >> I mean to say, you just can't refresh the session-timer without SDP > >> (atleast o= lien of SDP) when reINVITE used for session-refresh. > >> > >> > 3. If the session requires refreshing but the media does not, then > >> > send either: > >> > a. a reINVITE with SDP with the same version in the "o=" line as > >> before > >> > b. an UPDATE without SDP > >> > > >> > Now just because SDP is mentioned above, it does not > >> mean that the > >> > SDP is important for the session timer (The session timer would > >> > operate correctly even if you didn't use the recommended SDPs). > >> > The SDP is mentioned in the Session Timers RFC so that the most > >> > efficient way to refresh the session is explicitly stated. > >> > It is trying to tell you, if you don't want to update the media, > >> > then either: > >> > a. (with reINVITE) indicate that the media is the same as before > >> > b. (with UPDATE) indicate there is no media update > >> > > >> > In either case, you are making things more efficient because the > >> > receiver will know that it doesn't have to reprogram its media. > >> > > >> > > >> [ABN] see, here you wanted to perform session-refresh, but > >> you could not > >> do without SDP (at least o= line in SDP). That is the issue which is > >> leading confusion for many. > >> > >> If both UAC and UAS support UPDATE method, then using UPDATE (without > >> SDP) would be the best option for session-refresh with out > >> any confusion > >> between session-refresh and SDP negotiation... > >> > >> > Regards, > >> > > >> > Attila > >> > > >> > Attila Sipos > >> > Software Engineer > >> > www.vegastream.com > >> > > >> > > >> > > >> > >> -----Original Message----- > >> > >> From: [EMAIL PROTECTED] > >> > >> [mailto:[EMAIL PROTECTED] > >> Behalf Of Dutt > >> > >> Kalapatapu > >> > >> Sent: 30 June 2006 08:14 > >> > >> 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. > >> > >> > >> > >> 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 > > >> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
