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

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

Paul,

In-line.

John

....
> 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?
[JRE] It would go in hist-info field as a parameter of the URI from which
targeting has occurred, to augment the reason for that retargeting.

> 
>    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?
[JRE] I don't think it has a meaning in these responses.

> 
>    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?
[JRE] No it would be included in the history-info field of the retargeted
(recursed) request based on the contact in 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.
[JRE] The Reason header is present in H-I, so this new set of codepoints in
Reason helps to give more useful information 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
> 
> > 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

---

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

> targeting has occurred, to augment the reason for that retargeting.

I have to admit that I hadn't looked at the details of the H-I draft in 
a long time. I had forgotten how this reason is being carried there.

I looked at the syntax of the H-I header, didn't find a parameter for 
the cause, and assumed it wasn't in there. After seeing more of this 
discussion, I went back and looked again, and found it by looking at the 
examples. IMO is is a *perversion* to me to carry this info as an 
embedded header in the uri. And if the cause is so important to 
interpretting H-I, then why isn't it discussed in the draft? Examples 
aren't normative.

Maybe I can think of some other headers that could be embedded in the 
H-I URI and then interpretted. Any guidelines here about this?

> (recursed) request based on the contact in the 3xx.

Note my comment above. Where is there any explanation of this behavior?

> Reason helps to give more useful information in H-I.

Sorry for not realizing this before.

	Paul

[snip]

---

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

Talking to myself. :-(

I went back and read more in H-I. I was wrong. THere is indeed normative 
behavior about adding the Reason header. I should have read more 
carefully before shooting my mouth off.

I still think its a perversion, but at least its a *normative* 
perversion. :-)

	Paul