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

From: "Francois Audet" <[email-masked]>
Date: Mon, 17 Oct 2005 20:46:55 -0500

> 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:[email-masked]. Say I can also be reached at
sip:[email-masked];user=phone (or tel:+14085551212).

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:[email-masked];mode=deposit-busy

In the NNNNN case, it could be:
 sip:+14085551234.wcom.com;user=phone; \
	old-target=sip:[email-masked];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:[email-masked], 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 18 Oct 2005 13:32:58 -0400

I think I see progress here. More below.

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

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

> 	retargeting-reason=busy \

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

> redirecting numbers, it makes sense to use parameters as a trigger that are

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

> the URI (indeed, the "deputy" application is the one that defined the URI in the 

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

> 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

---

From: Dean Willis <[email-masked]>
Date: Tue, 18 Oct 2005 15:20:19 -0500

On Oct 18, 2005, at 12:32 PM, Paul Kyzivat wrote:
> 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.
>

In which case, if we follow the principles of RFC 3087, it becomes  
the responsibility of whoever fills in this URI to include whatever  
parameters are needed by the target. I'm fairly happy with that  
understanding, if that's what Francois is really saying, and if John  
and the other folks agree.

So if that's true, what we're talking about here is really something  
like the netann draft, in that it is informationally defining some  
reusable parameters for specific services that are invoked in a  
manner consistent with RFC 3087. If that's what we want, I think  
that's a manageable scope and something we know how to do.

Like netann and 3087, this doesn't even have to be (although it could  
be, if we have that sort of consensus) a working group document. It  
could proceed as an individual informational. Of course, like netann,  
we'd still want to make sure it actually answers the questions and  
doesn't confuse people excessively.

--
Dean