[OpenSER-Users-ES] ¿Es válido cambiar el From NAME en vez del From username?

[Iñaki Baz Castillo]

El Lunes, 5 de Mayo de 2008, Victor Pascual Ávila escribió:
> Retomando el thread,
>
> ¿Cómo puede un UA verificar que el From del Invite que recibe es
> realmente de quien dice ser?

En teoría el UA (UAS destino) debe "fiarse" de su proxy del cuál recibe ese 
INVITE. Y se supone que el proxy se ha encargado de autenticar al usuario, o 
tal vez el INVITE venga a su vez de otro proxy que tiene relación de 
confianza con nuestro proxy, etc etc...


> 2008/4/2 Jesus Rodriguez <jesusr at voztele.com>:
> >  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.
>
> ¿Qué diferencias hay entre el PPI y el RPID/PAI?

El PPI lo pone un UAC solicitando a su proxy qué PAI poner. O sea, en teoría 
un UAC no puede enviar un PAI a su proxy puesto que, en teoría, un proxy 
nunca ve a un UAC como "trusted" (pero sí al contrario). De hecho si un proxy 
recibe un PAI de un elemento no considerado como "trusted" debe ignorarlo (y 
eliminarlo) o rechazar el mensaje directamente.

También creo recordar de cuando me leí el RFC sobre PAI/PPI, que un UAC puede 
poner un PPI para indicar al proxy quién es (y cómo autenticarse) a la vez 
que solicita a su proxy que el INVITE salga como "anónimo". Por ejemplo 
Twinkle implementa este comportamiento si marcas la casilla "Llamada anónima" 
y genera un INVITE así:

---------
INVITE sip:pepe at dominio.com SIP/2.0
Max-Forwards: 70
To: <sip:pepe at dominio.com>
From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=fqtlx
Contact: <sip:192.168.0.129;transport=udp>
Privacy: id
P-Preferred-Identity: "IBC" <sip:ibc at aliax.net>
----------

Fíjate que el From no indica un URI sobre el que el proxy podría exigir 
autenticación, pero para evitar sea rechazado se supone que el proxy debería 
mirar el PPI y exigir autenticación para ese PPI (ibc at aliax.net).

Además, como valor añadido, Twinkle "esconde" el username en el "Contact" y 
añade el "Privacy: id".

Así pues, el proxy debería exigir autenticación para el usuario ibc at aliax.net. 
Tras recibirla, y suponiendo que el proxy envía el INVITE a otro nodo trusted 
de su red (por ejemplo un gateway o lo que sea), el proxy generaría un INVITE 
así:

---------
INVITE sip:pepe at dominio.com SIP/2.0
Max-Forwards: 70
To: <sip:pepe at dominio.com>
From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=fqtlx
Contact: <sip:192.168.0.129;transport=udp>
Privacy: id
P-Asserted-Identity: "IBC" <sip:ibc at aliax.net>
----------

Ya no hay PPI sino PAI, que es lo que tiene sentido entre nodos trusted. Y se 
mantiene el "Privacy: id".

El siguiente proxy/gateway/cosa_sip envía finalmente el INVITE a un elemento 
no trusted (un UAS registrado en él por ejemplo) que tendría esta pinta:

---------
INVITE sip:pepe at dominio.com SIP/2.0
Max-Forwards: 70
To: <sip:pepe at dominio.com>
From: "Anonymous" <sip:anonymous at anonymous.invalid>;tag=fqtlx
Contact: <sip:192.168.0.129;transport=udp>
----------

Es decir, el destino finalmente no se entera de quién llama.


PD: No sé para qué me esfuerzo en entender esto si luego no lo usa ni cristo 
XDDD



-- 
Iñaki Baz Castillo