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

From: "Mary Barnes" <[email-masked]>
Date: Wed, 9 Feb 2005 16:46:05 -0500

I don't think this problem is at all about a deficiency in History-Info
(albeit History-Info would likely be used in many of the scenarios where
John wants to use his new Reason value), but it's entirely transparent to
History what's in the Reason header (which is included as part of the
History-Info entry, if available). I think the issue was that the 302
response is ambiguous as to whether it was invoked as part of routing by a
Redirect server or due to a specific response at the end user. Francois had
provided an example back in August that highlighted the ambiguity when a
voicemail server is in the PSTN:
http://www.ietf.org/mail-archive/web/sipping/current/msg06919.html

I think, though, that we need to step back to a point made earlier on this
topic that suggests that what's really needed here would be a "Q.732"
protocol value extension to the Reason header:
http://www1.ietf.org/mail-archive/web/sipping/current/msg06561.html
John, I can't remember why this idea was discarded (I've not gone back
through the archives thoroughly); was there a "reason" other than it's not a
generic thing?  I think the VM example has gotten to be a bit of a red
herring and that fundamentally folks that are interworking various legacy
protocols need this information to properly interwork their services with
SIP.  As I recall, John's intent was to provide something a little more
general purpose.  Is there a use case for this functionality beyond VM
(which is already a topic that we know we can't agree upon)?  

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R Oran
Sent: Wednesday, February 09, 2005 2:04 PM
To: Cliff McCollum
Cc: Elwell, John; Paul Kyzivat; [email-masked]'
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.

>  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

_______________________________________________
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