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

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

Paul,

I greatly appreciate your taking time to write such a detailed and helpful
response. My further comments in-line.

John

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 09 February 2005 16:06
> To: Elwell, John
> Cc: Francois Audet; 'Jesske, R'; 'Joanne McMillen'; [email-masked]'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> John - a few comments inline and discussion at end.
> 
> 	Paul
> 
> Elwell, John wrote:
> > 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[email-masked]] 
> >>Sent: 08 February 2005 18:23
> >>To: Francois Audet
> >>Cc: 'Elwell, John'; 'Jesske, R'; 'Joanne McMillen'; 
> [email-masked]'
> >>Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> >>
> >>I have a problem with the whole notion of "retargetting" - I 
> >>don't know 
> >>how well defined it is.
> >>
> >>If I have two UAs registered to my AoR, with the same 
> q-value, and a 
> >>reqeust is parallel forked to them, then I guess there is no 
> >>retargetting.
> > 
> > [JRE] This is what I would regard as "normal retargeting".
> > 
> > 
> >>If they have different q-values and a request is serial 
> >>forked, and the 
> >>first fork doesn't answer, is going to the 2nd tine of the fork 
> >>retargetting?
> > 
> > [JRE] I would still regard this as "normal retargetting" - 
> the difference
> > between serial and parallel forking is just a matter of timing.
> > 
> > 
> >>Same, but the 2nd fork is to a VM server - is that retargetting?
> > 
> > [JRE] I guess it depends whether the VM server has 
> registered using the same
> > AoR or a different AoR - see below.
> 
> Why should it make a difference how the VM server has registered, as 
> long as the same behavior results if/when the VM server is reached?
[JRE] OK, I see your point.
> 
> >>Same, but the contact used in the 2nd fork happens to be 
> >>another AoR, is 
> >>that retargetting?
> > 
> > [JRE] I would consider this retargeting but not as normal 
> retargeting. From
> > the point of view of the UAS reached as a result of this, 
> this UA receives a
> > request that, according to history-info, was originally 
> targeted at an AoR
> > that is not an AoR against which it has registered. Or 
> alternatively, a
> > gateway receives a request to an AoR identifying an entity 
> in a legacy
> > network that, according to history-info, is not the entity 
> originally
> > targeted. In these cases the reason for this change of 
> target may not be
> > clear.
> 
> So you are saying that something special has happened here, 
> and it ought 
> to be reflected as such using your new Reason causes?
> 
> Who is responsible for realizing that something special has 
> happened and 
> inserting the Reason? In this case it seems like it must be 
> the proxy. 
> But how would it know to do this?
[JRE] I am beginning to see why you have an issue of how to distinguish
between normal retargeting and redirection. I still think there is a
distinction, but perhaps my earlier attempts to explain were misguided. The
point is, that if a UAC sends a request to your AoR and it gets immediately
retargeted by the proxy in your domain to one of your contact URIs and
obtains a 2xx response from that UAS, then I would not consider that to be
redirection and worthy of any additional information to accompany the
history-info. In fact, I seem to recall that earlier drafts of history-info
would not have considered that case worthy of generating a hist-info field.
However, if that request receives a negative response from that first UAS
(or no response) and as a result the request gets retargeted to a second
UAS, I would consider that to be redirection and would wish history-info in
the retargeted request to be accompanied by sufficient information to
indicate the reason for that retargeting. In this case the usefulness of
that redirection reason depends on circumstances. I can see that the second
UAS could potentially benefit, since it might help it figure out why the
request has arrived there (independent of whether it is a VM system or a
device with a human user). On the other hand, for the history-info that gets
reflected back to the UAC that last field may or may not be of use to the
UAC or its user. If the second UAS is just another contact for your AoR, it
is unlikely that that history-info field will be of much interest to the
caller, since the request has still gone to you (or a UAS representing you).
On the other hand, if the retargeting is to a different AoR, the proxy for
which retargets the request again to a registered contact URI for that AoR,
then I can see that the UAC might be interested in the reason for retarget
to that second AoR, as well as the fact that this has happened.

> 
> >>If I only have one UA registered to my AoR, and my proxy routes a 
> >>request to that UA but it doesn't answer, and then my proxy 
> >>routes the 
> >>request to a VM server using a URI configured into its call 
> handling 
> >>script, is that redirection?
> > 
> > [JRE] If this is retartgeting to a different URI, I would 
> consider it not
> > "normal retargeting".
> 
> Different from what? It has to be a different URI from any other that 
> the proxy has tried for this request - that is a requirement in 3261.
[JRE] My mistake, I meant to write "different AoR".

> 
> > Looking at the draft again, it is probably inconsistent in 
> the use of the
> > terms "redirection" and "retargeting". My intention had been to use
> > "redirection" to indicate retargeting other than "normal 
> retargeting".
> 
> That still doesn't help me, because my problem is with the 
> definition of 
> "normal". This starts to sound like all the verbal juggling 
> that goes on 
> in the US in trying to define community standards for what is 
> pornography.
> 
> >>And do any of these answers change if in some cases proxying 
> >>is replaced 
> >>with a 3xx response?
> > 
> > [JRE] They should not. In this case, of course, it is often called
> > "recursion" rather than "retargeting".
> > 
> > 
> >>It seems to me that the distinction between "redirection" 
> and "normal 
> >>routing" is entirely subjective, and probably depends on who 
> >>you imagine 
> >>will be looking at the result and what you think they will be doing 
> >>about it.
> > 
> > [JRE] If we can make a distinction between retargeting to a 
> contact for the
> > same AoR and retargeting to a different AoR, then I think 
> it would not be
> > subjective. However, it may also depend on policy or user 
> preferences (e.g.,
> > script) what redirection reason is declared when carrying 
> out a retarget.
> 
> 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?
[JRE] That is how I misled you earlier, but according to what I just wrote
above, my view on how to view "normal" has now changed.

> 
> 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.)
[JRE] Agreed, but the proxy responsible for the domain identified in a URI
that is an AoR will know that it is an AoR and will therefore know if it
retargets away from that AoR not to a registered contact but to some other
URI that it has been scripted to retarget to.

> 
> - 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?
[JRE] Well, the VM server may be interested to know whether the request got
to Bob from Alice because Alice had failed to answer, was busy, was known to
be not available, or whatever. Also whether the VM server got the request
from Bob because Bob failed to answer, was busy, was known to be not
available, etc. Also the Charlie may wish to know why he ended up at Bob (if
Bob answers) or at Bob's VM.

> 
> 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.
[JRE] But even if it was intended for Bob, the VM might be able to take
action depending on the reason, e.g., play a different announcement.

> 
> 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.
[JRE] But the To header doesn't include a reason.

> 
> 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.
> 
(remainder deleted)

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2005 18:55:32 -0500

This has gone on probably too long, and I have probably caused it to 
ramble, so I will try to cap it off here.

I am not especially fond of H-I in general, nor do I believe it provides 
a good solution for enabling VM systems to do good things. But I guess 
that is not the question here.

I am here mostly concerned with whether this new set of values is 
defined in such a way that reasonable people will be able to decide 
which is appropriate in a given situation. I think achieving this 
requires some operational definition - relating it to the actions in the 
components that have to assign the values. I guess that means:

- A UAS generating a 3xx response
- A proxy forwarding a request and adding an H-I entry

In the case of the proxy, I think it will require a lot of reference to 
the various steps a proxy takes to decide how to forward in order to 
nail this down.

I've severely trimmed and commented on a few points below. But please 
feel free not to respond to them.

	Paul

> URI that it has been scripted to retarget to.

Yes, if scripted. But apparently the scripting will also then need the 
ability to generate reasons for the H-I, explaining why it is scripted 
the way it is.

Scripting can have all sort of whimsical motivations. How do we map them 
all onto predefined reasons? I gather you think the set you have is a 
reasonably complete partitioning of all possible reasons, so that in all 
cases I should be able to pick one that a reasonable and best choice?

> Bob answers) or at Bob's VM.

I am really interested to see an algorithm for how a VM can look at H-I 
and make any reasonable sense of any complex case.

It can look at the last entry, and see that the request came to it 
because Bob failed to reply. Understanding that the call was intended 
for Alice, and forwarded by her to Bob is quite a bit harder.

> action depending on the reason, e.g., play a different announcement.

Yes, it can choose "Hi - this is Bob. I'm away from my phone..." rather 
than "Hi - this is Bob. I'm on another call now...". There is *way* more 
machinery here than is needed to solve that problem.

> [JRE] But the To header doesn't include a reason.

Why does it matter? So you imagine the VM is going to be able to figure 
out enough to say "Hi - while you called Alice, she was unavailable and 
forwarded the call to Bob, who was unavailable so you are now talking to 
Bob's answering system."

It would be doing good to be able to say "For some reason your call was 
directed to Bob, who is away. Please leave a message for Bob." You can 
achieve that solely by looking at To and realizing it is not the AoR 
this VM mailbox services.