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

["Henry Sinnreich" <[e-mail]>]

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

This is OK, but maybe it would be just simpler to have a panel pop up in the
SIP UA display (or use text to voice) asking the user what the preference
is.

This would make everything simpler, less to coordinate and test and would
work P2P as well. Remember, the endpoint understands best its own
intentions. See the relevant quote in RFC 2775 "2.1 The end-to-end
argument".

As mentioned by Dean Willis, just because the PSTN does it is not a good
argument to pursue such capabilities in on the Internet.

Just in case it has been missed:

"Personally, I'm sick and tired of trying to replicate the PSTN experience
on the Internet. I spent an hour yesterday wrangling with a colleague about
whether we needed to differentiate between "call forwarding busy or no
answer" and "forward unanswered calls to voice mail" behaviors as hard-coded
"features" in an application platform.  
This is just a ridiculous discussion to have, and it all comes from people
thinking about phone services and not internet services. It leads to
ITU-type exercises intending to replace the Internet with a phone-type
network that offers a few Internet-like services.

As the author points out in this draft, the Internet is a not the circuit
switched phone network. It may provide a different user experience, it has
different operational characteristics, it places different limits or
restrictions on the applications that might be used, and MOST IMPORTANTLY it
offers a different value-proposition to the end user. We need to understand
all of these differences in our work, and not pretend we're working on
"telephone 2.0"."

Thanks, Henry

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Francois Audet
Sent: Monday, October 17, 2005 12:56 PM
To: Paul Kyzivat
Cc: Elwell, John; sipping
Subject: RE: [Sipping] Re: draft-elwell-sipping-service-retargeting-00.txt

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




_______________________________________________
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