Subject: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Jun 2010 10:11:03 +0300

Folks,

per the our mailing list discussions, I have edited Section 3.5 of the
draft so that the rules to detect and address glare conditions are
clearer, more explicit, and less restrictive. Let me know if the new
text meets any of these three goals :o)

Below you have the new Section 3.5. You can check the old version at:

http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.5

Once we agree on the contents of this section, Section 4.5 will not need
to define further rules.

Comments are welcome.

Thanks,

Gonzalo

3.5.  Glare Situations

   Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user
   agent receiving an offer after having sent one but before having
   received an answer to it.  That section specifies rules to avoid
   glare situations in most cases.  When despite following those rules a
   glare conditions occurs (as a result of a race condition), it is
   handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261].
   The UAS returns a 491 (Request Pending) response and the UAC retries
   the offer after a randomly-selected time, which depends on which user
   agent is the owner of the Call-ID of the dialog.  The rules in RFC
   3261 [RFC3261] not only cover collisions between re-INVITEs that
   contain offers; they cover collisions between two re-INVITEs in
   general, even if they do not contain offers.  Sections 5.2 and 5.3 of
   RFC 3311 [RFC3311] extend those rules to also cover collisions
   between an UPDATE request carrying an offer and another message
   (UPDATE, PRACK or INVITE) also carrying an offer.

   Since re-INVITEs and UPDATEs can change not only the session state
   but also the dialog state, collisions among them need to be avoided
   even when they do not carry offers.  Therefore, this document extends
   the rules just described to also cover collisions that do not involve
   offers.

   A UA that receives an UPDATE request on a dialog while an UPDATE
   request it had sent on that dialog is in progress MUST return a 491
   (Request Pending) response to the received UPDATE request.

   If a UA receives a re-INVITE while an UPDATE request it had sent on
   that dialog is in progress and after receiving the re-INVITE the UA
   receives a 2xx response to the UPDATE request, the UA SHOULD generate
   a new UPDATE request or a reliable response to the re-INVITE in order
   to make sure that both UAs have a common view of the state of the
   session, as described in Section 3.4.

   The rules in RFC 3261 [RFC3261] do not cover collisions between an
   UPDATE request and a reliable response to a re-INVITE (non-2xx final
   responses to the re-INVITE are also considered reliable responses).
   Since both the UPDATE request and the reliable response could be
   requesting changes to the dialog or session state, it would not be
   clear which changes would need to be executed first.

   If the UAS of a re-INVITE transaction receives and UPDATE request
   after having sent a reliable response to the re-INVITE but before
   having received the corresponding ACK or PRACK request, the UA SHOULD
   return a 491 (Request Pending) response to the UPDATE request.  If
   the UAC of a re-INVITE transaction sends an UPDATE request, receives
   a reliable 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.

   If a UA receives a 491 response to an UPDATE request, it follows the
   rules in Section 5.3 of RFC 3311 [RFC3311].

---

From: [email-masked]
Date: Thu, 24 Jun 2010 18:48:59 +0800

Hi Gonzalo,

Thanks for your work at this topic.

Two comments inlines.

Cheers,

Gao

>    clear which changes would need to be executed first.

Here, the text points out the problem, but without handling rule. I guess 
adding some words like "re-send a new Re-INVITE or UPDATE to synchronize 
state" would be better.

>    return a 491 (Request Pending) response to the UPDATE request. 

This rule would make non-offer/answer UPDATE out side of PRACK/200OK of 
100rel 18x. But I am OK with this, because I saw many UAs can not handle 
parallel UPDATE with PRACK/200OK. And current UAC of this parallel UPDATE 
might not need to change to send the UPDATE after the PRACK/200OK 
designedly, as the UAS(of UPDATE) would reject it by 491 and the UA can 
re-send it later.

But I am not sure whether the Ini-INVITE should have the same rule for 
this case.
 
>If the UAC of a re-INVITE transaction sends an UPDATE request, receives

--------------------------------------------------------
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: Thu, 24 Jun 2010 20:05:41 +0900

Hi Gonzalo,

Gonzalo Camarillo <[email-masked]>
Thu, 24 Jun 2010 10:11:03 +0300
>   (Request Pending) response to the received UPDATE request.

I like this rule.

>   session, as described in Section 3.4.

Various cases are possible,

    A                                  B
    |                                  |
    |UPDATE(offer1)                    |
    |=================================>|
    |                  2xx-UPD(answer1)|
    |<---------\  /====================|
    |           \/                     |
    |           /\    re-INVITE(offer2)|
    |<=========/  \--------------------|
    |491-INV                           |
    |--------------------------------->|
    |                                  |

    A                                  B
    |                                  |
    |UPDATE(offer1)   re-INVITE(offer2)|
    |=============\  /-----------------|
    |              \/                  |
    |              /\                  |
    |<------------/  \================>|
    |491-INV                           |
    |--------------------------------->|
    |                           491-UPD|
    |<=================================|
    |                                  |

At least, if the UPDATE has an offer, I think the UA-A SHOULD
return a 491 response to the reINVITE.
This is simpler and does't contradict a current rule.

>   return a 491 (Request Pending) response to the UPDATE request.

I think this rule is more restrictive.
IMO;
In case that the reliable response is 18x, the UA SHOULD return a "500" response.
In case that the reliable response is 2xx;
    If the 2xx carries an offer, the UA SHOULD return a "500" response.
    Otherwise, the UA MAY return a 2xx response.
In case that the reliable response is 4xx, the UA MAY return a 2xx response.

>   If

In case that the reliable response is 4xx, this rule is necessary
from an offer-answer perspective.

In case that the reliable response is 2xx or 18x, this rule seems
to be also necessary from a remote-target perspective.
But I'm not sure at present.

>   rules in Section 5.3 of RFC 3311 [RFC3311].

And I think the rules are insufficient.
In the cases below, UA-A SHOULD send new offer after sending ACK.

               A                               B
               |                               |
             s0|re-INVITE (offer1)             |s0
               |------------------------------>|
               |               18x-rel(answer1)|
               |<------------------------------|
             s1|                        non-2xx|s1
               |                /--------------|<-+
               |UPDATE(offer2) /               |s0|
               |==============/===============>|  | accept UPDATE
               |             / 2xx-UPD(answer2)|  |
               |<===========/==================|  |
             s2|           /       ACK         |s2|
               |<---------/        ----------->|  |
             s0|ACK                            |  |
               |------------->                 |  |
               |UPDATE(offer0)                 |  |
               |==============================>|  |
               |               2xx-UPD(answer0)|  |
               |<==============================|  |
             s0|                               |s0|
               |                               |  v

               A                               B
               |                               |
             s0|re-INVITE (offer1)             |s0
               |------------------------------>|
               |               18x-rel(answer1)|
               |<------------------------------|
             s1|                        non-2xx|s1
               |                  /------------|<-+
               |                 /    ACK      |s0|
               |                /     -------->|  | accept UPDATE
               |               / UPDATE(offer2)|  |
               |<=============/================|  |
               |2xx-UPD(answer2)               |  |
               |============/=================>|  |
             s2|           /                   |s2|
               |<---------/                    |  |
             s0|ACK                            |  |
               |----------->                   |  |
               |UPDATE(offer0)                 |  |
               |==============================>|  |
               |               2xx-UPD(answer0)|  |
               |<==============================|  |
             s0|                               |s0|
               |                               |  v

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 25 Jun 2010 15:11:22 +0900

Hi,

>   return a 491 (Request Pending) response to the UPDATE request.

For reference, here are my opinion regarding an interworking
of UPDATE and re-INVITE from an offer-answer perspective.

Case 1: One or more O/A exchange and then 2xx to re-INVITE with an offer.
                                            A                      B
                                            |                      |
                                            |INVITE(offer)         |
                     +----->             +->|--------------------->|
                     |                   |  |           1xx(answer)|
   Don't send UPDATE | Don't send INVITE |  |<---------------------|
   491 to UPDATE     | 491 to INVITE     |  |PRACK                 |
                     |                   |  |--------------------->|
                     |                   |  |               2xx-PRA|
                     +----->             |  |<---------------------|
   may send UPDATE   |                   |  |                      |
   may acceptUPDATE  |                   |  |                   2xx|
                     |                   +->|<---------------------|
                     | may send INVITE   |  |                      |
                     | may accept INVITE |  |ACK                   |
                     |                   |  |--------------------->|
                     v                   v  |                      |

   A                      B
   |                      |
   |INVITE(offer)         |
   |--------------------->|<-+             <-----+
   |           1xx(answer)|  |                   |
   |<---------------------|  | Don't send INVITE | Don't send UPDATE
   |PRACK                 |  | 500 to INVITE     | 500 to UPDATE
   |--------------------->|  |                   |
   |               2xx-PRA|  |                   |
   |<---------------------|  |             <-----+
   |                      |  |                   | may send UPDATE
   |                   2xx|  |                   | may acceptUPDATE
   |<---------------------|<-+                   |
   |                      |  | may send INVITE   |
   |ACK                   |  | may accept INVITE |
   |--------------------->|  |                   |
   |                      |  v                   v

Case 2: One or more O/A exchange and then 4xx to re-INVITE with an offer.
                                            A                      B
   [UAC behavior]                           |                      |
                                            |INVITE(offer)         |
                     +----->             +->|--------------------->|
                     |                   |  |           1xx(answer)|
   Don't send UPDATE | Don't send INVITE |  |<---------------------|
   491 to UPDATE     | 491 to INVITE     |  |PRACK                 |
                     |                   |  |--------------------->|
                     |                   |  |               2xx-PRA|
                     +----->             |  |<---------------------|
   may send UPDATE   |                   |  |                      |
   may acceptUPDATE  |                   |  |               non-2xx|
                     |                   +->|<---------------------|
                     |                      |                      |
                     |                      |ACK          ACK      |
                     |                   +->|--------->   -------->|
                     v                   v  |                      |
                 (4xx and ACk to it are atomic.)

   A                      B
   |                      |    [UAS behavior]
   |INVITE(offer)         |
   |--------------------->|<-+             <-----+
   |           1xx(answer)|  |                   |
   |<---------------------|  | Don't send INVITE | Don't send UPDATE
   |PRACK                 |  | 500 to INVITE     | 500 to UPDATE
   |--------------------->|  |                   |
   |               2xx-PRA|  |                   |
   |<---------------------|  |             <-----+
   |                      |  |                   | may send UPDATE
   |               non-2xx|  |                   | may accept UPDATE
   |<---------------------|<-+                   |
   |                      |  | Don't send INVITE |
   |ACK          ACK      |  | may accept INVITE |
   |--------->   -------->|<-+                   |
   |                      |  v                   v

Regards,
Shinji

---

From: [email-masked]
Date: Fri, 25 Jun 2010 14:50:32 +0800

Hi Paul, Brett, Shinji & Gonzalo,

In fact, we are the people really care about the "Glare conditions" of 
SIP. Though it is a relative narrow topic, but it is really important for 
equipment interworking issue.

I'd like to propose a working-process for this issue:

Once Paul talked about which place is more proper for thisissue, O/A draft 
or Re-INVITE draft? 
//http://www.ietf.org/mail-archive/web/sipcore/current/msg02862.html

It also puzzled me. And after my thought, my suggestion is:

First, we should evaluate whether we need normative defintion for this 
issue? //My point is YES.

Then, if we need normative one, we can do it in Re-INVITE draft. And at 
the same time, we need a relative complex BCP suggestion in O/A draft 
along this normative track(More examples, illustration should be in O/A 
draft). 

Thanks,

Gao

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

OKUMURA Shinji <[email-masked]> 
发件人:  [email-masked]
2010-06-25 14:11

收件人
SIPCORE <[email-masked]>
抄送

主题
Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite

Hi,

   A                      B
   |                      |
   |INVITE(offer)         |

   A                      B
   |                      |    [UAS behavior]
   |INVITE(offer)         |

Regards,
Shinji

>   rules in Section 5.3 of RFC 3311 [RFC3311].
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jun 2010 14:59:03 +0300

Hi Gao,

thanks for your comments. My answer inline:

> Here, the text points out the problem, but without handling rule. I
> guess adding some words like "re-send a new Re-INVITE or UPDATE to
> synchronize state" would be better.

the text follows the same structure in all the section. First the issue
at hand is explained and then normative language to resolve the issue is
given. The normative rules to address the issue described in this
paragraph are in the next paragraph.

Thanks,

Gonzalo

---

From: Harbhanu <[email-masked]>
Date: Tue, 29 Jun 2010 17:37:02 +0530

Typo highlighted below:-

   If the UAS of a re-INVITE transaction receives **and UPDATE** (Should be
'an' UPDATE.. right??) request after having sent a reliable response to the
re-INVITE but before having received the corresponding ACK or PRACK request,
the UA SHOULD return a 491 (Request Pending) response to the UPDATE request.

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!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo Camarillo
Sent: Thursday, June 24, 2010 12:41 PM
To: SIPCORE
Subject: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite

Folks,

Comments are welcome.

Thanks,

Gonzalo

3.5.  Glare Situations

---

From: [email-masked]
Date: Tue, 29 Jun 2010 20:08:00 +0800

Hi Gonzalo,

OK. Then the handling way would be rejecting the UPDATE by 491, in the 
next paragraph.

And I am OK with it.

Thanks,

Gao

2010-06-29 19:59

收件人
"[email-masked]" <[email-masked]>
抄送
SIPCORE <[email-masked]>
主题
Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite

Hi Gao,

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jun 2010 15:21:20 +0300

Hi Shinji,

thanks for your comments. My answers inline:

> Various cases are possible,

I will add the following rule:

   A UA that receives a re-INVITE on a dialog while an UPDATE
   request it had sent on that dialog is in progress MUST return a 491
   (Request Pending) response to the re-INVITE.

> In case that the reliable response is 4xx, the UA MAY return a 2xx response.

No, these rules would not address the glare situation.

> from an offer-answer perspective.

Exactly.

> to be also necessary from a remote-target perspective.

Exactly.

> But I'm not sure at present.

Your understanding is correct.

>              s0|re-INVITE (offer1)             |s0

Yes, that rule is already specified in Section 3.4 of the draft.

http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.4

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jun 2010 15:36:34 +0300

Yes, Gao.

Thanks!

Gonzalo

On 29/06/2010 3:08 PM, [email-masked] wrote:
> *Gonzalo Camarillo <[email-masked]>*
> 
> 2010-06-29 19:59
> 
> 	
> 收件人

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jun 2010 15:40:56 +0300

Hi Harbhanu,

I have just fixed this typo in my working copy of the draft.

Thanks!

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 29 Jun 2010 15:25:47 +0300

Hi Gao,

thanks for your comments. The scope of the re-INVITE draft is not going
to change at this point. We are going to clarify the glare-related
rules, per our mailing list discussions, and then progress the draft as
planned.

In addition to the changes related to glare situations, I will also
address a set of comments I received from Robert as part of his AD
review of the draft.

Thanks,

Gonzalo

On 25/06/2010 9:50 AM, [email-masked] wrote:
> SIP. Though it is a relative narrow topic, but it is really important
> for equipment interworking issue.
> 
> Once Paul talked about which place is more proper for thisissue, O/A
> draft or Re-INVITE draft?  
> *OKUMURA Shinji <[email-masked]>*

---

From: Brett Tate <[email-masked]>
Date: Tue, 29 Jun 2010 06:08:54 -0700

Hi Gonzalo,

Thanks for addressing most of my concerns.  Comments are inline.

> text meets any of these three goals :o)

Yes; the text addresses my concerns about being too restricted on an early dialog.

If it isn't too late, I would still like the draft to clarify rfc3261 concerning updating dialog's route set and remote target per INVITE 101-299 response's Contact and Record-Route during call setup.  It was requested within the following thread.

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

> Once we agree on the contents of this section, Section 4.5 
> will not need to define further rules.

Do you plan to remove or reword section 4.5?

> even when they do not carry offers.  Therefore, this document 
> extends the rules just described to also cover collisions that do 
> not involve offers.

The last sentence is likely good enough; however to help avoid some from interpreting the non-normative text normatively, I recommend changing "cover collisions" to "cover some collisions".

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 30 Jun 2010 15:27:03 +0900

Hi Gonzalo,

Thanks for your reply.
My comments inline.

Gonzalo Camarillo <[email-masked]>
Tue, 29 Jun 2010 15:21:20 +0300
>thanks for your comments. My answers inline:
(snip)
>No, these rules would not address the glare situation.

I am very interested in this topic. Laying aside the
response code, I don't understand the reason why these rules
would not address the glare situation.
Please explain the reason.

In below cases, if a UAS returns a 2xx to the UPDATE, IMO
no ploblem would be occured.

               A                               B
               |                               |
             s0|re-INVITE(offer1)              |s0
               |------------------------------>|
               |                   2xx(answer1)|
               |<------------------------------|<-+
             s1|ACK                            |s1|
               |--------------\                |  |
               |UPDATE(offer2) \               |  |
               |================\=============>|  | accept PDATE
               |               2xx-UPD(answer2)|  |
               |<=================\============|  |
             s2|                   \           |s2|
               |                    \--------->|  |
               |                               |  v

               A                               B
               |                               |
             s0|re-INVITE(offer1)              |s0
               |------------------------------>|
               |                        non-2xx|
               |<------------------------------|<-+
             s0|ACK                            |s0|
               |-------------->                |  |
               |UPDATE(offer2)                 |  |
               |==============================>|  | accept PDATE
               |               2xx-UPD(answer2)|  |
               |<==============================|  |
             s2|                    ACK        |s2|
               |                    ---------->|  |
               |                               |  v

               A                               B
               |                               |
             s0|re-INVITE (offer1)             |s0
               |------------------------------>|
               |               18x-rel(answer1)|
               |<------------------------------|
             s1|PRACK                          |s1
               |------------------------------>|
               |                        2xx-PRA|
               |<------------------------------|
               |                            2xx|
               |                /--------------|<-+
               |UPDATE(offer2) /               |  |
               |==============/===============>|  | accept PDATE
               |             / 2xx-UPD(answer2)|  |
               |<===========/==================|  |
             s2|           /                   |s2|
               |<---------/                    |  |
               |ACK                            |  |
               |------------------------------>|  |
               |                               |  v

               A                               B
               |                               |
             s1|PRACK                          |s1
               |                        2xx-PRA|
               |                        non-2xx|
               |==============/===============>|  | accept PDATE

>http://tools.ietf.org/html/draft-ietf-sipcore-reinvite-04#section-3.4

You are right. I delude myself.
Apart from that, The behavior of UAC seems to be separated
in Section 3.4 and 3.5. I think it would be better to
describe the whole behavior of UAC (including a glare situation)
in Section 3.4.

Regards,
Shinji

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jun 2010 10:25:08 +0300

Hi Shinji,

> no ploblem would be occured.

as we discussed in the past, the collision of two given messages may or
may not be a problem. For example, two UPDATEs colliding each of them
updating a different parameter would not be a problem... but if they
update the same parameter the collision would get both UAs out of synch.
For the sake of simplicity, instead of having UAs implement complex
rules to figure out if a particular collision would cause problems, we
specify general rules that are (relatively) easy to implement by user
agents.

So, let's take your example below

>              s0|re-INVITE (offer1)             |s0

both the 2xx to the INVITE and the 2xx to the UPDATE can update the
dialog's target. As you see, the UAC receives them in a different order
than they were sent. So, for the UAC the latest target refresh was the
2xx to the INVITE but for the UAS the latest target refresh was the 2xx
to the UPDATE.

> describe the whole behavior of UAC (including a glare situation)

I will look into this while making the remaining changes I have to
introduce.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jun 2010 10:31:06 +0300

Hi Brett,

> Yes; the text addresses my concerns about being too restricted on an 

perfect.

> If it isn't too late, I would still like the draft to clarify
> rfc3261 concerning updating dialog's route set and remote target per
> INVITE 101-299 response's Contact and Record-Route during call setup.
> It was requested within the following thread.
> 

yes, I remember your request and I remember addressing it. For example,
Section 4 of the draft explicitly states:

  "Section 4.2 specifies new rules for the handing of target-
   refresh requests.  Note that the new rules apply to any target-
   refresh request, not only to re-INVITEs."

Let me know if there is something in particular you want me to change in
the draft regarding this issue.

>> Once we agree on the contents of this section, Section 4.5 will
>> not need to define further rules.
> 

I will look into the structure of te draft once I have addressed all
remaining comments.
> The last sentence is likely good enough; however to help avoid some 
> from interpreting the non-normative text normatively, I recommend 
> changing "cover collisions" to "cover some collisions".

Fixed.

Thanks,

Gonzalo

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 30 Jun 2010 20:10:57 +0900

Hi Gonzalo,

My comments inline.

Gonzalo Camarillo <[email-masked]>
Wed, 30 Jun 2010 10:25:08 +0300
>specify general rules that are (relatively) easy to implement by user

IMO only the rule in a particular collisions is simplified,
rule set is not always simplified as a whole.
And I think normative restrictions can never be too small.

In comparison of our proposal,

  [mine]
	  A                               B
	  |                               |
	  |                            2xx|  |
	  |                /--------------|  |

  [yours]
	  A                               B
	  |                               |
	s0|re-INVITE (offer1)             |s0
	  |------------------------------>|
	  |               18x-rel(answer1)|
	  |<------------------------------|
	s1|PRACK                          |s1
	  |------------------------------>|
	  |                        2xx-PRA|
	  |<------------------------------|<-+
	  |                            2xx|  | accept PDATE
	  |                /--------------|<-+
	  |UPDATE(offer2) /               |  |
	  |==============/===============>|  | reject PDATE
	  |             / 2xx-UPD(answer2)|  |
	  |<===========/==================|  |
	s2|           /                   |s2|
	  |<---------/                    |  |
	  |ACK                            |  |
	  |------------------------------>|--+
	  |                               |  v accept PDATE

IMO your rules don't seem to be always easy to implement by user
agents.

>From an offer-answer perspective, 2xx to the UPDATE doesn't
occur a ploblem.

>From a remote-target perspective, the consideration is
more complicate.
There is a variant case for a UAS.

	  A                               B
	  |                               |
	s0|re-INVITE (offer1)             |s0
	  |------------------------------>|
	  |               18x-rel(answer1)|
	  |<------------------------------|
	s1|PRACK                          |s1
	  |------------------------------>|
	  |                        2xx-PRA|
	  |<------------------------------|<-+
	  |                            2xx|  |
	  |<------------------------------|  |
	  |ACK                            |  |
	  |-------------\                 |  |
	  |UPDATE(offer2)\                |  |
	  |===============\==============>|  | accept PDATE
	  |               2xx-UPD(answer2)|  |
	  |<================\=============|  |
	s2|                  \            |s2|
	  |                   \---------->|  |
	  |                               |  v

In this case, 2xx to the UPDATE is no problem.
And this 2xx to the UPDATE has one clear advantage.
UAC(A) can refresh local target successfully.

After all, UAC should send UPDATE or re-INVITE to confirm a
remote target according to circumstances, even if the UPDATE
doesn't carry an offer and UAS send a 2xx to a re-INVITE.

At the very start I think this 2xx to UPDATE should have the
same Contact whth 2xx to re-INVITE.

And for reference, if this UPDATE is re-INVITE, according to
current text UAS may accept the re-INVITE.

Regards,
Shinji

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jun 2010 15:03:27 +0300

Hi Shinji,

thanks for your comments. I already responded to your first example in
my previous email. In your second example, the ACK (which does not carry
an answer) is not a problem because it is not a target refresh request.

Thanks,

Gonzalo

---

From: Brett Tate <[email-masked]>
Date: Wed, 30 Jun 2010 05:20:42 -0700

> > rfc3261 concerning updating dialog's route set and remote target 
> > per INVITE 101-299 response's Contact and Record-Route during 
> > call setup.  It was requested within the following thread.
> >
> yes, I remember your request and I remember addressing it. 
> For example, Section 4 of the draft explicitly states:
> 
> Let me know if there is something in particular you want me to 
> change in the draft regarding this issue.

The quote and section 4's subsections provide no clarity concerning INVITE 101-299 response's Contact and Record-Route during call setup (i.e. INVITE versus re-INVITE).

Concerning INVITE (not re-INVITE) 101-299 response handling on an existing early dialog, I would like the draft to clarify the rfc3261 rules:

- When MUST/SHOULD/MAY the UAC replace the dialog's remote target URI with the URI from the Contact header field from 101-199 response?

- When MUST/SHOULD/MAY the UAC update the dialog's route set using the Record-Route headers from 101-199 response?

- When MUST/SHOULD/MAY the UAC replace the dialog's remote target URI with the URI from the Contact header field from 2xx response?

- When MUST/SHOULD/MAY the UAC update the dialog's route set using the Record-Route headers from 2xx response?

The following rule only discusses reliable provisional responses.  What are rules for non reliable provisional responses?

Draft-ietf-sipcore-reinvite section 4.3: "If the UAC receives a reliable provisional response or a 2xx response to the target-refresh request, the UAC MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present."

Thanks,
Brett

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jun 2010 15:28:20 +0300

Hi Brett,

> The quote and section 4's subsections provide no clarity concerning
> INVITE 101-299 response's Contact and Record-Route during call setup
> (i.e. INVITE versus re-INVITE).
> 
> Concerning INVITE (not re-INVITE) 101-299 response handling on an
> existing early dialog, I would like the draft to clarify the rfc3261
> rules:

OK, you want the text to be more explicit about what happens with early
dialogs... I will look into that.

> The following rule only discusses reliable provisional responses.
> What are rules for non reliable provisional responses?

non-reliable responses do not refresh the target because SIP does not
provide any type of ordering for them. I can clarify that if you think
it is unclear.

Thanks,

Gonzalo

---

From: Brett Tate <[email-masked]>
Date: Wed, 30 Jun 2010 05:53:01 -0700

> provide any type of ordering for them. I can clarify that if you think

Yes; the rule/reason should be clearly documented since there are vendors that MAY be sending such target changes and MAY be honoring such a target change because of lack of 100rel and UPDATE support (or other reasons).  Thus if the rule is that they MUST/SHOULD NOT be sending/honoring such a target change, it should be documented.

Thanks,
Brett

---

From: [email-masked]
Date: Wed, 30 Jun 2010 21:14:05 +0800

Hi Gonzalo,

> dialogs... I will look into that.

I am OK with adding text about Ini-INVITE. 
And I think that, it might better to add some kind of remark for the 
Ini-INVITE topics in the text, in the Abstract or Introduction sections, 
as the name of the text is for Re-INVITE :)

> provide any type of ordering for them. I can clarify that if you think

+1. As explicitly text would make thing clear for interworking issue.

Thanks,

Gao

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jun 2010 09:43:37 -0400

> provide any type of ordering for them. I can clarify that if you think

Hmm. I think that is debatable.

That logic would suggest that non-reliable provisionals also could not 
establish an early dialog in the first place, since there might have 
been more than one with different targets that got reordered.

My reading of 3261 and 3311 leaves me with the conclusion that I could 
receive a non-reliable provisional, consider that to establish an early 
dialog, and then send an UPDATE, without ever using 100rel.

OTOH, there is logic to your argument. So maybe what you propose is the 
"right" solution even if it is to some extent incompatible with things 
as they stand. If so, then there should be an additional explicit 
statement that non-reliable provisionals never establish an early dialog.

That would also mean that INFO could not be used before 2xx unless 
100rel was used to establish the early dialog.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jun 2010 16:56:09 +0300

Hi Brett,

> dialogs... I will look into that.

I propose to address early dialogs by adding a new section right after
Section 4.5 (the new section would be 4.6) as follows:

4.6 Early Dialogs

The rules given in this section about which messages can refresh the
target of a dialog also apply to early dialogs created by an initial
INVITE transaction. Additionally, as specified in Section 13.2.2.4 of
RFC 3261 [RFC3261], on receiving a 2xx response to the initial INVITE,
the UAC recomputes the whole route set of the dialog, which transitions
from the "early" state to the "confirmed" state.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 30 Jun 2010 16:58:37 +0300

Hi Gao,

> as the name of the text is for Re-INVITE :)

All that text already talks about target refreshes (in addition to
re-INVITEs). So, it already covers what we are talking about here.

Thanks,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jun 2010 10:07:21 -0400

Replying to myself,

Perhaps the answer here is that a non-reliable response to an initial 
INVITE can indeed establish an early dialog. But then the contact 
address in all subsequent non-reliable responses must remain identical 
to that in the first non-reliable response. And Contacts received in 
non-reliable responses, except the first one received, must be ignored.

That would allow use of INFO and UPDATE in an early dialog without 
100rel, and even a remote target change via the UPDATE in that case.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Wed, 30 Jun 2010 07:34:44 -0700

Hi Gonzalo,

If adjustments are added to the other sections to clearly discuss non reliable provisional responses, the proposal appears to adequately clarify RFC 3261.

My understanding of the new section is that an INVITE 2xx response's updated Contact can trigger the UAC to update the remote-target.  The clarification is not because of the last sentence, it is because of the first sentence.  If this is not true, please explain.

Thanks,
Brett

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Wednesday, June 30, 2010 9:56 AM
> To: Brett Tate
> Cc: SIPCORE
> Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite
> 
> Hi Brett,
>