<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=iso-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Gracias de nuevo.<br>
<br>
Voy a documentarme un poco sobre el uso de t_relay porque me coge
totalmente de nuevas. Lo único que tengo configurado en el openser.cfg
es:<br>
<br>
route[1] {<br>
# send it out now; use stateful forwarding as it works reliably<br>
# even for UDP2TCP<br>
if (!t_relay()) {<br>
sl_reply_error();<br>
};<br>
exit;<br>
}<br>
<br>
<br>
Voy a indagar a ver si me entero de qué va y se me hace la luz... : )<br>
<br>
Un saludo.<br>
<br>
Iñaki Baz Castillo escribió:
<blockquote cite="mid:200810022159.45817.ibc@aliax.net" type="cite">
<pre wrap="">El Jueves, 2 de Octubre de 2008, Jose Fernandez escribió:
</pre>
<blockquote type="cite">
<pre wrap="">Muchas gracias por responder Iñaki.
Supongo que con "no está bien definido" te refieres a que he soltado
demasiado rollo para explicar el problema. La intención era dar los
mayores detalles posibles, por lo mismo que he incluido toda la traza
sip. Intento simplificar:
</pre>
</blockquote>
<pre wrap=""><!---->
Hola, realmente adjuntar la traza SIP es perfecto (en mi opinión), lo que
echaba en falta era un poco más de explicación previa, para saber qué buscar
en la traza SIP ;)
Pero ahora ya está más o menos claro.
</pre>
<blockquote type="cite">
<pre wrap=""> * Escenario: GW FXO, Openser 1.1 y varios teléfonos IP. Llamada
entrante que vía FXO (canal registrado como 9873) suena
directamente en el teléfono IP 43, y una vez atendida,
transferencia de esa llamada al teléfono IP 42.
* Problema: Se corta esa transferencia perdiéndose la comunicación
entre todos los puntos.
</pre>
</blockquote>
<pre wrap=""><!---->
He notado que hay retransmisiones (INVITE's repetidos que llegan al UAS). Esto
provoca que al aceptarse uno el proxy envíe un CANCEL para cancelar el otro,
el UAS recive dicho CANCEL y cancela la primera llamada (aunque no debería
pues ya fue contestada) y envía un BYE (no debería).
Una pregunta, ¿usas "t_relay" en el script de OpenSer? Tienes que
usar "t_relay" para evitar las retransmisiones, o sea, que si el UAC envía un
INVITE, llega a OpenSer, pasa un poco de tiempo sin recibir respuesta y el
UAC repite el INVITE, entonces OpenSer debe absorver dicho INVITE repetido,
pero para ello debe haber creado una transacción. Al rutar un mensaje
con "t_relay" se crea la transacción, pero también la puedes hacer antes
ejectutando "t_newtran" cuando empiezas a procesar el mensaje.
</pre>
<blockquote type="cite">
<pre wrap="">No entiendo muy bien por qué aparece un CANCEL del FXO al 42 después de
recibir el FXO un 200 OK de 42 al INVITE previo, ni el "no such call" al
BYE de la 43 al FXO.
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">No tengo demasiada experiencia y no tengo claro si la secuencia es
correcta en una transferencia de llamada SIP. ¿La secuencia en una
transferencia correcta sería la misma?
</pre>
</blockquote>
<pre wrap=""><!---->
La secuencia es más o menos correcta, yo creo que el UAS se comporta mal al
recibir 2 INVITE's iguales (retransmisiones) y un CANCEL.
Yo lo que te recomiendo es que te asegures de que OpenSer absorbe las
retransmisiones, es decir, el INVITE puede llegar varias veces a OpenSer,
pero sólo debe salir una vez de OpenSer y absorber las repeticiones.
Compruébalo haciendo más trazas SIP y comparando el "branch" del Via.
Y otra cosa, prueba a sustituir el teléfono 42 por otro modelo o softphone. Si
puedes pon un Twinkle que eso no falla ;)
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<br>
<table border="0">
<tbody>
<tr>
<td width="80"><img src="cid:part1.01000103.08090300@daikon.es"></td>
<td><b>José Fernández Perete</b><br>
<a class="moz-txt-link-abbreviated" href="mailto:jose.fernandez@daikon.es">jose.fernandez@daikon.es</a><br>
móvil: (+34) 672 173 199<br>
<b>DAIKON Integración y Desarrollo S.L.</b></td>
</tr>
</tbody>
</table>
</div>
</body>
</html>