This is starting to smell like BCP material actually.
> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 16, 2008 16:04 > To: Audet, Francois (SC100:3055) > Cc: SIP IETF; Dan WING; Dean Willis > Subject: Re: [Sip] E.164 - who owns it > > replying to myself - another thought: > > Paul Kyzivat wrote: > > > > Francois Audet wrote: > >> That's kind of what I was also saying. > >> > >> PS: what's the difference between 2 and 4? > > > > I think 4 is a typo and was presumably intended to be > > > > 4) sip:+445588675309:a.com;user=phone > > > > It is already the case that a.com may treat 3,4 & 5 alike > if it wishes. > > And b.com may treate 1,2 & 5 alike if it wishes. > > > > The question is whether a.com may treat 1&2 like 5, or if b.com may > > treat 3&4 like 5. > > > > Apparently some are saying that user=phone is license to ignore the > > domain. But that just raises the question of why one would insert a > > domain along with a parameter that says to ignore it. Makes > no sense to me. > > This would make *some* sense to me if the semantics were: > > 1) you MAY route to this domain following 3263 procedures > with expectation that it will work. > > 2) if you are unable to do that (say because you don't have a > sip path at all, or don't have a path to the domain in the > URI) then you may treat it as a tel URI and route it any way > that works for you. > > But it seems that in many of the use cases that have been > presented in this thread it is actually the case that if the > recipient routes to the domain in the URI the request *won't* > work. That makes absolutely no sense to me. In that case TEL > seems clearly the right way. > > Now Hadriel has made a case that it is the SBC's job to fix > this up. So when the URL exits the domain in which it will > work, then the SBC should fix it up with the domain it is > going into. I guess that could make sense if that SBC was > acting as an agent of *both* domains. But typically it is > only acting as an agent of one domain. An SBC acting for > b.com has no business changing the domain of the URL to > a.com, since doing so is (or isn't) a policy of a.com. > > A way around that is to say that if the URI contains b.com, > then an SBC acting for b.com, when it knows it won't honor > that, can change it to a TEL URI when it exits the domain. It > then may well go through another SBC acting for a.com as it > enters the a.com domain. That SBC could change the TEL URI to > an a.com URI if that will be handled correctly within the > a.com domain. > > Paul > > > Paul > > > >>> -----Original Message----- > >>> From: Anders Kristensen [mailto:[EMAIL PROTECTED] > >>> Sent: Wednesday, April 16, 2008 15:21 > >>> To: Dean Willis > >>> Cc: Hadriel Kaplan; SIP IETF; Audet, Francois (SC100:3055); Paul > >>> Kyzivat; Dan WING > >>> Subject: Re: [Sip] E.164 - who owns it > >>> > >>> > >>> > >>> Dean Willis wrote: > >>>> 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 > >>> The presence of user=phone and a valid E.164 number in > the user part > >>> seems like a pretty strong hint so I wonder if the > following might > >>> work as a pragmatic, if not exactly elegant, way forward: allow > >>> proxies and the UAC to treat cases 2 and 4 as if the URI is > >>> equivalent to 5 in the sense that they can do ENUM query on the > >>> E.164 number and they can even rewrite the domain part and expect > >>> the URI to identify the same entity. > >>> > >>> This doesn't prevent a.com from recursing when really Alice's UA > >>> would have liked to use another provider for gateway services but > >>> then neither does using a tel: URI. > >>> > >>> We'd also want to start pushing support for tel:, of course. > >>> > >>> Thanks, > >>> Anders > >>> > >>>> 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 > >>>> > > _______________________________________________ > > 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 > > > _______________________________________________ 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
