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

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

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

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

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.


_______________________________________________
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