I think the idea is that if you provide a phone number, then there are alternate ways to reach it than using the domain.
Not sure there is much we can do about this. It's a consequence of having this type of dualing addressing spaces. > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 16, 2008 15:39 > To: Audet, Francois (SC100:3055) > Cc: Anders Kristensen; Dean Willis; Hadriel Kaplan; SIP IETF; Dan WING > Subject: Re: [Sip] E.164 - who owns it > > > > 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. > > 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
