Subject: [BLISS] Rejection conditions for ACH

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Apr 2008 21:54:33 +0100

During BLISS ACH (automatic call handling) design team discussions at
the last conference call a provisional set of rejection conditions was
identified for which appropriate SIP response codes need to be
identified. Only conditions typically expected to influence ACH at a
proxy are included. The conditions need to be agreed before attempting
to select response codes. The following conditions have been identified:

          <t>Busy. UA resources are busy as a result of another call and
further calls cannot be accepted until resources become free. The
condition may also be visible via a presence system.</t>
          <t>Do not disturb. The user has indicated in advance an
unwillingness to receive calls and therefore calls cannot be accepted
until the user indicates that the condition has been lifted. A user may
impose such a condition during a meeting or while working on a critical
task. The user may indicate in advance a time at which she expects the
condition to be lifted. The condition may also be visible via a presence
system.</t>
          <t>Local rejection. The user has responded to this call by
rejecting it. Whether this impacts other branches (e.g., other UAs
registered for that AoR), forwarding to voicemail, forwarding to an
assistant, etc. depends on the proxy configuration. A user would use
this facility when not in a position to answer a particular call or when
she feels that it would be better handled elsewhere (e.g., by voicemail,
by an assistant). The fate of the call will depend on proxy ACH
settings.</t>
          <t>Global rejection. The user has responded to this call by
rejecting it with the preference that all other branches should be
cancelled and forwarding to voicemail, forwarding to an assistant, etc.
should not take place. A user would use this facility when she is
unwilling to handle a particular call and does not wish it to be handled
elsewhere. A user would typically use this facility for unwanted
traffic. The fate of the call will depend on proxy ACH settings, but
typically it will result in outright rejection.</t>

Please comment on this set of conditions.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Apr 2008 17:21:32 -0400

this seems fine to me. I am wondering about the case where the callee 
wants to hide the true reason from the caller. Does that have to be 
encoded as well? Or is that policy decide upstream?

E.g. John calls me. I don't want to talk to him right now, but I don't 
want him to know that. I would really like him to get the same user 
experience as if I was not present - typically ring a few times and then 
fail over to voicemail - which is different than if I bounce him to VM 
immediately.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Apr 2008 16:54:04 +0100

Paul,

Yes, that's an interesting one. In fact, we could have a condition
"ignore" or "silent reject", which basically means don't send an
immediate response to the caller (let him think it is alerting). Then it
will depend on ACH at the proxy whether that later gets forwarded to
voicemail or simply times out.

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 15 April 2008 22:22
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [BLISS] Rejection conditions for ACH
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Apr 2008 12:22:56 -0400

> voicemail or simply times out.

Now you know what happened all those times you tried to call me. :-)

To me the key issue here is the nature of the communication from the 
UAS. Is the UAS simply signaling some literal representation of its 
state? Or is it in fact attempting to explicitly signal a request for a 
feature to be carried out by a middlebox upstream of it? If the latter, 
what if there is no middlebox upstream that is prepared to act on that 
request? Do we just view the UAC as the feature server of last resort?

For my particular case, perhaps the button on the phone doesn't signal 
anything at all. Instead, perhaps it simply stops ringing the phone 
while simply allowing the transaction to time out. That is the local 
implementation of the feature that doesn't require any special feature 
support in the network. (If the proxy wants to cancel the leg after so 
many rings and send the call to VM it can still do that.)

A harder case is where there are several extensions registered for the 
same AOR, and all within hearing distance of one another. The call is 
parallel forked to them all, and so they all ring. My solution above 
will silence my phone, but not the others. Silencing them all without 
answering any is a bit harder. I guess it could be achieved if the 
button on my phone sent a 3xx response with a private address on the 
phone. (Its contact URL or a gruu.) Then when the call came in on that, 
it would suppress the ringing. But that would only work if the proxy 
recursed on the 3xx and canceled the prior legs. I don't know if that is 
a likely expectation.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Apr 2008 17:39:32 +0100

Paul,

> Sent: 17 April 2008 17:23
> To: Elwell, John
> Cc: [email-masked]
[JRE] OK, so I won't bother to try in future.

> request? Do we just view the UAC as the feature server of last resort?
[JRE] Yes, I should have remembered there is a problem with this. If
there isn't a feature server to "catch" this impolite response, then the
caller sees it. So it would have to be used with care.

> many rings and send the call to VM it can still do that.)
[JRE] That's clear, you can do this anyway. The only drawback is that it
continues to consume resources (memory) at the UA until the caller gets
tired or it times out, but I think those resources are trivial unless
you get a whole flood of such calls.

> recursed on the 3xx and canceled the prior legs. I don't know 
[JRE] If you rely on a proxy or B2BUA to do this for you, then you could
equally rely on it to hide an impolite 4xx. Or perhaps the argument is
that the caller would not understand what he is being redirected to and
therefore might not work out that the call is being ignored.

John

---

From: [email-masked]
Date: Tue, 22 Apr 2008 22:40:15 -0400

From: "Elwell, John" <[email-masked]>

   Global rejection. The user has responded to this call by rejecting
   it with the preference that all other branches should be cancelled
   and forwarding to voicemail, forwarding to an assistant, etc.
   should not take place. A user would use this facility when she is
   unwilling to handle a particular call and does not wish it to be
   handled elsewhere. A user would typically use this facility for
   unwanted traffic. The fate of the call will depend on proxy ACH
   settings, but typically it will result in outright rejection.

Do please ensure that the "global" rejection has its scope controlled
so that it only involves alternatives within some local domain.  As
has been argued elsewhere, since a recipient can never tell who all
the potential recipients are, a recipient cannot validly prescribe
truly global rejection, although it is reasonable to provide rejection
within a scope (e.g., all forks from an AOR).  There has been some
work done on this problem already...

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 24 Apr 2008 00:03:07 +0100

Dale,

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: 23 April 2008 03:40
> To: [email-masked]
[JRE] The BLISS ACH design team feels that, on balance, 6xx response
codes should be strictly "everywhere", to be consistent with RFC 3261.
Also, the design team had seen "global rejection" as being a 6xx
response code and applying "everywhere". I think there is a need for
such a global response, e.g., for handling unwanted traffic. We could
debate whether to have yet another response meaning rejection everywhere
within this domain, although personally I am not convinced.

John

---

From: [email-masked]
Date: Wed, 23 Apr 2008 21:52:55 -0400

[JRE] The BLISS ACH design team feels that, on balance, 6xx response
   codes should be strictly "everywhere", to be consistent with RFC 3261.
   Also, the design team had seen "global rejection" as being a 6xx
   response code and applying "everywhere".

In the general case, a call will have many targets, and no one
recipient can speak authoritatively for all the targets.  The fact
that the call is unwanted by one recipient is not evidence that it is
unwanted by all recipients, and sending a global rejection is simply
incorrect, it puts more power in the hands of a recipient than they
are authorized to have.

Now it is true that if the call is "telephone-like" and the original
request-URI is an AOR all of whose targets are in some small domain,
then one recipient may be able to speak for all targets.  But as SIP
becomes more popular, more and more calls won't be like this.
Designing features that break in the face of complex call routing is
building in trouble for the future.

Dale

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Wed, 23 Apr 2008 21:22:32 -0500

Dale,

The problem has to be bounded or lack of SIP interoperability will rule
forever...

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, April 23, 2008 9:53 PM
To: [email-masked]
Subject: Re: [BLISS] Rejection conditions for ACH

   [JRE] The BLISS ACH design team feels that, on balance, 6xx response
   codes should be strictly "everywhere", to be consistent with RFC
3261.
   Also, the design team had seen "global rejection" as being a 6xx
   response code and applying "everywhere".

Dale

---

From: [email-masked]
Date: Thu, 24 Apr 2008 11:04:33 -0400

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>

I don't understand what you mean by "the problem has to be bounded".

Dale

---

From: [email-masked]
Date: Thu, 24 Apr 2008 22:50:28 -0400

The BLISS ACH design team feels that, on balance, 6xx response
   codes should be strictly "everywhere", to be consistent with RFC 3261.
   Also, the design team had seen "global rejection" as being a 6xx
   response code and applying "everywhere". I think there is a need for
   such a global response, e.g., for handling unwanted traffic.

To clarify -- The difficulty as I see it is that the 3261 semantics
for 6xx responses is unusable in practice.  In the sipX proxy, we've
had to treat 6xx responses as 4xx responses because a popular brand of
phone generates a 603 response when the user pushes the Decline
soft-button in response to an incoming call.  If the proxy treated 603
per 3261, the call wouldn't go to voicemail.

I can see the motivation to define a "global rejection" function for
ACH, but I fear that it will be impossible to use, that very quickly
it will run into the problem we've seen, or one like it.  I don't
think that a workable global rejection function can be defined without
dealing with the "rejection scoping" problem.

Dale

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 24 Apr 2008 22:39:21 -0500

The definition of these codes is NOT clear. Bad/wrong implementation
just makes it worse...

Tighter definition is needed, that may help drive compliance. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Thursday, April 24, 2008 10:50 PM
To: [email-masked]
Subject: Re: [BLISS] Rejection conditions for ACH

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Sat, 26 Apr 2008 15:45:30 +0100

Dale,

Notwithstanding what I stated below, the design team also recognised
that in certain environments the proxy simply would not authorise a 6xx
to literally apply to all branches, and would instead override this,
particularly in a call centre, for example. So basically what it means
is "I would like to rejection to be "everywhere", although in practice
this might not be allowed and the proxy might permit some exceptions,
e.g., forwarding outside the domain, forwarding to email.

John

> Sent: 25 April 2008 03:50
> To: [email-masked]