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

Francois Audet wrote:
>>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:c@example.com;
>>	    old-target=sip:b@example.com;
>>	    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:b@example.com;
>>	    retargeting-reason=busy
>>
>>3.	sip:c-phone.example.com;
>>	    old-target=sip:c@example.com;
>>	    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.
> 
> Right: I wouldn't expect a proxy to "copy" parameters around. The whole
> purpose of this draft is NOT to add new requirements on generic proxy.

Good.

> Only the entity responsible for retargeting to a new SERVICE can modify
> the target.
> 
> Personally, I think the best way to do this would be to have the first
> retarget to point to:
>  
> sip:c@c-phone.example.com;old-target=sip:b@example.com;retargeting-reaso
> n=busy

You are suggesting that proxy B do the retargetting for proxy C? These 
don't even have to belong to the same provider!

At the time B is retargetting, all it knows is sip:c@example.com. 
(Sorry, I wrote this with user b and c having the same domain. I should 
have used different domains for them.)

> So it would avoid the "normal" routing steps afterwards, and the whole
> problem
> in the first place. I.e., don't use an AOR but a valid resolved contact.
> 
> That being said, if one is a masochist, you could decide to parse the
> History-Info including the information (which I wouldn't do because it
> is subject to be filtered out by "the network").

Then how do you make my use case work? Or doesn't it?

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP