Subject: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

From: Brett Tate <[email-masked]>
Date: Fri, 21 May 2010 10:34:25 -0700

Howdy,

Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate that an UPDATE without SDP should be treated (from a glare perspective) as though it contained an offer SDP.  However I currently find the definition of "glare" and the expected behavior to be ambiguous.

What is the precise meaning of glare?  I ask mainly because some vendors send a 491 when an RFC indicates to send a 500.

If INVITE contains offer SDP and 18x was not reliable, how SHOULD the called party respond if UPDATE without SDP is received from caller: 491, 500, or process as though no glare?

If INVITE contains offer SDP and 18x was not reliable, how SHOULD the caller respond if UPDATE without SDP is received from called party: 491, 500, or process as though no glare?

If caller receives INVITE 2xx without offer/answer, how SHOULD or MUST the caller respond if UPDATE without SDP is received from called party prior to sending ACK (if not willing to queue or drop UPDATE): 491 or 500?  Is it a SHOULD or MUST?

Thanks,
Brett

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 22 May 2010 17:17:33 +0900

Hi Brett,

I have a similar question too.

RFC 3261 and 3311 describe the definition regarding 500 and
491 response.
When UA rejects the INVITE during an INVITE transaction, or
rejects the UPDATE during an UPDATE transaction, it has nothing
to do with offer-answer which error code to be used.

If both transaction have the same direction, the error code is 500.
If not, the error code is 491.

But an interworking of INVITE and UPDATE is unclear.
The draft-offeranswer makes an efforts to clarify it in the
section 4.3.

>Howdy,
>
>Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate
>that an UPDATE without SDP should be treated (from a glare
>perspective) as though it contained an offer SDP.
>However I currently find the definition of "glare" and the
>expected behavior to be ambiguous.
>
>What is the precise meaning of glare?  I ask mainly because
>some vendors send a 491 when an RFC indicates to send a 500.
>
>If INVITE contains offer SDP and 18x was not reliable, how
>SHOULD the called party respond if UPDATE without SDP is
>received from caller: 491, 500, or process as though no glare?

If UA must refuse it , parhaps it is 500.
IMO it is another question whether UA must reject the UPDATE
without an offer.

>If INVITE contains offer SDP and 18x was not reliable, how
>SHOULD the caller respond if UPDATE without SDP is received
>from called party: 491, 500, or process as though no glare?

Parhaps it is 491.

>If caller receives INVITE 2xx without offer/answer, how SHOULD
>or MUST the caller respond if UPDATE without SDP is received
>from called party prior to sending ACK (if not willing to
>queue or drop UPDATE): 491 or 500?  Is it a SHOULD or MUST?

UA may send 2xx to UPDATE. Because the INVITE transaction has
been completed.

For reference, the following figures are now under consideration.

  A                      B
  |                      |
  |INVITE                |
  |--------------------->|<-+             <-----+
  |  1xx(offer or answer)|  |                   |
  |<---------------------|  | reject INVITE     | reject UPDATE
  |PRACK                 |  | Don't send INVITE | Don't send UPDATE
  |--------------------->|  |                   |
  |               2xx-PRA|  |                   |
  |<---------------------|  |             <-----+
  |                      |  |                   | may send UPDATE
  |                   2xx|  |                   | may accept UPDATE
  |<---------------------|<-+                   |
  |                      |  | may send INVITE   |
  |ACK                   |  | may accept INVITE |
  |--------------------->|  |                   |
  |                      |  v                   v
  |                      |
          Figure 16

  A                      B
  |                      |
  |INVITE                |
  |--------------------->|<-+             <-----+
  |  1xx(offer or answer)|  |                   |
  |<---------------------|  | reject INVITE     | reject UPDATE
  |PRACK                 |  | Don't send INVITE | Don't send UPDATE
  |--------------------->|  |                   |
  |               2xx-PRA|  |                   |
  |<---------------------|  |             <-----+
  |                      |  |                   | may send UPDATE
  |                   4xx|  |                   | may acceptUPDATE
  |<---------------------|<-+                   |
  |                      |  | Don't send INVITE |
  |ACK          ACK      |  | may accept INVITE | <-- Should B reject UPDATE or not?
  |--------->   -------->|<-+             <-----+     That is another question.
  |                      |  |                   |
  |                      |  v                   v
          Figure 17

In both figures, 
UA A reject all INVITE/UPDATE with 491.
UA B reject all INVITE/UPDATE with 500.

Regards,
Shinji

---

From: Brett Tate <[email-masked]>
Date: Sun, 23 May 2010 10:34:47 -0700

> The draft-offeranswer makes an efforts to clarify it in the

Thanks for the information.  Draft-ietf-sipping-sip-offeranswer needs to be updated to actually refer to draft-ietf-sipcore-reinvite.

> If UA must refuse it , perhaps it is 500.

If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, the following snippets apply.

"When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer."

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

> IMO it is another question whether UA must reject the UPDATE

My current understanding is that it MUST be rejected; see above.

> Perhaps it is 491.

If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, the following snippets apply.

"When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer."

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

If the calling party supports draft-ietf-sipcore-reinvite but called party doesn't, this can lead to numerous UPDATE/491 (retry interval 0-2 seconds) until called party no longer mandated to return 491.

> UA may send 2xx to UPDATE. Because the INVITE transaction has

If I understand draft-ietf-sipcore-reinvite and RFC3311 correctly, the following snippets apply.

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

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

---

From: [email-masked]
Date: Mon, 24 May 2010 11:04:55 +0800

Hi,

[email-masked] 写于 2010-05-24 01:34:47:

> Thanks for the information.  Draft-ietf-sipping-sip-offeranswer 
> needs to be updated to actually refer to draft-ietf-sipcore-reinvite.
> 
> 
> "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."
> 
> 
> "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."
> 
> If the calling party supports draft-ietf-sipcore-reinvite but called
> party doesn't, this can lead to numerous UPDATE/491 (retry interval 
> 0-2 seconds) until called party no longer mandated to return 491.

 While UAS(as this is about Re-INVITE, UAS could be more proper here) does 
not support draft-ietf-sipcore-reinvite, UAS may just send 2xx to UPDATE. 
And this may cause ambiguous session state. If UAC support 
draft-ietf-sipcore-reinvite, the UAC should send a new Re-INVITE/UPDATE to 
synchronize the session state.
If both of UAC and UAS do not support draft-ietf-sipcore-reinvite, the 
session state would be ambiguous.

I think the circulation of UPDATE/491 would happen if UAS support 
draft-ietf-sipcore-reinvite, no matter UAS supports 
draft-ietf-sipcore-reinvite or not. And the times of this circulation 
would not be numerous, the circulation would be ended after UAS gets the 
ACK(of Re-INVITE's 4xx). 

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

This is no a glare situation. UAC can handle the UPDATE OK.

Thanks,

Gao

--------------------------------------------------------
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: OKUMURA Shinji <[email-masked]>
Date: Mon, 24 May 2010 17:02:30 +0900

Brett,

Brett Tate <[email-masked]>
Sun, 23 May 2010 10:34:47 -0700
(snip)
>corresponding ACK request as an offer/answer exchange."

IMO in this case, if a 2xx to a reINVITE is not an offer nor
an answer, a UAS may accept an UPDATE.
At least from an offer-answer perspective, the above additional
rule is unnecessary.

Regards,
Shinji

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 11:41:33 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: 21 May 2010 18:34
> To: [email-masked]
> Subject: [sipcore] draft-ietf-sipcore-reinvite-04: glare and 
> UPDATE without SDP
> 
> Howdy,
> 
> perspective) as though it contained an offer SDP.  However I 
> currently find the definition of "glare" and the expected 
> behavior to be ambiguous.
> 
[JRE] I believe these two situations are both valid and should not result in a 4xx/5xx/6xx response unless something else is wrong with the request.

John

> 
> If caller receives INVITE 2xx without offer/answer, how 
> SHOULD or MUST the caller respond if UPDATE without SDP is 
> received from called party prior to sending ACK (if not 
> willing to queue or drop UPDATE): 491 or 500?  Is it a SHOULD or MUST?
> 
> 
> Thanks,
> Brett
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 04:54:51 -0700

> [JRE] I believe these two situations are both valid and should not
> result in a 4xx/5xx/6xx response unless something else is wrong with
> the request.

That was true before draft-ietf-sipcore-reinvite.  However it looks like the following snippets make it no longer true.

Draft-ietf-sipcore-reinvite 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,
 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 section 4.5:

"When checking for glare situations, UAs MUST treat every UPDATE
 request as if it contained an offer."

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

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 05:06:28 -0700

> At least from an offer-answer perspective, the above additional

Draft-ietf-sipcore-reinvite has changed the offer/answer rules by forcing offer/answer rules upon requests/responses which don't actually contain an offer or answer.

And for completeness, draft-ietf-sipcore-reinvite (such as the above snippet) has impacts on both INVITE and re-INVITE.

---

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

Hi,

As the text declared, such rules are used When checking for glare 
situations.
Any cases without ambiguity would be handled as RFC3261 and 3311.

Thanks,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Brett Tate <[email-masked]> 
发件人:  [email-masked]
2010-05-24 20:06

收件人
OKUMURA Shinji <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE withoutSDP

> At least from an offer-answer perspective, the above additional

Draft-ietf-sipcore-reinvite has changed the offer/answer rules by forcing 
offer/answer rules upon requests/responses which don't actually contain an 
offer or answer.

And for completeness, draft-ietf-sipcore-reinvite (such as the above 
snippet) has impacts on both INVITE and re-INVITE.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 14:22:44 +0200

Brett,

Thanks for the clarification. So the changes do not prohibit the use of UPDATE after only a non-reliable provisional response, provided the UPDATE request does not contain an offer - correct? If it does contain an offer it is subject to the glare rules.

John 

> From: Brett Tate [mailto:[email-masked]] 
> Sent: 24 May 2010 12:55
> To: Elwell, John; [email-masked]
> Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare 
> and UPDATE without SDP
> 
> That was true before draft-ietf-sipcore-reinvite.  However it 
> looks like the following snippets make it no longer true.
>

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 05:23:09 -0700

> While UAS(as this is about Re-INVITE, UAS could be more proper here) 

Where does it say draft-ietf-sipcore-reinvite sections 3.5 and 4.5 are limited to re-INVITE?  Notice section 3.5 explicitly indicates "re-INVITE or initial INVITE".

Section 3.5 indicates:

<snip>

> This is no a glare situation. UAC can handle the UPDATE OK. 

Per draft-ietf-sipcore-reinvite sections 3.5 and 4.5 it is a 500 response situation.  The "offer" was within INVITE 2xx even though it contained no SDP.  Another "offer" was within the UPDATE even though it contained no SDP.  Thus per RFC3311, a 500 with Retry-After MUST be returned.

---

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

Hi,

As I said in the previous mail.

Such rules in the text's 3.5 and 4.5, are used for glare situations, which 
have ambiguity.

So, it is not want to override current 3261 and 3311's semantics. It is 
UPDATE and clarification for the *dark corner*, which is ambiguous case at 
all.

Thanks,

Gao

2010-05-24 19:54

收件人
"Elwell, John" <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题
Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

> result in a 4xx/5xx/6xx response unless something else is wrong with

That was true before draft-ietf-sipcore-reinvite.  However it looks like 
the following snippets make it no longer true.

RFC3311 section 5.2:

---

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

Brett Tate <[email-masked]> 写于 2010-05-24 20:23:09:

> Where does it say draft-ietf-sipcore-reinvite sections 3.5 and 4.5 
> are limited to re-INVITE?  Notice section 3.5 explicitly indicates 
> "re-INVITE or initial INVITE".

I mean both side(caller and callee) can send Re-INVITE, so caller is not 
proper here. 

> Per draft-ietf-sipcore-reinvite sections 3.5 and 4.5 it is a 500 
> response situation.  The "offer" was within INVITE 2xx even though 
> it contained no SDP.  Another "offer" was within the UPDATE even 
> though it contained no SDP.  Thus per RFC3311, a 500 with Retry-
> After MUST be returned.

Please refer to the previous mail.

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 05:47:03 -0700

> Such rules in the text's 3.5 and 4.5, are used for 
> glare situations, which have ambiguity. 
>
> So, it is not want to override current 3261 and 3311's 
> semantics. It is UPDATE and clarification for the *
> dark corner*, which is ambiguous case at all. 

Draft-ietf-sipcore-reinvite section 3.5 and 4.5 appear to have changed the offer/answer rules by mandating that the rules apply when some requests and responses don't actually contain an offer or answer.

Hopefully the authors will clarify the intended behavior of sections 3.5 and 4.5 so that the text can be adjusted if needed.

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 24 May 2010 21:49:09 +0900

Brett,

>Draft-ietf-sipcore-reinvite has changed the offer/answer
>rules by forcing offer/answer rules upon requests/responses
>which don't actually contain an offer or answer.

I think I understand it probably.
What I make an issue is the validity of it.
I doubt whether the aproch is appropriate.

Regards,
Shinji

>And for completeness, draft-ietf-sipcore-reinvite (such as
>the above snippet) has impacts on both INVITE and re-INVITE.

---

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

> Draft-ietf-sipcore-reinvite section 3.5 and 4.5 appear to have 
> changed the offer/answer rules by mandating that the rules apply 
> when some requests and responses don't actually contain an offer or 
answer.
> 
> Hopefully the authors will clarify the intended behavior of sections
> 3.5 and 4.5 so that the text can be adjusted if needed.

We are trying to fix ambiguous case in 3261 and 3311, not want to override 
well-balanced things.

So, if you think there's rules have impact on *once* well-balanced use 
cases, please show the use cases.

And if you have better way for the ambigunous cases, please show it too.

Thanks,

Gao

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 06:02:44 -0700

> Thanks for the clarification. 
> So the changes do not prohibit the use of
> UPDATE after only a non-reliable provisional response, provided the
> UPDATE request does not contain an offer - correct? If it does contain
> an offer it is subject to the glare rules.

Concerning glare, my understanding is that the draft mandates treating UPDATE without offer as though it contained an offer.

I'm still trying to understand how section 3.5 and 4.5 are to be interpreted.  Because the draft uses offer/answer rules for the "fix", it prevents using UPDATE without SDP on an early dialog until allowed per offer/answer rules.  Thus sending 18x using 100rel with answer SDP is now important to avoid blocking ability to send UPDATE for non SDP reasons.

---

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

> Concerning glare, my understanding is that the draft mandates 
> treating UPDATE without offer as though it contained an offer.
> 
> I'm still trying to understand how section 3.5 and 4.5 are to be 
> interpreted.  Because the draft uses offer/answer rules for the 
> "fix", it prevents using UPDATE without SDP on an early dialog until
> allowed per offer/answer rules.

Not exactly here. The text never forbit usage of UPDATE without offer by 
O/A rules.

People can use it as before, and just refer the rules here while it is a 
really glare case.

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 06:15:42 -0700

> I doubt whether the aproch is appropriate.

The draft has already passed WGLC.  The current status is "Publication Requested".

Thus I'm not sure how willing the authors and working group would be to alter the solution.  However I'm not sure how many working group members noticed the impacts of section 3.5 and 4.5.

It definitely encourages sending answer SDP within reliable 18x.  Not doing so would block ability to use UPDATE on the early dialog.

---

From: [email-masked]
Date: Mon, 24 May 2010 21:23:03 +0800

> The draft has already passed WGLC.  The current status is 

Yes.

> 
> Thus I'm not sure how willing the authors and working group would be
> to alter the solution.  However I'm not sure how many working group 
> members noticed the impacts of section 3.5 and 4.5.

No matter how eager I want to make this text process, if you find real 
problem or other interworking issue, just point it out.

In fact, this is UPDATE of 3261. I do not want to see UPDATE of our text 
someday for our negligence.

> 
> It definitely encourages sending answer SDP within reliable 18x. 
> Not doing so would block ability to use UPDATE on the early dialog.

Not exactly, please see my previous mail's reply.

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 06:25:28 -0700

> Not exactly here. The text never forbit usage of UPDATE without offer by O/A rules. 

I agree that it doesn't forbid sending it.  It allows it and mandates the UAS return 491 or 500 (depending upon direction).

---

From: [email-masked]
Date: Mon, 24 May 2010 21:30:21 +0800

[email-masked] 写于 2010-05-24 21:25:28:

> I agree that it doesn't forbid sending it.  It allows it and 
> mandates the UAS return 491 or 500 (depending upon direction).

It mandates the UAS send 4xx/5xx to UPDATE only when the UAS send 4xx/5xx 
to the Re-INVITE and the UAS get the UPDATE before ACK of 
4xx/5xx(Re-INVITE).

If UAS send 2xx to Re-INVITE, the UAS would not send 4xx/5xx to the 
UPDATE.

And if the UAS get the ACK(Re-INVITE's 4xx/5xx) firstly, the UAS also 
would not mandate to the rules.

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 06:37:01 -0700

That might be what you wanted sections 3.5 and 4.5 to mean; however it currently doesn’t mean that when you factor in RFC3311.

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, May 24, 2010 9:30 AM
To: Brett Tate
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

> mandates the UAS return 491 or 500 (depending upon direction).

It mandates the UAS send 4xx/5xx to UPDATE only when the UAS send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before ACK of 4xx/5xx(Re-INVITE).

If UAS send 2xx to Re-INVITE, the UAS would not send 4xx/5xx to the UPDATE.

And if the UAS get the ACK(Re-INVITE's 4xx/5xx) firstly, the UAS also would not mandate to the rules.

---

From: [email-masked]
Date: Mon, 24 May 2010 21:40:03 +0800

Sorry, I can't catch the meaning of "when you factor in RFC3311". Could 
you show me the meaning?

2010-05-24 21:37

收件人
"[email-masked]" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

That might be what you wanted sections 3.5 and 4.5 to mean; however it 
currently doesn’t mean that when you factor in RFC3311.
 
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, May 24, 2010 9:30 AM
To: Brett Tate
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE 
without SDP

 
--------------------------------------------------------
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: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 06:47:48 -0700

> Sorry, I can't catch the meaning of "when you factor 
> in RFC3311". Could you show me the meaning?

Look at RFC3311 (especially section 5.2) concerning how to behave when UPDATE offer is received while there is an outstanding offer.

" If an UPDATE is received that contains an offer, and the UAS has

---

From: [email-masked]
Date: Mon, 24 May 2010 21:56:10 +0800

Brett Tate <[email-masked]> 写于 2010-05-24 21:47:48:

> Look at RFC3311 (especially section 5.2) concerning how to behave 
> when UPDATE offer is received while there is an outstanding offer.

I know this part of 3311. I don't know the meaning of why you highlight 
this part.

Do you think text of our draft has conflict with this part of 3311 here?

I don't think so, as our text only for ambiguous cases.

---

From: Brett Tate <[email-masked]>
Date: Mon, 24 May 2010 07:18:10 -0700

> I know this part of 3311. I don't know the meaning of why 
> you highlight this part. 
>

I'm indicating that the RFC3311 mandates the returning 491 or 500 (depending upon direction).

You are indicating that the RFC3311 text doesn't apply even though draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they would apply.  RFC3311 section 5.2 includes glare checking as part of normal UPDATE processing.

The drafts normative text causing the issue: "When checking for glare situations, UAs MUST treat every UPDATE request as if it contained an offer."

You keep interpreting/indicating that the normative text does not apply to all UPDATEs.  Please provide the normative text which indicates your interpretation.

Thanks,
Brett

---

From: [email-masked]
Date: Mon, 24 May 2010 22:35:00 +0800

Rules for "When checking for glare situations" in the draft text means the 
UAs's reasoning and handling while the UAs are in a glare situations, 
which is ambiguous.

It does not means UAs reasoning and handling for every use case to figure 
out whether this case is a glare case.

This is my understanding. And I'd like other co-authors and important 
reviewer to comment on this point. 

> You are indicating that the RFC3311 text doesn't apply even though 
> draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate they 
> would apply.  RFC3311 section 5.2 includes glare checking as part of
> normal UPDATE processing.
> 
> The drafts normative text causing the issue: "When checking for 
> glare situations, UAs MUST treat every UPDATE request as if it 
> contained an offer."
> 
> You keep interpreting/indicating that the normative text does not 
> apply to all UPDATEs.  Please provide the normative text which 
> indicates your interpretation.
> 
> Thanks,
> Brett
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 24 May 2010 17:12:35 +0200

If an UPDATE request without SDP offer cannot be accepted when only an unreliable provisional response has occurred, I believe this is a normative change to RFC 3311.

John

> Sent: 24 May 2010 14:25
> To: [email-masked]
> Cc: Elwell, John; [email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 25 May 2010 12:21:40 +0900

Brett,

Sorry for my lack of experience for publication of ID.
Was there an announcement about WGLC in this ML?

In any case, I do not deny a basic concept.
I agree that UAC generate new offer to synchronize.
But I doubt that UAs treat the final response to INVITE
and ACK as an offer/answer exchange.

Perhaps I think that my opinion is similar to yours.

Regards,
Shinji

Brett Tate <[email-masked]>
Mon, 24 May 2010 06:15:42 -0700
>> I doubt whether the approach is appropriate.
>
>Thus I'm not sure how willing the authors and working group
>would be to alter the solution.  However I'm not sure how many
>working group members noticed the impacts of section 3.5 and 4.5.
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 25 May 2010 14:27:21 +0900

Gao,

[email-masked]
Mon, 24 May 2010 21:30:21 +0800
>It mandates the UAS send 4xx/5xx to UPDATE only when the UAS
>send 4xx/5xx to the Re-INVITE and the UAS get the UPDATE before
>ACK of 4xx/5xx(Re-INVITE).

As you know, ACK to non-2xx is hop-by-hop.
There is little benefit to reject such an UPDATE.

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |                   18x(answer1)|
    |<------------------------------|
  s1|                        non-2xx|s1
    |<------------------------------|<-+
  s0|ACK                            |s0|
    |----------->                   |  |
    |UPD(offer0)                    |  |
    |==============================>|* | reject UPDATE
    |                       491(UPD)|  |
    |<==============================|  |
    |                    ACK        |  |
    |                    ---------->|<-+
    |                               |
                Figure 2

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |                   18x(answer1)|
    |<------------------------------|
  s1|                        non-2xx|s1
    |                 /-------------|<-+
    |                /   ACK        |s0| reject UPDATE
    |               /    ---------->|<-+
    |UPD(offer2)   /                |
    |=============/================>|
    |            /          200(UPD)|
    |<==========/===================|
  s2|          /                    |s2
    |<--------/                     |
  s0|ACK                            |
    |----------->                   |
    |                               |
                Figure 3

I've also been pointed out by Ian Elz.

Regards,
Shinji

---

From: [email-masked]
Date: Tue, 25 May 2010 14:15:10 +0800

Hi,

> There is little benefit to reject such an UPDATE.

UAS send 491 for the UPDATE(in the flow) to *tell* UAC that in it's(UAS) 
view, there's a glare case.

When UAS get the ACK then UPDATE, it still has no precise criterion for 
whether the UAC gets non-2xx(Re-INVITE) first then send the UPDATE or not. 
Keeping rejecting the UPDATE is not a reasonable way here. So, the draft 
suggest the way, as UAS can send 2xx to the UPDATE.

When UAC get UAS's 4xx of UPDATE, the session state is clear for it. And 
UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare 
case in the UAC's view.

IMO, this way is better than the way we might once use: allowing B send 
2xx to UPDATE, and both A and B *see* glare, and all send Re-INVITE/UPDATE 
to refresh session state by each's view.

Thanks,

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 25 May 2010 17:31:49 +0900

Gao,

[email-masked]
Tue, 25 May 2010 14:15:10 +0800
>view, there's a glare case.

But this UPDATE is sent in order to synchronize the common view.
If UAS return 2xx, then the situation goes into nonglare.

Probably another UPDATE will be sent, but this UPDATE
transaction is supposed to be avoided.

At the very start, the UAS rejects a reINVITE does not care
about this text. Is it necessary to let such a UAS follow a
new rule?

>suggest the way, as UAS can send 2xx to the UPDATE.

It is a conventional handling and enough for UAS.

>UAC would only send a synchronizing Re-INVITE/UPDATE when it is a glare 

UAS' behavior does not affect UAC' behavior directly.
UAC will do the needful regardless of whether UAS rejects
a reINVITE.

>to refresh session state by each's view.

The new rule for UAS does not seem to improve the situation.
The new rule for UAC seems to be just enough to synchronize
the view.

Regards,
Shinji

---

From: [email-masked]
Date: Tue, 25 May 2010 16:53:20 +0800

Hi,

> If UAS return 2xx, then the situation goes into nonglare.

I guess I have a inverse point here. By this draft's clarification, 
there's no inconsistent session state for the non-successful Re-INVITE. 
So, why UAC send a UPDATE to synchronize the common view?

While if UAS return 2xx(for the UPDATE), the situation would get into 
glare(UAS has no way to figure out this UPDATE is in-scope of Re-INVITE or 
not). This is relating to atomic of session state. I'd like to emphasize 
that keeping Re-INVITE atomic, except for target refresh, is the main idea 
in this draft.

> about this text. Is it necessary to let such a UAS follow a

These days, you guys showed a lot of use cases. I don't remember the 
details. Could you say more about this use case.

> The new rule for UAC seems to be just enough to synchronize

The key merit for the new rule is make both UAC and UAS clear in which 
situation is it's responsibility to handle glare case, and there's only 
one UA need to do something. Both sides want to refresh session state by 
each's view is not a elegant way.

Thanks,

Gao

---

From: Brett Tate <[email-masked]>
Date: Tue, 25 May 2010 04:37:59 -0700

Yes; there was a WGLC announcement.

http://www.ietf.org/mail-archive/web/sipcore/current/msg01950.html 

http://www.ietf.org/mail-archive/web/sipcore/current/msg02089.html 

Even though I may not prefer the solution (as I understand it) mandated by sections 3.5 are 4.5, I'm mainly just trying to understand it.  Gao and I currently don't agree upon how sections 3.5 and 4.5 impact UPDATE without SDP on an early dialog.  As Gao has requested, I hope the other authors and Paul will reply.

http://www.ietf.org/mail-archive/web/sipcore/current/msg02750.html 

> From: OKUMURA Shinji [mailto:[email-masked]]
> Sent: Monday, May 24, 2010 11:22 PM
> To: [email-masked]
> Cc: Brett Tate
> Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE
> without SDP
> 
> Brett,
>

---

From: OKUMURA Shinji <[email-masked]>
Date: Tue, 25 May 2010 23:32:30 +0900

Gao,

This is a figure I've assumed.

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |               18x-rel(answer1)|

>Hi,
>
>OKUMURA Shinji <[email-masked]>
>> Gao,
>> 
>> [email-masked]

In 3.4.  UAC Behavior,
  "In order to cope with these race condition
   situations, a UAC that receives an error response to a re-INVITE for
   which changes have been already executed 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 dialog and the session."

Under the above descriptions, this UAC generates a new UPDATE.

>that keeping Re-INVITE atomic, except for target refresh, is the main idea 

This issue has nothing to do with the "atomic of session state".

>details. Could you say more about this use case.

Please look at the original mail of mine, and re-comment it.
You seem to be confused a little.

>each's view is not a elegant way.

The crux of the matter is that a UAS can not recognize own glare
situation anytime.
It is UAC's duty to synchronize a common view.

Regards,
Shinji

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 20:51:03 +0200

Hi, 

>Thanks for the clarification. So the changes do not prohibit the use of UPDATE after only a non-reliable provisional response, provided the UPDATE request does not contain an offer - correct? If it…

Maybe I didn't understand, but what is the difference if you receive a reliable or unreliable response (without SDP)?

Regards,

Christer

> Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and 
> UPDATE without SDP
> 
> > > Draft-ietf-sipcore-reinvite-04 sections 3.5 and 4.5 indicate that 
> > > an UPDATE without SDP should be treated (from a glare
> > > currently find the definition of "glare" and the expected behavior 
> > > to be ambiguous.
> > >
> > > What is the precise meaning of glare?  I ask mainly because some 
> > > vendors send a 491 when an RFC indicates to send a 500.
> > >
> > > If INVITE contains offer SDP and 18x was not reliable, how SHOULD 
> > > the called party respond if UPDATE without SDP is received from 
> > > caller: 491, 500, or process as though no glare?
> > >
> > > If INVITE contains offer SDP and 18x was not reliable, how SHOULD 
> > > the caller respond if UPDATE without SDP is received from called 
> > > party: 491, 500, or process as though no glare?
> >
> That was true before draft-ietf-sipcore-reinvite.  However it looks 
> like the following snippets make it no longer true.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 May 2010 21:11:29 +0200

> From: Christer Holmberg [mailto:[email-masked]] 
> Sent: 25 May 2010 19:51
> To: Elwell, John; Brett Tate; [email-masked]
> >Thanks for the clarification. So the changes do not prohibit 
> the use of UPDATE after only a non-reliable provisional 
> response, provided the UPDATE request does not contain an 
> offer - correct? If it does contain an offer it is subject 
> >to the glare rules.
> 
> Maybe I didn't understand, but what is the difference if you 
> receive a reliable or unreliable response (without SDP)?
[JRE] If only an unreliable provisional response has been received , an UPDATE is not allowed to contain SDP, so treating it as if it contained SDP is rather odd. The following sequence:
(re-)INVITE----->
<-----18x (unreliable)
----->UPDATE (no SDP)
is valid in accordance with RFC 3311, I believe. What seems to be suggested by the draft is that in some circumstances the UAS might treat the received UPDATE as a glare. It is not clear to me under what conditions it might be treated as a glare, but in any case, that would seem to be a change to RFC 3311 for those particular conditions.

John

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 21:58:35 +0200

Hi, 

>>the use of UPDATE after only a non-reliable provisional response, 
>>provided the UPDATE request does not contain an offer - correct? If it 
>>does contain an offer it is subject
>>to the glare rules.
> 
>[JRE] If only an unreliable provisional response has been received , an UPDATE is not allowed to contain SDP, so treating it as if it contained SDP is rather odd.

But, how is it less "odd" than treating an UPDATE as it it contained SDP when you have received a reliable response (without SDP)? 

>The following sequence:
>(re-)INVITE----->
><-----18x (unreliable)
>----->UPDATE (no SDP)
>is valid in accordance with RFC 3311, I believe.
>
>What seems to be suggested by the draft is that in some circumstances the UAS might treat the received UPDATE as a glare. It is not clear to me under what conditions 
>it might be treated as a glare, but in any case, that would seem to be a change to RFC 3311 for those particular conditions.

I will have to try to refresh my memory, because I can't see how it would be a glare from an offer/answer perspective. Could it be related to target refresh?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 May 2010 22:18:34 +0200

Hi,

So, please note that the text in section 4.5 is about target refreshes - not offer/answers.

So, if you have received an unreliable response, I guess you could send an UPDATE. But, why would you want to? You cannot include SDP, and I don't believe you can include updated target information.

But, if you have received an reliable response, you CAN send an UPDATE to update the target - and so can the remote party. And, then you may end up with the glare situation described in section 4.5.

So, I believe that is the reason for the "treat the UPDATE as if it contained SDP" text, because in that case the UPDATE would be rejected (since you don't know if the remote end replied to your UPDATE before it sent its own UPDATE, or vice verse).

Brett said that the procedure "forces" the UAS to include SDP in the reliable response, but I can't find any text indicating that...?

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25. toukokuuta 2010 22:59
To: 'Elwell, John'; Brett Tate; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

Hi, 

>>Thanks for the clarification. So the changes do not prohibit the use 
>>of UPDATE after only a non-reliable provisional response, provided the 

>What seems to be suggested by the draft is that in some circumstances 
>the UAS might treat the received UPDATE as a glare. It is not clear to me under what conditions it might be treated as a glare, but in any case, that would seem to be a change to RFC 3311 for those particular conditions.

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 May 2010 08:35:20 +0200

> Sent: 25 May 2010 20:59
> >[JRE] If only an unreliable provisional response has been 
> received , an UPDATE is not allowed to contain SDP, so 
> treating it as if it contained SDP is rather odd.
> 
> But, how is it less "odd" than treating an UPDATE as it it 
> contained SDP when you have received a reliable response 
> (without SDP)? 
[JRE] You are right, a reliable response does not need to contain SDP if there was an offer in the INVITE request.

John

> >What seems to be suggested by the draft is that in some 
> circumstances the UAS might treat the received UPDATE as a 
> glare. It is not clear to me under what conditions 
> >it might be treated as a glare, but in any case, that would 
> seem to be a change to RFC 3311 for those particular conditions.
> 
> I will have to try to refresh my memory, because I can't see 
> how it would be a glare from an offer/answer perspective. 
> Could it be related to target refresh?
> 
> Regards,
> 
> Christer
> 
> 
> 
> > 
> > Regards,
> > 
> > Christer
> > 
> >

---

From: Brett Tate <[email-masked]>
Date: Wed, 26 May 2010 05:04:28 -0700

> refreshes - not offer/answers.

Section 3.5 indicates that section 4.5 isn't just about target refreshes.

Section 4.5's fix explicitly uses offer/answer rules.  And as far as I know, it intentionally or unintentionally updates rfc3311 since all UPDATEs MUST now be treated like they contained an offer.  If my understanding is not true, please explain how the following quote is to be interpreted.  Gao and I appear to interpreting it (or when it applies) differently.

> Brett said that the procedure "forces" the UAS to include SDP 
> in the reliable response, but I can't find any text indicating 
> that...?

I never used the word "forces".  And some may have thought my questions were associated with re-INVITE; my questions were/are associated with INVITE. 

The following appears to require returning 491 or 500 to UPDATE without offer SDP when the INVITE's offer SDP has not been answered.  If my understanding is incorrect, please explain how the normative text does not require it.

RFC3311 section 5.2:

Thanks,
Brett

---

From: Brett Tate <[email-masked]>
Date: Wed, 26 May 2010 05:46:04 -0700

> So, if you have received an unreliable response, I guess you 
> could send an UPDATE. But, why would you want to? You cannot 
> include SDP, and I don't believe you can include updated 
> target information.

Prior to draft-ietf-sipcore-reinvite, you could use UPDATE without SDP to update/communicate things without being confined to the current offer/answer state.  For example, rfc5876 section 3.2 discusses communicating P-Asserted-Identity.  It can no longer be successfully communicated within UPDATE over an early dialog (resulting in 2xx response) unless the called party has sent the answer for the INVITE's offer SDP.

> But, if you have received an reliable response, you CAN send an UPDATE
> to update the target - and so can the remote party. And, then you may
> end up with the glare situation described in section 4.5.

That isn't the only glare situation and it doesn't just apply to changing target.  As mentioned above, attempting to communicate P-Asserted-Identity will also lead to a 491 if the called party has not sent an answer SDP for INVITE's offer SDP.

> So, I believe that is the reason for the "treat the UPDATE as if it
> contained SDP" text, because in that case the UPDATE would be rejected
> (since you don't know if the remote end replied to your UPDATE before
> it sent its own UPDATE, or vice verse).

The normative text does not limit it only that situation.

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

RFC3311 section 5.2:

---

From: [email-masked]
Date: Wed, 26 May 2010 21:31:40 +0800

I guess the key for this divarication here is still about the different 
understanding of the semantics of "checking for glare situations". If it 
is only applied in happened glare situations, it would not be a problem.

To make the two understanding's merit and disadvantage clear, I'd like to 
say one disadvantage for the understanding you showed:
If the rules is for all target refresh request without O/A, it really 
forbid some behaviors which is lawful once. No matter how much behavior 
would be affected, it would be a real and remarkable compatible 
interworking problem.

So, urgency here is about the understanding of the semantics of "checking 
for glare situations".

And I'd like to hear your comments about the cases mentioned under my 
understanding "checking for glare situations". In fact, which 
understanding is *people's* understanding can not solve problem. Maybe we 
can step out the question a little to concentrate on which one can solve 
problem.

2010-05-26 20:46

收件人
Christer Holmberg <[email-masked]>, "'Elwell, John'" 
<[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送

主题

> include SDP, and I don't believe you can include updated 

Prior to draft-ietf-sipcore-reinvite, you could use UPDATE without SDP to 
update/communicate things without being confined to the current 
offer/answer state.  For example, rfc5876 section 3.2 discusses 
communicating P-Asserted-Identity.  It can no longer be successfully 
communicated within UPDATE over an early dialog (resulting in 2xx 
response) unless the called party has sent the answer for the INVITE's 
offer SDP.

> end up with the glare situation described in section 4.5.

That isn't the only glare situation and it doesn't just apply to changing 
target.  As mentioned above, attempting to communicate P-Asserted-Identity 
will also lead to a 491 if the called party has not sent an answer SDP for 
INVITE's offer SDP.

RFC3311 section 5.2:

---

From: Brett Tate <[email-masked]>
Date: Wed, 26 May 2010 08:18:26 -0700

You and I know where our disagreement is concerning what the draft mandates.  We are still waiting to hear for Paul, Christer, and Gonzalo concerning how to interpret the following quote.

> I guess the key for this divarication here is still about 
> the different understanding of the semantics of "checking 
> for glare situations". If it is only applied in happened 
> glare situations, it would not be a problem. 

How can you only apply "checking for glare situations" during a glare situation?

Checking for offer/answer glare is part of normal RFC3311 UPDATE processing.

RFC3311 section 5.2:

> To make the two understanding's merit and disadvantage clear, 
> I'd like to say one disadvantage for the understanding you showed: 
> If the rules is for all target refresh request without O/A, it 
> really forbid some behaviors which is lawful once. No matter how 
> much behavior would be affected, it would be a real and remarkable 
> compatible interworking problem. 

I agree.  That is why I'm trying to understand what the draft mandates or attempted to mandate.

> So, urgency here is about the understanding of the semantics of 
> "checking for glare situations". 

I agree.

> And I'd like to hear your comments about the cases mentioned under 
> my understanding "checking for glare situations".

I don't know how to reconcile your interpretation with the RFC3311 section 5.2 snippet checking for offer/answer glare (shown above).

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2010 17:31:20 +0200

Hi,

Just to let you know, Gonzalo is out of office this and next week, with limited access to his e-mail, so I doubt you will get his opinion before he is back.

I tried earlier to explain earlier how I understand the quote, but based on the previous replies I need to do some more reading.

Regards,

Christer

________________________________________
From: Brett Tate [[email-masked]]
Sent: Wednesday, May 26, 2010 6:18 PM
To: [email-masked]
Cc: Christer Holmberg; [email-masked]
Subject: RE: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

RFC3311 section 5.2:

I agree.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 May 2010 11:53:34 -0400

Brett,

I'm aware. I got behind, and need to read through a whole bunch of 
messages carefully before I can comment meaningfully. Because of the 
backlog I now need some unbroken time to study all those, and haven't 
been able to steal it from my day job yet.

My general (tentative) feeling right now is that the requirement in 
-reinvite- to treat UPDATEs as if they contained an offer is 
problematic. It may be necessary to spell out explicitly the desired 
behavior rather than doing so indirectly like this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 May 2010 21:07:25 +0200

Hi,

Isn't what the text is trying to say the following:

"When you are about to send an UPDATE, or when you receive an UPDATE, you shall apply the glare checking rules as if the UPDATE would contain an SDP offer."

So, it means you can only send an empty UPDATE if you in the same situation were able to send an UPDATE with an offer.

And, it means that you do whatever you would do if you have sent an UPDATE with an offer, and a glare situation occurs.

I am not sure what is meant by "while being in a glare situation". I guess it means "while being in a situation where a glare could occur", or something like that.

But, these are just some unreliable provisional thoughts - I still need to do further reading of the document.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Wednesday, May 26, 2010 6:53 PM
To: Brett Tate
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

Brett,

        Thanks,
        Paul

---

From: [email-masked]
Date: Thu, 27 May 2010 09:26:33 +0800

> Checking for offer/answer glare is part of normal RFC3311 UPDATE 
processing.

Making two analyzers in series as:

---> analyzer1 -----> analyzer2 ---->

analyzer1 using the rules in RFC3311, and if there's glares case under 
it's rule, send 491 or (500+retry) directly;
analyzer2 using the rules in the draft. 

analyzer2 also has two process:
1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it 
can do so, pass the UPDATE to the next step normally;
2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as if 
it contains Offer and using O/A rules to reject.

The effected cases/siutation is only these cases/situation which are 
ambiguous before the draft.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 27 May 2010 14:29:35 +0200

> Sent: 26 May 2010 13:46
> To: Christer Holmberg; Elwell, John; [email-masked]
> Prior to draft-ietf-sipcore-reinvite, you could use UPDATE 
> without SDP to update/communicate things without being 
> confined to the current offer/answer state.  For example, 
> rfc5876 section 3.2 discusses communicating 
> P-Asserted-Identity.  It can no longer be successfully 
> communicated within UPDATE over an early dialog (resulting in 
> 2xx response) unless the called party has sent the answer for 
> the INVITE's offer SDP.
[JRE] That would be a change to RFC 3311 in my opinion. Also the ability to send PAI if it changes (e.g., due to 3PCC transfer) without waiting for the 2xx is, in my opinion, a reasonable current use case. It should be possible to do this without using reliable provisional responses (the only way to get SDP answer, as opposed to just a preview of SDP answer, in a 18x response).

John

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 May 2010 10:21:09 +0900

Gao,

I have a question regarding a target-refresh.

If a UAS return 18x-rel, 2xx to reINVITE and an UPDATE,
and each response has a different Contact-URI(it is a remote
target for a UAC), then how should the UAC handle the UPDATE
and the remote targets?

How does your analyzer work?
Please explain it concretely in order.

    A                               B
    |                               |
    |re-INV (offer1)                |
    |------------------------------>|
    |               18x-rel(answer1)| m:c1
    |<------------------------------|
    |                       2xx(INV)| m:c2
    |<------------------------------|
    |                         UPDATE| m:c3
    |<------------------------------|
    |                               |
or
    A                               B
    |                               |
    |re-INV (offer1)                |
    |------------------------------>|
    |               18x-rel(answer1)| m:c1
    |<------------------------------|
    |                       2xx(INV)| m:c2
    |<---------\ /------------------|
    |           X             UPDATE| m:c3
    |<---------/ \------------------|
    |                               |

Regards,
Shinji

---

From: [email-masked]
Date: Fri, 28 May 2010 12:45:49 +0800

Only the 

If a UA
   uses an UPDATE request or response to modify the remote target while
   an INVITE transaction is in progress, and it is a UAS for that INVITE
   transaction, it MUST place the same value into the Contact header
   field of the 2xx to the INVITE that it placed into the UPDATE request
   or response.

2010-05-28 09:21

收件人
[email-masked]
抄送
[email-masked], Brett Tate <[email-masked]>, 
[email-masked]
主题
Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATEwithout SDP

Gao,

    A                               B
    |                               |
    |re-INV (offer1)                |

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 May 2010 15:18:38 +0900

Gao,

The INVITE transaction has been already completed at the point
to send the UPDATE. In my understanding, the UPDATE can have a
different Contact.

After all, you say that
in 1st chart, UAC may return 2xx to the UPDATE and
in 2nd chart, it should(must?) return 4xx.

Is that right?

Regards,
Shinji

[email-masked]
Fri, 28 May 2010 12:45:49 +0800
>Only the first chart is lawful. As the text from RFC3311:
>
>If a UA
>If the UPDATE is in-scope of Re-INVITE, the 2xx's contact should be the 
>same as the (last) UPDATE's contact. So, the second chart can only has the 
>interpretation as the first chart. Then, there's no ambiguous 
>representation here.
>

---

From: [email-masked]
Date: Fri, 28 May 2010 14:48:19 +0800

You two charts has difference as:

First chart: 2xx before UPDATE; 
UAC can treate the UPDATE's contact as the new one.

Second chart: UPDATE before 2xx.
I guess your puzzle here is about how UAC can order the sequence, that is 
"UPDATE before 2xx" or "2xx before UPDATE".

I showed that, if the UPDATE has different target, it MUST be sended after 
the 2xx by UAS. The reason is that, if UPDATE has a different 
target(compared as the state before this UPDATE), the 2xx MUST has the 
same one.(this is defined in RFC3311).

As this, the UAC can treate this UPDATE after 2xx and  UPDATE's target is 
newer, no matter which one reachs UAC firstly.

2010-05-28 14:18

收件人
[email-masked]
抄送
[email-masked]
主题

Gao,

After all, you say that

Is that right?

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 May 2010 16:35:16 +0900

Gao,

[email-masked]
Fri, 28 May 2010 14:48:19 +0800
>"UPDATE before 2xx" or "2xx before UPDATE".

I agree this is a puzzle. But your analyzer has to figure out
this puzzle.

>newer, no matter which one reachs UAC firstly.

After all, you say that in both case UAC may return 2xx to the
UPDATE.

BUT your analyzer2 seems to say "Reject it!".
> 2. If it can not do the ordering, handle the UPDATE and 2xx(INVITE) as 
> if contains Offer and using O/A rules to reject.

Regards,
Shinji

---

From: [email-masked]
Date: Fri, 28 May 2010 16:54:17 +0800

> > if contains Offer and using O/A rules to reject.

As the analyzer show is aimed for Brett's puzzle. That is 2xx(of 
Re-INVITE) and UPDATE on different direction, mentioned in section 4.5 of 
the draft. Your case is not so. 

Our aim is to clear up ambiguity case, to cover your case, I'd like to add 
a new restriction highlighted in the analyzer2.

analyzer2 also has two process:
1. Check whether it can do the ordering of 2xx(INVITE)and UPDATE. If it 
can do so, pass the UPDATE to the next step normally;
2. If there is ambiguity and UAs can not do the ordering, handle the 
UPDATE and 2xx(INVITE) as if it contains Offer and using O/A rules to 
reject.

---

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

Sorry to be so slow in responding. I got behind, and had to wait till I 
had time to read through all that has been said before I could make any 
sort of meaningful response.

As it is, there is so much that I am responding after reading most of 
the -reinvite- traffic, without first checking if some of the mail with 
different subject is also relevant.

[email-masked] wrote:
> 
> Rules for "When checking for glare situations" in the draft text means 
> the UAs's reasoning and handling while the UAs are in a glare 
> situations, which is ambiguous.
> 
> It does not means UAs reasoning and handling for every use case to 
> figure out whether this case is a glare case.
> 

In light of all the discussion this has generated, I think -reinvite- is 
not sufficiently clear on what it means. I think we need to be looking 
for a way to revise it to be more clear, regardless of its current 
post-WGLC status. (Note that -offeranswer- is also in post-WGLC status, 
and we are debating changes to it.)

We *REALLY* need to hear from Gonzalo for his opinion on this!

My opinion at this point is that stating that "UPDATEs without SDP 
should be treated as if they contained an offer" is an insufficient 
technique for stating the required behavior - that it needs to be stated 
more explicitly, even though that will take more words.

I *think* that considerations of *glare* occur when there is something 
to be *negotiated* and either side may initiate the negotiation. The 
negotiated piece of state that has been considered to date for glare is 
the pair of SDP bodies that describe the media sessions.

As noted elsewhere in this thread, another piece state that is 
*negotiated* is session-timer. As a result, there could be a glare 
situation around that. The determination of whether glare has occurred 
ought to be independent for each kind of negotiated state. So one 
determination for SDP, another for session-timer. But there is only one 
mechanism for signaling the glare in either case, the 491 response code. 
So it would be used if *either* sdp-glare or session-timer-glare occurred.

Target-refresh is somewhat different, because it isn't *negotiated* - it 
is simply *declared* independently in each direction. So I don't think 
it really ought to be considered a glare situation.

Another in this category is sending an updated PAI, or changing From. 
This to is a declaration rather than a negotiation, so that glare 
shouldn't apply.

In both of those cases, there remains an ordering issue, and perhaps the 
answer is to forbid behavior that can result in ambiguity. But I fear 
that cure is worse than the disease, so I'm inclined to seek a better cure.

I'm especially concerned about that in the case of target refresh. If 
the sender has lost its old address, then we are on the brink of losing 
the call entirely. Saving the call is more important than whether we 
have the proper o/a state - that can be fixed after the new target 
address is established. Also, target refresh cases are typically rare. 
Two successive ones in close succession in the same direction should be 
rare^2. (A target refresh of both ends in quick succession could be more 
likely - for instance if the same event causes both to lose their 
address. It seems unlikely that this will be a recoverable event.)

So, I think we ought not be forbidding target refresh just because of 
other state. Ambiguity about which is the old target and which is the 
new one can be measured by which is a change - assuming there aren't two 
changes in quick succession. I think Gao has also recommended this.

	Thanks,
	Paul

---

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

This is evidence for my assertion that glare is really about conflicts 
in negotiation of state, and not about the specific messages used to 
conduct that negotiation.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 18:16:31 -0400

I read through this discussion, and I cannot figure out what the 
difference is between the two of you. As of this reply it seems to me 
that the two of you are agreeing.

Can one of you restate the issue and the contrasting solutions?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 18:28:29 -0400

Shinji,

I agree with what you say, but perhaps for different reasons, for based 
on different view of what "glare" means.

IMO the 491 response should be used to indicate glare has been detected, 
specifically that a proposal to negotiate a state change has been 
*received* while a previously *sent* proposal to negotiate a state 
change is still unresolved. That can apply to o/a regardless of what 
messages cause the situation to be detected. And I think this can apply 
even when receiving an offerless reINVITE, which is a demand for an offer.

OTOH the 500 response applies when a proposal to negotiate a state 
change has been *received* while a previously *received* proposal to 
negotiate state is still unresolved. This is not glare, because the 
problem is not the result of coincidence in valid behavior. The 500 is a 
suitable response because it is bad behavior by the sender of those 
proposals that results in the problem.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 20:03:51 -0400

> If an UPDATE request without SDP offer cannot be accepted when only an unreliable provisional response has occurred, I believe this is a normative change to RFC 3311.

Yes, I agree. And I think its an undesirable change too.

	Thanks,
	Paul

---

From: [email-masked]
Date: Mon, 31 May 2010 08:53:18 +0800

I guess you are talking about section 4.5 of the draft.

But section 4.5's rules only apply to case which has ambiguity. I think 
that the talked use case here has no ambiguity. So, nothing is forbidden 
here.

Thanks,

Gao

Paul Kyzivat <[email-masked]> 
发件人:  [email-masked]
2010-05-31 08:03

收件人
"Elwell, John" <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, "[email-masked]" 
<[email-masked]>
主题
Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE without SDP

Elwell, John wrote:
> If an UPDATE request without SDP offer cannot be accepted when only an 
unreliable provisional response has occurred, I believe this is a 
normative change to RFC 3311.

                 Thanks,
                 Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 21:09:01 -0400

Yes.

> that the talked use case here has no ambiguity. So, nothing is forbidden 

I don't know for certain when those rules apply. It says "When checking
for glare conditions". That is too vague for me. Under what
circumstances does the UA check for glare conditions?

My longer message on glare, etc. is probably a better context within
which to have this discussion.

	Thanks,
	Paul

> *Paul Kyzivat <[email-masked]>*
>  > If an UPDATE request without SDP offer cannot be accepted when only 
> an unreliable provisional response has occurred, I believe this is a

---

From: [email-masked]
Date: Mon, 31 May 2010 09:09:09 +0800

Shinji is question is about how to distinguish the two chart.

I guess my previous mails:

http://www.ietf.org/mail-archive/web/sipcore/current/msg02811.html
and 
http://www.ietf.org/mail-archive/web/sipcore/current/msg02804.html

have settled Shinji's question here.

And if Shinji has something new, please go on.

Thanks,

Gao

2010-05-31 06:16

收件人
OKUMURA Shinji <[email-masked]>
抄送
[email-masked], "[email-masked]" <[email-masked]>
主题
Re: [sipcore] draft-ietf-sipcore-reinvite-04: glare and UPDATE  without 
SDP

                 Thanks,
                 Paul

---

From: [email-masked]
Date: Mon, 31 May 2010 09:23:25 +0800

> circumstances does the UA check for glare conditions?

Yes. I also think the words is vague. 
So, I think we may need *words enhancement*, if my understanding of it's 
technical semantics is correct.
If it's technical semantics is not correct or not comprehensive enough, we 
might need *words and technical enhancement* at the same time here.

My point here is that as ther's arguement about it's technical semantics's 
correctness(IMO, section 3.5 and 4.5 is correct, technically), it would be 
more acceptable for me to describe it as "its an *potential* undesirable 
change too".

> which to have this discussion.

I am reading it, and will go on soon.

Thanks,

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 15:09:56 +0900

Paul,

Paul Kyzivat <[email-masked]>
Sun, 30 May 2010 18:28:29 -0400
>proposals that results in the problem.

IMO whether your view and mine are different depend on one
disputed point.

Which is a UAC that sends an offerless reINVITE, a "sender" of
the negotiation or a "receiver"?

If it is a "sender", then we say the same thing by a different
wording. I call it "client transaction", you call it "sender".

You say "an offerless reINVITE is a demand for an offer".
I think we are agreeing.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 16:44:36 +0900

Paul,

In my recognition, Gao and I are not agreeing.

I have two comments regarding Figure 2.

1. Between a non-2xx to a reINVITE and an ACK, the UAS may
   accept a receiving UPDATE.

   This draft seems to forbid the UPDATE.

2. In this case, the common view of both UAs has already
   been synchronized. IMO if an UPDATE has been not used in
   offer-answer exchange before 4xx, then the original
   rollback process may work well.
   That is, a following UPDATE is unnecessary in this case.

Does Gao agree with my comments?

Regards,
Shinji

Paul Kyzivat <[email-masked]>
Sun, 30 May 2010 18:16:31 -0400

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 17:27:35 +0900

Paul,

In RFC3311 5.2 Receiving an UPDATE
   A UAS that receives an UPDATE before it has generated a final
   response to a previous UPDATE on the same dialog MUST return a 500
   response to the new UPDATE, and MUST include a Retry-After header
   field with a randomly chosen value between 0 and 10 seconds.

The above descriptions have nothing to do with an offer-answer.

Should this rule be applied only to an offer-answer situation?

Regards,
Shinji

---

From: [email-masked]
Date: Mon, 31 May 2010 16:29:11 +0800

> the pair of SDP bodies that describe the media sessions.

Your classification: 

"O/A glare case" and "Session Timer glare case" are subset of "negotiated 
glare case";

"Target-refresh ambiguous misorder" and "Updating PAI" are subset of 
"Declaring ambiguous misorder";

"negotiated glare case" and "Declaring ambiguous misorder" are subset of 
"ambiguous case".

I once had a classification as "glare case" = "ambiguous case". But if we 
choose the "Patching way"(see below), I guess my classification is enough. 
If we want the "Refashion way", your more refined classification might be 
needed.

>that cure is worse than the disease, so I'm inclined to seek a better 
cure.

I think there are two different methodology for this issue:
1. Patching way: Saving current right case as it is, and cure ambiguous 
case without any breach for current right case(or making the breach as 
little as possible). I think the way defined in the draft belongs to 
"Patching way". 

2. Refashion way: Based on the refined classification of "ambiguous case", 
seek solution and redefine rules on each classification's semantics. This 
way might forbid some *current right case*.

Technically, I think "Refashion way" is better. But considering there's 
would be a serious interworking issue behind the "Refashion way"(there 
would be a quit long period for most vendors adopting this draft), I 
finally prefer the "Patching way" for nowadays.

Personally, I prefer this draft has relative narrow aspect, and with tiny 
impact on current right working things. If someday, we have a 3261bis 
plan, I would prefer the "Refashion way" more.

> address is established. 

I admire this point.

> Also, target refresh cases are typically rare. 

> changes in quick succession. I think Gao has also recommended this.

Yes. And I think Gonzalo's current text in the draft covered this, 
technically. 

While some words level enhancement might needed for enhancing it's 
understandability. 

Thanks,

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 19:16:29 +0900

Paul,

Paul Kyzivat <[email-masked]>
Sun, 30 May 2010 17:25:37 -0400
>it really ought to be considered a glare situation.

Exactly!
I've thought the differences between offer-answer and target-
refresh as below,

1. When a UAS sends 4xx to reINVITE, UAs rollback offer-answer,
   but don't rollback remote target.
   
2. All reliable response to a reINVITE refresh a remote target
   within one INVITE transaction.
   
3. PRACK is used in offer-answer, but is not a target refresh
   request.
   
4. A target-refresh is acknowledged by all SIP request(e.g.
   MESSAGE, INFO, etc.).

An offer-answer and a target-refresh have a different concept
each other. It seems to be unreasonable that those two rules
are applied to both situations at the same time.

Regards,
Shinji

---

From: [email-masked]
Date: Mon, 31 May 2010 18:48:59 +0800

>>   s0|re-INV (offer1)                |s0

If the UPDATE is in scope of ReINVITE by UAS's view, and the 
modification(*negotiated*) in this UPDATE should not be committed.

If the UPDATE is out scope of ReINVITE by UAS's view, the 
modification(*negotiated*) in this UPDATE can be committed.

As there is a ambiguous for UAS, so UAS should reject it.

>    That is, a following UPDATE is unnecessary in this case.

And if the UPDATE is in scope of ReINVITE, the state could not be treated 
as synchronized.

Thanks,

Gao

---

From: [email-masked]
Date: Mon, 31 May 2010 20:47:11 +0800

>    but don't rollback remote target.

If target refresh is committed, it would no be rollback by non-2xx of 
Re-INVITE(not means at any situation of 4xx of Re-INVITE, the remote 
target would be enforced). But it doesn't mean that target refresh or 
other *non-negotiated-declare* is non-rejective. The point here is the 
commitment of target refresh.

And the commitment for target refresh has been defined in the draft, that 
is the first reliable response(a reliable provisional response or a 2xx 
response to the target-refresh request), or a request on the new target 
from UAS. 

[Discussion 1] It seams that this commitment rule can be generalized for 
all *non-negotiated-declare*. And the commitment for target refresh can be 
maintained by two ways: "would no be rollback by non-2xx of Re-INVITE" or 
"restrict UAS send 2xx to Re-INVITE". See details in [Discussion 2].
 
>    within one INVITE transaction.

this is clearly clarfied in section 4.3 of the draft.
(If the UAC receives a reliable provisional response or a 2xx response
   to the target-refresh request, or the UAC receives a request on the
   new target, the UAS has updated its remote target.  The UAC can
   consider the target refresh operation completed.)

> 3. PRACK is used in offer-answer, but is not a target refresh

this is 3262's defintion, we need to stick to.

> 4. A target-refresh is acknowledged by all SIP request(e.g.

this is clearly clarfied in section 4.3 of the draft.
(If the UAC receives a reliable provisional response or a 2xx response
   to the target-refresh request, or the UAC receives a request on the
   new target, the UAS has updated its remote target.  The UAC can
   consider the target refresh operation completed.)

[Discussion 2] Current draft has the text in section 4.2 as:

The new
   behavior regarding target-refresh requests implies that a target-
   refresh request can, in some cases, update the remote target even if
   the request is responded with a final error response.  This means
   that target-refresh requests are not atomic.

I think that there's no negative impact on the function and behavior, if 
we restrict the UAS send 2xx to Re-INVITE while there's target refresh(or 
other *non-negotiated-declare*) during it. And if the UAS want to reject 
something *negotiated*, it can send another Re-INVITE-in-scope UPDATE.
If we do so, we can unify the semantic of Re-INVITE atomicity.

Thanks,

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 23:17:54 +0900

Gao,

>modification(*negotiated*) in this UPDATE can be committed.

You say "the UPDATE is out scope of ReINVITE" or
"the UPDATE is in scope of ReINVITE".
That is meaningless.
The crux of the matter is that a UAS can not recognize
whether the UPDATE is in scope of a ReINVITE or out scope
of it.

>As there is a ambiguous for UAS, so UAS should reject it.

Why?
Even if there is a ambiguous, it's not that a UAS should
reject all ambiguous things. Such a new restriction is
unnecessary.
It is UAC's duty to synchronize a common view.

>And if the UPDATE is in scope of ReINVITE, the state could not be 
>treated as synchronized.

As I said, an UPDATE is not used. The state is not
ambiguous, the both views are synchronized.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 23:30:32 +0900

Gao,

>response to the target-refresh request), or a request on the new target 

Only "first" reliable response?
Is it correct?

Regards,
Shinji

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 May 2010 22:18:03 -0400

...

> *[Discussion 2]* Current draft has the text in section 4.2 as:
> 
> The new
> we restrict the UAS send 2xx to Re-INVITE while there's target 
> refresh(or other *non-negotiated-declare*) during it. And if the UAS 
> want to reject something *negotiated*, it can send another 
> Re-INVITE-in-scope UPDATE.

There is always one case when requiring a 2xx response to reinvite is 
totally unacceptable - when it fails authentication. E.g. this could be 
a forged request by a third party. It could even be an attempt by a 
third party to hijack the session by introducing a target change to itself.

There must be other similar cases, such as when the request is malformed.

So IMO requiring a 2xx response is not a successful solution.

	Thanks,
	Paul

---

From: [email-masked]
Date: Tue, 1 Jun 2010 10:37:53 +0800

> So IMO requiring a 2xx response is not a successful solution.

Yes. And I considered this case. 

As authentication failure, UAS should reject the target request directly. 
That is, there *MUST NOT* be any 100rel or other in-scope new request (to 
the new target) to do the commitment of the target request.

In other words, as the UAS commit the target request, there *MUST* be 2xx 
of the Re-INVITE.

Thanks,

Gao

---

From: [email-masked]
Date: Tue, 1 Jun 2010 11:06:14 +0800

> Only "first" reliable response?

This is about the triggering of commitment. After the first reliable 
response or a request to the new target, the target modification is 
committed. 

UAS can send subsequent reliable response with new target.

Thanks,

Gao