> -----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) 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. > 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). > 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". :) > 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. ;) > > 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. :) -hadriel _______________________________________________ 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
