Subject: [Sipping] Question on do not disturb indication

From: "Elwell, John" <[email-masked]>
Date: Wed, 02 Aug 2006 21:09:15 +0100

RFC 3261 suggests the use of response code 480 Temporarily Unavailable for
indicating do not disturb (DND), but it is not used exclusively for this
purpose. There are other documents (e.g., RFC 4504) that suggest the use of
486 Busy Here, but again this is not helpful if the receiver wants to
distinguish between DND and ordinary busy. Presence can be used to indicate
this condition through the RPID note element, but that does not say why a
particular session establishment attempt has failed. What are the best
practices for indicating the DND condition? Does anyone see a need for an
explicit indicator for this purpose, e.g., a new SIP response code? 

John

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 02 Aug 2006 17:14:30 -0400

On Wed, 2006-08-02 at 21:09 +0100, Elwell, John wrote:
> RFC 3261 suggests the use of response code 480 Temporarily Unavailable
> for indicating do not disturb (DND), but it is not used exclusively
> for this purpose. There are other documents (e.g., RFC 4504) that
> suggest the use of 486 Busy Here, but again this is not helpful if the
> receiver wants to distinguish between DND and ordinary busy. Presence
> can be used to indicate this condition through the RPID note element,
> but that does not say why a particular session establishment attempt
> has failed. What are the best practices for indicating the DND
> condition? Does anyone see a need for an explicit indicator for this
> purpose, e.g., a new SIP response code? 

Personally, I like 480 for this.  

If the phone wanted to be sneaky, it could just mute the ringing and
allow the transaction to time out without explicitly rejecting it.  That
prevents the caller from being able to tell they are being disregarded,
but some users might prefer that forwarding take effect sooner and not
like that.

The one thing that I _don't_ like to see is a 603 being used for this;
that messes up any upstream forking.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 02 Aug 2006 18:30:45 -0400

I pretty much agree with Scott. In many/most cases I won't want the 
caller to know why his call is going unanswered. Both 480 and 486 are in 
effect "white lies". Which one to use may depend on which impression you 
want to give to the caller. Another one - if you want to be more rude - 
is 403 Forbidden.

I don't see a need for a *special* code that is unique to this service.

	Paul

---

From: [email-masked]
Date: Wed, 2 Aug 2006 18:51:57 -0400

From: Scott Lawrence <[email-masked]>

Personally, I think we should file a bug against the *existence* of
6xx codes.  They just can't be made to work correctly in the light of
multiple routings and forwardings of a URI.

Dale

---

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 2 Aug 2006 17:58:36 -0500

Is not this a question for the market to decide? 
Do any of you think we can speak for J.Q. Public? Or should.  

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, August 02, 2006 6:31 PM
To: Scott Lawrence
Cc: [email-masked]; Elwell, John
Subject: Re: [Sipping] Question on do not disturb indication

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 2 Aug 2006 18:24:09 -0500

I agree: I don't see a need for a special code for this, as it seems to
make
pretty much exactly to existing practice.

In fact, even in the "old days" you had different features corresponding
to
the two codes.
- Do-not-Disturb is pretty much like 480
- Make-busy is pretty much like 486

Some vendors have "make busy", others have "do not disturb", some may
have
both.

On the 603 issue, I'd like to disagree with everybody else...
Sometimes being able to decline the call everywhere is actually what you
want.
As an example, I have multiple forked device. If I send a 603, it
triggers the proxy to
use whatever alternate routing is sees fit (e.g., voicemail, attendant,
etc.). That's
the desired behavior.

Problem with a 480/486 with that scenario is that it won't trigger the
alternate routing
and will keep on ringing the other fork. That may not be the desired
behavior.

My 2 cents. 

> Sent: Wednesday, August 02, 2006 3:31 PM
> To: Scott Lawrence
> I pretty much agree with Scott. In many/most cases I won't 
> want the caller to know why his call is going unanswered. 
> Both 480 and 486 are in effect "white lies". Which one to use 
> may depend on which impression you want to give to the 
> caller. Another one - if you want to be more rude - is 403 Forbidden.
> 
> >> RFC 3261 suggests the use of response code 480 Temporarily 
> >> Unavailable for indicating do not disturb (DND), but it is 
> not used 
> >> exclusively for this purpose. There are other documents (e.g., RFC 
> >> 4504) that suggest the use of 486 Busy Here, but again this is not 
> >> helpful if the receiver wants to distinguish between DND 
> and ordinary 
> >> busy. Presence can be used to indicate this condition through the 
> >> RPID note element, but that does not say why a particular session 
> >> establishment attempt has failed. What are the best practices for 
> >> indicating the DND condition? Does anyone see a need for 
> an explicit 
> >> indicator for this purpose, e.g., a new SIP response code?
> > 
> > allow the transaction to time out without explicitly rejecting it.  
> > That prevents the caller from being able to tell they are being 
> > disregarded, but some users might prefer that forwarding 
> take effect 
> > sooner and not like that.
> > 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 02 Aug 2006 19:57:01 -0400

> use whatever alternate routing is sees fit (e.g., voicemail, attendant,

Well, that depends on what you think 603 means.  

3261 says:

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

and for 603 specifically it says:

   This
   status response is returned only if the client knows that no other
   end point will answer the request.

I read that to mean that a forking proxy should abandon all forks for
the call and terminate the request - the response asserts that the
voicemail (another end point) will not answer.

That might be an appropriate response for a proxy to send if it is
authoritative for the domain and knows that a particular user does not
exist, but I can't see how a user agent can ever have enough global
knowledge to justify a 6xx response.

> and will keep on ringing the other fork. That may not be the desired

This is interesting - you seem to have exactly the opposite belief about
these.  No 4xx response will affect other forks in our proxy.

---

From: Dean Willis <[email-masked]>
Date: Wed, 2 Aug 2006 22:17:24 -0500

> Do any of you think we can speak for J.Q. Public? Or should.

Well, I personally speak for at least a portion of the service- 
consuming market. Myself. After all, I AM an AT&T customer for some  
of my services. And a Comcast customer, Verizon customer, Skype  
customer, etc.

Or maybe we should have a national poll on which code to use? Heck,  
people on the street can't seven seem to be able to pick a president,  
much less tell a 404 from an ACM.

So, as a service-consuming member of the market, I'd rather have the  
IETF recommend something that mostly works, thanks.

--
Dean

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 3 Aug 2006 03:37:35 -0400

> From: Scott Lawrence [mailto:[email-masked]]
>
[about a 603 response...]
> knowledge to justify a 6xx response.

That would be a 604 (Does not exist anywhere), no?  
A 603 could be useful someday for personal black-lists; for example where
the user agent may decide who to give 603's to based on the From, and not
send them to voicemail. 

The problem is just because I pressed DND doesn't mean I don't want it to go
to voicemail - I do want it to go to voicemail.  So 6xx is wrong.  But
sending a 480 typically only makes it go to voicemail if there are no other
contacts to try, or they all send 480.  So I have to press DND on all my
phones; but I'm not sure that's avoidable.  

-hadriel

---

From: "Xiaotao Wu" <[email-masked]>
Date: Thu, 3 Aug 2006 07:18:02 -0400

> and will keep on ringing the other fork. That may not be the desired

I would expect the response should be sent by the proxy, instead by
endpoints. If it's send by an endpoint, things may get complicated.
For example, Bob has a desk phone, a cell phone, a voicemail, and a
secretary. It's hard to compose a response from his desk phone to
indicate that he does not want to ring his desk phone, and cell phone,
but ring his secretary phone and voicemail.

So, I think the problem is more on what's the expected code for the
caller, not on the routing behavior of the request/response.

-Xiaotao

-- 
-Xiaotao

===========================================================
Name     : Xiaotao Wu
Email     : [email-masked], [email-masked]
Web       : http://www.cs.columbia.edu/~xiaotaow
Phone    : (732) 852-2133
SIP        : sip:[email-masked]
Address : 1M-240,  307 Middletown Lincroft Road
                Lincroft, NJ 07738-1526, U.S.A.

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 03 Aug 2006 08:35:43 -0400

> phones; but I'm not sure that's avoidable.  

Yes - I call that the 'ring twice problem'; if I ignore or reject a call
on my desk phone, then my personal forwarding rules send it to my cell
and I have to ignore or reject it there before it will go to my
voicemail.  I control whether or not I have that problem by deciding
whether or not to have that forwarding in place.

The only solution I can think of for avoiding ring-twice would be a
response that indicates that all forks that in the class 'my personal
phones' should be abandoned, but that phones in other classes, such as
'my assistant', or 'my voicemail' may proceed.  Perhaps such a thing
could be built with the caller prefs mechanisms, but I'm not optimistic
that it would see wide implementation (I probably would not try to
implement it in our proxy, for example).

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 3 Aug 2006 07:36:36 -0500

I agree with Francois. A 603 isn't a horrible thing. Essentially with
SIP you have two choices here, kill one forked leg of the call (4xx
response) or kill all of the forked legs (603). What the proxy does with
it from there for alternate routing is up to the proxy.

I don't know that the example Xiaotao gives is a reasonable use case. If
the user does not wish for their desk and cell phone to ring, then you
486 those legs individually. The only other mechanism 3261 gives you to
do that is with a 603 response. To be any more refined than that would
require extensions so that endpoints can coordinate their actions more
closely.

If we go with the notion that 603 is bad, then if Xiaotao's user's
cellphone is out in their car, and they don't want the call to go to
voicemail on the cellphone but go to the office secretary/voicemail  ,
all they can do is send a 603 from their desk phone.

Regards,
Brian

> From: Xiaotao Wu [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 7:18 AM
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]; Paul Kyzivat; Elwell, John; Scott Lawrence
> > Sometimes being able to decline the call everywhere is 
> actually what 
> > you want.
> > triggers the proxy to use whatever alternate routing is sees fit 
> > (e.g., voicemail, attendant, etc.). That's the desired behavior.
> >
> > alternate routing and will keep on ringing the other fork. That may 
> > not be the desired behavior.
> 
> I would expect the response should be sent by the proxy, 
> instead by endpoints. If it's send by an endpoint, things may 
> get complicated.
> For example, Bob has a desk phone, a cell phone, a voicemail, 
> and a secretary. It's hard to compose a response from his 
> desk phone to indicate that he does not want to ring his desk 
> phone, and cell phone, but ring his secretary phone and voicemail.
> 
> So, I think the problem is more on what's the expected code 
> for the caller, not on the routing behavior of the request/response.
> 
> -Xiaotao
> 
> >
> > My 2 cents.
> >
> > > caller to know why his call is going unanswered.
> > > Both 480 and 486 are in effect "white lies". Which one to use may 
> > > depend on which impression you want to give to the 
> caller. Another 
> > > one - if you want to be more rude - is 403 Forbidden.
> > >
> > > >> 4504) that suggest the use of 486 Busy Here, but again this is 
> > > >> not helpful if the receiver wants to distinguish between DND
> > > and ordinary
> > > Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP Use 
> > > [email-masked] for questions on current sip Use 
> > > [email-masked] for new developments of core SIP
> > >
> >
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> >
> 
> 
> --
> -Xiaotao
>

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 03 Aug 2006 09:15:20 -0400

> it from there for alternate routing is up to the proxy.

I don't think that it is - I think that 603 means that the proxy should
stop trying to route the call and reject it back to the caller.  If that
isn't what it means, then we need a bug against 3261 to fix it.

> all they can do is send a 603 from their desk phone.

But voicemail is, from the point of view of the proxy, just another fork
for the same user.  That's my point to begin with - either 603 means
'kill all forks', or it doesn't, and if it does then it kills voicemail
too.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Aug 2006 10:00:01 -0400

I went at reviewed 3261 on this and found some interesting things:

-  Global Failures 6xx

    (This refers to a "particular user", but how that relates to a call
    in progress isn't clear. Do two extensions on one AOR both belong
    to the same "user", or not? Should the phone and a VM server backing
    up the phone be viewed as the same user? If a proxy is configured
    to offer calls first to Alice's phone, and if no answer then to
    Alice's assistant Bob, does a 6xx response by Alice's phone say
    anything about Bob?)

- 603 Decline:

    This status response is returned only if the client knows
    that no other end point will answer the request.

    (This is in conflict with the language in 6xx because it talks
    about end point rather than user. It doesn't appear that the
    difference is because of anything special about 603 vs the
    general 6xx.)

- 604 Does Not Exist Anywhere:

    The server has authoritative information that the user indicated in
    the *** Request-URI *** does not exist anywhere.

    (This again differs from the 6xx description in a way that
    doesn't seem related to the specifics of 604 vs 6xx. This one
    does talk about *user*, and is more specific about what it means
    by user. But not in a very helpful way. It explicitly calls out
    the R-URI, and not say the To-URI. The R-URI typically only
    identifies one UA, which means this response may not technically
    mean anything different than 404.}

This to me indicates a general lack of specificity in 3261 about the 
scope of applicability of the 6xx codes. As we are finding with many 
aspects of 3261, as we progress we find a need to tighten things up - 
clarify things that ambiguous or just wrong. But before that can be 
done, we need to figure out how we thing it ought to work.

IMO there has to be some discretion in how 6xx codes are handled 
upstream - this interacts with what the upstream node is trying to 
accomplish. For instance:

- if a proxy intends to try one or more contacts of a single AOR,
   and it receives a 6xx from one of them, it normally shouldn't
   try the others.

- if a proxy intends to try one or more contacts of AOR-1 and then
   try one or more contacts of AOR-2, and it receives a 6xx from
   one of the AOR-1 contacts, then it should have the discretion
   to still try AOR-2. Whether it does this or not may depend on
   what it is trying to achieve by trying both.

There clearly is a fine line here. The nodes receiving the 6xx responses 
need some discretion. But the nodes sending the 6xx need to have enough 
definition about what the codes mean to choose which one to return, so 
that the right thing might happen.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 3 Aug 2006 09:16:15 -0500

I think we're missing an important distinction: nested target sets.

Let's say I have a proxy serving user X has two target sets: A and B.

Target set A consists of two routes that are forked sequentially: target
set B for user X, and go to voicemail for user X.

Target set B consists of several routes that are forked in parallel:
user X at device 1, user X at device 2, etc...

Now, take a look at RFC-3261, section 16.6 around response contexts
(third paragraph) and step 5 of section 16.7.

Ok, so let's run our thought experiment...

When a call comes in for User X, the proxy executes target set A for
user X (sequentially fork to user X's target set B). This in turn
executes target set B for user X (the user's registered contacts and
other endpoints). Device 2 for User X sends back a 603. 

This, according to RFC-3261, kills off all the other legs to target set
B. At that point, there is no normative language in section 16.7 that
requires the proxy to take any action towards target set A. It only MUST
NOT create any new branches out of the context of target set B.

And so the call then sequentially forks to the next destination in
target set A, i.e. voicemail.

Regards,
Brian

> Sent: Thursday, August 03, 2006 9:15 AM
> To: Stucker, Brian (RICH1:B620)
> Cc: Xiaotao Wu; Audet, Francois (SC100:3055); 
> [email-masked]; Paul Kyzivat; Elwell, John
> Subject: RE: [Sipping] Question on do not disturb indication
> 
> > response) or kill all of the forked legs (603). What the proxy does 
> > with it from there for alternate routing is up to the proxy.
> 
> I don't think that it is - I think that 603 means that the 
> proxy should stop trying to route the call and reject it back 
> to the caller.  If that isn't what it means, then we need a 
> bug against 3261 to fix it.
> 
> > I don't know that the example Xiaotao gives is a reasonable 
> use case. 
> > If the user does not wish for their desk and cell phone to 
> ring, then 
> > you
> > 486 those legs individually. The only other mechanism 3261 
> gives you 
> > to do that is with a 603 response. To be any more refined than that 
> > would require extensions so that endpoints can coordinate their 
> > actions more closely.
> > 
> But voicemail is, from the point of view of the proxy, just 
> another fork for the same user.  That's my point to begin 
> with - either 603 means 'kill all forks', or it doesn't, and 
> if it does then it kills voicemail too.
> 
> --

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 03 Aug 2006 11:43:36 -0400

> target set A, i.e. voicemail.

I recognize the utility of the 'target set' concept, but I don't know of
any standard way to express it in the existing protocol.  Do you?

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 3 Aug 2006 11:00:03 -0500

I think CPL captures it pretty well. 

Since it's local policy of the proxy as to how it expects the relevant
services to work, short of standardizing a DND service (which is likely
to prove very difficult) what do you see as missing?

Regards,
Brian  

> Sent: Thursday, August 03, 2006 11:44 AM
> > Target set A consists of two routes that are forked sequentially: 
> > target set B for user X, and go to voicemail for user X.
> > 
> > This, according to RFC-3261, kills off all the other legs to target 
> > set B. At that point, there is no normative language in 
> section 16.7 
> > that requires the proxy to take any action towards target set A. It 
> > only MUST NOT create any new branches out of the context of 
> target set B.
> > 
> I recognize the utility of the 'target set' concept, but I 
> don't know of any standard way to express it in the existing 
> protocol.  Do you?
> 
> --

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 03 Aug 2006 12:02:28 -0400

> to prove very difficult) what do you see as missing?

Something that tells me that the scope of a 6xx response is the class or
all classes.

---

From: [email-masked]
Date: Thu, 3 Aug 2006 13:23:07 -0400

The difficulty with the 6xx codes is that their effect is prescribed
in RFC 3261, section 16.7, item 9 -- immediately terminate *all* forks
of this INVITE, all the way back to the UAC.  And the UAS that
generates the 6xx cannot know (in general) what the original
request-URI was, and what its semantics are.

Consider when Able is a member of a support group.  If Able puts his
phone DND, an incoming call to the support group should fail over to
Baker.  But if Able's phone responds with a 6xx, the caller receives
the 6xx.

I suppose we could make an exception when the UAS recognizes the
To-URI and possesses authoritative information about it.

   From: Paul Kyzivat <[email-masked]>

This sounds reasonable to me, but we need to amend RFC 3261 to make it
possible.

Dale

---

From: [email-masked]
Date: Thu, 3 Aug 2006 13:32:08 -0400

From: "Brian Stucker" <[email-masked]>

Not quite -- the forking process for target set B cancels all
remaining branches, and then *forwards the 603 response to its parent
forking process*, the one for target set A.  Then *that* forking
process cancels all the remaining branches for target set A.  And so
on, recursively back to the caller.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Aug 2006 13:06:14 -0500

What I am saying is this:

603 means that the request to sip:[email-masked] will positively not
be 
answered by sip:[email-masked]

If the proxy's logic is that the session is retargeted to an attendant,
or a voicemail
service, a hunt group, or just dropped completely, that's fine. It's the
desired behavior.

As for your last claim, we are saying exactly the same thing: No 4xx
response will affect 
forks in our proxy (i think you misread what I said).

What I am trying to say is that IF the desired behavior is to affect ALL
forks, a
480/488 won't work.

> Sent: Wednesday, August 02, 2006 4:57 PM
> Cc: Paul Kyzivat; [email-masked]; Elwell, John
> > I agree: I don't see a need for a special code for this, as 
> it seems 
> > to make pretty much exactly to existing practice.
> 
> I read that to mean that a forking proxy should abandon all 
> forks for the call and terminate the request - the response 
> asserts that the voicemail (another end point) will not answer.
> 
> That might be an appropriate response for a proxy to send if 
> it is authoritative for the domain and knows that a 
> particular user does not exist, but I can't see how a user 
> agent can ever have enough global knowledge to justify a 6xx response.
> 
> This is interesting - you seem to have exactly the opposite 
> belief about these.  No 4xx response will affect other forks 
> in our proxy.
> 
> --

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Aug 2006 13:11:19 -0500

Sure you can do it on phones.

You an have a button on the phone to "Decline" an incoming call
dynamically.
You can have a DND feature (either permanent or dynamic).

This is widely done today. 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Xiaotao Wu
> Sent: Thursday, August 03, 2006 4:18 AM
> Cc: Paul Kyzivat; Scott Lawrence; Elwell, John; [email-masked]

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Aug 2006 13:15:11 -0500

Scott,

They key point is 603 kills all the forks, yes.

Going somewhere else (like a voicemail or attendant) is a retargeting.
It's
not the same target.

It's just an alternate route that the proxy can have.

Nothing particularly new about this. Cutting a cable will achieve the
same effect.

> Sent: Thursday, August 03, 2006 6:15 AM

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Aug 2006 13:20:04 -0500

I agree with Paul as well.

But I don't think RFC 3261 necessarily needs to be amended.
It's always been legal for a proxy to retarget however it pleases.

What I do see however is that we have never been very clear in our
documentation about normal forking (i.e., same targer AOR) versus 
forking with retargeting (when a fork goes to a different AOR). 

(In both cases, it applies to both sequential and parallel forking).

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 10:23 AM
> To: [email-masked]
> The difficulty with the 6xx codes is that their effect is 
> prescribed in RFC 3261, section 16.7, item 9 -- immediately 
> terminate *all* forks of this INVITE, all the way back to the 
> UAC.  And the UAS that generates the 6xx cannot know (in 
> general) what the original request-URI was, and what its 
> semantics are.
> 
> Consider when Able is a member of a support group.  If Able 
> puts his phone DND, an incoming call to the support group 
> should fail over to Baker.  But if Able's phone responds with 
> a 6xx, the caller receives the 6xx.
> 
> I suppose we could make an exception when the UAS recognizes 
> the To-URI and possesses authoritative information about it.
> 
> This sounds reasonable to me, but we need to amend RFC 3261 
> to make it possible.
> 
> Dale
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 03 Aug 2006 14:27:44 -0400

[email-masked] wrote:
> of this INVITE, all the way back to the UAC. 

Reviewing 16.7, I agree with you.

> And the UAS that

Yup.

> This sounds reasonable to me, but we need to amend RFC 3261 to make it

Yeah, does seem that way.

	Paul

---

From: "Xiaotao Wu" <[email-masked]>
Date: Thu, 3 Aug 2006 21:07:37 -0400

> You can have a DND feature (either permanent or dynamic).

Which entity to ebable the feature is different from which entity to
execute the service logic. Sure you can enable it on the phone, but
the service logic can still be executed on proxy servers. For example,
Microsoft Office Communicator uses CSTA to transmit the "Set DND"
command to a gateway, the "Set DND" is not executed on the
Communicator itself.

-Xiaotao

-- 
-Xiaotao

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 3 Aug 2006 20:14:32 -0500

Yeah, sure, but this is IETF (SIP), not ECMA (CSTA).

But I agree with you that if you have some other protocol, you can do
DND
on the proxy instead of the endpoint.

You could also have a Web Page that allows you to affect routing on the
proxy
in a similar way. 

> Sent: Thursday, August 03, 2006 6:08 PM
> Which entity to ebable the feature is different from which 
> entity to execute the service logic. Sure you can enable it 
> on the phone, but the service logic can still be executed on 
> proxy servers. For example, Microsoft Office Communicator 
> uses CSTA to transmit the "Set DND"
> > > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> > > Xiaotao Wu
> > > > alternate routing and will keep on ringing the other fork. That 
> > > > may not be the desired behavior.
> > >
> instead by 
> > > indicate that he does not want to ring his desk phone, and cell 
> > > phone, but ring his secretary phone and voicemail.
> > >
> > > > > I don't see a need for a *special* code that is 
> unique to this 
> > > > > service.
> > > > >
> > > > >       Paul
> > > > >
> > > > > Scott Lawrence wrote:
> > > > > >> 4504) that suggest the use of 486 Busy Here, but 
> again this 
> > > > > >> is not helpful if the receiver wants to 
> distinguish between 
> > > > > >> DND
> > > > > and ordinary
> > > > > > That prevents the caller from being able to tell they are 
> > > > > > being disregarded, but some users might prefer that 
> forwarding
> > > > > take effect
> > > > > [email-masked] for questions on current sip

---

From: [email-masked]
Date: Thu, 3 Aug 2006 22:15:44 -0400

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

I beg to differ -- RFC 3261 is unpleasantly clear on the effect of 6xx
responses.  Handling *other* responses leaves the proxy with a lot of
flexibility in deciding the "target set", but for 6xx, the target set
is effectively emptied.

Though I see no reason not to change that definition -- I see the
current definition of 6xx as unusable due to evil interaction with any
system that uses "interesting" retargeting, so "there are no current
uses of the feature".

Dale

---

From: [email-masked]
Date: Thu, 3 Aug 2006 22:29:24 -0400

A "nested target set" concept would work in some cases -- The 6xx
would be qualified (implicitly or explicitly) by a target set
identifier, and the response would be cascaded back through the
forking proxies until it reached the one that was the
point-of-first-forking for that target set.

The limitation would be that the UA would have to know that the
request had been routed to it through that particular target set
before 6xx-ing it with the scope of that particular target set.

In the PSTN this is more likely to be possible, as there are a much
smaller number of forking proxies (switches), and a particular UA
(phone) is usually fed from only one of them, which handles all the
target sets that could ever route to that UA.

Things can be "more general" (messier) in SIP.

Dale

---

From: "Xiaotao Wu" <[email-masked]>
Date: Fri, 4 Aug 2006 07:33:56 -0400

> Yeah, sure, but this is IETF (SIP), not ECMA (CSTA).

CSTA is just one example in the existing application of doing this.
HTTP (as you said), SOAP can all be used to do this. It's not about
whether it's IETF or ECMA.
It's about which place we should put the service at. Certainly you
can handle it on an endpoints, but you then need to make this endpoint
be able to control the routing to other endpoints. That should not be the task
of endpoings (well, maybe in a untrusted P2P environment, this is useful).
So, I think performing DND on a proxy server (if there is, and maybe
with the help of CPL
or something like) is more appropriate than performing the service on
endpoints.

-Xiaotao

-- 
-Xiaotao

---

From: "Xiaotao Wu" <[email-masked]>
Date: Fri, 4 Aug 2006 07:39:05 -0400

> or something like) is more appropriate than performing the service on

I think 480 is the right code we should use. It clearly convey the DND
information to the caller. If we really want to perform the service on an
endpoint, we need to define a way to express the user's prefered routing,
but still use 480 as the response code.

-Xiaotao

-- 
-Xiaotao

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2006 11:28:54 -0400

I agree with Paul and Dale that the current prescribed behavior for 6xx 
makes it hard to apply to the use case we're talking about here.

I think its worth taking a step back here and discussing the broader 
problem, which is one I recall we've touched on a few times but has 
never really been resolved.

The general problem is how a UA can impact routing logic in a proxy at 
the time of call setup. We have several use cases here that are important:

1. when a user has multiple devices, and a receives a call, they would 
like to press a button on their phone called 'send to voicemail' which 
causes the call to go to voicemail. This should terminate any other 
branches for other UAs for that user if any are in progress, and halt 
any sequential search for othe UAs for that user if any were planned, 
and go to voicemail.

2. Like use case 1, except that the user wants the call to be rejected 
outright, and not even sent to voicemail.

3. Like use case 1, except that the user wants the caller to hear 
ringing for a while more and then get voicemail (sort of a polite block, 
where the caller can't differentiate this case from one where the called 
party wasn't there. Dean alluded to this).

4. send-to-X: the user wants the caller to be immediately redirected to 
somewhere else

These cases all share the common problem that, its not that a response 
is being returend from a particular UA instance (in which case proxy 
logic should try others), but rather, a response is being returned from 
the *user* that is meant to ask the proxy to definitiely do something else.

There are sevearl ways one might solve this problem:

1. The UA uploads a CPL script when it registers; that CPL script tells 
the proxy what to do based on specific response codes. For example, it 
can tell the proxy that a 476 means forward to voicemail. This has the 
benefit of not requiring standardized definitions of codes, and of 
leaving a lot of flexibility for different services. However, it falls 
apart when there are multiple UA in use and requires CPL support which 
has not seen wide success for many reasons.

2. We define one or more new response codes which have the desired 
effects. I think this is going to be hard actually, given that the four 
use cases above each might require a new response code

3. We have a header field in the response which tells the proxy that 
this response shuold be treated as if it came from *all* UA instances 
forked to from the AOR, thus cancelling all other forks for that AOR.

It feels to me like we need some requirements work and problem 
definition here. I'd argue that this is perfect fodder for our MIG BoF 
next IETF.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Xiaotao Wu" <[email-masked]>
Date: Fri, 4 Aug 2006 12:07:30 -0400

> forked to from the AOR, thus cancelling all other forks for that AOR.

4. Putting a script (e.g., a CPL-like script) as a MIME part in the response to
 instruct the proxy what to do. This is different from option 1, which invokes
 service logic by a specific response code. For example, for DND, we can
 still use 480 response code, but have a script instructing the proxy to proxy
 the call to voicemail.

-Xiaotao

-- 
-Xiaotao

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Aug 2006 11:26:05 -0500

That's because you are thinking of a network with very centralized
control...

If there is not that much coordination between the operator of the
proxy,
and the manufacturer of the terminal, then you don't really have a
choice.

For example, if I install a proxy from Open Source, or some other
manufacturer,
and terminals are not tighly controlled, there will be no SOAP or other
interface
to do this dynamic DND.  An operator of a service, e.g., in an
Enterprise, may
choose to deploy the simplest most basic SIP proxy possible.

We can speculate all we want on config protocols between terminals and
proxy, but the 
fact is all terminals that I'm aware of have the capability to do this
type of feature 
on the terminal itself. 

Some of them have the ability to choose if these features are done "on
the device" or
on a centralized proxy.

> Sent: Friday, August 04, 2006 4:34 AM
> Cc: Elwell, John; Paul Kyzivat; [email-masked]; Scott Lawrence
> HTTP (as you said), SOAP can all be used to do this. It's not 
> about whether it's IETF or ECMA.
> It's about which place we should put the service at. 
> Certainly you can handle it on an endpoints, but you then 
> need to make this endpoint be able to control the routing to 
> other endpoints. That should not be the task of endpoings 
> (well, maybe in a untrusted P2P environment, this is useful).
> So, I think performing DND on a proxy server (if there is, 
> and maybe with the help of CPL or something like) is more 
> appropriate than performing the service on endpoints.
> 
> -Xiaotao
> 
> >
> > DND on the proxy instead of the endpoint.
> >
> > You could also have a Web Page that allows you to affect routing on 
> > the proxy in a similar way.
> >
> > > the service logic can still be executed on proxy servers. For 
> > > example, Microsoft Office Communicator uses CSTA to transmit the 
> > > "Set DND"
> > > > > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > > > > Of Xiaotao Wu
> > > > > > alternate routing and will keep on ringing the other fork. 
> > > > > > That may not be the desired behavior.
> > > > >
> > > > > secretary. It's hard to compose a response from his 
> desk phone 
> > > > > to indicate that he does not want to ring his desk phone, and 
> > > > > cell phone, but ring his secretary phone and voicemail.
> > > > >
> > > > > > > Both 480 and 486 are in effect "white lies". Which one to 
> > > > > > > use may depend on which impression you want to give to the
> > > > > caller. Another
> > > > > > > >> RFC 3261 suggests the use of response code 480 
> > > > > > > >> Temporarily Unavailable for indicating do not disturb 
> > > > > > > >> (DND), but it is
> > > > > > > not used
> > > > > > > >> exclusively for this purpose. There are other 
> documents 
> > > > > > > >> (e.g., RFC
> > > > > > > [email-masked] for questions on current

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Aug 2006 11:43:11 -0500

Agreed: it does seem like a perfect case for MIG next meeting. 

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 8:29 AM
> To: Paul Kyzivat
> Cc: [email-masked]
> I agree with Paul and Dale that the current prescribed 
> behavior for 6xx makes it hard to apply to the use case we're 
> talking about here.
> 
> I think its worth taking a step back here and discussing the 
> broader problem, which is one I recall we've touched on a few 
> times but has never really been resolved.
> 
> The general problem is how a UA can impact routing logic in a 
> proxy at the time of call setup. We have several use cases 
> here that are important:
> 
> 1. when a user has multiple devices, and a receives a call, 
> they would like to press a button on their phone called 'send 
> to voicemail' which causes the call to go to voicemail. This 
> should terminate any other branches for other UAs for that 
> user if any are in progress, and halt any sequential search 
> for othe UAs for that user if any were planned, and go to voicemail.
> 
> 2. Like use case 1, except that the user wants the call to be 
> rejected outright, and not even sent to voicemail.
> 
> 3. Like use case 1, except that the user wants the caller to 
> hear ringing for a while more and then get voicemail (sort of 
> a polite block, where the caller can't differentiate this 
> case from one where the called party wasn't there. Dean 
> alluded to this).
> 
> 4. send-to-X: the user wants the caller to be immediately 
> redirected to somewhere else
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 4 Aug 2006 12:15:07 -0500

Actually, now that I re-read it, I would say that it is
"unpleasantly UNclear"...

I was focusing on the paragraph of 21.6, which
relates 6XX to a SPECIFIC USER (i.e., not a GRUU, or "particular
instance").

That, I like, and implies to me that retargeting (i.e., going
to a different user) is a valid action upon receipt of 6XX.

If you call [email-masked], and I reject it with
6XX, it could be retargeted by one of our proxies to [email-masked]

for example or [email-masked].

However, the subsections for 600/603/606 talk of "no other
endpoint" as opposed to the SPECIFIC user. That's the ones
that I think you were focussing on. It would prohibit retargeting
to [email-masked]/[email-masked].

Interestingly enough, 604 however is related to a specific
URI, not "any endpoints" (and consequently could be retargeted).

In short, this whole section contradicts itself by not being clear
about what 6XX implies: a failure of target, or a failure of the 
session...

> Sent: Thursday, August 03, 2006 7:16 PM
> To: [email-masked]
> I beg to differ -- RFC 3261 is unpleasantly clear on the 
> effect of 6xx responses.  Handling *other* responses leaves 
> the proxy with a lot of flexibility in deciding the "target 
> set", but for 6xx, the target set is effectively emptied.
> 
> Though I see no reason not to change that definition -- I see 
> the current definition of 6xx as unusable due to evil 
> interaction with any system that uses "interesting" 
> retargeting, so "there are no current uses of the feature".
> 
> Dale
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 4 Aug 2006 10:53:40 -0700

I would like to add also the (hopeful) scenario where my multi-line SIP
UA is registered with competing service providers that don't cooperate
too much.

In such a scenario DND is a matter of local policy in the UA. 

Building DND into the network seems to be another Centrex-like pipe
dream. It's overly complicated as is already.

Thanks, Henry

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 4 Aug 2006 14:13:37 -0500

I was thinking this would be something for MiG to look at. The cat is
not without skin, it's just in how we wish to remove it.

Regards,
Brian 

> From: Audet, Francois (SC100:3055) 
> Sent: Friday, August 04, 2006 12:43 PM
> To: Jonathan Rosenberg; Paul Kyzivat
> Cc: [email-masked]
> > I agree with Paul and Dale that the current prescribed behavior for 
> > 6xx makes it hard to apply to the use case we're talking about here.
> > 
> they would 
> > ringing for a while more and then get voicemail (sort of a polite 
> > block, where the caller can't differentiate this case from 
> one where 
> > the called party wasn't there. Dean alluded to this).
> > 
> > logic should try others), but rather, a response is being returned 
> > from the *user* that is meant to ask the proxy to definitiely do 
> > something else.
> > 
> > 1. The UA uploads a CPL script when it registers; that CPL script 
> > tells the proxy what to do based on specific response codes. For 
> > example, it can tell the proxy that a 476 means forward to 
> voicemail.
> > This has the
> > effects. I think this is going to be hard actually, given that the 
> > four use cases above each might require a new response code
> >

---

From: [email-masked]
Date: Wed, 9 Aug 2006 00:04:44 -0400

From: Jonathan Rosenberg <[email-masked]>

1 and 4 can be accomplished by the callee UA either proxying the
INVITE on to the desired destination, or returning a 302 to make the
next upstream proxy do so.

3 can be accomplished by the UI ceasing user notification while the UA
continues to handle the SIP transaction as it would if the user did
not answer.

2 is trickier, because it wants to modify the forking results, when
the UA isn't fully aware of what those forking results might be.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Aug 2006 09:08:09 -0400

The trouble with these scenarios is that they are only part of a bigger 
picture. Consider the following:

- Alice calls Bob.
- Bob has configured his proxy with some policies about
   how to handle the call
- One of Bob's policies is to parallel fork calls to
   Bob's own phones (several) and to Charlie's AOR
- Charlie has configured his proxy with policies about
   how to handle the call.
- One of Charlie's policies is to parallel fork calls
   to his own phones.

Now assume that all of the phones above have buttons with meanings 
something like what Jonathan mentions.

One question is whether those buttons imply invocation of some new 
policy that competes with the proxy based policies, or if the buttons 
should simply provide input to the policy decisions.

That isn't a question we can or should answer here. I think we must 
recognize that there are many ways of doing this. What we can do is work 
through a variety of use cases and convince ourselves there is 
sufficient mechanism to facilitate the use cases we think important.

It seems to me that for a good result you must assume that the actions 
of the phone need to be coordinated with the actions of the proxy in 
front of the phone. (E.g. if the proxy has policy to fail over to 
voicemail, then the phone probably ought not be returning 3xx when it is 
busy or doesn't answer.)

That extends to the case where the call is delegated to another AOR. But 
in that case it is much harder to ensure the behaviors are coordinated.

	Paul

---

From: "Xiaotao Wu" <[email-masked]>
Date: Wed, 9 Aug 2006 09:57:16 -0400

> next upstream proxy do so.

302 may not terminate the other branches.

-Xiaotao

-- 
-Xiaotao

---

From: [email-masked]
Date: Wed, 9 Aug 2006 10:40:18 -0400

From: "Xiaotao Wu" <[email-masked]>

True.  But if it goes to a voicemail system, which presumably answers
immediately, then it will.

But some of these concepts (particularly, "reject"), assume that the
UA that is ringing has the knowledge/authority to affect the routing
for all branches of the call.  But is not always the case, since the
original request-URI may not be the AOR for the UA, but rather some
other AOR that has its own policies for routing.

Dale