Exactly. For example, me sitting in California can make a SIP call to somebody in Texas. Internally, it will be routed through our internal network until it reaches a PSTN gateway in Texas (least-cost routing). That gateway will insert my california CLID in the ISDN message.
And yes, this is totally prone to abuse. But the benefits have been judged by the industry to outweight the cost. So, trying to fix the "phone number" assertion problem seems (a) out of scope of what IETF's mandate is and (b) unlikely to be solveable. That is why my thinking is that we should focus on things were we can actually make a difference. "Email-looking addresses" or "Addresses where the domain matters" fall in that category. Putting a warning that if the system routes on the "user part" instead of the "domain" (like is often the case with phone numbers), it breaks domain-based identity assertion is a good start. > -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 20, 2008 23:47 > To: Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: IETF SIP List; Henry Sinnreich; [EMAIL PROTECTED]; Richard Shockey > Subject: RE: [Sip] Infrastructure issues involving e164 numbers > > Paul, > > You wrote: > > The SP *should* be restricting what the enterprise can put based on > > the numbers that the SP knows belong to the enterprise. (The SP > > doesn't need to care if the number is the precise one > originating this > > call.) > [JRE] The problem is a call that comes from a different part > of a large enterprise, with a number that is not within the > range of numbers reachable from that particular SP. Or a call > that comes from outside the enterprise and then is forwarded > to the PSTN (say to the enterprise user's home or mobile > phone). This "unscreened" number can advantageously be passed > to the callee. > > John > _______________________________________________ Sip mailing list http://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
