Interesting use case. You could argue though that the same thing could happen for tel, since a proxy along the way can recurse without Alice's consent.
(this use case though triggers some memory cells in my brain of something like this being used for a scam in the PSTN, where they got the terminating or originating provider to have to pay a 1-900 for calls they couldn't bill to the human callers, so of course the owners/co-conspirators of the 1-900 called themselves this way and profited... or maybe I'm remembering it wrong) -hadriel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean > Willis > Sent: Saturday, April 12, 2008 2:47 PM > To: Francois Audet > Cc: SIP IETF; Paul Kyzivat; Dan WING > Subject: [Sip] Restatement of redirect (or refer) to a phone number > problem (was Re: E.164 - who owns it) > > > On Apr 12, 2008, at 12:18 PM, Francois Audet wrote: > > Every single endpoint that I've seen does NOT use a Tel URI per se, > > but > > rather, a Tel URI embedded in a sip URI as per RFC 3261/19.1.6. > > > > Insisting on Tel URI seems kind of out of touch with reality. > > So they're functionally limited. > > Explain to me what you would send in a 302 response to redirect the > UAS to call a certain phone number on it's own dime. > > I don't believe we have a way to do this, and I have always believed > it to be a critical use case for real integration (and no, today's > "telephony over IP" services are not really integrated, which is why > Gizmo customers call Vonage customers through multiple PSTN gateways). > > Here's a use case: > > Let's say Gizmo and Vonage some day figure out how to peer at a SIP > level. > > Assuming we maintain current billing models: > > Alice is a Gizmo customer. As such, she pays Gizmo per minute on calls > going to the PSTN, but calls to IP destinations (which don't use > Gizmo's bandwidth) are not charged to her. Calls coming from the PSTN > are also not charged to her. > > Bob is a Vonage customer. As such, he pays Vonage per minute on calls > going to the PSTN, but calls to IP destinations (which don't use > Vonage's bandwidth) are not charged to him. Calls coming from the PSTN > are also not charged to him. > > Alice calls Bob. Bob wishes to redirect Alice to call the premium > telephone destination 1-900-HELP-DSK. This is an expensive service to > Bob, but perhaps he thinks Alice is willing to pay for it or already > has a service contract allowing her to call the service for free. > > If Bob wanted to pay for this call, he would proxy Alice through a > Vonage gateway, but provide credentials so that the call is charged > back to him. Bob does not wish to pay from his account . But in this > case, let us assume that Bob does NOT want to pay for Alice's call to > the help desk. > > The obvious way to do this is for Bob to send a 300 class response, > probably a 302. But remember that Bob's system has no knowledge of > Alice's PSTN routing model, and outside of a domain name, no knowledge > of Gizmo's service at all. > > So what should go into the 302 as a Contact: header field value? > > It can't be "sip:[EMAIL PROTECTED]" or even > "sip:[EMAIL PROTECTED];user=phone > " because Alice presumably doesn't have permission to use Vonage's > gateways. > > Perhaps Bob's system could guess that Gizmo might understand > ""sip:[EMAIL PROTECTED] > " or maybe ""sip:[EMAIL PROTECTED];user=phone" and use this to > reach an appropriate gateway. > > But what if Alice gets better rates by using a local phone line on her > FXO port to reach that phone number? > > What if, unknown to Bob, there's an ENUM entry for +19004357375 that > would have allowed Alice to call that number directly over SIP instead > of using a gateway at all? > > Similar (and perhaps less contrived) use cases can be constructed > around REFER -- how doe we ask somebody in a different domain to call > a PSTN destination? > > How do you think this should work? > > The only way I'm aware of that we have to express the desired semantic > is to redirect the call to "tel:+19004357375" and let Alice's UA > figure out how it wants to get there. > > -- > Dean > > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
