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

[OKUMURA Shinji <[e-mail]>]

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 <[e-mail]>
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
>
>On 05/07/2010 9:34 AM, Gonzalo Camarillo wrote:
>> 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