Yeah, exactly. Dean says "not working" but it is working in most scenarios. It just doesn't work that well if everybody is trying to offload the responsibility of providing the PSTN gateway to others.
I have no problem with us recommending Tel URI usage for this, and hoping that implementations will catch-up. > -----Original Message----- > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 15, 2008 07:12 > To: Paul Kyzivat > Cc: Dean Willis; Audet, Francois (SC100:3055); SIP IETF; Dan WING > Subject: RE: [Sip] E.164 - who owns it > > > 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
