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
