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

[Gonzalo Camarillo <[e-mail]>]

Hi Shinji,

thanks for your comments. Answers inline:

On 23/07/2010 12:10 PM, OKUMURA Shinji wrote:
> 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/

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.


>> 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?

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.


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

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


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


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.


>> 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?

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.

> When a UAS receives the CANCEL request, which code should
> 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