Hoola!
En muchas configuraciones leo este tipo de cosas:
if(method=="BYE" || method=="CANCEL") {
unforce_rtp_proxy();
}
Esto fuera del loose_route. Pues por más que lo he intentado, no he
conseguido generar un BYE fuera del dialogo. En el RFC3261, seccion
15, pone: "A UA MUST NOT send a BYE outside of a dialog".
Teniendo en cuenta esto, entiendo que lo de arriba esta "mal", y que
deberia ser:
if(method=="CANCEL") {
unforce_rtp_proxy();
}
porque los BYE entrarían en el loose_route no? Estoy equivocado? Thnx!
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Hola, para mi sorpresa si hago un INVITE a un alias y envío un CANCEL
OpenSer "interpreta" bien ese CANCEL aunque dicho CANCEL (que no
es "in-dialog" por supuesto) no haya pasado por la función de "aliases".
Parece un poco "magia", aunque leo esto que maś o menos lo explica:
"CANCEL messages can be safely processed with a simple call to t_relay()
because SER will automatically match the CANCEL message to the original
INVITE message (stateful)."
Vale, de acuerdo, entonces entiendo que lo correcto es aplicar "aliases" SOLO
a mensajes INVITE (que no re-INVITE), MESSAGE y OPTIONS. ¿Se me olvida
alguno? (entiendo que en SUBSCRIBE no tiene mucho sentido.
Saludos.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, sin el parámetro fr_inv_timer todo va bien, bueno, me refiero a que si
un usuario no responde su propio cliente SIP envía un "Not responding" que
llega al llamante y fin.
Pero si añado:
# Tiempo máximo de establecimiento de llamada tras el "Trying":
modparam("tm", "fr_inv_timer", 10)
entonces ocurre que a los **mucho más que 10 segundos** el llamado genera
(igual que antes) su "Not responding" el cual sencillamente no atraviesa
OpenSer y por lo tanto el llamado envía un montón de ACK esperando recibir u
200 OK.
Bueno, que casi casi que ya sé por dónde va los tiros, el
parámetro "fr_inv_timer" no limita en realidad el tiempo del INVITE, limita
el tiempo en el que OpenSer mantiene en memoria la actual transacción (o sea,
el valor del callid y tal). Pasado el tiempo ""fr_inv_timer" OpenSer desecha
cualquier respuesta a ese INVITE (¡¡ incluso aunque sea un "200 OK" !!). De
hecho lo he comprobado.
Vale, iluso de mí, y yo que pensaba que OpenSer generaría un "Not responding"
al llamante y un "CANCEL" al llamado... :(
Saludos.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, esta vez en vez de preguntar algo voy a compartir un cachito de código
del que me siento orgulloso :)
Se trata de un mecanismo para implementar permisos personalizados (ACL's) en
llamadas entrantes a cada dominio, y funciona en modo multidominio.
Ya puestos he empezado un blog XD
Pues nada, a ver qué os parece, toda opinión es bienvenida:
http://blog.aliax.net/2007/08/openser-acls-multidominio.html
Saludos.
PD: En caso de opinar casi prefiero que lo hagáis aquí en la lista y no en el
blog.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola,
Acabo de hacer un commit en el svn que actualiza el port de OpenSER
en FreeBSD a la versión 1.2.2 . A continuación haré el commit en el
árbol de ports de FreeBSD.
Los packages de OpenSER 1.2.2 para FreeBSD estarán disponibles en
todos los mirrors de FreeBSD en la próxima actualización de packages
(normalmente una vez a la semana).
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
Tras comprobar el tema de http-digest parcialmente ya que me falta poner lo
de tls,pero tengo que ir probando los distintos atatques con distintas
configuracioens de openser ahora estoy sin tls,estoy en el siguiente
escensario
softphone en windows : ekiga
softphone en gny/linux :twinkle
la petición de llamada le llega desde windows a gnu/linux y al reves
perfectamente.
arranco el wireshark y hago la llamada de A -> B , hablo con mi
supermaravilloso microfono de euro y cierro la conversación,miro si me ha
cogido alguna llamada el wireshark y aparece una , y la reproduzco y no me
reproduce ningun sonidos :S :S :S.
1º pienso el micro no funciona pero he probado a hablar con el por gmail y
funciona perfectamte
2º ni idea pero quedaba bien.
cual puede ser el problema???
--
=====================================================
Legolas_Bilbao[ID2006][GKR]
Dios creo un equipo Perfecto a los demas los lleno de extranjeros
http://www.forosindicedonkey.comhttp://usuarios.lycos.es/ligaforo/
=====================================================
Pues eso, sorry por el offtopic, pero ya tengo compilada la rama de
Asterisk con soporte para SIP sobre TCP y me disponía a hacer algun
experimento, pero en ahora mismo en GNU/Linux tengo el X-Lite, Twinkle
y Zioper, y ninguno soporta SIP sobre TCP!! Alguno decente?
De mientras usaré un eyeBeam 'con parche en el ojo' que tengo en el
otro PC que tiene Hasefroch...
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/
Umm, entonces tu no implementas desvios y demás? Por ejemplo el DND se
puede hacer con el telefono, pero el call forwarding? Los telefonos ip
tienen funciones para eso?
El 16/08/07, Iñaki Baz Castillo <ibc(a)in.ilimit.es> escribió:
>
> El Thursday 16 August 2007 11:54:10 Saúl Ibarra escribió:
> > Hoola:
> >
> > Sorry por mandar este mail a las 2 listas, es por si alguien todavía
> > no se ha cambiado...
> >
> > He implementado un sistema de call forward con OpenSER bajo los 3
> > tipicos supuestos (blind, busy y no answer). Me funciona, pero tengo
> > una dudilla respecto a la función append_branch: según yo entiendo, lo
> > que hace es "abir" un nuevo call leg (o algo asi) hacia el ruri
> > indicado y luego conectarme.
> >
> > Pues bien, yo lo he utilizado porque me daba error y me decia que no
> > quedaban branches... y al ponerlo voila! La cuestion es: es esto
> > correcto?
> >
> > Por otro lado, al implementar la cosa esta me ha venido la siguiente duda:
> >
> > Cuando el desvío es blind, simplemente cojo el uri que tengo
> > almacenado en la tabla usr_preferences hago relay hacia alli, por lo
> > que si soy yo mismo no hay problema, la llamada iria saltando y
> > saltando hasta llegar a destino.
> >
> > En cambio, el control del desvio si ocupado o si no contesta lo hago
> > en el on_failure, y por lo tanto, no puedo hacer ese "bucle", es
> > decir, si el usuario destino tambien se encuentra desviado, yo no lo
> > se. Pregunta: como puedo volver a meter la llamada en el route central
> > (con el ruri alterado) para asi poder tener un forwarding "recursivo"?
>
> Personalmente intento no hacer "dialplan" con OpenSer, me parece excesivamente
> complejo y sobretodo poco escalable. No obstante el tema de "serial forking"
> es lo que creo que buscas, y algo de doc (ojo por si está desfasada) hay
> aquí;
>
> http://openser.org/dokuwiki/doku.php/tutorials:avpops?s=serial#serial_forki…
>
>
> > Ahora mismo lo tengo tal que asi:
> >
> > # -----------------------------------------------------------------
> > # failure_route[1] -- Cuando falla un INVITE - 486 busy o 408 no
> > answer, le mandamos al buzon o desviamos
> > # -----------------------------------------------------------------
> >
> > failure_route[1]
> > {
> > if(!t_was_cancelled()) {
> >
> > if (t_check_status("(486)|(408)")) {
> >
> > ## Miramos si tiene el Voicemail activado
> > if (avp_db_load("$ruri/username", "$avp(s:vm)")) {
> > xlog("L_INFO","$Cbx--- Voicemail ACTIVADO ---$Cxx\n");
> > revert_uri();
>
> ¿Por qué ese revert_uri(); ahí?
>
> > rewritehostport("10.68.42.134:5070");
> > append_branch();
>
> ¿No se supone que un append_branch(); tiene sentido **antes** de modificar el
> URI?
> http://openser.org/dokuwiki/doku.php/core-cookbook:devel#append_branch
>
> > ## Activamos el flag 10 para evitar bucles
> > xlog("L_INFO","$Cbx---> Redirigiendo al Voicemail...$Cxx\n");
> > setflag(10);
> > route(1);
> > exit;
> > }
> > }
> >
> > ## Si devuelve BUSY comprobamos su hay desvio
> > if (isflagset(21) && t_check_status("486")) {
> > if (avp_pushto("$ruri", "$avp(s:cfb)")) {
>
> Sólo por comentar, esa función "avp_pushto" ya no hace falta, sirve un simple:
> $avp(s:cfb) = $ruri
> (que es más bonita) XD
>
> > avp_delete("$avp(s:cfb)");
> > resetflag(21);
> > route(6);
> > exit;
> > }
> > }
> >
> > ## Si devuelve NO ANSWER comprobamos su hay desvio
> > if (isflagset(22) && t_check_status("408")) {
> > if (avp_pushto("$ruri", "$avp(s:cfna)")) {
> > avp_delete("$avp(s:cfna)");
> > resetflag(22);
> > xlog("L_INFO","$Cbx Estoy en el failure donde noanswer $Cxx\n");
> > route(6);
> > exit;
> > }
> > }
> >
> >
> > }
> > }
>
>
>
> --
> Iñaki Baz Castillo
> ibc(a)in.ilimit.es
>
> --~--~---------~--~----~------------~-------~--~----~
> Has recibido este mensaje porque estás suscrito a Grupo "openser-es" de Grupos de Google.
> Para anular la suscripción a este grupo, envía un mensaje a openser-es-unsubscribe(a)googlegroups.com
> Para obtener más opciones, visita este grupo en http://groups.google.com/group/openser-es?hl=es.
> En el canal #openser-es de la red de IRC irc.freenode.net puedes encontrar gente del grupo.
> -~----------~----~----~----~------~----~------~--~---
>
>
--
Saúl -- "Some people say why, other just say, why not."
----------------------------------------------------------------
http://www.saghul.net/