Subject: RE: [Sipping] Question on do not disturb indication

From: "Elwell, John" <[email-masked]>
Date: Thu, 03 Aug 2006 07:28:28 +0100

Dean,

So what would you like the IETF to recommend? Do you believe 480 mostly
works, or do you think something new is needed?

John 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 03 August 2006 04:17
> To: Dolly, Martin C, ALABS
> Cc: Paul Kyzivat; Scott Lawrence; Elwell, John; [email-masked]
> Subject: Re: [Sipping] Question on do not disturb indication
> 
> 
> On Aug 2, 2006, at 5:58 PM, Dolly, Martin C, ALABS wrote:
> 
> > Is not this a question for the market to decide?
> > 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
> 

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 3 Aug 2006 16:05:54 -0500

> works, or do you think something new is needed?

Hey, I'm just a consumer. I don't want to know the technical details.  
I just want it to work, mostly.

If it were up to me, I'd be asking the question:

What part of DND is important for a calling human to understand, vs.  
a calling automata? Is there a distinction needed?

If we believe that we'd like to convey a distinction between  
"Temporarily unavailable" and "Temporarily unavailable due to  
subscriber choice" to a human, perhaps a reason phrase on a 480 would  
be adequate? Like "480 Do Not Disturb", maybe.

An automata is just likely to retry the call periodically anyhow, but  
a human might stop and think "Oh yeah, it IS the middle of the night  
in Singapore . . .".

Question: How beneficial would a Retry-After value be in rate- 
limiting the retries of automata?

Now, I will say that Martin is right in that there might be many  
reasons to reject a call, that DND is just the tip of the iceberg,  
and that there's no way we can define them all.

Now, here's an interesting thought. If I use a reason phrase on 480,  
and couple it to the right software, I can use SIP INVITE requests as  
a covert-channel replacement for HTTP GET operations (or file  
transfer, or whatever) , but peer-to-peer using the SIP  
infrastructure as a rendezvous service.  Don't try this at home, kids.

--
Dean

---

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

I agree with Dean here.

Why do you want to know, at the calling UA side, that the call was busy 
because of DND? Whether you need a new code depends on the answer:

1. if you want the human user to know that this was DND so they can do 
something appropriate, a reason phrase is exactly the right thing

2. if you want to have the calling UA to do something different, what 
would it do differently on a 'your call was rejected by DND' vs. 'your 
call was rejected because the user is on another call'? If the answer is 
nothing, then you don't need a new response code.

I'm also leary about defining new response codes to do a specific 
terminating application that is running. Saying that this was rejected 
due to 'DND' requiers you to have a standard definition for DND. I don't 
want to do that. As others have pointed out, a reasonable implementation 
for DND is that the termianting network simply lets the phone ring and 
eventually responds with a 480. That should be allowed.

Thanks,
Jonathan R.

Dean Willis wrote:

> Hey, I'm just a consumer. I don't want to know the technical details.  I 
> just want it to work, mostly.
> 
> What part of DND is important for a calling human to understand, vs.  a 
> calling automata? Is there a distinction needed?
> 
> An automata is just likely to retry the call periodically anyhow, but  a 
> human might stop and think "Oh yeah, it IS the middle of the night  in 
> Singapore . . .".
> 
> Question: How beneficial would a Retry-After value be in rate- limiting 
> the retries of automata?
> 
> reasons to reject a call, that DND is just the tip of the iceberg,  and 
> that there's no way we can define them all.
> 
> 
> and couple it to the right software, I can use SIP INVITE requests as  a 
> covert-channel replacement for HTTP GET operations (or file  transfer, 
> or whatever) , but peer-to-peer using the SIP  infrastructure as a 
> rendezvous service.  Don't try this at home, kids.
> 
> -- 
> Dean
> 

-- 
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: "Henry Sinnreich" <[email-masked]>
Date: Fri, 4 Aug 2006 10:53:40 -0700

This is also a good time to remember once more there is in a SIP a
capability called PRESENCE that is much more useful than DND and many
other legacy telephony features.  :-)

Why ignore Presence and just stick with the "old proven way"?

Thanks, Henry

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 8:12 AM
To: Dean Willis
Cc: Dolly, Martin C, ALABS; Paul Kyzivat; Elwell,John; [email-masked];
Scott Lawrence

I agree with Dean here.

Thanks,
Jonathan R.

> Hey, I'm just a consumer. I don't want to know the technical details.
I 
> What part of DND is important for a calling human to understand, vs.
a 

> An automata is just likely to retry the call periodically anyhow, but
a 

> Question: How beneficial would a Retry-After value be in rate-
limiting 
> reasons to reject a call, that DND is just the tip of the iceberg,
and 
> and couple it to the right software, I can use SIP INVITE requests as
a

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Aug 2006 13:48:53 -0500

> Why ignore Presence and just stick with the "old proven way"?

Unfortunately, it is not that easy (or clean).

The original question from John Elwell (I think) was:
 > 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?

We had a discussion on DND way back in January 2003 in the
SIMPLE WG (links to the thread follow in a bit).  If you follow
that thread, you will conclude that DND is more of a state of
mind that cannot be actively captured by a response code.  When
coupled with presence, it means that all devices that are
representing my presence should show a state of CLOSED (and this
was debated hotly back in 2003), otherwise if they don't then
we simply train the watcher to call us even though we are not in
a state to accept that call.  As things stand today, I don't
think I can push a DND button and make all my devices show a
state of CLOSED -- some will after no activity (computer),
others will if they are shut off (PDAs, cell phones, with
representable avatars on a buddy list), and so on.

For some institutional memory, the folks who are active in
this thread should really look at the thread we had way back
in January 2003 on this subject.  The link is:
http://www1.ietf.org/mail-archive/web/simple/current/msg00144.html

The rest of the thread can be followed from
http://www1.ietf.org/mail-archive/web/simple/current/mail265.html

Thanks.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Bell Laboratories, Lucent Technologies, Inc.
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
_______________________________________________
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: Dean Willis <[email-masked]>
Date: Fri, 4 Aug 2006 14:15:54 -0500

On Aug 4, 2006, at 1:48 PM, Vijay K. Gurbani wrote:
> When

So when a request shows up at a device that is CLOSED, how should the  
device respond?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 04 Aug 2006 09:12:38 -0400

Dean Willis wrote:

> "Temporarily unavailable" and "Temporarily unavailable due to subscriber 
> choice" to a human, perhaps a reason phrase on a 480 would be adequate? 
> Like "480 Do Not Disturb", maybe.

I have never understood the purpose of reason phrases, or the value of 
sending different ones with the same response code.

Doing so implies an expectation that the UAC will do something different 
as a result. Its hard to do something different algorithmically, because 
there are no useful specs on what can be there. (Some UASs may choose to 
send the reason phrases translated into the language of the UAS 
developer - say Klingon.)

About the best one could hope for would be for some UACs to *display* 
the value, uninterpretted. But that only works for UACs that have the 
capability to do so, and that in fact do so. Realistically, providing 
that is only useful to geeks.

> Now, I will say that Martin is right in that there might be many reasons 
> to reject a call, that DND is just the tip of the iceberg, and that 
> there's no way we can define them all.

Right.

There *is* a mechanism defined for this: Error-Info. There is good and 
bad to it:

- good: because the value is a URI (or several) it is arbitrarily 
extensible to new reasons

- good: it can make it possible for the UAC to obtain something that can 
be rendered to the calling user, without the UAC needing to know all 
possible reasons.

- bad: its still hard for the UAC or a proxy to take programatic action 
based on the reason because there are no standards for what the reasons 
might be. It is possible that two different UASs might choose different 
URIs to represent the same reason.

On balance, this seems like a reasonable approach to me.

	Paul

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Aug 2006 14:24:55 -0500

> So when a request shows up at a device that is CLOSED, how should the  

Dean: Are you trying to bait me, for I am sure you know the
answer to that question...

In an ideal world, a request would not even show up when a device
is CLOSED.

In our non-ideal world, a 4xx type response seems appropriate.
But DND also means that a request will not succeed on other
devices either; so a 6xx is more appropriate.

But it is one thing to have a response code, quite another
to uniformly apply the DND directive across all the devices
that contribute to my presence -- and that was what I was
trying to point out in my email regarding institutional
memory.

Thanks.

- vijay

---

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

Actually, this is a very good point.

There are really 2 aspects to "Do Not Disturb":

1 - On aspect for the terminating side to "reject" a session. That's the
one I was
    focussing on. That's the one where many of us are not convinced that
we need
    something beyond what is already allowed with SIP (480, 486, 6XX,
etc.).

2 - The other aspect is conveying a DND indication to the other end. I
guess
    John was thinking about that. Henry is right that this aspect is
definitively 
    something appropriate for presence...

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 10:54 AM
> To: Jonathan Rosenberg; Dean Willis
> Cc: Dolly, Martin C, ALABS; Paul Kyzivat; Elwell, John; 
> [email-masked]; Scott Lawrence
> Subject: RE: [Sipping] Question on do not disturb indication
> 
> This is also a good time to remember once more there is in a 
> SIP a capability called PRESENCE that is much more useful 
> than DND and many other legacy telephony features.  :-)
> 
> Cc: Dolly, Martin C, ALABS; Paul Kyzivat; Elwell,John; 
> [email-masked]; Scott Lawrence
> Why do you want to know, at the calling UA side, that the 
> call was busy because of DND? Whether you need a new code 
> depends on the answer:
> 
> 1. if you want the human user to know that this was DND so 
> they can do something appropriate, a reason phrase is exactly 
> the right thing
> 
> 2. if you want to have the calling UA to do something 
> different, what would it do differently on a 'your call was 
> rejected by DND' vs. 'your call was rejected because the user 
> is on another call'? If the answer is
> 
> I'm also leary about defining new response codes to do a 
> specific terminating application that is running. Saying that 
> this was rejected due to 'DND' requiers you to have a 
> standard definition for DND. I don't
> 
> for DND is that the termianting network simply lets the phone 
> ring and eventually responds with a 480. That should be allowed.
> 
> Thanks,
> Jonathan R.
> 
> Dean Willis wrote:
> 
> > 
> > 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
> > 
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 4 Aug 2006 13:03:30 -0700

> DND is more of a state of
> mind that cannot be actively captured by a response code.  

Exactly!

That why all commercial IM's have presence icons and the SIMPLE WG is
developing RPID, see
http://www3.ietf.org/proceedings/06mar/IDs/draft-ietf-simple-rpid-10.txt

One of the authors is V. Gurbani :-)

Thanks, Henry

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 11:49 AM
To: Henry Sinnreich
Cc: SIPPING LIST
Subject: Re: [Sipping] Question on do not disturb indication

Thanks.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Aug 2006 16:21:52 -0500

> sending different ones with the same response code.

Paul: From a development point of view, reason phrases are
simply fantastic.  Why ... inline.

> as a result. 

I don't view it that way.  Take for instance the 400 Bad Request
response.  In and of itself, it only says that the request was
malformed.  But, when coupled with an descriptive phrase, the
intent of why the response was issued becomes clearer:

   400 Missing Call-ID Header
   400 Missing Contact Header
   400 Multiple To Headers

and so on.

Here, to the receiving UAC, the 4xx puts it in a certain state.
The state would be the same regardless of the reason phrase.
But if the UAC has display capabilities (and many, if not all
do), then this becomes another tool for imparting information
to the user (or the developer, as the case may be).

Another example is the following 200 OK for a REG request:

   200 OK
   200 Registration Expired

The first 200 OK tells the UAC that the registration was
accepted.  If the UAC later sends a REG w/ Expires:0, then
the reason phrase "Registration Expired" conveys appropriate
semantic information that to me is better than a simple "OK".

> that is only useful to geeks.

Or implementors [(who are geeks by definition, anyway ;-)]

Thanks.

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 04 Aug 2006 15:11:34 -0500

> One of the authors is V. Gurbani :-)

Thanks, Henry; yes, I do remember.  The thread I pointed out
was the successor of another thread that eventually lead to the
creation of RPID (which became an RFC recently -- RFC 4480 ;-) )

Ciao.

- vijay

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 05 Aug 2006 21:40:50 +0200

Other example is 403 -- I don't think there is enough error code space for 
all possible reasons why a request is prohibited from execution. If not for
other reasons, than for troubleshooting reason phrases seem a great deal to me.

-jiri

At 23:21 04/08/2006, Vijay K. Gurbani wrote:
>Paul Kyzivat wrote:
>>I have never understood the purpose of reason phrases, or the value of sending different ones with the same response code.
>
>>Doing so implies an expectation that the UAC will do something different as a result. 
>
>>About the best one could hope for would be for some UACs to *display* the value, uninterpretted. But that only works for UACs that have the capability to do so, and that in fact do so. Realistically, providing that is only useful to geeks.
>

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 07 Aug 2006 09:10:07 -0400

> simply fantastic.  Why ... inline.

OK. I do accept that they can be useful for debugging. But I don't 
reason phrases being useful for communicating reasons *operationally*.

> to the user (or the developer, as the case may be).

For developer, yes. For the user, I don't think so. It requires the UAC 
to give up too much control over the UI, potentially leading to support 
calls, etc. because the user is confused over what is displayed.

	Paul