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

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

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:[e-mail]

_______________________________________________
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