I agree and have an additional question: What happens if the phone number is actually owned by the end user due to number portability? It seems in this case a database service is the essential ingredient.
This is an excellent I-D and I suggest we use it to clear up all these issues. Thanks, Henry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat Sent: Friday, February 15, 2008 4:09 PM To: SIP IETF; Elwell, John Subject: Re: [Sip] draft-elwell-sip-e164-problem-statement-00.txt John, Thanks for opening this can of worms. It is a very important problem to solve. Did you intend for this to be discussed on the SIP WG mailing list? > When a UA receives an E.164 number represented as a SIP URI in a From > header field, what does this say about the source of the request? Of > course, it should indicate that the request originated at a user who > has a right to use that E.164 number and who can be reached by > submitting a request targeted at that E.164 number. I'm not convinced about the above. It depends on what you mean by "should". The existing rules for use of SIP URIs don't require that the user be reachable from the PSTN, or that the user have any relationship to the pstn number. The user part is still wholly the responsibility of the domain. A corollary is that there are significant issues about how the recipient displays the identity of the caller. If the identity is displayed based solely on the e.164 number, without the domain, then it is a misrepresentation precisely because reverse routing using the e.164 number may well not reach the same place. > However, the last > of these issues is a far more serious problem: the user expects a > communication partner to be from a particular domain (the E.164 > number is not necessarily an important factor). Seeing that domain > in the From: URI, coupled with authentication by means of the > Identity header field, would satisfy the user's expectation. Seeing > a different domain, that of an intermediate service provider, which > may or may not be known to the user, would not satisfy the user's > expectation. The user might not be prepared to accept the unexpected > URI and might decide not to proceed with the communication. This argument isn't very compelling to me. Nobody using the PSTN expects to see the enterprise name as part of the calling "number". PSTN caller id with calling name might be relevant, but it isn't a domain name. If you want to use sip domain names for authorization purposes, then it makes more sense to use *real* sip URIs. > REQ2: When a UAS receives a SIP request that includes a SIP or SIPS > URI identifying the originating user, if that URI contains an > E.164 number that number alone, when placed in a TEL URI, must be > suitable for routing a request back to the originating user. Your examples all include ;user=phone, but none of the text says that you mean that when talking about sip URIs that contain E.164 numbers. I am somewhat inclined to agree with this requirement if user=phone is present, but otherwise not. IMO, rather than trying to fix up the handling of sip URIs containing phone numbers we would be better off trying to fix up the use of TEL URIs. The main limitation of TEL URIs is the inability of sip identity to deal with them. What we need is a way to extend identity to them in such a way that it truly proves ownership of the number, in whatever sense of ownership we want it to mean. I think that can be achieved by translating a TEL URI to its ENUM dotted inverted number domain name format, and then applying sip identity to that. It means that if I am the end user assigned usage of TEL:+1978-555-1234 then *I* or some middle box acting as my agent, must have a certificate for 4.3.2.1.5.5.5.8.7.9.1.e164.ansi. Thanks, Paul _______________________________________________ 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 _______________________________________________ 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
