On Apr 14, 2008, at 6:24 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >> Of Dean >> Willis >> >> The problem is we're talking about TWO service providers, and >> reaching >> the wrong one's gateway. > > I'm not sure I understand the problem. Service providers decide > whether they want to send a call to the PSTN or not for another > domain, and that decision is based on their peering relationship and > regulatory restrictions. If the peering relationship is such that > b.com will try the PSTN (e.g., because a.com pays b.com to be its > provider), then it will, else not. So it's not reaching the wrong > one's gateway. A.com calls b.com, b.com can forward the call to the > pstn if it has that type of relationship with a.com, else it sends > the 302 redirect back upstream. What's the "wrong one's" gateway? > > >>> I guess you are worried about [EMAIL PROTECTED] phoning [EMAIL PROTECTED] >>> and b.com >>> doesn't have >>> a gateway but wants to forward to PSTN (and wants the originating to >>> fork >>> the bill). So it sends tel URI instead. Sure, but again, I doubt it >>> will >>> work very well. >> >> It has the potential to work well, whereas what we have now doesn't. > > Well, it seems to be working. There's plenty of bilateral peering > already happening, and the 302's seem to work across the providers. > It's just that the contact URI in them is not what I would call the > "right" one, but it's working.
I really can't see how; I can't make it work with my providers Let's revisit the problem again: Alice is a customer of provider A. Bob is a customer of provider B. Alice calls Bob. Bob wishes to forward her call to Jenny's telephone number, +445558675309. At this point, Bob and provider B don't know what gateway Alice might use to reach the PSTN, They also don't know whether reaching Jenny's phone number even requires Alice to use a gateway. What does Bob put into the Contact of a 302 he might send to Alice? I've heard several alternatives: 1) sip:+445588675309:b.com 2) sip:+445588675309:b.com; user=phone 3) sip:+445588675309:a.com 4) sip:+445588675309:b.com;user=phone 5) tel:+445588675309 So let's step through what these mean and why they each might not work. Keep in mind also that there's a very real possibility that Alice might nod NEED a gateway to reach Jenny; it's possible that Jenny's phone number is already in ENUM and is directly reachable via SIP. But this only works if Alice knows to look it up that way. 1) causes Alice to make a call to a user ID in the domain of b.com. Assuming that b figures out that this means a telephone destination, Alice probably doesn't have an account at b.com to use for placing the call. So unless B provides free SIP-to-PSTN calling, or at least provides free translation service to ENUM, she's out of luck. Of course, maybe a.com knows that when it gets a 302 back with a contact that looks like it might be a phone number, it should discard the host part and do phone number routing on the user part. That works until a.com also has user IDs that look like phone numbers. Of course, this is a direct violation of RFC 3261, which bans a.com from retargeting a request with a b.com host part. 2) is much the same as 1, except that "user=phone" provides another hint. B is no more likely to provide gateway services, but at least least if A is going to do an illegal foreign retargeting, it has a broader hint that phone number routing instead of user routing is required. 3) instructs alice to make a call in the domain of a.com. That's fine as long as sip:+445588675309:a.com routes to Jenny. Does it? It might route to somebody with user ID +445588675309, which is a perfectly valid user ID. It might also be true that Alice doesn't use a.com for her PSTN calls. Perhaps instead, she uses c.com. So to use c.com services, or do an enum lookup, she has to do an illegal retargeting. 4) is much like 3, with the added hint that a telephone-number destination is indicated. This might eliminate the accidental calling of user +445588675309, but it does nothing to resolve the question of Alice not using a.com services for PSTN gateways. There's also an open issue as to whether PSTN routing (such as an ENUM lookup) can be applied, vs requiring the call to traverse a gateway. At the very best, a.com (or Alice's UA) knows to discard the host part and do telephone routing on the user part. If Alice's UA does this, it's probably a violation of RFC 3261, as the UA itself is not responsible for the host-part of the contact. A proxy in a.com could do this translation. But what happens if Alice doesn't use a.com for routing PSTN calls? For example, I might place SIP calls using "softarmor.com", but I make my PSTN calls using "sipphone.com", so a 302 sent to me for "sip: [EMAIL PROTECTED];user=phone" will most assuredly fail. Now, if the a.com proxy knew to translate the call, that would be OK, but depending on the relationship between Alice and a.com, it might not. 5) doesn't work at all, because Alice's phone doesn't understand tel: URLs, since understanding of such was listed as a MAY in RFC 3261. But it's the only suggestion from the set that doesn't require violating a bunch of existing protocol rules. > Really, in the long list of interop issues, this one's pretty low on > the totem pole, imho. People are having trouble getting basic calls > to work without the aid of a middle-box. That's a bit higher on the > list to me. :) This is a very basic interdomain calling scenario. I'm really hoping we get more and more interdomain calls. > > > >>> Again, don't shoot the messenger: it makes sense to me to use Tel >>> URI for >>> this. I am just saying it may cause interop problems. Maybe that's >>> ok, and >>> maybe implementations will start implementing tel URI. >> >> I've no doubt that there will be interop problems. That's what >> happens >> when you specify something that has previously been unspecified and >> left to whim or caprice. > > OK, but failing calls will not give it a high chance of being > adopted. Maybe we can figure out how to get a sip: uri to work as > well - there's more than one way to skin a cat, even with a potato > peeler. ;) Failing calls that don't work now isn't much of a handicap. Changing the rules of RFC 3261 to make case 3 or 4 generally valid might also work. Fundamentally, we need a documented solution that works in the general case and doesn't conflict with MUST level rules of other RFCs we cite, unless it supercedes those RFCs. -- 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
