Subject: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 05 Jul 2010 09:34:42 +0300

Hi,

the re-INVITE draft talks about modifications in the session state,
dialog state, and the dialog's remote target. While it is relatively
well understood what we mean by session state and the dialog's remote
target, we do not really have a good definition for dialog state.

We have discussed it in the past and what people had in mind were things
such as called party identity. However, the draft is too vague at this
point; it should be more precise regarding which piece of "dialog state"
the rules in the draft apply to.

My suggestion would be to have the draft talk only about session state
and the dialog's remote target, and forget about any other dialog state.
New extensions whose parameters can be modified by re-INVITEs can
specify their own rules, possibly referring to this draft and using the
rules defined in it by reference. In this way, the applicability of this
draft would be much clearer.

Comments?

Thanks,

Gonzalo

---

From: [email-masked]
Date: Mon, 5 Jul 2010 17:11:57 +0800

Hi Gonzalo,

Fisrt, I am glad to hear about this suggestion. And I once proposed the 
similar idea, as putting things which has been cleared forward, and make 
the basic rules(such as *in use* way for O/A usage, and notify way for 
remote target) as reference for other *dialog state* usages, in separate 
drafts.

Second, I once do one proposal for the other *dialog state* usages in one 
previous mail:
http://www.ietf.org/mail-archive/web/sipcore/current/msg02850.html
I think we might need several months's discussion for such topics.

Third, I suggest one expert(Gonzalo, Paul, or Robert?) to draft out one 
draft, to collect requirments for the remaining topics(the other *dialog 
state* usages's) which still need normative definition/clarification. This 
memo would have the following meanings:
1. To figure out current status of all SIP Core standard;
2. As memo of conclusions for points.
3. If someday, we need 3261bis, this might be a not bad start. 

Thanks,

Gao

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

Gonzalo Camarillo <[email-masked]> 
发件人:  [email-masked]
2010-07-05 14:34

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

主题
[sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

Hi,

Comments?

Thanks,

Gonzalo

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Jul 2010 10:35:24 -0400

Gonzalo,

> draft would be much clearer.

This is one of those areas that has bugged me for a long time.
3261 defines dialog state, but the definitions are spread through the 
text, and subject to interpretation. Things identifiable in 3261:

- remote URI
- local URI
- dialog id
   * local tag
   * remote tag
   * call-id
- local sequence number
- remote sequence number
- route set
- secure flag

- early / final
- local SDP
- remote SDP

(I just coined terms local/remote SDP. AFAIK its never mentioned as 
state, but clearly it is.) Of course there is no distinction between 
dialog state and dialog usage state - that distinction was made later. 
But based on subsequent refinements we now know that most of the above 
is generic dialog state, *except* for the local/remote SDP and the 
early/final attribute. (Early dialogs can only arise with INVITE.)

Clearly *reinvite* cannot really affect non-invite usages. So I think 
attributes of non-invite usages are out of scope for this draft.

I don't know of an exhaustive list of dialog state or invite-usage state 
that has been introduced in other documents. And in fact its not 
especially clear which things should be considered dialog/dialog-usage 
state, vs. just being transient/transaction state.

I do think it would be a good thing if an exhaustive list of dialog and 
dialog-usage state was documented, and possibly made an IANA registry. 
But the information certainly doesn't change much, or often, so maybe we 
can get by without that.

Its interesting that the "rollback" we have been so concerned with 
regarding reinvite in fact does not impact *any* of the *dialog* state - 
only some of the invite-usage state, and not all of that. So the 
rollback is really very limited, and should probably be described in 
terms of what it *does* affect rather than what it does not affect.

The modifications to the remote target discussed in this draft are 
indeed about *dialog* state, which affects other usages. But the 
*issues* about the remote target change are only applicable to INVITE, 
because only it can use provisional responses. The update of remote and 
local targets in other (i.e. subscribe) usages is straightforward.

You mention p-called-party, to which one might add p-asserted-id, 
p-preferred-id, etc. Its not at all clear to me whether those are even 
intended to be stateful. If they are, then they are dialog state, not 
invite-usage state.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 15 Jul 2010 13:26:12 +0300

Hi,

thanks for the feedback I have received on and off list. We seem to have
consensus on reducing the scope of the draft to session state and target
refreshes. That is great because it allows us to hugely simplify the
rules to avoid glare conditions (this is something a few of you have
requested on the list in the past). I have put together a new revision
of the draft, which you can fetch from:

http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-01.txt

In addition to adjusting the scope of the draft and simplifying the
glare-related rules, I have also added a few clarifications to Section 5
in response to Robert's AD review.

Let me know if you have any comments.

Thanks,

Gonzalo

---

From: [email-masked]
Date: Mon, 19 Jul 2010 11:40:14 +0800

Hi Gonzalo,

I found time to read this version on weekend. And there are three main 
points:

1. Glare Situations(section 3.5)
As the new way, this part is relatively simple now. And the new way is 
sending a new refresh usage Re-INVITE to synchronize state for any glare 
situations.
This is simple, and effective. So, I am OK at this point.

2. Race Conditions and Target Refreshes(section 4.8)
To disallow target refreshes in unreliable response can solve this 
problem. And in fact, I think it is a nice way, as do "Target Refreshes" 
in unreliable response is unreliable. So, I'm OK with it.
As this rule's meaning is more than glare issue, so we may put this rule 
in a new section, and only mention in section 4.8 that galre problem here 
can be solved by this rule.

3. Section 5
I am OK with this section's revision.

Thanks,

Gao

2010-07-15 18:26

收件人
Gonzalo Camarillo <[email-masked]>
抄送
SIPCORE <[email-masked]>
主题
Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite

Hi,

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 19 Jul 2010 09:35:58 +0300

Hi Gao,

thanks for your answers. Regarding Section 4.8, I agree with you it is
not about glare. That is why the title of the section does not mention
glare. It mentions race conditions. I think we are OK.

Thanks for your comments,

Gonzalo

On 19/07/2010 6:40 AM, [email-masked] wrote:
> in a new section, and only mention in section 4.8 that galre problem
> here can be solved by this rule.
> 
> 3. Section 5
> *Gonzalo Camarillo <[email-masked]>*

---

From: [email-masked]
Date: Mon, 19 Jul 2010 14:46:00 +0800

Hi Gonzalo,

Your explanation works for me at this small point.

Then, I am OK with all the three points.

Cheers,

Gao 

2010-07-19 14:35

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

Hi Gao,

Gonzalo

> ZTE Information Security Notice: The information contained in this mail 
is solely property of the sender's organization. This mail communication 
is confidential. Recipients named above are obligated to maintain secrecy 
and are not permitted to disclose the contents of this communication to 
others.
> This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
originator of the message. Any views expressed in this message are those 
of the individual sender.

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 23 Jul 2010 18:10:10 +0900

Hi Gonzalo,

I have some comments and questions.

>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 session (the UAC uses the criteria in
>   Section 3.3 in order to decide whether or not changes have been
>   executed for a particular stream).

As I have said many times, this restriction is excessive.
I propose as follows;
s/which changes have been already executed/which changes
have been already executed by an UPDATE transaction/

>4.8.  Race Conditions and Target Refreshes
The rule for a UAS is looking good. But if a UAS sends a
reliable response and an UPDATE request in order to refresh
its local target, what should a UAC do?

In the cases below, UA-B should not use a 18x-rel.
But UA-A can not reject the 18x-rel and prohibit UA-B from
using the 18x-rel.

Should UA-A reject this UPDATE? or ignore a Contact of 18x-rel?
Otherwise should UA-A send another UPDATE to confirm a remote target?

       A                               B
       |                               |
     s0|re-INVITE (offer1)             |s0
       |------------------------------>|
       |               18x-rel(answer1)|
       |<------------------------------|
     s1|PRACK                          |s1
	   |------------------------------>|
	   |                        2xx-PRA|
	   |<------------------------------|<-+
       |                               |  |
       |                   UPDATE(m:c1)|  |
       |<-------------\  /=============|  |
       |               \/              |  |
       |               /\ 18x-rel(m:c2)|  |
       |<=============/  \-------------|  |
       |                               |  | accept UPDATE
       |                               |  |
       |                               |  v

       A                               B
       |                               |
     s0|re-INVITE (offer1)             |s0
       |------------------------------>|
       |               18x-rel(answer1)|
       |<------------------------------|
     s1|PRACK                          |s1
	   |------------------------------>|
	   |                        2xx-PRA|
	   |<------------------------------|<-+
       |                               |  |
       |                  18x-rel(m:c1)|  |
       |<=============\  /-------------|  |
       |               \/              |  |
       |               /\  UPDATE(m:c2)|  |
       |<-------------/  \=============|  |
       |                               |  | accept UPDATE
       |                               |  |
       |                               |  v

>5.2.  Problems with UAs Losing their Contact
>   On detecting some of
>   these errors, UAs following the rules specified in RFC 3261 [RFC3261]
>   will terminate the dialog.

According to RFC5057, 408 affects an only transaction.
Just to be sure, I think it is better to describe about RFC5057.

>5.3.  UAS Losing its Contact: UAC Behavior
>   When a UAS that moves to a new contact and loses its old contact
>   generates a non-2xx final response to the re-INVITE, it will not be
>   able to receive the ACK request.  The entity receiving the response
>   and, thus, generating the ACK request will either get a transport
>   error or a timeout error, which, as described in Section 8.1.3.1 of
>   RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable)
>   response and as a 408 (Request Timeout) response, respectively.

IMO It is not described in RFC3261 that a transport error for
sending ACK is treated as an error for re-INVITE request.

>5.5.  UAC Losing its Contact: UAC Behavior

Even though the UAC probably can't receive a response to the
CANCEL requst, should it send CANCEL?

When a UAS receives the CANCEL request, which code should
it return to a UAC? 2xx or 487?

Thanks,
Shinji

Gonzalo Camarillo <[email-masked]>
Thu, 15 Jul 2010 13:26:12 +0300

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 23 Jul 2010 14:19:47 +0300

Hi Shinji,

thanks for your comments. Answers inline:

> have been already executed by an UPDATE transaction/

We have discussed this issue many times. At this point, we are not
going to reopen all the discussions we had on this in the past.

> Otherwise should UA-A send another UPDATE to confirm a remote target?

The draft identifies the problem and specifies a solution to it. Of
course, a legacy UAS could act as you describe. However, such behavior
would only be a problem in certain race conditions. So, I do not think
it is worthwhile specifying more rules to cover that type of legacy UAS.
With all the background in the draft, implementers should be able to
understand what types of different behaviors they can expect from legacy
UAs.

>      s0|re-INVITE (offer1)             |s0

Section 5.2 of RFC 5057 states that the 408 affects a dialog usage. In
this case, the invite usage.

> sending ACK is treated as an error for re-INVITE request.

As I noted before, the background material in the draft is given so that
implementers understand what to expect from different legacy UAs. I am
sure some UAs act as you describe and do not relate ACK errors to the
re-INVITE. However, others will do that.

> CANCEL requst, should it send CANCEL?

Yes, because the CANCEL will allow the UAC to initiate a new re-INVITE
transaction (if needed) from its new location. The CANCEL will
synchronize the UAs.

> it return to a UAC? 2xx or 487?

The UAS will apply normal CANCEL processing, which typically consists of
returning a 487 to the original request and a 200 to the CANCEL.

Thanks,

Gonzalo