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

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

Cliff,

Thanks for reading the draft. See in-line.

John

> -----Original Message-----
> From: Cliff McCollum [mailto:[email-masked]] 
> Sent: 09 February 2005 17:41
> To: Paul Kyzivat
> Cc: Elwell, John; [email-masked]'
> Subject: Re: [Sipping] draft-elwell-sipping-redirection-reason-01
> 
> 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?
[JRE] Yes, I agree we need to tighten up on definitions. Perhaps we don't
need a "normal redirection" but we just don't use the Reason header with
redirection reason in circumstances where there is nothing special to say,
e.g., the request has just been retargeted by the original target's proxy to
the first choice registered contact.

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