[Kamailio-Users-ES] Fallo al transferir llamadas externas

[Jose Fernandez]

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 en daikon.es
móvil: (+34) 672 173 199
*DAIKON Integración y Desarrollo S.L.*

------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://lists.kamailio.org/pipermail/users-es/attachments/20081003/179833be/attachment.htm 
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : daikon-email.png
Tipo       : image/png
Tamaño     : 4311 bytes
Descripción: no disponible
Url        : http://lists.kamailio.org/pipermail/users-es/attachments/20081003/179833be/attachment.png