> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Paul Kyzivat > Sent: Thursday, April 10, 2008 12:19 PM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip] E.164 - who owns it > > If I understand what Dan is proposing, the result is that you > get a call > if the callee believes the caller owns the number, regardless > of whether anyone else in the world does.
Right. And we know our own SIP routing is set up correctly, right? Otherwise it's broken and doesn't work for the intended purpose -- namely, sending SIP messages to their intended destination. -d > Paul > > [EMAIL PROTECTED] wrote: > > From: "Dan Wing" <[EMAIL PROTECTED]> > > > > > 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." > > > > Interesting... Because the verification generated by this algorithm > > is not quite what I expected from how it was described, and > it is both > > narrower and probably more useful than what I expected. The > > verification is that "Within the Verifier's context, the > routing rules > > that are in effect send tel:+1234 to the given domain." > This actually > > doesn't say anything about ownership of E.164 numbers > (other than that > > E.164 numbers are the space of URIs), but it says a > tremendous amount > > about how requests are routed from the Verifier's context: > "If I call > > the given number, will I reach the given domain?" That's not useful > > for validating an incoming caller based on an asserted E.164 origin > > number (unless one's local E.164 routing is known to be trustable), > > but it's really useful for knowing if I can call the caller > back using > > the asserted E.164 number. > > > > Dale > > _______________________________________________ > > 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
