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

From: Jeroen Van Bemmel <[email-masked]>
Date: Thu, 03 Aug 2006 20:29:35 +0200

...but 3xx wouldn't stop other devices from ringing

To clarify: I was argueing for a 6xx response. In addition, the body could have some HTML with links for alternative means of contact. Could be personalized, etc

IMHO there should not be too much complicated automatic handling in the proxies. Better to present the case to the caller, and let him decide

Regards,

Jeroen

PS but perhaps a "3xx code with 6xx effect" (or vice versa) could help

-----Oorspronkelijk bericht -----
Van: "Francois Audet" <[email-masked]>
Aan: "Jeroen Van Bemmel" <[email-masked]>; "Xiaotao Wu" <[email-masked]>
CC: [email-masked]; "Paul Kyzivat" <[email-masked]>; "Elwell,	John" <[email-masked]>; "Scott Lawrence" <[email-masked]>
Verzonden: 3-8-06 20:12
Onderwerp: RE: [Sipping] Question on do not disturb indication

If you provide an alternate address, then it should be a 3XX response.

> -----Original Message-----
> From: Jeroen Van Bemmel [mailto:[email-masked]] 
> Sent: Thursday, August 03, 2006 5:06 AM
> To: Xiaotao Wu; Audet, Francois (SC100:3055)
> Cc: [email-masked]; Paul Kyzivat; Elwell, John; Scott Lawrence
> Subject: RE: [Sipping] Question on do not disturb indication
> 
> 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.
> 
> (JvB) The reason phrase is (and was always) intended for 
> this. "480 Do not disturb (use IM, call my secretary or leave 
> a voiemail)" would seem appropriate. The semantics are hard 
> to convey to a machine, therefore ideally the choice for any 
> follow ups should be made by the caller IMHO. A 6xx would 
> guarantee that outcome
> 
> Regards,
> Jeroen 
> 
> 
> 

_______________________________________________
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: Jeroen Van Bemmel <[email-masked]>
Date: Fri, 04 Aug 2006 13:33:48 +0200

It occurred to me that perhaps the best response would be 200, immediately followed by BYE. That will take care of the "retargeting people" who interpret 6xx as "only CANCEL this set" (and then retarget to voicemail)

Regards,

Jeroen

-----Oorspronkelijk bericht -----
Van: [email-masked]
Aan: [email-masked]
Verzonden: 4-8-06 04:15
Onderwerp: Re: [Sipping] Question on do not disturb indication

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

   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.

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: "Elwell, John" <[email-masked]>
Date: Sun, 06 Aug 2006 14:52:33 +0100

Francois,

If the use of 480 temporarily available were restricted to that described in
RFC 3261, then that means pretty much DND. Unfortunately current practice
seems to use 480 for other purposes too, such as mapping from Q.850 cause
code 19 No Answer From User in RFC 3398.

John

> From: Francois Audet [mailto:[email-masked]] 
> Sent: 04 August 2006 17:21
> To: Elwell, John
> Cc: [email-masked]
> Hi John,
> Can you provide me an example of where  a proxy would react 
> different to
> "temporarily unavailable" versus "Do not disturb"?
> 
> I sense that this is kind of similar to the ambiguity of 302 
> problem...
> 
> > From: Elwell, John [mailto:[email-masked]] 
> > Sent: Thursday, August 03, 2006 11:33 AM
> > To: Audet, Francois (SC100:3055); Paul Kyzivat; Scott Lawrence
> > Cc: [email-masked]
> > Francois,
> > It is not only that I want the caller to know that I am in 
> > DND - also my proxy, if it is scripted to perform special 
> > behaviour on DND (e.g., retarget), then I would like it to 
> > know. I am not sure that 480 is sufficiently precise.
> > 
> > John 
> > 
> > > From: Francois Audet [mailto:[email-masked]]
> > > Sent: 03 August 2006 19:10
> > > To: Elwell, John; Paul Kyzivat; Scott Lawrence
> > > Cc: [email-masked]
> > > > [JRE] I agree that "make busy" is a separate feature 
> and is best 
> > > > dealt with by 486. But where I explicitly want the 
> caller to know 
> > > > that I am in DND (possibly with a retry-after time), do 
> you think 
> > > > that 480 is sufficient, bearing in mind that it gets used 
> > for other 
> > > > purposes too, e.g., in RFC3398?
> > > 
> > > Personally, I think it is sufficient, and I also think 
> that mapping 
> > > DND to 480 is pretty much established by now.
> > > 
> > > My perspective is Enterprise-centric however: there might be some 
> > > Service Provider services that need a more precise indication.
> > > I could be convinced that it is needed...
> > > 
> > 
>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 8 Aug 2006 11:40:08 -0400

There seems to be a distinction between "what just happened" (hit a
busy/DND user) and "what should happen next" (go to voicemail or stop
calling me).  Is MIME and CPL needed or just some token in a new header:

Instruction:<urn:suggestion:go-to-voicemail>
or
Instruction:<urn:suggestion:go-pound-sand>

Mike

> From: Xiaotao Wu [mailto:[email-masked]] 
> Sent: Friday, August 04, 2006 12:08 PM
> To: Jonathan Rosenberg (jdrosen)
> Cc: Paul Kyzivat (pkyzivat); [email-masked]
> Subject: Re: [Sipping] Question on do not disturb indication
> 
> >
> > 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.
> 
> 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
> 
> >
> >
> > 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.
> >
> >
> >
> > Paul Kyzivat wrote:
> >
> > > I went at reviewed 3261 on this and found some interesting things:
> > >
> > > -  Global Failures 6xx
> > >
> > >    6xx responses indicate that a server has definitive 
> information about
> > >    a particular user, not just the particular instance 
> indicated in the
> > >    Request-URI.
> > >
> > >    (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
> > >
> > >
> > >
> > > [email-masked] wrote:
> > >
> > >>    From: Scott Lawrence <[email-masked]>
> > >>
> > >>    The one thing that I _don't_ like to see is a 603 
> being used for this;
> > >>    that messes up any upstream forking.
> > >>
> > >> 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
> > >>
> > >> 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
> > >>
> > >
> > > 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
> > >
> >
> > --
> > 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
> >
> > 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
> 
> ===========================================================
> 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.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>