Subject: RE: [Sipping] draft-elwell-sipping-redirection-reason-01

From: "Elwell, John" <[email-masked]>
Date: Wed, 09 Feb 2005 21:42:54 +0000

Dave,

Thanks for your interest. Response in-line.

John

> -----Original Message-----
> From: David R Oran [mailto:[email-masked]] 
> Sent: 09 February 2005 20:04
> To: Cliff McCollum
> Cc: [email-masked]'; Elwell, John; Paul Kyzivat
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> 
> On Feb 9, 2005, at 12:40 PM, Cliff McCollum wrote:
> 
> > Paul, I appreciate your detailed example. I agree that 
> Bob's VM server 
> > can't do anything useful with the H-I or Reason.
> >
> >  However, Alice's VM server can benefit substantially from the 
> > proposed Reason codes. One of the most used enterprise 
> features in a 
> > VM system is the ability to play a different greeting 
> depending upon 
> > whether the call arrived at the VM due to a busy-signal, no-reply, 
> > immediate forwarding, etc. Without the proposed extension (or 
> > something like it), I'm not sure how a VM server can offer this 
> > feature.
> >
> Correct me if I'm wrong, but history already tells you this - 
> it shows 
> the contacts tried and the response codes. In fact, it can tell you 
> about ambiguous behavior, where you parallel forked to two contacts 
> before trying the voicemail, and one gave you a 486 and the 
> other got a 
> no-answer time out. The voicemail server can even tell if the call 
> arrived because of an explicit redirect from one of the contacts and 
> play a "Bob really doesn't want to talk to you so don't bother trying 
> again because you'll just wind up right back here" greeting.
[JRE] But there are some shortcomings in this, as I tried to describe in the
draft. In particular, if a node wishes to redirect because of busy, there is
no 3xx response code to say that. It could return a 302, say, to invite
redirection, but the enhanced Reason header could say that this is because
of busy, no reply, etc.

> 
> >  I believe this extension is required to provide proper 
> behavior for 
> > VM servers and other automated systems. It can probably 
> provide value 
> > to human users as well. For example, knowing that a call 
> arrived at my 
> > mobile handset because it was an immediate forward from 
> some other UaR 
> > could offer me the chance to pass my handset to my friend 
> instead of 
> > answering it myself.
> >
> I disagree. If there are deficiencies in history we should fix this 
> there. There's a general philosophy question at stake on whether you 
> have intermediaries guessing policy for the application servers and 
> telling then via the reason field why they think they sent the call 
> there, or just telling them what happened and letting the application 
> server apply its policy to that. There may be some reasons to do the 
> former, but so far I haven't heard one that's persuasive.
> 
> >  I think we just need to tighten up some of the definitions in the 
> > draft. What if we removed the phrase "Normal redirection" 
> and turned 
> > it into a catch-all for anything that wasn't one of the 
> other reasons?
> >
> For me, that doesn't help. The set of reasons why a call got bumped 
> somewhere is essentially unbounded.
> 
> Dave.
> 
> >  Cliff
> >
> >
> >
> >  Paul Kyzivat wrote:
> >
> >
> > OK. Now for more discussion.
> >
> >  I *think* you are getting into what is really mushy ground 
> in 3261. 
> > We constantly talk about AoRs and Contact addresses, 
> pretending that 
> > they are different things. Roughly I think what people have in mind 
> > is:
> >
> >  - an AoR is something managed by a proxy/registrar. Registrations
> >    are accepted to an AoR, associated Contact addresses with it.
> >
> >  - a Contact address is something that identies and is managed by a 
> > UAS.
> >    It is associated with an AoR via a REGISTER.
> >
> >  Using those definitions, I think you are trying to say that:
> >  - when a proxy responsible for an AoR retargets or 
> redirects to one 
> > of the contact addresses associated with that AoR, then it 
> is "normal" 
> > retargeting or redirection.
> >
> >  - when retargetting or redirection occurs for any other 
> reason then 
> > it is not "normal", and you want to characterize why it happened.
> >
> >  Do I have that about right?
> >
> >  The problem is that the real world is more complex than the above. 
> > The following are some problems:
> >
> >  - AoRs and Contact addresses can generally only be 
> recognized for what
> >    they are by the node responsible. You can't look at an 
> arbitrary URI
> >    and decide which it is.
> >
> >  - even ignoring who can tell, a given URI isn't 
> necessarily just an 
> > AoR
> >    or just a Contact. It can be both, or neither. The terms are
> >    contextual. (Whether it is a good idea or not, I can 
> take a URI that
> >    identifies an AoR, and register it as a contact of another AoR.)
> >
> >  - What is a URI that identifies a mailbox in a VM server? (e.g.
> >    sip:[email-masked].) Is it a contact if it is registered
> >    and something else if it is not? Is it a contact if it 
> is registered
> >    to sip:[email-masked] but not if it is registered to
> >    sip:[email-masked]?
> >
> >  Lets consider one case that might be illustrative:
> >
> >  - We have two addresses: sip:[email-masked] and 
> sip:[email-masked]
> >
> >  - a proxy/registrar atlanta.com considers 
> sip:[email-masked] to be
> >    an AoR that it is responsible for. Similarly, a proxy/registrar
> >    biloxy.com considers sip:[email-masked] to be an AoR.
> >
> >  - Alice has a phone. It has address phone.alice.com, and registers
> >    sip:[email-masked] as a contact for 
> sip:[email-masked], with
> >    a q-value of 1.0.
> >
> >  - Alice also has a voicemail account on a server at vm-r-us.com.
> >    Her mailbox has the address sip:[email-masked]. The server
> >    registers this mailbox address as a contact for 
> > sip:[email-masked],
> >    with a q-value of 0.1.
> >
> >  - Bob has a phone. It has address phone.bob.com, and registers
> >    sip:[email-masked] as a contact for sip:[email-masked], with
> >    a q-value of 1.0.
> >
> >  - Bob also has a voicemail account on a server at cheap-vm.com.
> >    His mailbox has the address sip:[email-masked]. The server
> >    registers this mailbox address as a contact for 
> sip:[email-masked],
> >    with a q-value of 0.1.
> >
> >  - Alice is visiting Bob and wants to get her calls. The atlanta.com
> >    server isn't a very good one, and doesn't provide any way to 
> > configure
> >    forwarding. But Alice found a little hack tool that allows her to
> >    do registrations from the web. So she uses that tool to register
> >    sip:[email-masked] as a contact for sip:[email-masked], with a
> >    q-value of 0.5.
> >
> >  - Charlie calls Alice, resulting in
> >        INVITE sip:[email-masked]
> >        To: sip:[email-masked]
> >        ...
> >
> >  - The call reaches atlanta.com. It first retargets the call to
> >    sip:[email-masked], but there is no answer there.
> >
> >  - So atlanta.com tries the next highest q-value, retargetting the
> >    call to sip:[email-masked].
> >
> >  - the call reaches biloxy.com. It first retargets the call to
> >    sip:[email-masked]. But Alice and Bob are out for coffee,
> >    so there is no answer there either.
> >
> >  - So biloxi.com tries the next highest q-value, retargetting the
> >    call to sip:[email-masked]. This answers the call.
> >
> >  I'd like to know what behavior you would expect the VM server to 
> > exhibit, and what you would expect it to look at in order 
> to decide on 
> > that behavior. Does it require something special in 
> History-Info? Does 
> > the Reason header play any part?
> >
> >  If you like, we can make changes to the above scenario in order to 
> > display other aspects of what you are trying to achieve.
> >
> >      Paul
> >
> >  P.S. The following is *my* opinion:
> >
> >  In the above, I see no role for either H-I or Reason. 
> Probably the VM 
> > system acts exactly the same way it would if the call was 
> intended for 
> > Bob.
> >
> >  It *might* take a look at the To header, note that it 
> isn't the AoR 
> > it had registed with, and adjust the message it plays out. But in 
> > general it would not know who Alice is, so there isn't a lot of 
> > special behavior it can exhibit.
> >
> >  In particular, it isn't the VM server for Alice, so it 
> can't decide 
> > to use Alice's message and mailbox. If that is what Alice wanted to 
> > happen, then she should have forwarded directly to 
> > sip:[email-masked]. Or she could have forwarded to Bob's AoR with 
> > callerprefs to reject voicemail there, but that would be 
> trickier to 
> > set up.
> >
> >
> >
> >
> > -- 
> > Cliff McCollum, M.Sc.
> > Vice-President Technology and Development, Voice Mobility Inc.
> >
> >  [email-masked]
> >  www.voicemobility.com
> > Voice, Mobile, Fax: (250) 978 4255
> >
> > _______________________________________________
> > 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
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: [email-masked]
> 

_______________________________________________
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