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

[Paul Kyzivat <[e-mail]>]

More inline.
	
	Paul

Francois Audet wrote:
> See below.
> 
> 
>>>>>Personally, I think the best way to do this would be to
>>>>>have the first retarget to point to:
> 
> 
>>The case I am describing above is like the cases involving a 
>>"deputy". I 
>>would imagine a "deputy" would be referenced by an AOR.
>>
>>The following is from the draft introduction:
>>
>>    For example, a request could be retargeted to a 
>>destination that can
>>    handle requests that encounter busy or no reply at the original
>>    target. As another example, a user could arrange that requests
>>    targeted at the user be retargeted to a deputy, perhaps 
>>because the
>>    original user expects to be absent or does not wish to be 
>>disturbed.
>>    The fact that a request has been service retargeted is often of
>>    interest to the users involved, i.e., the retargeted-to 
>>user and the
>>    calling user, or to an application. Therefore it would be 
>>very useful
>>    to provide to the UAS and the UAC details of retargeting 
>>in the form
>>    of the original target URI, the retargeted-to URI and the 
>>reason for
>>    retargeting.
>>
>>This clearly seems to include a case where the retargetted-to user is 
>>indeed a "user" and not an "application". Presumably the 
>>"application" 
>>includes the VM case. But if it is a "user", then in sip 
>>terms, what is 
>>it? I think it is probably an AOR. If so, and if the goal is 
>>to provide 
>>the retargetting details to the UAS, then how does this 
>>happen? It seems 
>>that it can only happen if the proxy representing the 
>>retargetted-to AOR 
>>copies the parameters into the contact address when 
>>forwarding on to the 
>>registered contact.
> 
> Yes, if the "proxy" wants to preserve the parameters it can certainly 
> preserve the parameters (i.e., it could retarget and copy the
> parameters).
> It could even retarget to something completely different (inlucing 
> other RFC 3087 parameters or whatever it sees fit). 
> 
> I imagine that there will be cases where one may want to do this, in 
> environments where there is some coordination between the domains.
> 
> However, I don't believe this would be the general case. A generic proxy
> wouldn't do this, and yes, indeed, the retargeted-to user or application
> would see the original redirection reason.
> 
> 
>>Also, if the retargetting reason, etc. parameters are only 
>>inserted into 
>>the URI when the target is known to be a server that will use 
>>them, then 
>>how does this involve PSTN gateways. It seems like you would only use 
>>this when forwarding to a phone number that is known to denote a 
>>voicemail server. How often is that done? I would think most of the 
>>cases of forwarding to the PSTN are like forwarding to a deputy.
> 
> 
> Yes. I would say that for PSTN gateways supporting this, you would
> typically 
> want to include the parameters (I would say it applies to PSTN in
> general, not
> just voicemail servers).

Now I think you are being inconsistent.

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.

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

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. 
And in addition, every proxy that translates a phone number had better 
copy these parameters during the translation.

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.

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.

	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