Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer

From: Christer Holmberg <[email-masked]>
Date: Tue, 1 Jun 2010 11:37:12 +0200

Hi, 

>>>I agree that there are issues with session-timer.
>>>
>>>Normally session-timer is simple, because it is negotiated anew with 
>>>each exchange. That works reasonably well for reINVITE and for UPDATE 
>>>outside of an invite transaction. Its a mess if an UPDATE within a 
>>>(re)INVITE transaction negotiates S-T. I think that needs to be 
>>>forbidden, which will be a revision to 4028.
>> 
>>That could be added to my "NEW DEAL" list of things which shouldn't be 
>>done within a re-INVITE :)
>> 
>>  
>>>(A reINVITE should not take so long that a session-timer will expire 
>>>before it is complete. Perhaps it should be specified that *if* a 
>>>session-timer does expire while a reINVITE is in progress, that 
>>>expiration is ignored.)
>> 
>>I don't think one should try to do too many things with a single re-INVITE (or UPDATE) in the first place.
>> 
>>If you are going to perform a re-INVITE, which may take some time to finish, do you S-T refresh *before* that, in a 
>>separate transaction.
> 
>By current definition, you can't do this. Every reinvite and 
>every update renegotiates the session timer - either a new 
>timer value or else  the absence of a session timer. So if 
>you want to keep your session timer going you must respecify 
>it on each reinvite.

Yes.

But, if you first perform the session timer refresh, then I guess the chance of timer expiry is rather small, even if it takes a while for the subsequent re-INVITE to finish.

Regards,

Christer

>It will require a normative change to alter this.
> 
>The normative change I advocate is simply the one that says 
>an update within a reinvite transaction does not affect the 
>session timer. This however still has issues when there is 
>ambiguity as to whether the update is within the reinvite or not.
> 
> 	Thanks,
> 	Paul
> 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > 
> >> [email-masked] wrote:
> >>> Hi,
> >>>
> >>> Not like O/A usage and target refresh usage, there's no explicit 
> >>> definition of allowing subsequent session refresh request
> >> in embedded
> >>> requests(such as UPDATE during pending Re-INVITE). So, I
> >> think it is
> >>> not recommended to sending UPDATE as subsequent session refresh 
> >>> request in pending INVITE/Re-INVITE.
> >>>
> >>> I'd like to talk more about session timer. If people want 
> to do the 
> >>> semantics extension for session timer's to allow embedded 
> >>> requests(such as UPDATE during pending Re-INVITE), there's one 
> >>> suggestion way(INFORMATIVE at all):
> >>>
> >>> Do it like target refresh, then the 2xx of
> >> INVITE/Re-INVITE's SE value
> >>> should be as the SE value in the last embedded subsequent session 
> >>> refresh request's 2xx.
> >>>
> >>> Then, the glare handling for such usage would be the same as the 
> >>> Target Refresh part in draft-ietf-sipcore-reinvite.
> >>>
> >>> Thanks,
> >>>
> >>> Gao
> >>>
> >>> ===================================
> >>> Zip    : 210012
> >>> Tel    : 87211
> >>> Tel2   :(+86)-025-52877211
> >>> e_mail : [email-masked]
> >>> ===================================
> >>>
> >>>
> >>> *Harbhanu <[email-masked]>*
> >>> 发件人:  [email-masked]
> >>>
> >>> 2010-05-24 13:40
> >>>
> >>> 	
> >>> 收件人
> >>> 	[email-masked]
> >>> 抄送
> >>> 	
> >>> 主题
> >>> 	[sipcore] REg. draft-ietf-sipcore-reinvite-04
> >>>
> >>>
> >>> 	
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>  
> >>> 1. UE1 --- INVITE SE-1800 à UE2
> >>> 2. UE1 <--- 183 ------------------ UE2
> >>>  
> >>> 3. UE1 --- UPDATE SE-600 à UE2
> >>> 4. UE1 <--- 200 UPDATE -SE600 -- UE2
> >>>  
> >>> 5. UE1 <--- 200 INVITE SE-1800 -- UE2
> >>>  
> >>> Please refer the scenario above for handling of
> >> Session-Timer, (4028).
> >>> As per the Draft-ietf-sipcore-reinvite-04 section 4.5:
> >>> “  When checking for glare situations, UAs MUST treat every UPDATE
> >>>    request as if it contained an offer.  Additionally, UAs
> >> MUST treat
> >>>    the exchange of a 2xx response to an INVITE request and its
> >>>    corresponding ACK request as an offer/answer exchange.  
> >> Consequently,
> >>>    the rules regarding glare situations applicable to offer/answer
> >>>    exchanges are also applicable to those exchanges.”
> >>>  
> >>> Here, we are not able to conclude whether both UAs should
> >> run session
> >>> timer with 1800 or 600, or otherwise whether the UPDATE should be 
> >>> rejected.
> >>>  
> >>> As per my understanding this draft doesn’t **explicitly** mention 
> >>> anything about the Session-Timer, wherein there is an early
> >> negotiation.
> >>> Since 4028 also doesn’t
> >>> have any reference for early negotiation, so we suggest 
> that it can 
> >>> better be incorporated in the above mentioned 
> >>> draft[ietf-sipcore-reinvite-04].
> >>>  
> >>> Please share your opinion and do guide us incase any of the
> >> existing
> >>> RFC/active-draft already captures this.
> >>>  
> >>> Thanks!
> >>>  
> >>> Regards,
> >>> Harbhanu
> >>>  
> >>>
> >> 
> *********************************************************************
> >> *
> >>> ***************** This e-mail and attachments contain 
> confidential 
> >>> information from HUAWEI, which is intended only for the person or 
> >>> entity whose address is listed above. Any use of the information 
> >>> contained herein in any way (including, but not limited to,
> >> total or
> >>> partial disclosure, reproduction, or dissemination) by
> >> persons other
> >>> than the intended
> >>> recipient's) is prohibited. If you receive this e-mail in error, 
> >>> please notify the sender by phone or email immediately and
> >> delete it!
> >>>  _______________________________________________
> >>> sipcore mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >>>
> >>> --------------------------------------------------------
> >>> ZTE Information Security Notice: The information contained
> >> in this mail is solely property of the sender's organization. 
> >> This mail communication is confidential. Recipients named 
> above are 
> >> obligated to maintain secrecy and are not permitted to 
> disclose the 
> >> contents of this communication to others.
> >>> This email and any files transmitted with it are
> >> confidential and intended solely for the use of the individual or 
> >> entity to whom they are addressed. If you have received 
> this email in 
> >> error please notify the originator of the message. Any views 
> >> expressed in this message are those of the individual sender.
> >>> This message has been scanned for viruses and Spam by ZTE
> >> Anti-Spam system.
> >>>
> >>>
> >> 
> ---------------------------------------------------------------------
> >> -
> >>> --
> >>>
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >> _______________________________________________
> >> sipcore mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/sipcore
>