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

From: "Francois Audet" <[email-masked]>
Date: Thu, 13 Oct 2005 14:04:38 -0500

Hi all,

Sorry to come late to the debate, but I was on vacation for a week.

I think one of the reason we are having difficulties with the service retargeting
draft is that people keep on comparing it with History Info.

It would be much better to compare it with RFC 3087 "Control of Service 
Context using SIP Request-URI".

As pointed out by many on the list, using service URIs is far more accurate,
predictable and flexible than relying on "derived" information such as what is
provided by History-Info, when the intent is to access a specific service.

RFC 3087 is very flexible, and explains how to invoke arbitrary services using
arbitrary URIs using arbitrary parameters. While this flexibility is very
powerful, it does have some practical difficulties in real life scenarios:

1) Coordination of service URIs accross various pieces of equipment from 
   various vendors, networks, etc.
2) It is somewhat difficult to make it work with PSTN gateways, hybrid
   TDM-SIP systems, or even pure SIP systems that are meant to work in
   an environment where TDM/Analog devices actually exist.
3) It is somewhat difficult to make it work with simple devices like
   SIP phones.
4) RFC 3087 doesn't propose concrete parameter names to address very basic
   scenarios. 

The service retargeting draft should therefore be viewed as using RFC 3087, 
with registed URI parameters, as opposed to something similar to History-Info.

Indeed, one of the major use cases is Voicemail. There are also many others 
including Call Centers and IVR.

When looking at RFC 3087, it became clear that the points above make it difficult
to implement without further standardization for the following reasons:

a) When interoperating with TDM gateways (both in the case where the voicemail 
   system is itself a legacy voicemail system behind a gateway, or when it is
   native SIP but some of the phones are actually TDM/Analog phones behind gateways),
   the Voicemail application works by the "redirection reasons" as a trigger 
   (instead of or in addition to an explicit "play this message" promt).  

b) Most phones, proxies, gateways and other devices can do "call forwarding" of
   different flavors. They have a means to configure those features, and forwarding
   will be to a specific SIP URI. For example, it would be typical to have a 
   "Call forwarding busy" feature on a device that could point to a service 
   URI as defined by this draft (or for RFC 3087 for that matter). 

My expectation is that when one wants to build a SIP application, say a voicemail 
system, one would define a bunch of service URIs for different treatment.
RFC 3087 defines a bunch of them (abstractly) that should be used when BOTH the
VM system and the clients themselves are smart enough to "understand" the concepts 
of "deposit message", or "play announcement X", or "retrieve messages". This is
very suitable in a "closely integrated model of both the clients and application".

In cases where there is no "close integration" between the applications and the
client we would use the URI parameters defined in service-retargeting. This could 
be the case when we don't know what the applications are, like Voicemail/IVR/Call 
center and the logic is based on "redirecting reasons". It would also be useful 
when PSTN interworking on either side is used.

Also, both "plain" RFC 3087 and the service redirecting draft could be used 
together on the same SIP application server: they would just be different aliases
for service URIs.

The beauty of this is that from the point of view of the end-user devices, if you
support RFC 3087, you will also support service-retargeting. You can therefore build
a device that is usable in multiple environments. 

In summary, what we are proposing is really based on RFC 3087. It can work in
conjunction with History-Info, but it is orthogonal to it.

The aim is to make RFC 3087 more usable in practical scenarios involving loosely
coordinated environments (for service URIs), and/or PSTN interop, and/or simple
end-user devices.

----
François AUDET, Nortel Networks
mailto:[email-masked]

_______________________________________________
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: Fri, 14 Oct 2005 11:37:32 -0400

> Sorry to come late to the debate, but I was on vacation for a week.

Welcome back. Your message here helps.

> with registed URI parameters, as opposed to something similar to History-Info.

Interesting. In spite of the reference to 3087, it hadn't seemed much
like that to me. It seems to me there are some fundamental differences 
in what you are doing.

But there is something I am not sure of in your draft. Maybe you can 
clarify.

Suppose A calls B. But B has forwarding on busy set (to C). So the proxy 
for B retargets, with the new R-URI being:

	sip:[email-masked];
	    old-target=sip:[email-masked];
	    retargeting-reason=busy

This then goes to the proxy for C. It again has to retarget, to one of 
the registered contacts for C. This is a "normal" retargetting. What 
does the draft expect the new R-URI to be? I can see at least three 
possibilities:

1.	sip:c-phone.example.com

2.	sip:c-phone.example.com;
	    old-target=sip:[email-masked];
	    retargeting-reason=busy

3.	sip:c-phone.example.com;
	    old-target=sip:[email-masked];
	    retargeting-reason=distribution

This is similar to the examples in the draft involving a deputy, but 
where the address of the deputy is an AOR that requires further routing. 
If the human deputy that answers the phone is to get any value out of 
this, it will be because his phone (sip:c-phone.example.com) tells him 
the situation. Only (2) above makes that work.

If that is what is intended, then proxy C must copy the parameters from 
the R-URI it receives to the new target. This is not standard behavior 
for a proxy.

	Paul