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
