Or, we could put the "original-From" in From, the "original-To" in To, etc.
Paul
Adam Roach wrote:
On 7/11/08 2:56 AM, Elwell, John wrote:
I understand that some service providers expect PAI to identify the
charged user, so accepting any PAI value outside the legitimate range of
the authenticated entity from which the request is received (e.g.,
authenticated at the IPSEC or TLS level) causes them grief. Hence,
considering an enterprise network to be part of their trust domain is
problematic for these service providers. In my opinion, the From URI is
more likely to pass through unchanged than the PAI. But perhaps the best
chance of success is to place the e2e-authenticated identity in some
other header field.
P-Original-From?
Actually, that would work pretty well -- if we add "P-Original-Call-Id,"
"P-Original-CSeq," "P-Original-Contact," and "P-Original-Identity," we
could use RFC 4474 with just minor modification.
Or, even better, we could do away with P-Original-* headers altogether,
and put the relevant header fields (including Identity) in an
application/sipfrag body part. Then, you could use a normal RFC4474
identity service, and add a security mangler to make the signature
SBC-safe.
/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
_______________________________________________
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
