That's kind of what I was also saying. PS: what's the difference between 2 and 4?
> -----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
