There is fall back in the circuit switched world, never mind IP over lays for enterprise.
> 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 _______________________________________________ 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
