I don't disagree with what you or Dean are saying in general (though I think you'll find Tel isn't going to avoid some of the issues Dean raises - they're more issues of response recursion in general). My only point is that this is what is happening *today*, in many cases. Dean said "it's not working", and my point was "not true - it is working right now, just not how we want and therefore it may have serious issues in the future".
-hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 15, 2008 9:02 AM > To: Hadriel Kaplan > Cc: Dean Willis; Francois Audet; SIP IETF; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Dean Willis [mailto:[EMAIL PROTECTED] > >> > >> 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 > > > > Right, and there is no single answer to this, because different strokes > for different folks. (not that there shouldn't be only one way, or that > the ways should be documented - I'm just being the messenger here) > > > > Typically, Bob as a UAS puts in 1 or 2. (if one can say "typically" for > a UAS redirecting to begin with) Since that's a 302 for the original > transaction, it goes upstream through Bob's b.com proxy/reg, since that's > how it got to Bob to begin with. > > > One of those does a recursion, says "hmmm, not one of my users, and I > won't send calls for a.com to PSTN, so time to redirect back a.com". The > contact then gets either changed to 3 or 4. (I assume you have a typo in > 4) > > Dean already discussed the problems with b.com attempting to construct a > sip-based phone number URI in the domain of a.com. IMO its a really bad > idea. > > > OR, a.com does it when it gets a 302 back from b.com with 1 or 2 in it. > So ultimately a.com is looking at 3 or 4 in a 302 redirect. And a.com > will get this response before Alice does, because a.com was in the request > path to get to b.com, so it's in the 302 response via path. A.com then > recurses on it, to the PSTN if it doesn't have such a user. > > Conversely, it seems like a bad idea for a.com to be second guessing the > validity of a sip uri in the domain of b.com. How does it know that it > *won't* work? And how does it know its not really important that it > remain as written? After all, it is b.com's URI. > > At least for the moment there is nothing that I am aware of in all specs > that suggests this is any more valid to do than it would be to change > mailto:[EMAIL PROTECTED] to mailto:[EMAIL PROTECTED] > > >> 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. > > > > 1 and 2 never reach Alice in those forms. 3 or 4 might, but even that's > debatable (it's debatable if Alice gets the 302 redirect unless both b.com > and a.com can't recurse route it). > > When and if it is appropriate to recurse on 3xx, vs returning it, > remains an open question. I think we can assume that the policies > relating to that will change over time. So we ought not assume too much. > > >> 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. > > > > A.com gets 3 or 4, with a.com in it. > > > > > >> 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. > > > > You're absolutely right that there could be a > sip:[EMAIL PROTECTED];user=phone, which b.com did not really mean. But > what *exactly* do you think will happen if a.com gets tel:+445588675309 > instead?? Most likely answer: a.com will immediately resolve it to > sip:[EMAIL PROTECTED];user=phone. I mean there's a reason people are > calling it an "alias". If you'd like, we can make the param > "user=^H^H^H^H^H^H^H^H^H^H^H". :) > > The difference is that tel: really does unambiguously represent a phone > number, whose target is well defined for all. Domains a.com and b.com > are expected to agree on what it designates. > > That is not true of sip:[EMAIL PROTECTED] and sip:[EMAIL PROTECTED] > And it is, arguably, not true for those with user=phone either. > > >> 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. > > > > Somehow I don't think a.com or b.com care much about that. ;) > > Perhaps they don't, if they don't care about standards. > > But *we* care, since we are making the standards. I think we want a > standard that can be used successfully without violating it. And I think > we would like to make it possible for Alice to use two providers in that > way - at least I do. > > >>> 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. > > > > Oh me too! But what I meant was there are problems getting the call > from Alice to Bob working, never mind Bob redirecting to Charlie. :) > > I hope we fairly quickly get to the point where anybody with sip phone > can call anybody else with a sip phone, using a sip path e2e. > > Paul _______________________________________________ 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
