Hola lista,
Alguien sabe qué significa ésto?
Mar 31 14:03:36 [26168] ERROR:tm:t_check_status: cannot check status for a reply which has no transaction-state established
Hasta hace unos días, veía en onreply_route[1] los status 200 OK a un invite con:
(t_check_status("200") && $rm=="INVITE")
ahora no lo veo, sólo veo un "ACK"...
saludos
El Monday 31 March 2008 14:06:34 David Villasmil escribió:
Hola lista,
Alguien sabe qué significa ésto?
Mar 31 14:03:36 [26168] ERROR:tm:t_check_status: cannot check status for a reply which has no transaction-state established
OpenSer sólo puede "matchear" respuestas a request de transacciones. Si has "forwardeado" el INVITE en modo "stateless" entonces OpenSer no puede capturar sus respuestas.
Hasta hace unos días, veía en onreply_route[1] los status 200 OK
Hace unos días enviarías los INVITE con "tm_relay" y ahora tiene pinta de que los envías con "sl_relay", ¿es así?
no, pero es con forward, efectivamente... pero yo tengo un record_route por ahí... veo que no sirve así... en realidad es así: tengo variables en unos avp y lo hago así: 192.168.1.254 es el openser
if (method=="INVITE"||method=="CANCEL") { record_route(); .... subst_uri("/192.168.1.254/$avp(s:ip):$avp(s:port)/"); xlog("L_ERR", "\n************** GATEWAY: $avp(s:ip):$avp(s:port) - subst_uri = $tu ************\n"); sl_send_reply("100","Trying"); forward();
¿Cómo he de hacerlo entonces? rewritehostport no sirve con $avp, no las parsea.
gracias
david
2008/3/31 Iñaki Baz Castillo ibc@in.ilimit.es:
El Monday 31 March 2008 14:06:34 David Villasmil escribió:
Hola lista,
Alguien sabe qué significa ésto?
Mar 31 14:03:36 [26168] ERROR:tm:t_check_status: cannot check status for a reply which has no transaction-state established
OpenSer sólo puede "matchear" respuestas a request de transacciones. Si has "forwardeado" el INVITE en modo "stateless" entonces OpenSer no puede capturar sus respuestas.
Hasta hace unos días, veía en onreply_route[1] los status 200 OK
Hace unos días enviarías los INVITE con "tm_relay" y ahora tiene pinta de que los envías con "sl_relay", ¿es así?
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
El Monday 31 March 2008 12:49:17 David Villasmil escribió:
no, pero es con forward, efectivamente...
http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.3.x#forward_destina...
forward(destination) Forward the SIP request to the given destination in **stateless** mode.
if (method=="INVITE"||method=="CANCEL") { record_route();....
subst_uri("/192.168.1.254/$avp(s:ip):$avp(s:port)/"); xlog("L_ERR", "\n************** GATEWAY: $avp(s:ip):$avp(s:port) - subst_uri = $tu ************\n"); sl_send_reply("100","Trying"); forward();
¿Cómo he de hacerlo entonces? rewritehostport no sirve con $avp, no las parsea.
Dios, qué difícil lo has echo XDDDD, mira:
$ru = $rU + "@" + $avp(s:ip) + ":" + $avp(s:port);
PD: Por cierto, eso de: "*** GATEWAY: $avp(s:ip):$avp(s:port) - subst_uri = $tu ********\n");
¿Por qué usas $tu? $tu es el valor de la cabecera "To" que NADA tiene que ver con el URI del Request ($ru).
Saludos.
forward(destination) Forward the SIP request to the given destination in **stateless** mode.
good to know!
subst_uri("/192.168.1.254/$avp(s:ip):$avp(s:port)/");
Dios, qué difícil lo has echo XDDDD, mira:
$ru = $rU + "@" + $avp(s:ip) + ":" + $avp(s:port);
Esto está fenomenal, el problema que me enconté y que (aparentemente) no funciona es algo así: $avp(s:destip) = $avp(s:ip) + ":" + $avp(s:port); rewritehostport($avp(S;destip));
openser no "expande" el avp! Leí en un list que el tipo que preguntaba sobre ésto lo resolvió con el subst_uri.... por eso lo uso...
PD: Por cierto, eso de:
"*** GATEWAY: $avp(s:ip):$avp(s:port) - subst_uri = $tu ********\n");
¿Por qué usas $tu? $tu es el valor de la cabecera "To" que NADA tiene que ver con el URI del Request ($ru).
entonces Request URI es el número "marcado"? y no lo es también el "To URI"?
gracias Iñaki
david
El Monday 31 March 2008 14:23:33 David Villasmil escribió:
forward(destination) Forward the SIP request to the given destination in **stateless** mode.
good to know!
subst_uri("/192.168.1.254/$avp(s:ip):$avp(s:port)/");
Dios, qué difícil lo has echo XDDDD, mira:
$ru = $rU + "@" + $avp(s:ip) + ":" + $avp(s:port);
Esto está fenomenal, el problema que me enconté y que (aparentemente) no funciona es algo así: $avp(s:destip) = $avp(s:ip) + ":" + $avp(s:port); rewritehostport($avp(S;destip));
openser no "expande" el avp! Leí en un list que el tipo que preguntaba sobre ésto lo resolvió con el subst_uri.... por eso lo uso...
PD: Por cierto, eso de:
"*** GATEWAY: $avp(s:ip):$avp(s:port) - subst_uri = $tu ********\n");
¿Por qué usas $tu? $tu es el valor de la cabecera "To" que NADA tiene que ver con el URI del Request ($ru).
entonces Request URI es el número "marcado"? y no lo es también el "To URI"?
¿Y si hay un forwarding en medio entonces qué? El "To" no debe cambiar nunca, pero el RURI es el destino final (que puede ser modificado por desvíos, localizaciones de usuarios...).
Te recomiendo estas lectura:
http://tools.ietf.org/html/rfc3261#section-8.1.1.1 http://tools.ietf.org/html/rfc3261#section-8.1.1.2 http://tools.ietf.org/html/rfc3261#section-8.2.2.1
Créeme que no hay nada como un buen tiempo dedicado a leer el RFC 3261.
ok, lo leeré... siempre y cuando no esté igual de explicado que los módulos de openser.. XD que estan fataaaaal!! jajaja!
Sabes dónde puedo encontrar info sobre cómo configurar openser detrás de nat? la llamada sale perfecta y conecta y tal pero... no audio!! he intentado:
force_rtp_proxy("213.97.249.180"); y force_rtp_proxy("c","213.97.249.180"); y force_rtp_proxy("o","213.97.249.180");
pero nada... :S
tal vez sea donde lo estoy haciendo
route[3] { if (is_method("BYE|CANCEL")) { unforce_rtp_proxy(); } else if (is_method("INVITE")){ force_rtp_proxy("mi_ip_pública"); t_on_failure("1"); }; if (isflagset(5)) search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes'); t_on_reply("1"); }
El Lunes, 31 de Marzo de 2008, David Villasmil escribió:
Sabes dónde puedo encontrar info sobre cómo configurar openser detrás de nat? la llamada sale perfecta y conecta y tal pero... no audio!! he intentado:
Sinceramente, da igual lo que hayas intentado, lo que hay que averiguar es la **causa**. Si consigues que funcione "de chiripa" a base de prueba y error no te extrañes de que al mínimo cambio te deje de funcionar sin saber de nuevo "porqué".
Mi consejo es el siguiente (y es como yo más he aprendido sobre SIP y NAT):
- Usa ngrep (o Wireshark/Ethereal) para capturar los mensajes SIP y examina MUY BIEN los SDP, el cómo salen y el cómo llegan a cada extremo. Así de fácil verás si en los INVITE que llega al llamado llega en el SDP la IP pública y en el 200 OK también.
- Usa también Tcpdump (si usas un softphone en Linux) y mira a ver a dónde está enviando el RTP.
Y luego dices que:
la llamada sale perfecta y conecta
Eso no es suficiente, ¿has comprobado si pasado unos 40 segundos (lo típico que dura una "conexión" UDP abierta en el router) el llamado puede mandar un BYE y lo recibe el llamante? ¿has tenido en cuenta el asunto del rport? es necesario si hay NAT y un router te saca por un puerto distinto del que tienes en la máquina con IP privada) -> force_rport() Y sobre todo, comprueba los "Contact" que llegan al llamado en el INVITE y el "Contact" que llega al llamante en el "200 OK", ¿son direcciones públicas o privadas? (deben ser las públicas que ha mapeado el router NAT).
Saludos.
sr-users-es@lists.kamailio.org
-
David Villasmil -
Iñaki Baz Castillo -
Iñaki Baz Castillo