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 will
exist (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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
