Subject: [Sip] Reg. session timer+earlyupdate

From: Harbhanu <[email-masked]>
Date: Tue, 18 May 2010 14:05:07 +0530

Hi,

We were unable to locate the specific behavior of session timer handling in
UA, for the following scenario:

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

6. UE1 -------------------------  BYE --> UE2

7. UE1 <--- BYE 200 ------------------ UE2

Here, UE1 sends a BYE since UE2(UAS) has increased the value of session
expires, which it MUST NOT (4028-Section-9, Page-16).

Please let me know whether this behaviour is correct or not.

Thanks in advance.

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: Brett Tate <[email-masked]>
Date: Tue, 18 May 2010 05:40:00 -0700

The UAS is compliant; thus sending BYE (because think UAS is acting incorrectly) is not correct behavior.  If the following is the section 9 snippet in question, notice that the dialog's previously negotiated session-expires value has no relevance; the "MUST NOT" is associated the header received within the request.  If you are referring to another "MUST NOT" (within this section or another), please send the paragraph.

"  If the UAS wishes to accept the request, it copies the value of the
   Session-Expires header field from the request into the 2xx response.

   The UAS response MAY reduce its value but MUST NOT set it to a

   duration lower than the value in the Min-SE header field in the

   request, if it is present; otherwise the UAS MAY reduce its value but

   MUST NOT set it to a duration lower than 90 seconds.  The UAS MUST

   NOT increase the value of the Session-Expires header field.
"

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harbhanu
Sent: Tuesday, May 18, 2010 4:35 AM
To: [email-masked]
Subject: [Sip] Reg. session timer+earlyupdate

Hi,
We were unable to locate the specific behavior of session timer handling in UA, for the following scenario:

Here, UE1 sends a BYE since UE2(UAS) has increased the value of session expires, which it MUST NOT (4028-Section-9, Page-16).

Thanks in advance.

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: Harbhanu <[email-masked]>
Date: Tue, 18 May 2010 19:13:38 +0530

May be your expectation is correct, but here the issue is in defining the
behavior of UA for the following scenario.

I will rephrase the issue.Which value should the UAC and UAS take for SE and
interval timer, when either of them is acting as refresher ? i.e.

1.	UAC refresher, then SE and refresh time for UAC and SE value at UAS?
2.	UAS refresher, then SE and refresh time for UAS and SE value at UAC?

Please consider the consistency of behavior incase there is a crossover of
2xx of UPDATE and that of INVITE.

***********

  _____  

From: Brett Tate [mailto:[email-masked]] 
Sent: Tuesday, May 18, 2010 6:10 PM
To: Harbhanu; [email-masked]
Subject: RE: [Sip] Reg. session timer+earlyupdate

The UAS is compliant; thus sending BYE (because think UAS is acting
incorrectly) is not correct behavior.  If the following is the section 9
snippet in question, notice that the dialog's previously negotiated
session-expires value has no relevance; the "MUST NOT" is associated the
header received within the request.  If you are referring to another "MUST
NOT" (within this section or another), please send the paragraph.

"

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harbhanu
Sent: Tuesday, May 18, 2010 4:35 AM
To: [email-masked]
Subject: [Sip] Reg. session timer+earlyupdate

Hi,

 

Thanks in advance.

Regards,

Harbhanu

---

From: Brett Tate <[email-masked]>
Date: Tue, 18 May 2010 07:19:12 -0700

Similar to many other of SIP RFCs, RFC4028 has race condition issues.  Thus the UAC, UAS, and proxies might not be in agreement concerning session-expires value, activation, and/or refresher.

Based upon RFC4028, it is basically the latest negotiated 2xx sent/received.  Within the call flow provided, the INVITE 2xx's Session-Expires value is latest.  However since there can be race conditions associated within UPDATE, UPDATE 2xx, and INVITE 2xx, the UAC, UAS, and proxies might not all be in agreement concerning which 2xx was the latest.

From: Harbhanu [mailto:[email-masked]]
Sent: Tuesday, May 18, 2010 9:44 AM
To: Brett Tate; [email-masked]
Subject: RE: [Sip] Reg. session timer+earlyupdate

May be your expectation is correct, but here the issue is in defining the behavior of UA for the following scenario.
I will rephrase the issue...Which value should the UAC and UAS take for SE and interval timer, when either of them is acting as refresher ? i.e.

Please consider the consistency of behavior incase there is a crossover of 2xx of UPDATE and that of INVITE.

***************************************************************************************
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: Brett Tate [mailto:[email-masked]]
Sent: Tuesday, May 18, 2010 6:10 PM
To: Harbhanu; [email-masked]
Subject: RE: [Sip] Reg. session timer+earlyupdate

Hi,

Thanks in advance.

Regards,
Harbhanu

---

From: Brett Tate <[email-masked]>
Date: Fri, 21 May 2010 09:53:07 -0700

Yes; draft-ieff-sipcore-reinvite-03.txt attempts to address some of the issues.  My favorite is the sections 3.5/4.5 text indicating to treat (from a glare perspective) UPDATE without SDP as though it contained an offer.  Thus if I understand correctly, an UPDATE without SDP SHOULD trigger 491 if step 1 contained offer SDP and step 3 was sent from UE2 to UE1.

Concerning your example (assuming step 1 contained offer SDP), I currently find the draft to be ambiguous concerning sending 491, 500, or 200.  The ambiguity relates to not having a precise definition of glare and some vendors preferring to send 491 instead of 500.

Concerning your example... yes; the UPDATE 2xx is allowed (even though potentially not following a SHOULD).  However at step 4, session-expires 600 becomes active; and at step 5 session-expires 1800 becomes active.

From: Harbhanu [mailto:[email-masked]]
Sent: Friday, May 21, 2010 10:07 AM
To: Brett Tate; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Sip] Reg. session timer+earlyupdate

Hi Brett,
I just came across an interesting draft in this regard - draft-ieff-sipcore-reinvite-03.txt. Please refer.
IMO this does attempt to address a lot of UPDATE-[re-]INVITE pain areas ...

AFAICU, as per this draft the UAS will take care of sending -
1. Either 2xx of INVITE and wait till its ACK for sending success response of UPDATE & might also send a 409...
2. Or 2xx of UPDATE before sending 2xx of INVITE.
Similarly, UAC also do have clearly defined expectations ...

That said, the UPDATE -2xx here is absolutely allowed and so does the INV 2xx...
Although not explicitly specified in this draft, but for the given scenario both UAC and UAS SHOULD run timer with value 600. Atleast UAC MUST.

Please correct me, if I am wrong. Thanks!

Authors of draft-ieff-sipcore-reinvite-03.txt: IMO this draft can consider this glare scenario as well, i.e. session timer, to make it more a comprehensive text.
Excellent effort anyways!!

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: Brett Tate [mailto:[email-masked]]
Sent: Tuesday, May 18, 2010 7:49 PM
To: Harbhanu; [email-masked]
Subject: RE: [Sip] Reg. session timer+earlyupdate

Hi,

Thanks in advance.

Regards,
Harbhanu

---

From: Harbhanu <[email-masked]>
Date: Fri, 21 May 2010 19:36:57 +0530

Hi Brett,

I just came across an interesting draft in this regard -
draft-ieff-sipcore-reinvite-03.txt. Please refer.

IMO this does attempt to address a lot of UPDATE-[re-]INVITE pain areas . 

1. Either 2xx of INVITE and wait till its ACK for sending success response
of UPDATE & might also send a 409. 

Similarly, UAC also do have clearly defined expectations .

That said, the UPDATE -2xx here is absolutely allowed and so does the INV
2xx.

Although not explicitly specified in this draft, but for the given scenario
both UAC and UAS SHOULD run timer with value 600. Atleast UAC MUST.

Authors of draft-ieff-sipcore-reinvite-03.txt: IMO this draft can consider
this glare scenario as well, i.e. session timer, to make it more a
comprehensive text. 

 

Regards,

Harbhanu

***********************************

  _____  

Similar to many other of SIP RFCs, RFC4028 has race condition issues.  Thus
the UAC, UAS, and proxies might not be in agreement concerning
session-expires value, activation, and/or refresher.

Based upon RFC4028, it is basically the latest negotiated 2xx sent/received.
Within the call flow provided, the INVITE 2xx's Session-Expires value is
latest.  However since there can be race conditions associated within
UPDATE, UPDATE 2xx, and INVITE 2xx, the UAC, UAS, and proxies might not all
be in agreement concerning which 2xx was the latest.

  _____  

"

Hi,

 

Thanks in advance.

Regards,

Harbhanu

---

From: Harbhanu <[email-masked]>
Date: Sun, 23 May 2010 13:04:15 +0530

>> Concerning your example... yes; the UPDATE 2xx is allowed (even though
potentially not following a SHOULD). 

Please let me know which 'SHOULD' clause is missed.

Although in the draft, it does mentions about failure response to re-INVITE,
but again the crossover of success response will make things murkier.

"If the UAC of a re-INVITE transaction sends an UPDATE request with an

   offer, receives a non-2xx response to the re-INVITE, and then a 2xx

   response to the UPDATE request, the UA SHOULD generate a new re-

   INVITE or UPDATE request in order to make sure that both UAs have a

   common view of the state of the session, as described in Section 3.4."

Here, I beg to disagree that UAC should run a timer value of 1800, since
then the sole purpose of this early refresh will be defeated. Although what
you just said is as per 4028, but as already discussed, it doesn't mention
anything about early negotiation of Session-timer and certainly not the
UPDATE/ INVITE glare. So 4028 will not suffice to standardize the behavior
here.

So, either the UPDATE should be *explicitly* disallowed and rejected with a
491 or it should be treated as a refresh request queued after the INVITE, to
be effective after the INVITE parameters takes effect and thus making both
run with SE value 600. 

Here, the basis of former behavior can be formed as - the INVITE is carrying
the 'offer', to negotiate the SE, and thus it disallows the generation of
UPDATE which too attempts to update the SE ('offer').

Please share your opinion.

***

  _____  

From: Brett Tate [mailto:[email-masked]] 
Sent: Friday, May 21, 2010 10:23 PM
To: Harbhanu; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Sip] Reg. session timer+earlyupdate

Yes; draft-ieff-sipcore-reinvite-03.txt attempts to address some of the
issues.  My favorite is the sections 3.5/4.5 text indicating to treat (from
a glare perspective) UPDATE without SDP as though it contained an offer.
Thus if I understand correctly, an UPDATE without SDP SHOULD trigger 491 if
step 1 contained offer SDP and step 3 was sent from UE2 to UE1.

Concerning your example (assuming step 1 contained offer SDP), I currently
find the draft to be ambiguous concerning sending 491, 500, or 200.  The
ambiguity relates to not having a precise definition of glare and some
vendors preferring to send 491 instead of 500.

Concerning your example... yes; the UPDATE 2xx is allowed (even though
potentially not following a SHOULD).  However at step 4, session-expires 600
becomes active; and at step 5 session-expires 1800 becomes active.

Cc: [email-masked]; [email-masked];
[email-masked]

Hi Brett,

 

Regards,

Harbhanu

  _____  

  _____  

"

Hi,

 

Thanks in advance.

Regards,

Harbhanu

---

From: Brett Tate <[email-masked]>
Date: Sun, 23 May 2010 08:22:06 -0700

My apologies for indicating "SHOULD"; draft-ietf-sipcore-reinvite-04  and RFC3311 actually appear to use "MUST".  Thus based upon the draft, an UPDATE without SDP MUST now be rejected unless an answer SDP has been received for the INVITE's offer SDP.  The draft doesn't adjust the rfc4028 behavior that you appear to want altered.  If want the rfc4028 behavior changed, I recommend that you post your concerns to the sipcore working group.

Draft-ietf-sipcore-reinvite-04 section 3.5:

"  An UPDATE request without an offer can change dialog parameters.  So
   can a non-2xx final response to a re-INVITE request or a 2xx response
   to an INVITE request (re-INVITE or initial INVITE).  However, there
   are no rules to avoid a collision between an offerless UPDATE request
   and a final response to an INVITE request.  The rules in Section 4.5<http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-4.5>,
   which are given in the context of target refreshes, cover these types
   of collisions as well.  Therefore, there is no need to specify
   further rules here."

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

RFC3311 section 5.2:

"  If an UPDATE is received that contains an offer, and the UAS has
   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response.  Similarly, if an UPDATE is received that contains an
   offer, and the UAS has received an offer (in an UPDATE, PRACK, or
   INVITE) to which it has not yet generated an answer, the UAS MUST
   reject the UPDATE with a 500 response, and MUST include a Retry-After
   header field with a randomly chosen value between 0 and 10 seconds."

Sent: Sunday, May 23, 2010 3:34 AM

>> Concerning your example... yes; the UPDATE 2xx is allowed (even though potentially not following a SHOULD).
Please let me know which 'SHOULD' clause is missed...

Although in the draft, it does mentions about failure response to re-INVITE, but again the crossover of success response will make things murkier.

Here, I beg to disagree that UAC should run a timer value of 1800, since then the sole purpose of this early refresh will be defeated. Although what you just said is as per 4028, but as already discussed, it doesn't mention anything about early negotiation of Session-timer and certainly not the UPDATE/ INVITE glare. So 4028 will not suffice to standardize the behavior here.

So, either the UPDATE should be *explicitly* disallowed and rejected with a 491 or it should be treated as a refresh request queued after the INVITE, to be effective after the INVITE parameters takes effect and thus making both run with SE value 600.
Here, the basis of former behavior can be formed as - the INVITE is carrying the 'offer', to negotiate the SE, and thus it disallows the generation of UPDATE which too attempts to update the SE ('offer').

***********************************************************************************************************************************************************

Hi Brett,

Regards,
Harbhanu