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