[OpenSER-Users-ES] Problemas reINVITE y check_from llamando con alias

[Iñaki Baz Castillo]

El Miércoles, 24 de Octubre de 2007, MAS escribió:
> Hola Iñaki,
>
>    Gracias por la rapidez de la respuesta. No acabo de enteder porque no es
> necesario
> verificar credenciales en el reINVITE y si en el INVITE, y solo es
> necesario verificar el has_totag().

Es SIP puro y duro ;)

Una llamada (diálogo) se identifica con el From_tag, To_tag y Call-id.
Una vez que se ha establecido ambos teléfonos finales conocen esos parámetros.

Así que si a tu OpenSer lellega un mensaje (un INVITE por ejemplo) con un tag 
en el To entonces lo puedes rutar perfectamente al destino final puesto que 
dicho destino SOLO aceptará ese paquete si dicho To tag, el From tag y el 
Call-id pertenencen a los de un diálogo que tiene abierto.

Si es un INVITE nuevo sólo llegará con From tag y call-id, y entonces pasa por 
el control de seguridad de OpenSer y si lo pasa llega al destino, quien pone 
el To tag en el 180/200 y se conforma el diálogo.
A partir de ese momento no es necesario pedir auth pues sólo permites rutar 
paquetes in-dialog  (loose_route() y has_totag()) si cumplen con esas dos 
premisas.


> Intentaré documentarme más sobre el uso del has_totag().
>
>    El caso es que en el inicio de una transferencia A->B->C:
>
>       - A llama ALIAS_B (INVITE), y B llama-transfer a C (INVITE
> in-dialog=reINVITE) creo
>         que es necesario que en el INVITE de B a C , B sea verificado (al
> igual que se hace
>         en el INVITE de A a B incial), no ?

Si, es cierto, el REFER hay que autenticarlo, aunque efectivamente me has 
descubierto un problema:

- A llama a ALIAS_B
- ALIAS_B trata de hacer una transferencia (REFER)
- OpenSer le pide auth.
- No puede hacer el auth porque su From indica ALIAS_B y su auth username 
B -> !check_from.


Hummm, ¿y esto cómo se resuelve?
¿Tal vez el teléfono destino debería NO usar como From el To recibido y usar 
su From de "toda la vida" sin alias?





-- 
Iñaki Baz Castillo