En algunos escenarios donde hay un numero considerable de usuarios que se registran en un Proxy SIP o en una PBX, puede ser una optima opción implementar delante un OpenSIPs con el modulo Mid-Registrar configurado y activado. Este modulo lo que hace es absorber/procesar todas las solicitudes SIP de tipo REGISTER enviadas hacia el destino final y comunicarse con el Proxy SIP o la PBX para mantener los registros actualizados. Quizás el más fácil explicarlo gráficamente:

Sin el modulo Mid-Registrar todos los REGISTER van desde los usuarios hasta el servidor REGISTRAR.

Con el modulo Mid-Registrar en el medio, el alto volumen de REGISTER enviados por los usuarios es procesado por el modulo y al REGISTRAR principal llegará un bajo volumen de REGISTER.. ¿Cómo se obtiene eso? Aumentando el tiempo de expiración del registro entre el Mid-Registrar el REGISTRAR PRINCIPAL y absorbiendo los REGISTER del mismo usuario procedentes de distintos dispositivos. Un ejemplo de la configuración del modulo:

loadmodule "mid_registrar.so"
modparam("mid_registrar", "mode", 1)
modparam("mid_registrar", "outgoing_expires", 7200)
modparam("mid_registrar", "insertion_mode", 0) /* 0 = contact; 1 = path */

1. se carga el modulo
2. se escoge el modo en que trabajará el modulo. Las distintas opciones:
   • 0: el modulo se añade en el flujo del los REGISTER sin realizar ningún tipo de mitigación de los REGISTER.
   • 1: el modulo, a través del parámetro que sigue, mitiga el numero de REGISTER recibidos por el REGISTRAR principal aumentando el tiempo de duración del registro
   • 2: el modulo además de absorber los registros aumentando el tiempo de duración (como la opción anterior) absorbe también los múltiples registros procedentes desde el mismo usuario pero desde dispositivos distintos. Ejemplo: Se aceptan 5 Registros por cada usuario configurado y los 5 envían sus respectivos REGISTER al modulo Mid-Registrar. A su vez Mid-Registrar envía solamente un Register al REGISTRAR principal indicando en la cabecera Contact su IP/Dominio y su puerto. Esta es la opción que más reduce el trafico de REGISTER hacia el REGISTRAR Principal
3. Los REGISTER enviados al REGISTRAR principal tendrán una duración de 7200 segundos (2 horas)
4. Se indica la forma en que el modulo Mid-Registrar se añade a los REGISTER procesados. Puede ser:
   1. A través de la cabecera contact que es modificada por el  modulo y en lugar de la IP y puerto del usuario aparecerá la IP y puerto donde el modulo está escuchando.
   2. Añadiendo una cabecera PATH a todas las solicitudes reenviadas al REGISTRAR principal. De esta forma todos las futuras solicitudes pasarán siempre por él.

Luego en el script de OpenSIPs se utilizará una de las funciones activadas por el modulo de esta forma:

if (is_method("REGISTER")) {
        mid_registrar_save("location");
        switch ($retcode) {
        case 1:
            xlog("forwarding REGISTER to main registrar ($$ci=$ci)\n");
            $ru = "sip:10.0.0.3:5070";
            t_relay();
            break;
        case 2:
            xlog("absorbing REGISTER! ($$ci=$ci)\n");
            break;
        default:
            xlog("failed to save registration! ($$ci=$ci)\n");
        }

        exit;
    }

la IP 10.0.0.3 y el puerto 5070 es donde se encuentra el REGISTRAR principal.

La función mid_registrar_save decidirá si la solicitud tiene que ser reenviada al REGISTRAR principal o no; además procesará los 200 OK recibidos desde el REGISTRAR principal y guardará el resultado final en su LOCATION SERVER. Dependiendo del modo configurado en el parámetro "mode" realizará las siguiente operaciones:

• modo 1
  • cambiará el valor de la cabecera Expires con el valor indicado en el parámetro outgoing_expires
  • modificará el contenido de la cabecera Contact con su IP y puerto de escucha
  • añadirá un parámetro a la cabecera Contact (predefinido rid) que luego le permitirá enrutar correctamente las respuestas y las llamadas
  • dependiendo de la configuración, si es el caso añadirá una cabecera PATH
• modo 2
  • cambiará el valor de la cabecera Expires con el valor indicado en el parámetro outgoing_expires
  • modificará el contenido de la cabecera Contact con su IP y puerto de escucha de todas las solicitudes recibidas y del mismo usuario desde dispositivos distintos
  • dependiendo de la configuración, si es el caso añadirá una cabecera PATH

IMPORTANTE: el valor del outgoing_expires se puede indicar como parámetro de la función. Si está presente tiene procedencia sobre el valor configurado como parámetro del modulo. La función devuelve una valor numérico que tiene el siguiente significado:

• 1: el REGISTER será reenviado al REGISTRAR principal
• 2: el REGISTER sera absorbido por el modulo Mid-Registar
• -1: error genérico

Para buscar un usuario en el LOCATION SERVER y de esa forma procesar los INVITE/MESSAGE:

 # initial requests from main registrar, need to look them up!
    if (is_method("INVITE|MESSAGE") && $si == "10.0.0.3" && $sp == 5070) {
        xlog("looking up $ru!\n");
        if (!mid_registrar_lookup("location")) {
            t_reply("404", "Not Found");
            exit;
        }

        t_relay();

        exit;
    }

Modo 1 y modo 2 vistos gráficamente:

• MODO 1

• MODO 2

Cuando del REGISTRAR principal llega un INVITE:

Los desarrolladores no descartan de utilizar el modulo también para otros métodos SIP

Fuentes: documentación del modulo

              Tutorial