Getting back to this, the circumstance that is worried about cannot exist. Unlike in IP networks, an e.164 cannot be "dual homed". It is not possible for sp1.net and sp2.net to allow origination/termination of the same e.164
In the PSTN, a call to an e.164 always is routed to a specific service provider. The service provider can route it to one of several termination domains (at the direction of the enterprise/consumer). The enterprise can indeed be served by multiple service providers, but the e.164s would be different. On the PSTN, "who owns it" is actually fairly poorly defined. In countries where number portability is implemented, the subscriber has a right to port the number, but it's actually "owned" in nearly every sense by the carrier who currently serves it. In most non-portability countries, for all intents and purposes, the carrier owns the number. For routing purposes, the destination of the route is known by the service provider. Other service providers can learn the identity of the carrier that currently serves the number, but typically not the identity of, or the route to, the terminating domain. The advent of user ENUM could change these relationships and knowledge, but, so far, user ENUM is not widely implemented. Infrastructure ENUM attempts to fix the route issue, by providing anyone the termination domain information, while retaining the current effective ownership of the numbers by the carrier. Private ENUM leaves the relationships as they are. When an enterprise asserts that it owns a number, it doesn't. The carrier effectively owns it. What the enterprise can do is use the number as a globally unique string and then create some URIs using that string. That isn't the same thing. We need to keep that in mind. Brian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Wing Sent: Thursday, April 10, 2008 4:22 PM To: 'Elwell, John'; [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip] E.164 - who owns it ... > [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. Here is a quick ASCII diagram of what you are describing: sp1.net-<<- / / Enterprise.com -< \ \sp2.net->>- > 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. Exactly. If enterprise.com is UNABLE to create a signature, but rather its signatures are destroyed and over-written by sp1.net or sp2.net, then yes, the best that can be done is trust sp1.net and sp2.net to have Done The Right Thing. That is not too valuable to me. If that is the only value we want or need, we already have RFC4474 that provides exactly this same characteristic. draft-wing-sip-e164-rrc is an attempt to provide something stronger, so that the message arrives at Enterprise.com and they -- not their service provider(s) -- create the signature (as you said). -d _______________________________________________ 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
