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

[Paul Kyzivat <[e-mail]>]

Francois Audet wrote:
> Hi all,
> 
> Sorry to come late to the debate, but I was on vacation for a week.

Welcome back. Your message here helps.

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

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:[e-mail];
	    old-target=sip:[e-mail];
	    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:[e-mail];
	    retargeting-reason=busy

3.	sip:c-phone.example.com;
	    old-target=sip:[e-mail];
	    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

_______________________________________________
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