On 7/9/08 4:45 PM, Dan Wing wrote:
On 7/9/08 4:19 PM, Dan Wing wrote:But it doesn't matter what the ITSPs do inside their networks - we can do this without the ITSP needing to do per-transaction crypto, or TLS, or squat. If it causes them no harm, causes them no grief, and lets them continue Business As Usual, it's a win for them and a win for the edge (their subscribers).We can provide edge-to-edge identity (between enterprises, or handset-to-handset) in both worlds: the world that exists (which has ITSPs with B2BUAs and SBCs) and the world that we hope willexist (RFC3263 routing on the Internet, perhaps with some peer-to-peer sprinkled on top). SIP's current identity mechanism, RFC4474+RFC4916, only works with the latter. I want an identity mechanism that works with both. And I have long been convinced it is possible to build such a beast.But *who* is going to deploy it?The very same entity that cares about identity: the subscriber connected to the ITSP, such as an enterprise connected to its SIP trunking provider.
Ah, so this argues for the media-path identity. I don't have as strong an opinion on that yet. My (possibly naive) first impression is that it has no better chance of surviving the SBC sausage factory any more than 4474 does (given that SBCs tend to sit on the media path, too).
But this doesn't give any rationale for signing P-Asserted-Identity (which will need to be stripped off as it leaves the enterprise, rendering your use case pretty much moot).
/a _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip