La funcion t_relay() es el corazon del modulo Transaction Manager (TM) de Kamailio. Aunque su uso parece simple, internamente realiza operaciones complejas y criticas para el manejo correcto de transacciones SIP. Este articulo examina en detalle que hace esta funcion paso a paso.

Que hace t_relay()

La funcion t_relay() tiene como proposito principal crear una transaccion SIP y reenviar el mensaje actual hacia su destino. Sin embargo, este proceso involucra multiples operaciones internas que garantizan el cumplimiento del protocolo SIP y la confiabilidad de la comunicacion.

Proceso Paso a Paso

1. Verificacion de Transaccion Existente

El primer paso que ejecuta t_relay() es verificar si ya existe una transaccion para el mensaje actual. Esta verificacion es crucial porque SIP no permite crear transacciones duplicadas para el mismo mensaje.

route[EJEMPLO_VERIFICACION] {
    # t_relay() primero verifica si ya existe una transaccion
    if (t_check_trans()) {
        xlog("L_INFO", "Ya existe transaccion, no se puede usar t_relay()\n");
        exit;
    }
    
    # Si no existe, procede a crear una nueva
    xlog("L_INFO", "Creando nueva transaccion\n");
    t_relay();
}

Si encuentra una transaccion existente, la funcion falla inmediatamente. Esto previene problemas de estado inconsistente y loops infinitos.

2. Creacion de la Transaccion

Una vez confirmado que no existe una transaccion previa, t_relay() procede a crear una nueva estructura de transaccion en memoria que incluye:

• Identificador unico interno para la transaccion
• Estructura de datos para rastrear el estado actual
• Copia del mensaje original completo
• Lista de destinos (branches) donde enviar el mensaje
• Timers asociados para manejar timeouts
• Referencias a callbacks configurados (failure_route, onreply_route)

Esta estructura permanece en memoria durante toda la vida de la transaccion, permitiendo el manejo stateful de la comunicacion SIP.

3. Resolucion de Destino

t_relay() utiliza la Request-URI (variable $ru) como destino principal, pero tambien procesa cualquier branch adicional que haya sido agregado mediante append_branch().

route[RESOLUCION_DESTINO] {
    # t_relay() usa la Request-URI ($ru) como destino base
    xlog("L_INFO", "Request-URI original: $ru\n");
    
    # Si hay branches adicionales (via append_branch), los procesa todos
    if ($branch(uri[0]) != "") {
        xlog("L_INFO", "Branch adicional encontrado: $branch(uri[0])\n");
    }
    
    t_relay();
}

La funcion puede manejar multiples destinos simultaneamente (forking paralelo) o secuencialmente segun la configuracion establecida.

4. Clonacion del Mensaje

Antes del envio, t_relay() crea una copia completa del mensaje SIP original. Esta clonacion incluye:

• Todos los headers SIP
• El cuerpo completo del mensaje (SDP, XML, etc.)
• Informacion de enrutamiento
• Parametros de transporte

La clonacion es necesaria porque el mensaje original puede ser modificado durante el proceso de reenvio sin afectar las retransmisiones posteriores.

5. Configuracion Automatica de Timers

Una de las funciones mas importantes de t_relay() es la configuracion automatica de timers SIP segun los estandares RFC 3261:

route[TIMERS_AUTOMATICOS] {
    # t_relay() configura automaticamente varios timers:
    
    # Timer A: Retransmision de requests (solo UDP)
    # Timer B: Timeout final para non-INVITE  
    # Timer F: Timeout final para INVITE
    # Timer I: Tiempo de vida de transaccion completada
    
    xlog("L_INFO", "Timers configurados automaticamente\n");
    t_relay();
}

Estos timers garantizan que las transacciones no permanezcan indefinidamente en memoria y que se manejen apropiadamente los casos de timeout de red.

6. Manejo de Forking

Cuando existen multiples destinos, t_relay() implementa automaticamente el mecanismo de forking SIP:

route[FORKING_DETALLE] {
    # Si hay multiples destinos, t_relay() maneja el forking
    append_branch("sip:user1@server1.com");
    append_branch("sip:user2@server2.com");
    
    xlog("L_INFO", "t_relay() enviara a multiples destinos:\n");
    xlog("L_INFO", "Destino principal: $ru\n");
    xlog("L_INFO", "Branch 1: $branch(uri[0])\n");
    xlog("L_INFO", "Branch 2: $branch(uri[1])\n");
    
    # Envia simultaneamente (forking paralelo por defecto)
    t_relay();
}

El forking paralelo es el comportamiento por defecto, enviando el mensaje a todos los destinos simultaneamente y manejando las respuestas de manera coordinada.

7. Modificacion Automatica de Headers

t_relay() modifica automaticamente ciertos headers SIP para cumplir con los estandares del protocolo:

• Agrega una nueva entrada al header Via con la informacion del proxy

• Decrementa el valor de Max-Forwards para prevenir loops

• Puede agregar headers adicionales configurados globalmente

  route[HEADERS_AUTOMATICOS] { xlog("L_INFO", "Via antes de t_relay(): $hdr(Via)\n"); xlog("L_INFO", "Max-Forwards antes: $hdr(Max-Forwards)\n");

    t_relay();
    
    # Los headers son modificados automaticamente
  

  }

Estas modificaciones son transparentes para el administrador pero criticas para el funcionamiento correcto del proxy SIP.

8. Envio del Mensaje

El proceso de envio incluye:

• Determinacion del protocolo de transporte (UDP, TCP, TLS, SCTP)

• Establecimiento de conexion si es necesario (para TCP/TLS)

• Resolucion DNS si la URI contiene un nombre de dominio

• Envio fisico del mensaje a traves de la red

  route[RESOLUCION_DNS] { # t_relay() puede hacer resolucion DNS si es necesario $ru = "sip:test@example.com"; # Sin IP especifica

    xlog("L_INFO", "t_relay() resolvera DNS para: $rd\n");
    
    if (!t_relay()) {
        xlog("L_ERR", "Fallo en resolucion DNS o envio\n");
        t_reply("503", "Servicio no disponible");
    }
  

  }

9. Gestion de Estado de Transaccion

Una vez enviado el mensaje, t_relay() mantiene activamente el estado de la transaccion:

route[GESTION_ESTADO] {
    # t_relay() mantiene el estado de la transaccion
    
    t_on_failure("MANEJO_FALLO");
    t_on_reply("MANEJO_RESPUESTA");
    
    xlog("L_INFO", "Estado inicial: PROCEEDING\n");
    
    if (!t_relay()) {
        xlog("L_ERR", "Error en t_relay(), transaccion no creada\n");
        # La transaccion NO se crea si t_relay() falla
        exit;
    }
    
    xlog("L_INFO", "Transaccion creada y en estado PROCEEDING\n");
    # A partir de aqui, la transaccion existe y esta activa
    exit;
}

failure_route[MANEJO_FALLO] {
    xlog("L_INFO", "Estado cambio a: TERMINATED\n");
    xlog("L_INFO", "Codigo de respuesta final: $T_reply_code\n");
}

onreply_route[MANEJO_RESPUESTA] {
    if ($rs >= 200) {
        xlog("L_INFO", "Estado cambio a: COMPLETED\n");
    }
}

Casos Especiales Manejados por t_relay()

Retransmisiones Automaticas

Para conexiones UDP, t_relay() implementa automaticamente el mecanismo de retransmision definido en RFC 3261:

route[RETRANSMISIONES] {
    # Para UDP, t_relay() maneja retransmisiones automaticamente
    if ($proto == "UDP") {
        xlog("L_INFO", "UDP detectado - retransmisiones automaticas activadas\n");
    } else {
        xlog("L_INFO", "TCP/TLS - no necesita retransmisiones\n");
    }
    
    t_relay();
}

Las retransmisiones siguen un patron exponencial: 500ms, 1s, 2s, 4s, etc., hasta alcanzar el timeout final.

Manejo Especial de ACK

Los mensajes ACK requieren tratamiento especial en SIP, y t_relay() los maneja apropiadamente:

route[MANEJO_ACK] {
    if (is_method("ACK")) {
        if (t_check_trans()) {
            xlog("L_INFO", "ACK para transaccion existente\n");
            # t_relay() maneja ACK de manera especial
            t_relay();
            exit;
        } else {
            xlog("L_INFO", "ACK huerfano - enviado statelessly\n");
            forward();
            exit;
        }
    }
}

Integracion con Resolucion DNS

t_relay() puede realizar resolucion DNS automatica cuando la Request-URI contiene nombres de dominio en lugar de direcciones IP:

route[RESOLUCION_DNS] {
    # t_relay() puede hacer resolucion DNS si es necesario
    $ru = "sip:test@example.com";  # Sin IP especifica
    
    xlog("L_INFO", "t_relay() resolvera DNS para: $rd\n");
    
    if (!t_relay()) {
        xlog("L_ERR", "Fallo en resolucion DNS o envio\n");
        t_reply("503", "Servicio no disponible");
    }
}

Valores de Retorno y Manejo de Errores

t_relay() retorna un valor booleano que indica el exito o fracaso de la operacion:

route[VALORES_RETORNO] {
    if (t_relay()) {
        xlog("L_INFO", "EXITO: Transaccion creada y mensaje enviado\n");
        # Retorna 1 (verdadero)
        # La transaccion ahora existe en memoria
        # Los timers estan activos
        exit;
    } else {
        xlog("L_ERR", "FALLO: No se pudo crear transaccion\n");
        # Retorna 0 (falso)
        # Posibles causas:
        # - Error de red
        # - Destino inalcanzable  
        # - Falta de memoria
        # - Transaccion ya existente
        
        # Necesario manejar el error
        t_reply("500", "Error interno del servidor");
        exit;
    }
}

Comparacion con Otros Metodos de Envio

Es importante entender las diferencias entre t_relay() y otros metodos de envio disponibles en Kamailio:

route[COMPARACION_METODOS] {
    # 1. t_relay() - Stateful (con transaccion)
    if (is_method("INVITE")) {
        xlog("L_INFO", "Usando t_relay() para INVITE (recomendado)\n");
        t_relay();  # Crea transaccion completa
        exit;
    }
    
    # 2. forward() - Stateless (sin transaccion)
    if (is_method("OPTIONS")) {
        xlog("L_INFO", "Usando forward() para OPTIONS\n");
        forward();  # Solo reenvia, no crea transaccion
        exit;
    }
}

Recursos Consumidos por t_relay()

La funcion t_relay() consume varios recursos del sistema:

1. Memoria: Para almacenar la estructura de transaccion completa

2. Timers del sistema: Para manejo de timeouts y retransmisiones

3. Sockets de red: Para envio de mensajes y manejo de conexiones

4. CPU: Para procesamiento de estado y logica de transaccion

   route[MONITOREO_RECURSOS] { xlog("L_INFO", "Transacciones activas antes: $T_branch_idx\n");

    t_relay();
    
    xlog("L_INFO", "Nueva transaccion creada - ID interno generado\n");
    xlog("L_INFO", "Memoria de transaccion reservada\n");
    xlog("L_INFO", "Timers de timeout configurados\n");
   

   }

Mejores Practicas para el Uso de t_relay()

1. Siempre verificar el valor de retorno y manejar apropiadamente los errores
2. Configurar failure_route para manejar respuestas de error
3. Usar onreply_route cuando sea necesario procesar respuestas
4. Configurar timeouts apropiados segun el tipo de red y destino
5. Implementar logging adecuado para facilitar la depuracion
6. Considerar el consumo de recursos en entornos de alto volumen

Conclusion

La funcion t_relay() es mucho mas que un simple mecanismo de reenvio. Es un gestor completo de transacciones SIP que implementa automaticamente todas las complejidades del protocolo SIP, incluyendo manejo de estado, timeouts, retransmisiones, forking y modificacion de headers.

Su uso correcto es fundamental para implementar proxies SIP confiables y que cumplan con los estandares. La comprension detallada de su funcionamiento interno permite a los administradores configurar sistemas Kamailio mas robustos y eficientes.

Aunque su sintaxis es simple, las operaciones internas que realiza t_relay() son la base que permite a Kamailio funcionar como un proxy SIP de nivel empresarial, manejando miles de transacciones simultaneas de manera confiable y eficiente.