Jonathan Rosenberg wrote:
In a case where your chat provider has no relationship whatsoever
with this edge proxy, for what purpose would you be connecting to it
in the first place? You should connect directly to your chat provider
offering the service. Then, if you have a cert - great - authenticate
to it using mutual TLS.
Well, I might be doing "outbound" with my edge proxy in order to get
some help from it for relaying messaging back through my NAT.
Why can't you do that with the edge proxy in your home providers network?
You might do that with the edge proxy in your home provider's network.
But that doesn't mean thet your 3rd-party service provider trusts the
authentication service provided by your home provider's network.
Or it might be a QoS-controlling proxy ala PacketCable. Or a
firewall-control-proxy . . .
Ah, well QoS control is much better handled through policy server
peering than SIP connectivity. And it works for non-SIP things. Why is
it that SIP is the vehicle for getting QoS in a visited network? Is this
problem not more generic?
Probably. But as I recall, PacketCable does it with SIP.
The chat provider might not just be on the other side of my edge
proxy, but on the other side of my home serving proxy too. And the
certificate auth stuff would appear to be able to traverse that proxy
as well.
I don't follow the picture you have in mind.
Clearly.
Imagine a "home network" consisting of an edge proxy and a home service
proxy. Imagine a 3rd party service that is NOT in a trust relationship
with the "home network". How does that 3rd party service validate the
identity of a user?
Options include:
1) Do a conventional SIP authentication using digest or basic, both of
which have issues we understand.
2) Trust the P-A-ID (which we've exluded by definition, since we don't
trust it).
3) Use AIB (which doesn't exist, and we might have just excluded by
definition as well).
4) Use certificate authentication as proposed.
--
Dean
_______________________________________________
Sip mailing list https://www1.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
