Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.txt

From: [email-masked]
Date: Sat, 8 May 2010 00:30:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.

	Title           : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP)
	Author(s)       : G. Camarillo, et al.
	Filename        : draft-ietf-sipcore-reinvite-04.txt
	Pages           : 24
	Date            : 2010-05-08

In this document, we clarify the handling of re-INVITEs in SIP.  We
clarify in which situations a UAS (User Agent Server) should generate
a success response and in which situations a UAS should generate an
error response to a re-INVITE.  Additionally, we clarify issues
related to target-refresh requests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: OKUMURA Shinji <[email-masked]>
Date: Wed, 12 May 2010 20:13:08 +0900

Hi,

I have one question and one comment about UAC behavior.

question:
At first, oa status is only audio, and during a next reINVITE
transaction oa status is changed to audio and video. And then
UAS sends a 4xx response to the reINVITE.
In this case which is a new offer UAC should send, only audio
or both of audio and video with zero port?

comment:
If already-executed changes is made by only PRACK transaction,
IMO UAC need not generate a new offer to synchronize both UAs.

Regards,
Shinji

[email-masked]
Sat,  8 May 2010 00:30:02 -0700 (PDT)

---

From: [email-masked]
Date: Wed, 12 May 2010 21:10:02 +0800

> UAS sends a 4xx response to the reINVITE.

If the O/A in Re-INVITE without precondition, the media modification is 
defined as *in use* after the O/A by RFC3264.
So, the UAS need to send 2xx, while not 4xx.
 
> or both of audio and video with zero port?

Here, if you are talking the *legacy* UAS, then the *legacy* UAS may send 
4xx.
This case is talked in "3.4.  UAC Behavior" of the text.

Current normative text is that UAC SHOULD send a new Offer to synchronize 
the session state. As the session state would be synchronize by the new 
O/A, so there's no rigorous rule about the content of the Offer. But the 
text show tendency by the description of:
the UAC uses the criteria in Section 3.3 in order to decide whether or not 
changes have been executed for the stream

I guess this is the deliberate arrangement by Gonzalo. Gonzalo?

> IMO UAC need not generate a new offer to synchronize both UAs.

New Offer is used by UAC in the conditions:
"modification is *in use*, AND UAS send 4xx" or other race condition.

I think it is not relating to the request type.

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: Paul Kyzivat <[email-masked]>
Date: Wed, 12 May 2010 16:49:31 -0400

> or both of audio and video with zero port?

Well, the new o/a is to restate the status quo.
Since the new o/a never succeeded, the status quo includes only one 
m-line. So I think it would be acceptable to send an offer with that.

OTOH, its possible that the other party is confused and thinks there are 
two m-lines in effect. It might be further confused to receive another 
offer with only one m-line. So it might be prudent to send the new offer 
as you suggest. Its legal to do so, and it ought not hurt anything.
(But it might cause trouble if the other UA simply can't handle the 
additional m-line. If so it is quite broken.)

> IMO UAC need not generate a new offer to synchronize both UAs.

I don't understand what point you are making, or why.

	Thanks,
	Paul

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

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 13 May 2010 10:17:00 +0900

Gao,

[email-masked]
Wed, 12 May 2010 21:10:02 +0800
>I guess this is the deliberate arrangement by Gonzalo. Gonzalo?

My question is not so complicated.
If a UAS recognize that current oa state is audio and video.
It means SDP include two m= lines.
In this condition, may UAC send offer SDP that include only one
m= line?

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 13 May 2010 10:30:00 +0900

Hi Paul and Gao,

Paul Kyzivat <[email-masked]>
Wed, 12 May 2010 16:49:31 -0400
>I don't understand what point you are making, or why.

As Reconfirmation of fundamental premise:

If reINVITE is rejected, then both UAs must cancel all of
changes within the reINVITE transaction.
Originally this rollback is an automatic process, so sending
new offer is not necessary.

Why should UAC send new offer?
The reason is that:
   "There are also certain
   race condition situations that get both user agents out of
   synchronization" as shown in Figure 5.

In Figure 5, if UPDATE transaction does not exist, the common
view of oa state is already synchronized(i.e., sendrecv audio
and inactive video).

I think in this case UAC need not generate a new offer.

Regards,
Shinji

---

From: [email-masked]
Date: Thu, 13 May 2010 09:30:07 +0800

Hi Shinji,

> In this condition, may UAC send offer SDP that include only one

Sure.

But I'd like to point out that this UAS is *legacy* one. As it is *legacy* 
one, the UAC need to send a new O/A to synchronize the session state. And 
the UAC can not know the UAS's *understanding* of the state(*legacy* one 
is ambiguous).

Thanks,

Gao

---

From: [email-masked]
Date: Thu, 13 May 2010 09:37:19 +0800

Hi Shinji,

As I said in my first mail in this thread, the UAS should not send 4xx by 
the new rule in this draft.

The basic principle in this draft is, 

1. If the modification triggered by the Re-INVITE is *in use*, then the 
UAS should not send 4xx.

2. If the UAS want to rollback modification which has been *in use*, an 
UPDATE before final 2xx of Re-INVITE is suggested.

Thanks,

Gao

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

OKUMURA Shinji <[email-masked]> 
2010-05-13 09:30

收件人
[email-masked]
抄送
Paul Kyzivat <[email-masked]>, [email-masked]
主题
Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-04.txt

Hi Paul and Gao,

Regards,
Shinji

>>>              Title           : Re-INVITE and Target-refresh Request 
Handling in the Session Initiation Protocol (SIP)

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 13 May 2010 11:08:00 +0900

Gao,

I am talking about "UAC Behavior".
What you say is "UAS Behavior".

The basic principle in my opinion is, 

If an UPDATE has been not used, then the original rollback
process may works well.

Regards,
Shinji

[email-masked]
Thu, 13 May 2010 09:37:19 +0800

---

From: [email-masked]
Date: Thu, 13 May 2010 10:11:17 +0800

Shinji,

If the UAS is under this draft's rules, the UAS would not send 4xx.
Then, your problem is not exist.

That's why I talk UAS's rule first.

Thanks,

Gao

2010-05-13 10:08

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

Gao,

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 13 May 2010 14:12:59 +0900

Hi,

In this text,

3.5.  Glare Situations
   These rules imply that if the
   UAS of a re-INVITE transaction receives and UPDATE request with an
   offer after having sent a non-2xx final response to the re-INVITE but
   before having received the corresponding ACK request, the UA SHOULD
   return a 491 (Request Pending) response to the UPDATE request.

that is shown in a Figure below.

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

Regarding 491 and 500 response, there are some descriptions in RFC3261
and RFC3311. But in these text, an interworking of INVITE and UPDATE
is not clear.

IMO when the directions of the both request are corresponding,
the response code seems to be 500. And if the directions are not
corresponding, the response code seems to be 491.

Therefore in this case, I think a UAS should return a 500 response to
an UPDATE request.

Regards,
Shinji

[email-masked]

---

From: [email-masked]
Date: Thu, 13 May 2010 14:00:16 +0800

Hi Shinji,

There's precondition for the text you mentioned: 

When checking for glare situations, UAs MUST treat the exchange of a
   non-2xx final response to a re-INVITE and its corresponding ACK
   request as an offer/answer exchange.  Consequently, the rules
   regarding glare situations applicable to offer/answer exchanges are
   also applicable to those exchanges.  These rules imply that if the
   UAS of a re-INVITE transaction receives and UPDATE request with an
   offer after having sent a non-2xx final response to the re-INVITE but
   before having received the corresponding ACK request, the UA SHOULD
   return a 491 (Request Pending) response to the UPDATE request. 

With the precondition defined here, the UAS(of Re-INVITE) MUST think it 
has sended a Offer after it send the non-2xx.

Before the UAS get the ACK, it get a new Offer in UPDATE, it SHOULD send 
4xx.

There's normative definition here.

Thanks,

Gao

OKUMURA Shinji <[email-masked]> 
发件人:  [email-masked]
2010-05-13 13:12

收件人
[email-masked]
抄送

主题

Hi,

In this text,

3.5.  Glare Situations

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

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Thu, 13 May 2010 18:35:00 +0900

Gao,

IIUC you means that UAS treats a 4xx to INVITE as an offer and
an ACK as an answer.

Well, 

    A                               B
    |                               |
    |re-INV (offer1)                |
    |------------------------------>|
    |                   18x(answer1)|
    |<------------------------------|
    |                        non-2xx|
    |<------------------------------|
    |                               |
    |                   /---------->|*
    |ACK               /            |
    |-----------------/------------>|
    |                /              |
    |re-INV (offer2)/               |
    |--------------/                |
    |                               |

In an above Figure, what is a response code to the 2nd
re-INVITE?
Or if UA B received the 2nd re-INIVTE before non-2xx,
what is a response code to it?

[email-masked]
Thu, 13 May 2010 14:00:16 +0800
>There's normative definition here.

Is that "normative definition" defined in this draft?

Regards,
Shinji

---

From: [email-masked]
Date: Thu, 13 May 2010 18:08:15 +0800

Hi Shinji,

UA A MUST finish the first Re-INVITE before the second Re-INVITE. So, 
there's no ambiguity here. The UA B can handle the Re-INVITE OK.

In my understanding, it is crossing case, while not glare one.

Though it is not normative, but I'd like to distinguish the two:

Glare case: there's ambiguity.
Crossing case: there's no ambiguity, but message is interlaced from the 
normal sequence. 

Thanks,

Gao

2010-05-13 17:35

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

Gao,

Well, 

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

[email-masked]

Regards,
Shinji

---

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

Paul,

>additional m-line. If so it is quite broken.)

Since both UAs agreed with two m-lines once, probably it does
not cause trouble.

Additionally, IMO a sess-version of SDP should be increased too.

Regards,
Shinji

>> IMO UAC need not to generate a new offer to synchronize both UAs.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 May 2010 09:26:36 -0400

Shinji,

> Since both UAs agreed with two m-lines once, probably it does

It would be good to explain the reasoning.

> Additionally, IMO a sess-version of SDP should be increased too.

Some problem cases would be the following:

	A                       B
  M1	| reINVITE SDP1,V=a     |
	|---------------------->|
  M2	| 180rel SDP2,V=b       |
	|<----------------------|
  M3	| PRACK SDP3,V=a+1      |
	|---------------------->|
  M4	| 200PRA SDP4,V=b+1     |
	|<----------------------|
  M5	| 4xx INVITE            |
	|<----------------------|
  M6.1	| UPDATE SDP1,V=x       | Either this
	|---------------------->|
  M6.2	| UPDATE SDP4,V=x       | or this
	|---------------------->|

The question above is: should x be 'a', or 'a+2' in M6.*, and does the 
answer to that matter depending on whether the SDP is SDP1 or SDP5?

I think this is moot in most cases because there will be no rejection of 
the invite after two o/a exchanges. But it can happen, say in case of 
preconditions that aren't met.

In M6.1 I think x should be 'a+2'. Does that seem right to you?
I think M6.2 is not recommended. If it occurs, then again I think x 
should be a+2.

	A                       B
  M1	| reINVITE SDP1,V=a     |
	|---------------------->|
  M2	| 180rel SDP2,V=b       |
	|<----------------------|
  M5	| 4xx INVITE            |
	|<----------------------|
  M6.1	| UPDATE SDP1,V=x       | Either this
	|---------------------->|
  M6.2	| UPDATE SDP4,V=x       | or this
	|---------------------->|

In this simpler case, for M6.1 x='a' should be fine and prudent,
because somebody *might* complain if the get two successive SDPs that 
are identical except for the version.

IMO the SDP version is untrustworthy and probably ought to be ignored, 
but it seems that some do check it, depend upon it, and get upset if it 
doesn't behave as they expect.)

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 21 May 2010 21:52:00 +0900

Gao,

[email-masked]
Thu, 13 May 2010 18:08:15 +0800
>there's no ambiguity here. The UA B can handle the Re-INVITE OK.

In 4.5.  Race Conditions and Target Refreshes, 
   Additionally, UAs MUST treat
   the exchange of a 2xx response to an INVITE request and its
   corresponding ACK request as an offer/answer exchange.

What do above descriptions require to UAS?
Should UAS reject a UPDATE received between 2xx response to an
INVITE request and its corresponding ACK or not???

>In my understanding, it is crossing case, while not glare one.

The figure in the previous mail is a glare case of UPDATE.

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

And the crossing case of UPDATE is shown as below.

    A                               B
    |                               |
  s0|re-INV (offer1)                |s0
    |------------------------------>|
    |                   18x(answer1)|
    |<------------------------------|
  s1|                        non-2xx|s1
    |<------------------------------|
  s0|                               |s0
    |                   /---------->|*
    |ACK               /  ACK       |
    |---------->      /   --------->|
    |                /              |
    |UPDATE (offer2)/               |
    |--------------/                |
    |                               |

UAS will not be able to recognize the difference between
the glare case and the crossing case.

Regards,
Shinji

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 22 May 2010 12:34:51 +0900

Hi all,

In 3.5.  Glare Situations,
|  These rules imply that if the
|  UAS of a re-INVITE transaction receives and UPDATE request with an
|  offer after having sent a non-2xx final response to the re-INVITE but
|  before having received the corresponding ACK request, the UA SHOULD
|  return a 491 (Request Pending) response to the UPDATE request.

There are two variants, shown in Figure 1 and 2 below.

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

    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

And there is another variant of Figure 1, shown in Figure 3 below.

    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

In Figure 1, even if UAS reject the UPDATE, UAC send new UPDATE
to synchronize a common view in the current rules(Section 3.4).

In Figure 2, if UAS reject the UPDATE, it fails to synchronize
a common view.

In Figure 3, this rule is useless.

After all I think "UAS SHOULD return a 491 between non-2xx and ACK"
is unnecessary.
That is, UAS may return 2xx to this UPDATE.

And, in Figure 1 and 2, the common view of both UAs has already
been synchronized. UAC need not to send an UPDATE request to
synchronize. IMO, If O/A exchange succeeds by the use of UPDATE
before 4xx to INVITE, or UAC has sent UPDATE before 4xx and received
2xx to the UPDATE after 4xx, then UAC should sent new offer to
synchronize.

Regards,
Shinji

[email-masked]

---

From: OKUMURA Shinji <[email-masked]>
Date: Sat, 22 May 2010 14:49:35 +0900

Paul,

>Some problem cases would be the following:

Perhaps does you mean M6.2 is "UPDATE SDP5"?

>answer to that matter depending on whether the SDP is SDP1 or SDP5?

I think x should be a+2, and SDP5 should be based on SDP4.

>preconditions that aren't met.

I agree. this is unclear, but UAC should prepare for it as described
in this draft.

In the following case,

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

s0: only audio
s1: audio and video
s2: audio and video and fax

UA-B recognizes that the current status is s2.
UA-A should send a SDP that is considered reasonable and proper by UA-B.
That is, x is a+2 and m-lines is 3. Certainly video and fax are "zero port".

IMO universal rules should be able to support the most complex cases.

>I think M6.2 is not recommended. If it occurs, then again I think x 

I assume that PRACK transaction is not shown but exists.

>are identical except for the version.

On the contrary, somebody might complain about a "decrement"
of the sess-version.
At least an increment is not against a rule.

I think x should be a+1 and SDP should be based on SDP2.

Regards,
Shinji

---

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

Hi,

> I think M6.2 is not recommended. If it occurs, then again I think x 

I agree with your argument, while only one thing:

*SDP1* in M6.1 means the session state before this Re-INVITE, so it should 
not be the SDP1 in M1.

Thanks,

Gao

---

From: OKUMURA Shinji <[email-masked]>
Date: Fri, 28 May 2010 13:19:05 +0900

Hi all,

Following texts seem to be conflicted.

3.8.  Clarifications on Cancelling Re-INVITEs
   Per
   the rules specified in Section 3.3, if the INVITE request was a re-
   INVITE and some of its requested changes had already been executed,
   the UAS would return a 2xx response instead.

5.5.  UAC Losing its Contact: UAC Behavior
   Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE
   and cause the INVITE client transaction corresponding to the re-
   INVITE to enter the "Terminated" state.

At least there is a possibility that the conflict occurs.

Regards,
Shinji

[email-masked]

---

From: [email-masked]
Date: Fri, 28 May 2010 13:09:35 +0800

>    the UAS would return a 2xx response instead.

This is about UAS's behavior.

>    INVITE to enter the "Terminated" state.

This is about UAC's behavior. And which(2xx/Non-2xx) final response UAS 
would send is defined in section 3.8.

As the UAC may not get the final response from UAS, it should send a new 
Re-INVITE(/UPDATE) to synchronize the state.
And this is defined in the draft.

This is the understanding while I did the review for this part, and I keep 
my understanding as so.

---

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

Gao,

I understand.

The text says that the UAC can not expect to receive a 487
response to the INVITE. Right?

And now, assuming that some of changes have already been
executed, the UAS would send a new UPDATE to undo the changes.
But the local target of the UAC has been changed, so I think UAC
should an UPDATE to announce own new target before sending the
CANCEL.

Do you think so?

Regards,
Shinji

[email-masked]
Fri, 28 May 2010 13:09:35 +0800

---

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

> response to the INVITE. Right?

As UAC's old contact has been lost, UAC can not expect to receive any 
final response for the old Re-INVITE here.
So, the specific for final response is not important here. And the UAC's 
next Re-INVITE as synchronization can refresh the state here. 

> should an UPDATE to announce own new target before sending the

I think the UAC should send a target refresh UPDATE before CANCEL. But the 
reason is not about UAS's rollback usage UPDATE.(the state would be 
synchronized by a next Re-INVITE).

To send a new request(the CANCEL) at new address, sending a target refresh 
UPDATE before the new request (the CANCEL) might be better.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 May 2010 19:52:59 -0400

I think its important to send the target refresh ASAP (if the old target 
is no longer functional.)

Whether sending it before/after CANCEL otherwise makes little 
difference. Either way the 487 won't be received.

	Thanks,
	Paul

---

From: OKUMURA Shinji <[email-masked]>
Date: Mon, 31 May 2010 13:21:42 +0900

Gao,

>next Re-INVITE as synchronization can refresh the state here. 

Even if the UAS would send a new UPDATE to undo the changes
and return a 2xx to the reINVITE, the UAC never receive the 2xx.
The UAC will assume that the reINVITE is rejected with 408
(Request Timeout) and send a new UPDATE or reINVITE to
synchronize a common view.
And if the UAS responds 2xx to the reINVITE, it waits for an
ACK from the UAC, but the UAC never send an ACK.
If the UAS responds a 487, it can expect to receive an ACK
from an adjacent proxy.

After all, if a UAS receives a target-refresh UPDATE within
a reINVITE transaction, the UAS should send a 4xx(487?) to
the reINVITE immediately without sending a new UPDATE to
undo the changes.

>UPDATE before the new request (the CANCEL) might be better.

IMO a CANCEL transaction doesn't depend on a local target.
It has only one Via header that is identical to the one of
the reINVITE.

The UAC may not be able to receive a response to the CANCEL
and an adjacent proxy may retransmit the response.

Should the UAC send the CANCEL?

Regards,
Shinji

---

From: [email-masked]
Date: Mon, 31 May 2010 13:32:06 +0800

> synchronize a common view.

I think, a new UPDATE or ReINVITE to synchronize state is mandatory here. 
I guess you have the same point here.

4xx to the old ReINVITE is not proper, if there's some change/modification 
in the ReINVITE has be enforced. This is the basic concept in the draft.

If there's no change/modification in the ReINVITE has be enforced, 4xx 
would be OK.

> IMO a CANCEL transaction doesn't depend on a local target.

Yes. But if the CANCEL send before the target refresh, UAC would not get 
the response.
That's why I think a target refresh request would be better. But this is 
not the critical point here.
So, if there's vendors want to send CANCEL before target refresh UPDATE, I 
am OK with it.

> Should the UAC send the CANCEL?

You seems arguing using target refresh UPDATE to trigger UAS's final 
response. IMO, CANCEL might be better here.

And it is more natural for UAC to send a CANCEL, if it want to terminate 
current pending ReINVITE.