Gracias de nuevo.

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:

route[1] {
        # send it out now; use stateful forwarding as it works reliably
        # even for UDP2TCP
        if (!t_relay()) {
                sl_reply_error();
        };
        exit;
}


Voy a indagar a ver si me entero de qué va y se me hace la luz... : )

Un saludo.

Iñaki Baz Castillo escribió:
El Jueves, 2 de Octubre de 2008, Jose Fernandez escribió:
  
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:
    

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.


  
    * 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.
    

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.


  
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.
    

  
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?
    

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 ;)




  

--

José Fernández Perete
jose.fernandez@daikon.es
móvil: (+34) 672 173 199
DAIKON Integración y Desarrollo S.L.