From: "Dan Wing" <[EMAIL PROTECTED]> If those URIs included ";user=phone", there is a transitive relationship between the SIP URI and the TEL URI. Without ";user=phone", I agree that no meaning is supposed to be applied to the user-part (the part to the left of the "@").
True. In that case, we have SIP URIs which are essentially aliases for tel URIs. But in that case, any signing should be of the fundamental tel URI, which then obviates the problem with an SBC that translates one alias-URI into another. In SIP, you accomplish something similar to the TCP SYN cookie by sending a SIP request towards the E.164, asking them to sign the request and return it to you. Details are in draft-wing-sip-e164-rrc-01.txt and comments are welcome. It seems like this mechanism is at most as certain as the E.164 mapping that it uses for the "reverse direction". I gather from the Enum people there is some trouble with that. It seems to me that in practice, people don't validate requestors by checking their apparent IP address, but rather by whether they can present certificates. But that is probably an issue that has been hashed over before... Dale _______________________________________________ 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
