Hoola!
En algún hilo se ha comentado el tema de qué mensajes deberían ir
autenticados o no, pero como no era el tema central, he decidido abrir
este otro hilo para comentar mi pregunta/cosa:
Según he leido por aqui (creo que lo comentó Iñaki), los mensajes que
tienen que autenticarse con el proxy_authorize y tal son:
-INVITE
-REGISTER
-MESSAGE
-SUBSCRIBE
-PUBLISH
-OPTIONS
Vale, si esta es la lista, entonces yo ahora mismo tengo un
problemilla de seguridad, así que quería verificar una cosa:
Los INVITE se suelen tratar en u route aparte, así como los REGISTER.
Aunque todavía no me he metido mucho con ello, PUBLISH y SUBSCRIBE
también irían aparte, porque están relacionados con la presencia.
Entonces me quedan MESSAGE y OPTIONS. Actualmente he estado probando
los mensajes sin autenticación y por supuesto iban OK. Ahora he
añadido este bloque para manejarlos:
# -----------------------------------------------------------------
# MESSAGE handler
# -----------------------------------------------------------------
route[8]
{
xlog("L_INFO","$Cbx-- Mandando un MESSAGE --$Cxx\n");
## Es necesario autenticarse
if (!proxy_authorize("","subscriber")) {
xlog("L_INFO","$CbxSe necesita autenticacion para el MESSAGE$Cxx\n");
proxy_challenge("","0");
exit;
}
## Tienen que coincidir el nombre de usuario con el de la cabecera FROM
else if (!check_from()) {
xlog("L_INFO","$Crx*** check_from() = NO!! ***$Cxx\n");
sl_send_reply("403", "Use From=ID");
exit;
};
xlog("L_INFO","$Cbx*** MESSAGE correcto ***$Cxx\n");
consume_credentials();
# Puede que venga a nosotros pero tengamos definido un alias a fuera.
lookup("aliases") nos da la nueva URI que puede sea !=myself.
lookup("aliases");
if (!is_uri_host_local()) {
xlog("L_INFO","$CrxNot my URI after the alias lookup$Cxx\n");
## A las salientes
route(4);
exit;
};
## Miramos si existe el destino en nuestra tabla "location".
if (!lookup("location")) {
xlog("L_INFO","$Crx404 User Not Found$Cxx\n");
sl_send_reply("404", "Not Found");
exit;
};
## Si hemos llegado hasta aquí enrutamos el mensaje al destino por la
ruta por defecto.
route(1);
exit;
}
La pregunta es: podría utilizar este mismo bloque para los OPTIONS?
Entonces, llegados a este punto (sorry por la chapa) nos quedan por
tratar CANCEL, BYE, INFO, REFER, UPDATE, y PRACK?
Bien, entonces, asumiendo que tenemos esto en nuestro route principal:
if (!is_uri_host_local()) {
if (is_from_local()) {
route(4);
}
else {
sl_send_reply("403", "Forbidden");
};
exit;
}
Si un cuanlquiera nos manda algo pasaremos de ello. Entonces, para los
CANCEL y los BYE podemos hacer t_relay tranquilamente.
Los INFO solo ocurririan en loose_route no?Al igual que los UPDATE?
Ya solo nos quedan REFER, UPDATE y ese PRACK que no se yo... :P
Segun leo en el RFC3515, "REFER request MAY be placed outside the
scope of a dialog" entonces, deberia tratarlo fuera del loose_route?
Iria autenticado?
PD: Sorry por la "pesadilla mail", si aun os quedan fuerzas tras haber
llegado hasta aqui: que hacemos con el PRACK? (aunque no lo he visto
nunca...)
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Hola, tengo una duda de concepto sobre el ALG para SIP que implementan algunos
routers.
Ya os comenté que el SpeedTouch no mantiene el puerto abierto y redirigido, y
mi duda es si debería o no hacerlo.
Es decir, para realizar llamadas y solventar el NAT el router ALG sólo tiene
que interceptar el INVITE y cambiar el Contact y SDP. En ese momento se
produce una conexión UDP que dura poco y se mantiene el keepalive UDP del
router (normalmente 20-30 segundos creo).
Pero pare recibir llamadas es necesario que el router, al detectar un REGISTER
saliente (con éxito) deje el puerto abierto y redirigido al host local
indefinidamente. Pero claro, el router no puede saber cuándo se envía un
un-REGISTER ya que desde un mismo dispositivo SIP puede haber varias cuentas
registradas. Y dudo muchísimo que el router almacena datos SIP para saber qué
cuentas se han registrado.
Y por supuesto, el cliente SIP no tiene razón alguna para enviar ningún tipo
de keepalive (sólo lo haría si usa STUN).
Sólo se me ocurre poner la periodicidad del REGISTER a menos tiempo del
keepalive UDP del router (o aumentar éste si se puede), pero me parece una
guarrada (sobre todo porque el proxy SIP puede limitar el tiempo mínimo de
entre registros)
O sea, mi conclusión un poco alarmista es que el ALG de los routers sólo sirve
para corregir el NAT en llamadas salientes.
¿Me equivoco en algo? ¿es correcta mi conclusión?
Gracias por cualquier explicación.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, en el RFC 3880 (CPL) no veo forma de discriminar el tipo de mensaje SIP,
o sea, que si OpenSer manda ejecutar el CPL de un usuario entonces se ejecuta
el CPL sea INVITE o MESSAGE.
Una pena, porque estaría bien que una vez dentro del CPL se pudiese, por
ejemplo, desviar un MESSAGE a un gateway SIP_SMS sólo si el remitente es del
mismo dominio, pero en cambio desviar a un gateway SIP_PSTN sea cual sea el
dominio del llamante.
Bueno, pues nada... ojalá me equivoque. ¿Es así?
Muchas gracias.
--
Iñaki Baz Castillo
Hola, para controlar el estado de un diálogo se supone se debe usar los
Session Timers (RFC 4028) con re-INVITE o UPDATE y tiempos de expiración y
tal.
Pero en breves me tendré que comunicar con una Nortel SIP_2_PSTN que comprueba
el estado de una llamada con OPTIONS. Mi pregunta es si los dispositivos SIP
comunes responden con un 200 OK si reciben un OPTIONS in-dialog, ya que no
planeo meter un B2BUA entre OpenSer y el NORTEL.
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, me cambio a Orange y me dan un router SpeedTouch ST530 v6 con firmware
5.4.0.13.
Hace ALG de SIP, pero **cómo no**, no funciona ni pa'trás,
Para empezar al loro con lo que llega en un REGISTER:
contact = sip:ibc@85.58.1.105:55638
received = sip:85.58.1.105:55637
¿¿¿Qué sentido tiene que no sea el mismo puerto???
Obviamente me llamo a mí mismo y no funciona. Un tcpdump en OpenSer muestra
que el INVITE llega desde el puerto 57043 y OpenSer lo envía al puerto 57042
22:52:46.387184 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 888
22:52:46.389656 IP 77.77.0.110.5060 > 85.58.1.105.57043: SIP, length: 471
22:52:46.448896 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 338
22:52:46.463137 IP 85.58.1.105.57043 > 77.77.0.110.5060: SIP, length: 1130
22:52:46.466879 IP 77.77.0.110.5060 > 85.58.1.105.57043: SIP, length: 328
22:52:46.467787 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062
22:52:46.948355 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062
22:52:47.948374 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062
22:52:49.948498 IP 77.77.0.110.5060 > 85.58.1.105.57042: SIP, length: 1062
Es más, un "nmap -sU 85.58.1.105 -p 57042" (y 57043) devuelve que el puerto
está cerrado. Vaya **** ******.
Ahora simplemente busco como quitar este ALG pero no hay forma. Al parecer en
otras versiones del firmware se podía hacer:
nat unbind application=SIP port=5060
Pero esa opción no aparece ahora (la de "unbind"). He encontrado otro
testimonio que lo corrobora.
He rebuscado en todo el menú del telnet y no veo nada. ¿Tiene truco? ¿me
tendré que comprar al final un router y dar por hecho que las operadoras de
ADSL se van a cargar el SIP?
Gracias.
--
Iñaki Baz Castillo
Hola, el sábado noche aún con el resacón del viernes-SIMO le eché un vistazo
al RFC de CPL (los ejemplos básicamente XD):
http://www.faqs.org/rfcs/rfc3880.html
Tengo algunas cuestiones sobre ello:
1) ¿Hay algún cliente SIP que soporte CPL? sería muy chulo que en la
configuración de un tfno te diese la opción de subir las preferencias (desvío
condicional, etc) al servidor en forma de CPL en vez de sólo comportarse así
en el caso de éste teléfono (esta branch).
2) ¿Qué tal sería usar CPL "al margen del usuario"? me refiero a alguna
especia de aplicación que meta "a piñón" el XML del CPL para cada usuario e
implemente redirecciones, desvíos, bloqueos...
Lo pregunto porque tengo entendido que si el CPL XML llega en un REGISTER
(como cabe esperar) el módulo CPL de OpenSer lo pasa a binario y lo guarda
así en la tabla, lo que luego es más eficiente en su lectura.
En cambio si una aplicación externa (web por ejemplo) mete el XML en la tabla
no se pasa a binario.
Además, no me queda claro cómo interactúa el CPL con el resto del script, ¿qué
hay de los flags, los branch_route y todo eso? por ejemplo:
Mediante CPL pongo un desvío a otra URI. Cuando se produzca este caso, ¿sale
la llamada por el branch_route? ¿o una vez que entra en el CPL queda al
margen de script? también he oído sobre problemas para tratar el NAT y así.
En fin, ¿alguna aclaración o pista para empezar con esto? Mil gracias.
PD: ¿Se usa el CPL en la vida real?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, anteriormente daba por hecho que si un dominio de OpenSer tiene asignada
una centralita externa, para rutar la llamada a ella había que hacer
un "seuri(IP_fija_PBX)".
Pero claro, esto limita en cuanto a que se hace necesario tener IP fija en la
PBX.
Ahora he hecho otra cosa aprovechando que me parece lógico esperar que la
centralita se registre en OpenSer con usuario "pbx(a)dominio.org".
Entonces la cosa es que se registra con "pbx" pero tiene que permitir llamadas
a otros usernames. Así que primero hago un "lookup" del RURI y si no es un
usuario registrado hago lo siguiente para rutar la llamada a la PBX del
dominio:
$var(rU_original) = $rU;
$rU="pbx";
lookup("location");
$rU=$var(rU_original);
route(1);
exit;
Es decir, averiguo en qué IP está la centralita "pbx(a)dominio.org" (desde qué
IP se registró) y mando allí la llamada pero conservando el username original
llamado.
Bueno, y funciona :)
¿Acierto con este mecanismo? ¿ o es más fiable el rutar a una IP fija sin
exigir que la centralita esté registrada?
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, Saúl me ha comentado un fallo de seguridad en SIP bastante terrible y lo
comento aquí junto con alguna posible solución que se me ha ocurrido:
El problema es éste:
http://voipsa.org/pipermail/voipsec_voipsa.org/2007-November/002475.html
La clave está en que el atacante envía un INVITE a la víctima con un "Contact:
num_PSNT@proxy_victima" y luego solicita auth a la víctima cuando ésta le
envía un re-INVITE. Entonces finalmente el atacante dispone de un digest
válido para hacer la llamada a ese número.
Vale, y en dicha lista de correo están bastante alarmados con esto por lo que
supongo que en las soluciones que se me han ocurrido falla algo
estrepitosamente:
1) Meter un "consume_credentials()" dentro de "loose_route()" para borrar la
autenticación justo antes de enviar el paquete al destino. Es decir, entiendo
que si un usuario(a)proxy.org es usuario de dicho proxy.org sólo tiene sentido
que se autentique en ese proxy (a pesar de los divertidos esquemas del país
de la piruleta que se ven en tech-invite.com con autenticaciones secuenciales
y demás fricadas que luego sencillamente no existen).
2) Mirar el Contact y denegar el paquete si la URI en dicho Contact está
prohibida (se corresponde con el proxy). El módulo "permissiones" permite
esto para REGISTER pero no lo encuentro para otros mensajes, ¿no se puede
hacer así? sería elegante.
En fin, ¿es grave doctor?
Saludos.
--
Iñaki Baz Castillo
Hola a todos!
Soy nuevo con WeSip, y me ha surgido el primer problema tonto que no sé
solucionar :).
Tengo wesip corriendo sobre OpenSER 1.2.0, y quiero probar un HelloWorld
Servlet que simplemente recibe un MESSAGE request para
sip:greetings@amd-openims.test, responde un 200 OK, y a continuación manda
un MESSAGE request con un mensaje "Hello, World!". El servlet está metido
en un sar en webapps, e instalado con el web app manager de wesip. OpenSER
está configurado para reenviar cualquier request de tipo MESSAGE hacia
wesip. La conexión por seas parece estar funcionando bien. Sin embargo,
cuando pruebo a mandar un MESSAGE desde un cliente alice(a)amd-openims.test,
la consola de WeSIP suelta lo siguiente:
*******************************************************
SeasMessageEvent [SeasRouter] - New message received, from
138.4.7.163:6060 to 138.4.7.163:5080 over UDP
SeasTransactionEvent [SeasRouter] - hash_index = 54974,label=620758046
flags=0
ExpressMessageChannel [ExpressMChannel[0]] - peerAddress =
138.4.7.163/6060
ExpressMessageChannel [ExpressMChannel[0]] - About to process MESSAGE
sip:greetings@amd-openims.test SIP/2.0
SipConnector [ExpressMChannel[0]] - createProcessor: Reusing existing
processor
SipProcessor [ExpressMChannel[0]] - An incoming message is being
assigned
SipProcessor [SipProcessor[4]] - <<<<<<<<< Request Received <<<<<<<<<
MESSAGE sip:greetings@amd-openims.test SIP/2.0
Route:
<sip:138.4.7.163:5080;lr=on>,<sip:iscmark@scscf.amd-openims.test:6060;lr=on;s=1;h=0;d=0>
Via: SIP/2.0/UDP
138.4.7.163:6060;branch=z9hG4bKeb6d.ff7360e1.0,SIP/2.0/UDP
138.4.7.163:4060;branch=z9hG4bKeb6d.000ef08.0,SIP/2.0/UDP
138.4.7.149:63926;branch=z9hG4bK-d87543-b370c6252d6ad226-1--d87543-;rport=63926
Max-Forwards: 14
To: "Servicio HelloWorld" <sip:greetings@amd-openims.test>
From: "alice" <sip:alice@amd-openims.test>;tag=737cbe08
Call-ID: Y2FiYmY0MmM2NjFhYzU5NWUzNTE2MmM5MWY2ZjdhMGI.
CSeq: 2 MESSAGE
Allow: INVITE,CANCEL,ACK,BYE,INFO,OPTIONS,MESSAGE,SUBSCRIBE,NOTIFY,REFER
Content-Type: application/unknown?
User-Agent: X-Lite release 1011s stamp 41150
P-Charging-Vector:
icid-value="P-CSCFabcd4739818c00000007";icid-generated-at=138.4.7.163;orig-ioi="amd-openims.test"
Content-Length: 262
SeasHashTable [SipProcessor[4]] - Inserting hashIdx:54974
label:620758046 into hashTable
SipProcessor [SipProcessor[4]] - Transaction [z9hG4bKeb6d.ff7360e1.0]
is new Transaction?? --> true
EngineSipMapper [SipProcessor[4]] - Request from 138.4.7.163
mapped to: ConvergedEngine[WeSIP_engine].StandardHttpHost[localhost]
ConvergedEngineValve [SipProcessor[4]] - Invoking Host:localhost
ConvergedHostValve [SipProcessor[4]] - SipSession not found for
requestMESSAGE, trying match against Rules
ConvergedHostValve [SipProcessor[4]] - No servlet-mapping matched
this Request.
SipResponse [SipProcessor[4]] - >>>>>>>>> Sending Response >>>>>>>>>
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Via: SIP/2.0/UDP
138.4.7.163:6060;branch=z9hG4bKeb6d.ff7360e1.0,SIP/2.0/UDP
138.4.7.163:4060;branch=z9hG4bKeb6d.000ef08.0,SIP/2.0/UDP
138.4.7.149:63926;branch=z9hG4bK-d87543-b370c6252d6ad226-1--d87543-;rport=63926
Max-Forwards: 14
To: "Servicio HelloWorld" <sip:greetings@amd-openims.test>
From: "alice" <sip:alice@amd-openims.test>;tag=737cbe08
Call-ID: Y2FiYmY0MmM2NjFhYzU5NWUzNTE2MmM5MWY2ZjdhMGI.
CSeq: 2 MESSAGE
Content-Length: 0
LingerList [SipProcessor[4]] - scheduled transaction
z9hG4bKeb6d.ff7360e1.0 for deletion
ExpressMessageChannel [SipProcessor[4]] - sending with spiral=false
SipConnector [SipProcessor[4]] - recycle: Recycling processor
SipProcessor[4]
ActionRouter$ActionSender [ActionSender] - Writing 509 bytes into
Action Socket
SeasHashTable [ExpressMChannel[0]] - Removing hashIdx:54974
label:620758046 from hashTable
SeasHashTable [ExpressMChannel[0]] - Transaction with
id:z9hG4bKeb6d.ff7360e1.0, hash_idx:54974, label:620758046 removed from
the Seas Hash Table
ExpressMessageChannel [ExpressMChannel[0]] - Done processing MESSAGE
sip:greetings@amd-openims.test SIP/2.0
******************************************************************
Y en mi cliente recibo el Error 481 Call Leg/Transaction Does Not Exist.
No sé si tengo algo mal en mi server.xml o en el propio servlet. Alguien
podría echarme un cable?
Adjunto un zip con la configuración de openser y wesip (openser.cfg y
server.xml) y el servlet HelloWorldServlet.
Gracias y un saludo!
--
Álvaro Marí
Hola,
estoy buscando equipos sobre los que poder poner un Asterisk, Openser
o aplicaciones propias. He encontrado algunos (AP's, switchs, etc) en
los que se puede hacer sobre un openwrt. Me gustaría encontrar CPE's
(tipo ata, pap2, teléfono IP, dualphones...) en los que pueda cargar
mi propio SIP UA. ¿sobre symbian puedo cargar este tipo de
aplicaciones? -pensando en usar nokia nxx-
Como algunos sabréis, estamos trabajando en temas de P2PSIP y buscamos
equipos sobre los que poder cargar nuestro prototipo.
¿tenéis alguna idea?
Muchas gracias y siento si se trata de un off-topic, sobretodo por los
que tb forméis parte de la lista de asterisk-es :-)
--
Victor Pascual Ávila