> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean > Willis > > RFC 3261 Section 19.1.1 says: > > The set of valid telephone-subscriber strings is a subset of > valid user strings. The user URI parameter exists to > distinguish telephone numbers from user names that happen to > look like telephone numbers. If the user string contains a > telephone number formatted as a telephone-subscriber, the user > parameter value "phone" SHOULD be present. Even without this > parameter, recipients of SIP and SIPS URIs MAY interpret the > pre-@ part as a telephone number if local restrictions on the > name space for user name allow it
That last sentence is fascinating. If I read it right, it basically allows me to treat a sip URI for my domain without the user=phone as a global E.164, if I so wish. (which so happens to be fairly common in my world) Good, I feel better now. ;) > If we made it mandatory for a PSTN gateway to assert identities using > user=phone and documented that Identity headers over an identity with > a user=phone parameter do not assert the "user part" of that identity, > then I think we'd have a complete solution. > Corollary , we need to document that a "phone" UAS that is attached to > the Internet does NOT use "user=phone" even if its user ID is a phone > number and the ENUM entry for that phone number happens to point at > this user ID at this UAS (or supporting domain). There's a problem with that. There are many "phone" UAS's which are ultimately reachable over the PSTN. In fact, I would bet most of them are. If the From of a request is used to store in one's address book, for later requests, then per Paul's desired behavior that later request could only be delivered over sip, or it should fail. One would think if the original request were to be delivered by sip, then a request anytime later the other direction could as well. But that's not the case. For one, transit peering arrangements are not symmetrical, and it's totally possible that calls across providers in one direction go sip the whole way, but calls the other direction cross the PSTN or H.323 or whatever. For another, many enterprises have "PSTN fallback" abilities, so that if their SIP trunks fail for some reason, there is a PRI-type backup. But this issue is somewhat orthogonal to your proposal. And it's leading me to think that we cannot reasonably have a "if sip: then only SIP" behavior solely based on scheme, as Paul seems to feel is currently implied (I think). -hadriel _______________________________________________ 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
