Subject: [BLISS] I-Ds concerning problems with response codes

From: [email-masked]
Date: Thu, 1 Mar 2007 10:31:26 -0500

I've submitted a set of Internet-Drafts about three problems with SIP
response codes:

(1) the current response codes are not in some instances fine-grained
enough to support networks in which there are redundant paths to
destination UAs,

(2) the 6xx class responses are (as defined) harmful in most
applications and should not be generated by UAs, and

(3) the response codes in the category "no usable destination for this
URI" are muddled and need careful redefinition.

The abstracts are:

   Classifying Response Codes to Support Multiple Path Routing in the
   Session Initiation Protocol (SIP)
   draft-worley-redundancy-response-00

   http://www.ietf.org/internet-drafts/draft-worley-redundancy-response-00.txt

   An increasing number of SIP architectures implement multiple path
   routing (MPR), which is the providing of more than one path for a
   call to reach a destination user agent (UA).  To implement MPR
   well, the proxy which forks a request onto the paths needs to be
   able to determine if a fork that failed reached the destination UA
   and was rejected by the UA (and so an alternate path should not be
   tried), or if the fork failed before reaching the UA (and so an
   alternate path should be attempted).  In order that the proxy can
   distinguish these two situations, response codes should
   unambiguously identify which of these situations applies.  This
   Internet-Draft begins classifying the current usage of response
   codes, their implications for MPR, and possible improvements.

   6xx-Class Responses Considered Harmful in the Session Initiation
   Protocol (SIP)
   draft-worley-6xx-considered-harmful-00

   http://www.ietf.org/internet-drafts/draft-worley-6xx-considered-harmful-00.txt

   The specification of the Session Initiation Protocol (SIP) permits a
   user agent (UA) that receives a call to generate a response in the
   "6xx class" that not only rejects the call but also requires the
   termination of all attempts to route the call to alternative
   destinations.  As the call may have reached the UA through multiple
   forwardings whose meanings cannot be known by the UA, the global
   termination of alternative routing can only rarely be correctly
   requested by the UA.  Because such responses are almost never
   appropriate, ability of a UA to generate such responses is harmful,
   and all 6xx class responses should be replaced with 4xx class
   responses with similar meanings.  However, there is no 4xx class
   response similar to "603 Decline", and so one needs to be created.

   Response Codes Regarding URIs that Cannot Be Routed to a
   Destination in the Session Initiation Protocol (SIP)
   draft-worley-ex-uri-00

   http://www.ietf.org/internet-drafts/draft-worley-ex-uri-00.txt

   The Session Initiation Protocol (SIP) provides a number of response
   codes which a SIP agent can use to indicate that it cannot find a
   suitable destination to which to send a request.  Unfortunately, this
   set of response codes was not carefully designed, making it difficult
   in many cases for a proxy to select a response code that accurately
   reflects the proxy's knowledge about the request URI.  This document
   describes these response codes and their current usage.

Feel free to contact me with any comments.

Dale

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 1 Mar 2007 12:17:05 -0600

Dale,

While I understand the motivation for this draft, it does not
address at all the reason why people actually use 600/603 to Decline
a call everywhere (which, it is true, may cause the session to 
be delivered to voicemail, or may just result in busy tone).

There are real scenarios where you want to have busy/decline everywhere.

If you call me, and I don't want to take your call at all, I may
want to send 600 or 603. It is not harmful. That's what I want.

I specifically do not want to use 486 or 441 because I do not want
other devices to continue to ring. This would be particularly 
annoying for people who have both a phone at their desk and a PC
client. 

So in my mind, the use case for 6XX is not "harmul" if that is the
desired behavior. What may be harmful is the improper usage of 6XX.
I think the document should really be "Best Current Practice for
the use of 6XX-Class Response". And should make this clear how to
use 6XX: i.e., warn of the consequences.

Now, for the specific issue of voicemail.

The reason why people send a 603 today is for the same reason described
above (i.e., I want it to go to voicemail NOW, not after all my other
phones
stop ringing. This is mostly because I don't want my phone to keep
ringing
in my face, especially if I'm talking on another phone). Again, a 4XX
class response will not solve this problem.

That particular usage of 6XX is perhaps an abuse of the protocol (at
least for
the description of 600). I don't know why we put that restriction about
voicemail
in 600 in the first place as it sounds kind of stupid to me, but
assuming 
we want to keep it, we must find a way to allow for dynamically
forwarding
to voicemail. A 302 to voicemail may work (at first glance this may seem
to be
an extra requiremnt to have the voicemail address configured in the
phone, but I'd 
argue you need it anyways to access voicemail, unless the user memorizes
the
voicemail number).

Also, voicemail is only one usecase. There is the more general case of
"default 
treatment". This could include retargeting to an automata, operator, and
so forth.

To me it would be much more logical if 6XX meant that the AOR was not
reachable
anywhere, thereby allowing retargeting. I find the notion that service
operators
will not provide "alternative treatment" when a 6XX is received just
because of
"considered harmful" spec extremely naive. At the end of the day,
customers
and legal considerations are more important than a spec.

On the desireability of a new 441 "Decline": I don't think it is
warranted.
One can use 480 "Temporarily unavailable" which is described as being 
the proper value for a "Do not disturb" service.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, March 01, 2007 07:31
> To: [email-masked]
> Subject: [BLISS] I-Ds concerning problems with response codes
> 
> I've submitted a set of Internet-Drafts about three problems 
> with SIP response codes:
> 
> (1) the current response codes are not in some instances 
> fine-grained enough to support networks in which there are 
> redundant paths to destination UAs,
> 
> (3) the response codes in the category "no usable destination 
> for this URI" are muddled and need careful redefinition.
> 
> The abstracts are:
>

---

From: "Michael Procter" <[email-masked]>
Date: Mon, 5 Mar 2007 06:38:16 -0800

Francois, Dale,

I agree with both of you, but I think there is a problem associated with
both approaches.  On the one hand, Dale is right when he observes that
global termination of a call attempt by a UA is almost never correct.
And on the other, Francois is right when saying that there are
circumstances when you do want to cancel multiple forks from one UA.

Dale wrote (in hid 6xx-considered-harmful draft):
> As the call may have reached the UA through multiple
> requested by the UA.

> annoying for people who have both a phone at their desk and a PC

Here is a clear case when the fork-cancelling property of a 6xx code is
very desirable.  However, there is a related case where it is not.

Consider three salespeople (Alice, Bob and Colin) who each have multiple
devices (desk-phones and soft-clients for example).  If a call arrives
at sip:[email-masked], it is forked to each salesperson.  The call to
each salesperson is in turn forked to each device.  Now, Alice is busy
with a client, and wishes to hit one button to cancel the call attempt
for both her UAs.  603 is a natural choice, as Francois suggests.  But
because of the problem that Dale describes, the calls to Bob and Colin
are also cancelled.  This is clearly undesirable.

I think that the problem arises because the request-uri is rewritten
multiple times (e.g. from sip:[email-masked] to sip:[email-masked]
to sip:alice-desk-phone@some-ip).  It is far from clear what the scope
of a 6xx code should be.  The description of 6xx codes from RFC3261
Section 21.6 is quite broad:

   6xx responses indicate that a server has definitive information about
   a particular user, not just the particular instance indicated in the
   Request-URI.

I suspect that 6xx codes would work a lot better if this was taken to
refer to the request-uri just prior to the final rewriting.  That is to
say, when Alice's desk-phone rejects a call with 6xx, it is assumed that
it refers to sip:[email-masked] and not any earlier one (such as
sip:[email-masked]).

This could be achieved by saying that 6xx responses propagate back until
they reach a proxy that forked, at which point the cancelling occurs as
expected.  But the forking proxy should map the 6xx code to an
appropriate 4xx code before sending it further upstream.

This approach seems to me to answer both problems raised - it clearly
puts a limit on the scope of a 6xx, whilst still giving a useful action
for a specific user.

Regards,

Michael Procter

---

From: "Kucmerowski, Dennis \(Com US\)" <[email-masked]>
Date: Mon, 5 Mar 2007 08:30:53 -0800

Francois and Dale,

In reply to the 6xx to cancel the call.  Very few business will allow an
employee the capability to cancel/reject a call.  It is not good
business to take an incoming call whereby the calling party is ringing
and reject the call which may then return busy tone to the calling
party. Loss of business. The calling party would go from hearing
ringback to busy and think someone has answered and then disconnected
them.  The call party will most likely call again.

The proper way to handled the call is to redirect to another destination
e.g., human or voicemail, in order to not lose business.

As for not wishing to listen to ringing; the UA has multiple ways to
locally handle ringing (e.g., Ringer Off, low volume ringing, ring
burst, no ringing (audible) when the user is active in a connection,
etc.

Do Not Disturb is another issue and should have an explicit DND response
(note: 480 is not explicit since 480 can be used for many functions to
indicate temporary unavailable) so that the originating UA can act on a
DND in a specific way is needed.

Reject the call 6xx is the exception case for releasing all multiple
forked call and not the normal case, once a call is alerting.

I agree there are cases when forking calls, where releasing a single
call is needed.

Best Regards,
 
Dennis L. Kucmerowski 

561-923-1703
Systems Engineering

-----Original Message-----
From: Michael Procter [mailto:[email-masked]] 
Sent: Monday, March 05, 2007 9:38 AM
To: Francois Audet; [email-masked]; [email-masked]
Subject: RE: [BLISS] I-Ds concerning problems with response codes

Francois, Dale,

Regards,

Michael Procter

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Mar 2007 11:49:25 -0600

Dennis and Michael both brought some interesting point, which I agree
with.

To me the core problem is the definition of 6XX in RFC 3261.

I can not imagine anybody that would be foolish enough to have an
implementation 
that would let a user effectively reject all legs of a call and prevent 
alternative treatment. It doesn't matter what RFC 3261 says really: the
business
or service provider will do what it needs to do, which may include
retargeting 
elsewhere (operator, voicemail, etc.).

I believe that what we need is a BCP for this topic, and possibly an
errata
for RFC 3261 if we come to conclusion that there is something
fundamentally wrong
with it.

Cheers

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2007 14:03:43 -0500

> elsewhere (operator, voicemail, etc.).

IMO this is strictly a policy issue. If a SP is providing service to me, 
and I want to do this, I see no reason why the SP should prevent me. 
OTOH, a business may not want to give its employees this capability.

If we assume that a UA registered to an AOR is authoritative for the 
AOR, then it should have as much right as the home proxy to reject a 
call. But maybe we should not make that assumption.

I guess that the definition of 6xx handling may be a problem as it 
stands because it effectively prevents a policy of trapping 6xx and 
sending the call to voicemail.

> for RFC 3261 if we come to conclusion that there is something

Possibly.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2007 14:05:59 -0500

> e.g., human or voicemail, in order to not lose business.

That's a policy issue, not a protocol issue.

> burst, no ringing (audible) when the user is active in a connection,

That doesn't solve the problem if there are multiple UAs registered that 
are within hearing distance but not within reach.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Mar 2007 13:06:42 -0600

Correct. That is my view. 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, March 05, 2007 11:04
> To: Audet, Francois (SC100:3055)
> Cc: Kucmerowski, Dennis (Com US); Michael Procter; 
> [email-masked]; [email-masked]
> Subject: Re: [BLISS] I-Ds concerning problems with response codes
> 
> 
> 
> Francois Audet wrote:
> > implementation that would let a user effectively reject all 
> legs of a 
> > call and prevent alternative treatment. It doesn't matter what RFC 
> > 3261 says really: the business or service provider will do what it 
> > needs to do, which may include retargeting elsewhere (operator, 
> > voicemail, etc.).
> 
> IMO this is strictly a policy issue. If a SP is providing 
> service to me, and I want to do this, I see no reason why the 
> SP should prevent me. 
> If we assume that a UA registered to an AOR is authoritative 
> for the AOR, then it should have as much right as the home 
> proxy to reject a call. But maybe we should not make that assumption.
> 
> I guess that the definition of 6xx handling may be a problem 
> as it stands because it effectively prevents a policy of 
> trapping 6xx and sending the call to voicemail.
> 
> > errata for RFC 3261 if we come to conclusion that there is 
> something 
> > fundamentally wrong with it.
> 
> Possibly.
> 
> 	Paul
>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 05 Mar 2007 14:15:57 -0600

What is wrong with a 6xx?

When I give SIP tutorials, I say it is what you send to a telemarketer 
when they call.  Do you really want a voicemail from a telemarketer??  
Do you want your other devices to ring??

If UAs are generating 6xx responses and they don't really mean it, then 
that is a problem with the UAs not 3261.

Thanks,
Alan

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 5 Mar 2007 15:13:10 -0600

Yep, I agree.

Again, I think we need a BCP to explain how it is supposed to be used. 

> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Monday, March 05, 2007 12:16
> When I give SIP tutorials, I say it is what you send to a 
> telemarketer when they call.  Do you really want a voicemail 
> from a telemarketer??  
> If UAs are generating 6xx responses and they don't really 
> mean it, then that is a problem with the UAs not 3261.
> 
> Thanks,
> Alan
> 
> Francois Audet wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 Mar 2007 18:23:36 -0500

> that is a problem with the UAs not 3261.

I don't think there is anything wrong with 6xx. But what might be wrong 
is that no latitude is given to a proxy to consider or try other 
alternatives once a 6xx is received. There seems to be a justified need 
for a proxy to have some policy control in this regard. In some cases 
each and every UA may be allowed to have the last word, but not in all 
cases.

In particular, when a proxy is authoritative for an AOR, and chooses to 
translate and forward, it should have the discretionary authority to 
ignore the 6xx and try something else if it wishes. In some cases the 
proxy may trump the UA, and in other cases it may not.

	Paul

>> implementation that would let a user effectively reject all legs of a 
>> 3261 says really: the
>> retargeting elsewhere (operator, voicemail, etc.).
>>

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 05 Mar 2007 20:54:31 -0600

Hi, Paul,

From: "Paul Kyzivat" <[email-masked]>

> proxy may trump the UA, and in other cases it may not.

Yeah, where the answer is "it depends", a BCP would help a lot!

Thanks,

Spencer

---

From: [email-masked]
Date: Tue, 6 Mar 2007 11:52:01 -0500

Let me construct a slightly elaborate, but as far as I can tell,
completely realistic use case.

I, <sip:[email-masked]> call a call distributor
<sip:[email-masked]>.  my-friends serial forks in random
order to a series of URIs.  In this case, the first is
<sip:[email-masked]> and the second is <[email-masked]>.

When the first fork reaches the proxy for nortel.com, it parallel
forks to your two user agents, <sip:10.1.1.1> and <sip:10.2.2.2>.
There is also a lower-priority contact, <sip:[email-masked]>, which
is a voicemail automaton.

So <sip:10.1.1.1> and <sip:10.2.2.2> start ringing, and you wish to
decline on sip:10.1.1.1.  This can have several meanings, each with
different implications:

1. You wish for <sip:10.1.1.1> to stop ringing, but for processing to
   continue elsewhere.  This can be accomplished by the UA just not
   ringing.  This has no protocol effect.

2. You wish for <sip:10.1.1.1> to stop ringing, but for processing to
   continue elsewhere immediately.  For this, the UA has to send a 4xx
   response.  There is no specific "Decline Here" response, although
   480 has a similar meaning.

3. You wish for <sip:10.1.1.1> and <sip:10.2.2.2> to stop ringing,
   thus causing the fork to the voicemail server to ring.

4. You wish for <sip:10.1.1.1> and <sip:10.2.2.2> to stop ringing, and
   for the call to not go to voicemail, which means that it will then
   continue with ringing <[email-masked]>.

5. You wish to terminate all forks of the call everywhere.  This can
   be accomplished with a 603 response.

These are all effects that you might want to achieve.  1, 2, and 5 can
be done with SIP as it currently stands.  (Note that effect 5 is the
*specified* effect of any 6xx response, and though a proxy can violate
that specification in a nearly-transparent manner, it would be good to
document that that deviation is considered acceptable.)  (In regard to
2, I object that "this call was specifically rejected" is not within
the defined meanings of 480, and would like to see a specific "Decline
Here" response code, but that's a smaller issue.)

Interestingly, effect 5 *should not* be achievable -- You are not
authoritative for calls to Michael, and you have no right to terminate
the forks of my call to his UA.

3 and 4, the most desirable and reasonable "reject" effects, simply
cannot be achieved under RFC 3261.

What I'm trying to establish is:

1. Consensus that the defined effect of 6xx is not a good idea,
   because of the authority problem in case 5.

2. Consensus that proxies should, by default, treat 6xx as 4xx, and
   translate them into 4xx in their upstream responses (to prevent
   upstream proxies that conform to RFC 3261 from having the authority
   problem).

3. Establish a proper 4xx translation of 603, either by defining a new
   code (e.g. 441) or enlarging the definition of 480.

4. Start discussion on how to provide a properly scoped "non-local
   decline" response.  (draft-rajesh-sipping-605-01 is an approach to
   this issue.)

And it turns out that the "non-local decline" issue is more
complicated than it appears -- it's not at all clear (in the face of
the messy routing that SIP makes possible) how to reliably determine
when a response should be treated as having authority over a
particular forking transaction.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 6 Mar 2007 12:17:52 -0600

Hi Dale, you did a good job. I think we are going somewhere.

> Sent: Tuesday, March 06, 2007 08:52
> To: [email-masked]
> Let me construct a slightly elaborate, but as far as I can 
> tell, completely realistic use case.
> 
> <sip:[email-masked]>.  my-friends serial forks in 
> random order to a series of URIs.  In this case, the first is 
> When the first fork reaches the proxy for nortel.com, it 
> parallel forks to your two user agents, <sip:10.1.1.1> and 
> <sip:10.2.2.2>.
> There is also a lower-priority contact, 
> <sip:[email-masked]>, which is a voicemail automaton.

This is ONE way to implement voicemail. Probably the simplest and
best way when living in a uniform SIP environment.

However, voicemail is often done differently. Often, sessions
are retargeted to a voicemail server (as opposed to forked to
voicemail). And the mailbox are then derived from "redirection
number information", such as that available from History-Info
(RFC 4244) or from the URI itself (RFC 4458, RFC 4240). This
is extremely common when you have to deal with legacy voicemail
systems through PSTN gateways (but is not limited to that).

This explains a bit why some implementations have been 
relying of 603.

> So <sip:10.1.1.1> and <sip:10.2.2.2> start ringing, and you 
> wish to decline on sip:10.1.1.1.  This can have several 
> meanings, each with different implications:
> 

Yes, valid case. I call this the "Ignore" function.

>    480 has a similar meaning.

Correct. This is a "Decline local" (and I really don't see a reason
for anything but 480).

>    thus causing the fork to the voicemail server to ring.

Correct. Depending on your reading of 603 in RFC 3261, it may or may
not be usable for this purpose. This would also depends on the way
your voicemail is set up.

With your description (forked voicemail server), it wouldn't work. 
Behavior 4 would happen instead.

>    continue with ringing <[email-masked]>.

Yes, that is interesting. Especially if Michael is the Enterprise's 
operator. That could be quite useful.

As per my comment on 3, depending how voicemail is implemented and your
reading of 603, this may or may not be the result.

>    be accomplished with a 603 response.

That depends on your reading of 3261.

> These are all effects that you might want to achieve.  1, 2, 
> and 5 can be done with SIP as it currently stands.  (Note 
> that effect 5 is the
> *specified* effect of any 6xx response, and though a proxy 
> can violate that specification in a nearly-transparent 
> manner, it would be good to document that that deviation is 
> considered acceptable.)  (In regard to 2, I object that "this 
> call was specifically rejected" is not within the defined 
> meanings of 480, and would like to see a specific "Decline 
> Interestingly, effect 5 *should not* be achievable -- You are 
> not authoritative for calls to Michael, and you have no right 
> to terminate the forks of my call to his UA.

I don't think that's the conclusion. I think Paul said it best
when he said it was policy.

If my service provider is OK with a "Decline (really) everywhere"
behavior, then it's fine.

But the service provider could decide he's not and provide alternative
treatment. Policy decisions.

> 3 and 4, the most desirable and reasonable "reject" effects, 
> simply cannot be achieved under RFC 3261.
> 

As above, I think we need to clarify it's a policy issue.

>    code (e.g. 441) or enlarging the definition of 480.

I think 480 is already enlarged to be honest.

>    decline" response.  (draft-rajesh-sipping-605-01 is an approach to

Yes, I like this draft too.

It basically does the following:
- 603 == "my" reading of RFC 3261, i.e., "Decline fork"
- 605 == "your" reading of RFC 3261, i.e., "Decline really everywhere"

> complicated than it appears -- it's not at all clear (in the 
> face of the messy routing that SIP makes possible) how to 
> reliably determine when a response should be treated as 
> having authority over a particular forking transaction.

Agreed.

---

From: [email-masked]
Date: Wed, 7 Mar 2007 10:38:09 -0500

Some initial comments:

   From: "Francois Audet" <[email-masked]>

This "retargeting" system has implications that extend beyond
call-decline.  I'm going to have to think about it some more.  At the
very least, it's an alternative configuration whose operation in this
situation has to be considered as well.

Actually, I've got another I-D that I hoping to get a discussion going
in regard to 404, 410, 480, and 604, which not only overlap, but also
provide no choice for reporting certain common conditions.

And within the "decline" semantic, there are further sociological
complications, as the user may wish to decline the call *without*
providing specific indication to the caller that the call was
declined, versus cases where he wants to make such a specific
indication.

What do you mean by "the Enterprise"?  NCC-1701?

True, but the text of 3261 is quite clear on the required processing.
If we discover that we want the *default* behavior of proxies to be
different, we should formally decide so.

Whose policy?  Which service provider?

In practice, it's very poorly defined.  My personal preference is that
as part of straightening out those response codes, we create a
specific Decline Here response.  But that is really a Different Topic.

Dale

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 7 Mar 2007 07:50:34 -0800

> completely realistic use case.

Thanks Dale.  I think this is what I was trying to say.  Breaking out
the 5 cases is very helpful.

I think case 3 is the most interesting for 'normal' use, and 4 is most
relevant for calls that have already been forked multiple times (your
example has this as [email-masked] --> [email-masked] +
[email-masked] --> collection of contacts).

The obvious difference between cases 3 and 4 (one goes to VM, and one
doesn't) can be explained by the fact that in case 4, you are unlikely
to want to talk to voicemail for [email-masked], nor for
[email-masked].  If there was a voicemail system for 
[email-masked], that might be useful, though.

Whilst it is probably a little premature to discuss implementation, I
would like to point out that the distinction between 3 and can already
be handled in SIP, using RFC3841 (and examples in RFC4596).  At the time
of the first fork, the proxy could add the following to the outgoing
INVITEs:

	Reject-Contact: *;msgserver		// taken from RFC4596
[1]

This would have the effect of avoiding Francois' and my voicemail
systems in the unlikely case that we decline[2] a call from you.

But, if you called me directly ([email-masked]), and I
declined the call in the same way[2], then you could get my voicemail
account, since such a Reject-Contact line would not have been added.

Therefore, I suggest that whatever approach to declining a call in case
3 is found, the same approach should be used in case 4.  Handling the
difference in voicemail behaviour can be achieved using RFC3841/RFC4596
Reject-Contact headers added by the first proxy.

[1] RFC3840 defines 'msg-taker', used in RFC3841, but RFC4596 prefers
'msgserver', whilst not mentioning 'msg-taker' at all.  I think they are
supposed to be roughly comparable.
[2] Mechanism to be defined.  But draft-rajesh-sipping-605-01 seems
useful.

Regards,

Michael

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 7 Mar 2007 10:31:53 -0600

> Sent: Wednesday, March 07, 2007 07:38
> To: [email-masked]
> And within the "decline" semantic, there are further 
> sociological complications, as the user may wish to decline 
> the call *without* providing specific indication to the 
> caller that the call was declined, versus cases where he 
> wants to make such a specific indication.

Correct.

For example, an "ignore" button (i.e., stop called party user
ringing, but let's the other user ring) looks like you are not 
there.

A "Make busy" makes it look like you are busy.

A "Decline" may make it look like you don't want to talk to the
user (depending on that user's UI).

> What do you mean by "the Enterprise"?  NCC-1701?

No, I mean the Corporation that received the call.

Say you call my phone number (assigned to Nortel), or
my SIP address (@nortel.com). 

Nortel may decide that if I can't take the call, it gets
anwered by our operator.

Nortel is probably a bad example, but for some Enteprises, this
is exactly the expectation.

> If we discover that we want the *default* behavior of proxies 
> to be different, we should formally decide so.

I don't think it's clear at all... 

The introduction in 21.6 implies we are talking about a particular user,
i.e., the "AOR", as opposed to, "any user". It's only the definition of
600 that expand it to "any other endpoint". And even then, you could
interpret it (as I did) as saying that it's the endpoints that share
the AOR. That would validate the Voicemail comment (provided we use
your Voicemail model where the mailbox shares the user's AOR).

> Whose policy?  Which service provider?

The proxy responsible for the domain will decide what to do when it 
receives a 6XX from a UA in that domain based on it's own policy. 
It may forward the 6XX or it may map it to 4XX or it may provide
alternative treatment.

> In practice, it's very poorly defined.  My personal 
> preference is that as part of straightening out those 
> response codes, we create a specific Decline Here response.  
> But that is really a Different Topic.

Yeah, it is a different topic.

I think it's too late to change it because 480 is widely used for that
purpose (and other purposes).