El Miércoles, 2 de Abril de 2008, Jesus Rodriguez escribió:
RFC 3325:
-----------------------------------------------------
5. Proxy Behavior
[...]
If the proxy receives a message (request or response) from a node
that it trusts, it can use the information in the P-Asserted-
Identity
header field, if any, as if it had authenticated the user itself.
[...]
If the proxy received the message from an element that it does
not trust and there is a P-Asserted-Identity header present which
contains a SIP or SIPS URI, the proxy MUST replace that SIP or SIPS
URI with a single SIP or SIPS URI or remove this header field.
-----------------------------------------------------
¿Consideras a tus usuarios, gateways e interconexiones IP como nodos
trusted? :-)
Sabías que me lo preguntarías :)
http://tools.ietf.org/html/rfc3324#section-2.3
2.3 Trust Domains
We say that a node, A, in the domain is 'trusted by' a node, B, (or
'B trusts A') if and only if:
1. there is a secure connection between the nodes, AND
2. B has configuration information indicating that A is a member
of the Trust Domain.
Note that B may or may not be a member of the Trust Domain. For
example, B may be a UA which trusts a given network intermediary, A
(e.g., its home proxy).
Pero claro, con lo de "secure connection" pues queda todo muy abierto, ¿qué es
una conexión segura? si al menos se MOJARAN en decir "debe ser TLS" o algo
por el estilo...
NOTA: Según el
RFC 3324 un proxy puede ser considerado trusted para
un cliente
pero no la inversa. En el caso que nos ocupa el proxy es trusted
para el
cliente, pero el cliente no es trusted para el proxy luego estamos
en el caso
9.2.
¿Me equivoco? Gracias.
Sí.
Por desgracia, como siempre pasa, los fabricantes implementan lo que
les rota y el P-Preferred-Identity todavía no está muy extendido y
casi todo el mundo tira de RPID/PAI.
Finalmente he bajado la cabeza y mi OpenSer ya permite indicar el callerid que
se aplicará en la llamada a PSTN con PPI y PAI. :(
Saludos.
--
Iñaki Baz Castillo