Re: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

[Paul Kyzivat <[e-mail]>]

I think I see progress here. More below.

Francois Audet wrote:
>>There is what the service operator does, and there is what 
>>the user does 
>>to enable the service. Lets be very concrete:
>>
>>I have an (sip-based) operator that lets me configure 
>>forwarding and VM 
>>over the web. For the busy or no answer case I have two choices:
>>- VM
>>- Forward to NNNNNNNNN (Where I fill in the NNNNNNNNN.)
>>
>>I understand your point that if I pick the VM option, then 
>>the operator 
>>can put whatever URI it wants in for the VM, either a native 
>>sip uri or 
>>a phone number in sip or tel format. And it knows it is a VM. If it 
>>knows that the VM wants these parameters, it can put them in at 
>>provisioning time or remember to do so at runtime.
>>
>>But the case I was concerned with is the other one. I don't tell the 
>>provider this is a VM. It *could* be the dedicated phone 
>>number of a VM. 
>>Or it could be the phone number of my Deputy. How would the service 
>>operator know?
>>
>>Lets assume it is the phone number of my deputy - a person 
>>with a phone 
>>and his own VM feature.
>>
>>According to your draft, I *thought* there was a goal that the 
>>retargetting information be passed along to the deputy. (For 
>>use however 
>>it sees fit, including the case where it just happens to be a VM.) If 
>>that is not the case, then I think we have few remaining issues.
> 
> 
> In my mind, the VM and the NNNNNN cases are very similar. I guess the VM
> cases is where the proxy knows that the target is a voicemail system, as
> opposed to just an application.

I would say that in the VM case the proxy knows the target is a VM 
system, and in the other case the proxy knows *nothing* about the 
characteristics of the target. It might be an application. It might be a 
user device, or it might be an AOR that could route to either a user 
device, a VM, some other application, or yet another unknown target.

> Say my AOR is sip:[e-mail]. Say I can also be reached at
> sip:[e-mail];user=phone (or tel:[phone]).
> 
> The operator can configure my "voicemail system with busy announcement"
> retargetting (your VM case), or the call forwarding busy retargeting 
> (your NNNNNN case).
> 
> In both cases, the operator just sticks a URI in there. In both cases, the 
> URI refers to a specific function of a specific mailbox.

In the first case it refers to a specific function of a specific mailbox.

In the second case we don't know that. "call forwarding busy 
retargetting" doesn't seem to imply there is a mailbox. I the user 
supplied the NNNNNNN, so it is I who know the characteristics of it.

Of course the configuration could be more complex, with different options:
- forward to operator supplied mailbox for this AOR
- forward to mailbox for this AOR at server with URI UUUUUUUUUUU
- forward to NNNNNNNNN (no serviced implied)
- ...

> In the vm case, it could be (based on RFC 3087 example):  
>  sip:[e-mail];mode=deposit-busy
> 
> In the NNNNN case, it could be:
>  sip:[phone].wcom.com;user=phone; \
> 	old-target=sip:[e-mail];user=phone;
> 	retargeting-reason=busy \

If the understanding is that the forwarding is for the purpose of going 
to a mailbox, then I agree.

> In both cases, the system is configured to "forward" to the Opaque URI on busy. 
> This is valid to calls to all my AORs (sip:[e-mail], or the tel-URI/phone number).
> 
> In both cases the recipient of the request may parse the URI to figure out what
> to do with it (i.e., the application, which is a GW or a native SIP application).
> 
> In both cases, it is transparent to "the network". In both cases, the provising
> is essentially identical.
> 
> The NNNNNN case has the characteristic that we define the parameters formally, (à
> la Netann) so that people can build interoperable systems without coordinating the
> app server with the proxy. This is particularly useful for allowing access to
> "legacy" systems behind a Gateway. This is because we do not expect gateways to
> be very bright. Since the "other side" of the gateway only supports concepts like
> redirecting numbers, it makes sense to use parameters as a trigger that are
> easy to map. 

Again, if that is all, I agree with you. The issue is below.

> That's it. There is nothing more to this draft. I think the "deputy" concept is what
> is causing the confusion (at least, this particular confusion...). I do agree that 
> the "deputy" can NOT be an arbirary user: it has to be an application that expects
> the URI (indeed, the "deputy" application is the one that defined the URI in the 
> first place).

Well, that is not apparent to me from the draft.

> Would it be better if we remove completely the "deputy" reference, and use
> voicemail instead in the example, everywhere?

If it was only voicemail, and a few clarifying words were put in, then I 
think it would be fine.

The "deputy" stuff has at least led me to interpret the draft 
differently than you intended. If there is indeed a requirement to 
support this concept, then perhaps the wording can be changed to make 
the intent clearer.

	Thanks for you patience,
	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP