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

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

> At the time the parameters are to be inserted, the element 
> doing so most 
> likely doesn't know if the target is a gateway or not. All it really 
> knows is that the new target is a phone number. That *might* 
> get routed 
> to a gateway. Or it *might* turn out to be something 
> reachable via SIP.

What?

When you retarget, you know what you are retargeting to. You don't 
randomly retarget to anywhere and expect it to work.

You have a phone (or a proxy) that supports Call Forwarding on busy. 
The phone or proxy is configured with a SIP URI of where to direct the
call if it is busy.

That URI can be anything. This URI will be provided by the service 
operator. It puts whatever value it wants to get the service working.

RFC 3087 provides examples useful for closely coordinated environments.

This draft is no different. You put the URI as described in our draft in

there. The format of the URI is different, and allows for
interoperability
with Gateways (or anything that only understand 

> You seem to be saying that if it will go to a gateway (which probably 
> isn't known at that point) then the parameters go in. If no, 
> they don't 
> go in. So a feature might be working, and then if the target 
> is upgraded 
>   to a sip phone it will stop working.

If your voicemail server is behind a GW, you put the parameters.

If your voicemail server is native SIP, you put some different
parameters (like RFC 3087) if you want.

It's as simple as that. I don't understand why we need to talk about
hypothetical
proxies in the middle trying to muck around with retargeting.

> >>>If my Nortel college calls me at Nortel, and I'm forwarded
> >>
> >>to you at
> >>
> >>>Cisco, and you are forwarded to Cisco's voicemail, surely you would
> >>>expect my college
> >>>to get YOUR mailbox, not mine, right?
> >>
> >>Yes, I would *expect* that, though it is probably not what I would
> >>*desire*. What I would desire, at least in many cases, is that your 
> >>colleague would call you, the call would be forwarded to me, 
> >>and that if 
> >>I failed to answer the call would not be forwarded to my voicemail. 
> >>Instead, the proxy acting for me would give up, and then the proxy 
> >>acting for you would forward the call to your mailbox.
> >>
> >>
> >>>In other words, it seems that only the last redirection is 
> useful in 
> >>>this case.
> >>
> >>It seems to me that only the redirection that goes to a
> >>mailbox matters, 
> >>whether it be the first, last, or some other.
> > 
> > 
> > Yes, agreed.
> > 
> > So, in the example above of what you would "desire" versus 
> "expect", 
> > if Nortel and Cisco wanted to make it work as you desire, 
> they could. 
> > Cisco's Proxy
> > could decide to look at the parameter (which would be in 
> the IETF RFC
> > that we
> > are trying to create) and implement that behavior (e.g., by 
> rejecting
> > the call
> > instead of forwarding it to your mailbox). It would be a 
> lot easier to
> > implement
> > if we had a spec for it versus the status quo.
> 
> We already have a different spec for this - RFC 3841 - 
> callerprefs. The 
> caller says he doesn't want the call to go to voicemail. (In 
> this case 
> it would be the forwarding proxy that would insert the callerpref, 
> because *it* doesn't want the *forwarded* call to go to voicemail.)
> 
> > If Cisco's proxy in this example didn't implement this, you 
> would get
> > what you "expect" versus what you "desire".
> > 
> > I think we are saying the same thing now.
> 
> I'm not convinced. It appears to me that to get the PSTN interop you 
> want, you must insert the parameters if the target *might* be 
> the PSTN, 
> regardless of whether you know the parameters will be 
> understood by the 
> recipient or not.

No. You only put the parameters when the service you are requesting
in this case is a service behind the PSTN. There is no "might" in this.

> And if you also want to preserve the same functionality when 
> users are 
> migrated from the PSTN to sip, you must do this for all phone 
> numbers. 

Let's say your VM system is being a gateway. 

You migrate Users to SIP. You put as a service logic for the URI 
corresponding to "deposit message, busy announcement for user x" to 
the URI parameter described in the spec. 

> And in addition, every proxy that translates a phone number 
> had better 
> copy these parameters during the translation.

No, again, I wouldn't do this. You were the one pushing for this.
I wouldn't do this. It's not illegal of course, but I wouldn't do it.


> And then, to preserve the same functionality when people use 
> native sip 
> addresses rather than just phone numbers, this behavior must 
> be done for 
> all sip addresses.

There is only one retargeted-to address.

> The end result is that this no longer looks much like 3087. And it 
> requires proxies everywhere to support it or else it won't work right.

Again, you are putting words into my mouth. 

I wouldn't do any of the sequential retargeting you were suggesting.

_______________________________________________
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