You are making this more complicated than it is. See below.
On Apr14 2008 20:08 , "Dean Willis" <[EMAIL PROTECTED]> wrote: > 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 Bob would typically put 2, (assuming you meant sip:[EMAIL PROTECTED];user=phone) despite the fact that 5 would be more appropriate. If B.com is not the cheapest crappiest service provider or enterprise possible, it will then recurse on it's own PSTN gateway and route the call there. I guess in theory, it's possible that it would pass the 302 back. If it did do this, then I would think that it should make the 302 usable by a.com. Passing a b.com might work (although it would probably have recursed on it already). If it doesn't have a gateway, then I guess it could change it to a Tel URI (which might then fail) or even substitute the domain with a.com and let a.com deal with it (which it may or may not). Fact is, there is no free lunch. In any case, I think 2 is the most likely. Now, if we want a service where you want Alice to be responsible for figuring out "how to get to the PSNT", then yeah, I think the Tel URI is better (but it may not work today in practice unfortunately, in which case Alice's Proxy would have to B2BUA it and much around with the contact, which would break 4474, yadi yada). > 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
