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

["Michael Hammer \(mhammer\)" <[e-mail]>]

Francois,

The draft is compared with History-Info because service-retargeting proposes parameters that can have *identical* information.  Both are *not* derived information.  If the proposed parameters were more like RFC 3087, we would be having that comparison discussion.

So, are you are proposing that service-retargeting drop information identical to History-Info and using something along the lines of a standardized "service=" parameter with values along the lines of RFC 3087?

Did I summarize your view correctly?

Mike


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Francois Audet
> Sent: Thursday, October 13, 2005 3:05 PM
> To: sipping
> Cc: Elwell, John
> Subject: RE: [Sipping] Re: 
> draft-elwell-sipping-service-retargeting-00.txt
> 
> 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
> 

_______________________________________________
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