Dan, > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Dan Wing > Sent: 09 April 2008 19:54 > To: [EMAIL PROTECTED]; [email protected] > Subject: Re: [Sip] E.164 - who owns it > > > From: "Dan Wing" <[EMAIL PROTECTED]> > > > If those URIs included ";user=phone", there is a transitive > > > relationship between the SIP URI and the TEL URI. Without > > > ";user=phone", I agree that no meaning is supposed to > > be applied > > > to the user-part (the part to the left of the "@"). > > > > > > True. In that case, we have SIP URIs which are > > essentially aliases > > > for tel URIs. But in that case, any signing should be of the > > > fundamental tel URI, which then obviates the problem > > with an SBC that > > > translates one alias-URI into another. > > > > But the only mechanism we have to sign, RFC4474, does > not provide a > > way to sign a tel URI. > > > > OK, so we have several different URIs, sip:[EMAIL PROTECTED];user=phone, > > which are understood to be equivalent to tel:1234 and also to each > > other, and because of that, SBCs feel free to translate > each of these > > into each other, but the signing mechanism generates > signatures which > > depend on which of these particular URIs is present. So you have to > > change either your signing mechanism to recognize the > equivalence, or > > your SBCs to stop exploiting the equivalence. > > Yes, I agree. > > > > In SIP, you accomplish something similar to the TCP > > SYN cookie by > > > sending a SIP request towards the E.164, asking them > > to sign the > > > request and return it to you. Details are in > > > draft-wing-sip-e164-rrc-01.txt and comments are welcome. > > > > > > It seems like this mechanism is at most as certain as the E.164 > > > mapping that it uses for the "reverse direction". I > > gather from the > > > Enum people there is some trouble with that. > > > > I don't understand your statement; > draft-wing-sip-e164-rrc-01.txt > > does not use ENUM, rather it uses the same routing that the SIP > > network (of proxies, B2BUAs, and SBCs) uses. > > > > Sorry, I don't understand. You said "sending a SIP request towards > > the E.164", by which I understand an Enum lookup. Did you mean > > "sending a SIP request towards a SIP URI which purposts to represent > > an E.164"? > > draft-wing-sip-e164-rrc-01.txt says to turn the SIP URI into > a TEL URI, > and then generate a Return Routability Check (RRC) towards > that TEL URI: > > "1. Strip the domain name of the From: of the incoming > INVITE. This > results in a TEL URI. For example, > "sip:[EMAIL PROTECTED];user=phone" is rewritten to > "tel:+14085551212". > > 2. Rewrite the TEL URI to a SIP URI, following the Verifier's > default routing rules. For example, if outgoing calls are sent > to the service provider example.net, then "tel:+14085551212" is > rewritten to "sip:[EMAIL PROTECTED];user=phone". > > 3. Generate a random nonce. > > 4. Using the SIP URI constructed in step (2), construct a SIP > SUBSCRIBE message with Request-URI and To headers that use that > SIP URI, and an "Expires" header of 0. The SUBSCRIBE contains > the random nonce in its body as Content-Type application/ > return-routability-nonce. > > 5. Send the SUBSCRIBE message. This will cause the > calling party to > send a NOTIFY." > > > Once we start thinking about that, it opens the can of > worms again, in > > that validating sip:[EMAIL PROTECTED];user=phone is a different > operation than > > validating sip:[EMAIL PROTECTED];user=phone, so we can validate only one of > > those two purportedly equivalent SIP URIs. This seems to > lead back to > > the position that assuming those two URIs are equivalent for any > > purpose is a Bad Idea, and therefore we should change the SBCs > > behavior. > > (I assume the omission of "+" in those two URIs was an accident.) > > If I receive two Invites on one day from > > (a) sip:[EMAIL PROTECTED];user=phone > and > (b) sip:[EMAIL PROTECTED];user=phone > > I expect that they were both originated by someone who really > does 'own' that > number. > > If I turn the SIP URL into a TEL URI (tel:+1234), and route > it using my > default routing rules, it could be routed somewhere else > (sip:[EMAIL PROTECTED];user=phone), and then to somewhere else again > (sip:[EMAIL PROTECTED];user=phone). But as long as it eventually > arrives at the same > place as (a) or (b) originated from -- then I am happy that > my own outbound > SIP routing thinks that (a) or (b) really do "own" the E.164 > number "+1234" -- > because that is what my SIP routing says is true. [JRE] What about the following case? Enterprise.com uses two service providers, sp1.net for incoming calls and some outgoing calls and sp2.net for other outgoing calls. It sends an INVITE request via sp2.net, which signs the E.164-based From URI. The SUBSCRIBE request is routed via sp1.net to enterprise.com, which will be unable to sign the NOTIFY request. However, if the outgoing call had gone via sp1.net there would be no problem. I am not sure whether this behaviour is a good thing or a bad thing.
Of course, if enterprise.com signs and the signature survives end-to-end there is no problem and the called user gets a more useful caller ID. John _______________________________________________ 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
