Buenos días:
Tengo el siguiente escenario. Registro dos sip-phones con la misma
sipUri. Les hago una llamada desde otro sip-phone y los INVITE llegan
bien a ambos. El problema llega, cuando quiero cancelar la llamada desde
uno de ellos, ya que hasta que no cuelga el segundo el Openser no lo
envía al llamante. Necesito poder mandarle el mensaje 480 al llamante
cuando llega del primero de los llamados, y no esperar al segundo, y no
sé si se podría hacer.
Si alguien tiene alguna idea se lo agradezco. Un saludo.
Siguiendo con la pelea de los branches .. a ver si los termino de dominar ..
esto es lo que tengo puesto ...
route[n]
{
..
t_on_branch(2);
if(!lookup("location"))
{
..
}
...
}
branch_route[2]
{
if(isbflagset(6))
{
xlog("L_INFO", "Fix 2 BI:$T_branch_idx flags=$bF\n");
use_media_proxy();
t_on_reply(2);
}
else
{
xlog("L_INFO", "Fix 2 non needed BI:$T_branch_idx flags=$bF\n");
t_on_reply(1);
}
}
Bien .. pues devolviendo lookup 2 contacs, uno en IP pública y el otro tras
NAT, saltan ambos a branch_route[2] como era de esperar.
Al contact tras NAT, se le aplica correctamente el use_media_proxy y al otro
nada, limpito .. pues resulta que todos los REPLY's me entran por
onreply_route[1] ... y no entiendo porqué, cuando se supone que los reply's
del usuario NAT de deberían llegar a onreply_route[2]
¿Algo no he captado de como funcionan los branch_route? ¿no deberían de
quedar "marcados" estos branches en openser para que sus replies vayan a
donde deben?
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Hola a todos, me he encontrado con una situación curiosa probando Zoiper,
resulta que el nene manda como Contact un precioso "*." cuando le dices que
se unREGISTER, lo que hace que el OpenSer se cepille TODOS los contacs del
AoR.
¿Cual es el comportamiento habitual ante estas situaciones? ¿simplemente
comprobar si cuando llega un REGISTER tiene Expire=0 y un Contact: * e
ignorarlo? ¿generar un error?
El RFC dice que habría que comprobar si el usuario tiene permiso para
modificar el contact, pero creo que OpenSer no implementa un mecanismo para
eso.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Cuando se utiliza t_on_branch y desde un INVITE se generan varios branches
porque hay varios contacs para un mismo AoR, se pasa por el bloque
branch_route especificado en el t_on_branch y desde ahi se puede usar los
otros bloques route que se hallan definido, hasta aquí todo bien.
Pero en cuestión de los flags, si en un route(n) se comprobaba un flag
concreto con isflagset, ¿esa comprobación se hace sobre el request original
(branch[0]) ó sobre cada uno de los branches que pasan por ahi?
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
¿Que pseudovariable se puede utilizar para imprimir los logs y saber en que
branch_id se está ejecutando un route?
Algo del estilo ..
route[3]
{
...
xlog("L_INFO", "BranchID: $bi ....");
...
}
Solo he visto referencias a Branch First Request y a Branch All request .. y
no me queda nada claro lo que contienen.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
openser: CRITICAL:tm:w_t_relay: unsupported route type: 8
¿Alguna pista?, no encuentro referencias en google a este error.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Buenas a todos, os planteo una duda ...
Ante un INVITE que llega a un OpenSer, para un usuario que tiene n contacs (se
ha registrado desde varios sitios), el comportamiento de TM y REGISTRANT es
hacer branching y paralel forking, hasta ahi todo ok.
Ahora resulta que uno o varios de los n contacs tiene Path y esto
hace "saltar" las branches a otro proxy.
Todos los contact reciben su INVITE, al que contestan con sus respectivos 100
Trying, 180 Ringing, etc ...
Si un contact contesta (genera un 200 Ok), el OpenSer "autogenera" (desde el
proxy que ha recibido el 200 OK) un 487 para el resto de los branches,
incluidos los que van con PATH, hasta aqui todo ok
Problema: algunos de los contacs estaban detrás de NAT, lo que hico que el
INVITE generase peticiones de sesion a un MediaProxy, pero cuando los
branches que no contestaron reciben su 487, cortan, pero es que el OpenSer
tambien me llama a end_media_session, jodiendome el invento, porque el
usuario se queda con una llamada con el canal de señalización abierto, pero
sin RTP.
Pregunta: ¿Como se puede hacer que el end_media_session se ejecute SOLO ante
el final reply del branch que contestó y no ante los 487 que van para los
branches que no contestaron?, está claro que será con setbflag, pero la duda
es como puedo saber, ante una llamada a lookup que este INVITE va a generar
branching.
--
Saludos.
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Amigos, buenos dias, tengo el siguiente inconveniente, tengo un host
definido como sip.mydominio.com y cuando trato de accesarlo via http (
http://sip.mydominio.com) al entrar en serweb trae consigo solo @
mydominio.com, es decir no indica el host, al hacer la consulta a la tabla
suscribers esta trae el host completo sip.mydominio.com, razon por la cual
no autentica a ni muestra los usuarios, que puedo hacer al respecto.. Por
otro lado tengo activo el acc de openser pero serweb no lo ve directamente
sino a traves del cdr pero esta tabla no la trae ni openser ni serweb,
tendre que montar asterisk para ello o tienen un script que me indique una
vista dinamica del acc ? . mysql v.5
--
Saludos y gracias
Frank Gonzalez
414-6260492
Hola, en unas cuantas ocasiones hemos hablado de los routers con ALG's y el
daño que hacen a la VoIP. Por ello he iniciado una sección en voip-info sobre
este asunto:
http://www.voip-info.org/wiki/view/Routers+SIP+ALG
Por supuesto se ha de corregir muchísimo, y la lista de routers es mínima de
momento (los dos casos que conozco yo).
No sé si tal vez dándole calor podríamos usarlo como "medida de represión"
contra los fabricantes de routers que hacen chapuzas y se cargan, a efectos
prácticos, la VoIP.
Saludos.
--
Iñaki Baz Castillo