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

["Francois Audet" <[e-mail]>]

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

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

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. 

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

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

_______________________________________________
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