Subject: [sipcore] REg. draft-ietf-sipcore-reinvite-04

From: Harbhanu <[email-masked]>
Date: Mon, 24 May 2010 11:10:43 +0530

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!

---

From: [email-masked]
Date: Mon, 24 May 2010 14:51:12 +0800

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

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].

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.

---

From: Harbhanu <[email-masked]>
Date: Mon, 24 May 2010 12:54:00 +0530

Honest thanks for a prompt reply.. That said, below are some clarifications
for your mail -

But then it might break the existing clause mentioned in RFC-4028, when the
scenario has INV(SE-600) & UPDATE(SE-1800),that –
“ The UAS MUST NOT increase the value of the Session-Expires header
field.”

>> So, I think it is not recommended to sending UPDATE as subsequent session
refresh request in pending INVITE/Re-INVITE.

I suggest to incorporate its clear handling in this draft itself, since
anyways it makes an excellent attempt to clear the muck around all the
refresh-request handling.

IMO this will make the draft a bit more comprehensive and might
baseline/standardize the behavior for other extension handlings.

Thanks again!

Regards,

Harbhanu

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, May 24, 2010 12:21 PM
To: Harbhanu
Cc: [email-masked]
Subject: Re: [sipcore] REg. draft-ietf-sipcore-reinvite-04 //Session Timer

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): 

Thanks, 

Gao 

2010-05-24 13:40 

收件人

[email-masked] 

抄送

主题

 

  

  

  
Thanks! 
  
Regards, 
Harbhanu 

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

---

From: [email-masked]
Date: Mon, 24 May 2010 15:59:20 +0800

Hi,

Harbhanu <[email-masked]> 写于 2010-05-24 15:24:00:

> Honest thanks for a prompt reply.. That said, below are some 
> clarifications for your mail -

Welcome.

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

> But then it might break the existing clause mentioned in RFC-4028, 
> when the scenario has INV(SE-600) & UPDATE(SE-1800),that –
field.”

What I suggest is about the potential extension. If people want to do the 
extension, it would be a UPDATE of RFC4028.

But by myself, I think there's no rational reason/use-case to do such 
extension, currently. If you have some, please share them with us.

> 
> >> So, I think it is not recommended to sending UPDATE as subsequent
> session refresh request in pending INVITE/Re-INVITE.
> I suggest to incorporate its clear handling in this draft itself, 
> since anyways it makes an excellent attempt to clear the muck around
> all the refresh-request handling.

Here, there are three things here:

1. Do people want to do such UPDATE for RFC4028? //By myself, I am not 
want to do such UPDATE, unless there's strong reason.

2. How would the UPDATE details be? //My suggestion is just informative.

3. Where should the UPDATE be, if people need it. //I'd like to talk the 
first two things fristly.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 17:34:24 -0400

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.

(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.)

	Thanks,
	Paul

[email-masked] wrote:
> 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):
> 
> should be as the SE value in the last embedded subsequent session 
> refresh request's 2xx.
> 
> *Harbhanu <[email-masked]>*
> 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].
>  
> 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!
> ------------------------------------------------------------------------
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 31 May 2010 12:11:38 +0200

Hi, 

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

Regards,

Christer

> > 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.
> > 
> > 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):
> > 
> > Then, the glare handling for such usage would be the same as the 
> > Target Refresh part in draft-ietf-sipcore-reinvite.
> > 
> > Thanks,
> > 
> > Gao
> > 
> > timer with 1800 or 600, or otherwise whether the UPDATE should be 
> > rejected.
> >  
> **********************************************************************
> > ***************** 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!
> > 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 May 2010 21:56:31 -0400

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

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