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

From: "Francois Audet" <[email-masked]>
Date: Fri, 14 Oct 2005 17:35:49 -0500

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

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.

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:[email-masked];old-target=sip:[email-masked];retargeting-reaso
n=busy

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

_______________________________________________
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 19:17:28 -0400

> purpose of this draft is NOT to add new requirements on generic proxy.

Good.

> sip:[email-masked];old-target=sip:[email-masked];retargeting-reaso

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:[email-masked]. 
(Sorry, I wrote this with user b and c having the same domain. I should 
have used different domains for them.)

> is subject to be filtered out by "the network").

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

	Paul