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

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

On Thu, 2006-08-03 at 15:18 +0100, Elwell, John wrote:
> Scott,
> 
> To solve your 'ring twice' problem, we could, as an alternative to your
> suggestion, have an explicit indication of DND, and so at least this would
> allow a proxy that is scripted to take special action on DND (e.g., go to
> voicemail) to know when to take that action, rather than assuming 480 is DND
> or relying on a reason phrase in 480.

At this point, the difficulty in the proxy is that it doesn't know or
care which forks are phones and which are voicemail and which are rude
recorded messages.  It just forks calls to the configured/registered
contacts.  Other than a couple of special cases called out by 3261 like
authentication challenges, it treats all 4xx responses exactly the same.

I don't actually think that there is a 'problem' to be solved other than
user agents asserting global knowledge by sending 6xx responses.

To get back to your original question - whether or not there is an
explicit response code needed for 'I am in DND mode, so your call has
been ignored'... I don't think so.  We have a framework for providing
presence information that is rich enough to provide that information,
and to mediate who gets which view of it.  I think that the response to
invite should be as simple as it is now (480 is fine for this), and if
user agents want to provide a richer experience then they should support
presence.

-- 
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/

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Thu, 3 Aug 2006 10:20:42 -0500

IMHO- 480 seems too generic a response from the UAS (although I have no
problem with sending this to the UAC). What's wrong with 486 from the
UAS?

Regards,
Brian  

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 10:29 AM
> To: Elwell, John
> Cc: [email-masked]
> Subject: RE: [Sipping] Question on do not disturb indication
> 
> > To solve your 'ring twice' problem, we could, as an alternative to 
> > your suggestion, have an explicit indication of DND, and so 
> at least 
> > this would allow a proxy that is scripted to take special action on 
> > DND (e.g., go to
> > voicemail) to know when to take that action, rather than 
> assuming 480 
> > is DND or relying on a reason phrase in 480.
> 
> At this point, the difficulty in the proxy is that it doesn't 
> know or care which forks are phones and which are voicemail 
> and which are rude recorded messages.  It just forks calls to 
> the configured/registered contacts.  Other than a couple of 
> special cases called out by 3261 like authentication 
> challenges, it treats all 4xx responses exactly the same.
> 
> I don't actually think that there is a 'problem' to be solved 
> other than user agents asserting global knowledge by sending 
> 6xx responses.
> 
> To get back to your original question - whether or not there 
> is an explicit response code needed for 'I am in DND mode, so 
> your call has been ignored'... I don't think so.  We have a 
> framework for providing presence information that is rich 
> enough to provide that information, and to mediate who gets 
> which view of it.  I think that the response to invite should 
> be as simple as it is now (480 is fine for this), and if user 
> agents want to provide a richer experience then they should 
> support presence.
> 
> --

---

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

Scott,

John

> Sent: 03 August 2006 13:36
> To: Hadriel Kaplan
> Cc: [email-masked]
> On Thu, 2006-08-03 at 03:37 -0400, Hadriel Kaplan wrote:
> > 
> > [about a 603 response...]
> > > 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.
> > 
> > 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.  
> 
> 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).
> 
> --