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

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

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

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

> 
> 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".
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".

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

> 
> I am at a loss for naming the distinction when I don't see one.
> 
> 	Paul
> 
> Francois Audet wrote:
> > I believe "Normal" is meant to mean routing the way a 
> redirect server
> > would do, for "normal routing reasons".
> > 
> > I'm not sure I like the word "Normal" to describe this. But 
> basically,
> > the idea is to distinguish between "normal routing" and 
> "retargetting".
> > 
> > The problem is that in an environment where a redirect 
> server is used
> > instead of a proxy for "normal" routing, all calls then 
> look like they
> > are "retargeted".
> > 
> > One example where this is a problem is the voicemail 
> example in Appendix
> > B of draft-ietf-sip-history-info-06.txt. Voicemail systems rely on
> > knowing if the call was "forwarded/retargeted" or not in 
> order to take
> > appropriate action.
> > 
> > If you have a better idea for how to call this, please 
> suggest it, because
> > I do think the current term is ambiguous.
> > 
> > 
> > 
> >  > -----Original Message-----
> >  > From: [email-masked]
> >  > [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> >  > Sent: Tuesday, February 08, 2005 07:48
> >  > To: Elwell, John
> >  > Cc: Jesske, R; Joanne McMillen; [email-masked]'
> >  > Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> >  >
> >  >
> >  > John,
> >  >
> >  > I just took a look at this, and have a couple of questions about
> >  > specific causes:
> >  >
> >  > Cause=1 (Normal redirection - The call has been 
> retargeted for normal
> >  > routing reasons): what is a "normal routing reason"? AFAIK,
> >  > some or all
> >  > of the other listed causes are themselves normal routing reasons.
> >  >
> >  > Cause=8 (Mobile not reachable): how is this different from
> >  > causes 2,3,4?
> >  > If you want this, why not "fixed phone unavailable, video phone
> >  > unavailable, etc."?
> >  >
> >  >       Paul
> >  >
> >  > Elwell, John wrote:
> >  > > This examines the need for signalling additional information
> >  > > concerning the reason for redirection in SIP and proposes
> >  > an extension
> >  > > to the Reason header. In particular it can be used in
> >  > conjunction with
> >  > > request history.
> >  > >
> >  > > The 01 draft was submitted to address preferences 
> expressed during
> >  > > discussion of the 00 draft. In my opinion the draft is fairly
> >  > > complete, although obviously the list of initially
> >  > registered values
> >  > > for redirection cause codes might be subject to 
> discussion. I would
> >  > > like to ask how the community would wish this to 
> progress. Is there
> >  > > interest in making this a SIPPING work item? Are any
> >  > changes required?
> >  > >
> >  > > John
> >  > >
> >  > > _______________________________________________
> >  > > 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
> >  >
> >  >
> > 
> > 
> > 
> --------------------------------------------------------------
> ----------
> > 
> > _______________________________________________
> > 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2005 11:05:30 -0500

John - a few comments inline and discussion at end.

	Paul

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

> targeted. In these cases the reason for this change of target may not be

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] If this is retartgeting to a different URI, I would consider it not

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.

> "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.

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

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.

---

From: Cliff McCollum <[email-masked]>
Date: Wed, 09 Feb 2005 09:40:56 -0800

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.

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

Cliff

Paul Kyzivat wrote:

> it would not know who Alice is, so there isn't a lot of special 
> behavior it can exhibit.
>
> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2005 14:23:18 -0500

> how a VM server can offer this feature.

There has been a lot of discussion in the past about this. There are 
clearly at least two camps:

- those that want to describe what has happened to the call,
   which the VM server then uses to decide what to play

- those that want to simply tell the VM server what to play,
   putting the logic for deciding that into the proxy.

AFAIK there has been no agreement that one of these approaches is preferred.

> catch-all for anything that wasn't one of the other reasons?

If you can come up with something that is deterministic, and that puts 
correct info in a place where it can do some good, then I won't object.

Aside from the meanings of specific codes, I have some other issues:

- How does the use of the Reason header with these causes relate
   to the request or response in which it appears?

   E.g. in a request, does the cause describe why the R-URI is what
   it is? Or what?

   In a 3xx response, I suppose the cause describes why the call is
   being redirected. But what, if anything, does it mean in a 2xx
   or 4xx, 5xx, or 6xx?

   If a 3xx is returned with a reason, is that reason to be included
   in the request that results from retrying with the contact(s) from
   the 3xx?

- Exactly how does it relate to the entries in the H-I header?

   As the request progresses, and entries are added to H-I,
   in principle there could be a reason for each entry.
   Interpretation of H-I could conceivably require that info,
   but it isn't present in H-I.

- How is the reason determined by the component that must do it?

   I can perhaps agree that a component returning a 3xx will have
   some ideal of why.

   If a 3xx is returned with a reason, then that reason could be included
   in the request that results from retrying with the contact(s) from
   the 3xx.

   I think that only covers a small number of the cases of interest.
   How is this determined in other cases? If you can describe how
   this is done without unduly constraining implementors, then this
   may be worthwhile. If you have to constrain the implementation
   a lot, then maybe what you are defining is a proprietary extension.

	Paul

---

From: David R Oran <[email-masked]>
Date: Wed, 9 Feb 2005 15:04:22 -0500

On Feb 9, 2005, at 12:40 PM, Cliff McCollum wrote:

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

>  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:
>
>  - when a proxy responsible for an AoR retargets or redirects to one 
> of the contact addresses associated with that AoR, then it is "normal" 
>  - when retargetting or redirection occurs for any other reason then 
> it is not "normal", and you want to characterize why it happened.
>
>  The problem is that the real world is more complex than the above. 
> The following are some problems:
>
>  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 
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Cliff McCollum <[email-masked]>
Date: Wed, 09 Feb 2005 13:16:52 -0800

Comments inline...

Paul Kyzivat wrote:

>
>
> 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.
>>
>> something like it), I'm not sure how a VM server can offer this feature.
>
>

In my mind, forcing this decision is artificial. If a redirecting device 
provides a header telling my VM that the call was forwarded because it 
was "busy", which of these two camps does that action fall into? Is it a 
simple description of what happened to the call? Or is it the network 
forcing my VM to invoke its "call busy" behavior?

I think you can only assume it is the second category if you KNOW that 
providing this header will somehow force a particular behavior in my VM 
system. But you can't know that when you provide the header - since you 
don't know what the new destination party might be. Therefore, you can't 
assume you are doing anything more than telling me what has happened 
with the call.

Is this discussion any different if we assume that somehow, the endpoint 
provides the Reason header, and not the proxies themselves? I realize 
this doesn't answer the question about how to propagate Reason headers, 
etc. I only ask because I don't think I understand what the exact 
concerns with this header are.

Cliff

[email-masked]
www.voicemobility.com

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 09 Feb 2005 17:16:07 -0500

> forcing my VM to invoke its "call busy" behavior?

I was thinking more of something like:

	<sip:[email-masked];play=http://messages.com/busy.vxml>

Then the distinction is pretty clear.

> concerns with this header are.

Bringing this was was probably a useless digression.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 11 Feb 2005 15:32:41 -0600

> could offer me the chance to pass my handset to my friend instead of  
How about reading  
http://www.softarmor.com/wgdb/docs/draft-jennings-sip-voicemail-uri 
-02.txt?

The alternative to using history for this broken sort of voice mail  
implementation is to have the element that is forwarding the request to  
VM (and KNOWS why it is forwarding the request to VM) use a different  
request-URI (or parameter) for busy-forward-treatement,  
no-answer-forward-treatment, immediate-forward-treatment, etc. The  
behavior that the VM delivers is based on the request-URI it receives,  
without any explicit knowledge of the processing model.

Logic:

	&cause=(forward-to(&registered-contact));
	switch(&cause) {
		case "ok": break;
		case "busy": forward-to("[email-masked]");
		case "refused": forward-to("[email-masked]");
	 	case "noanswer": forward-to("[email-masked]");
	}
	
I keep hearing this "We have to have History or Diversion or whatever  
because the PSTN encodes cause codes this way for interacting with  
voicemail". That's a weak argument. I'm unwilling to accept the logic  
that "SIP must do it this way because the PTSN does it this way and  
we're too lazy to think about the problem from a different  
perspective".

When we follow that logic, we end up with PSTN 2.0 . . . constraining  
the applications to exactly what could have been done with the PSTN,  
which is pretty much pointless.

History at least offers some really nifty debugging capabilities,  
although I think building an application that is sensitive to or  
dependent on history info is probably a very bad idea.

--
Dean, not as chair