En la configuración del modulo NATHELPER de Kamailio es posible configurar una serie de parámetros para definir si a los dispositivos que Kamilio ha detectado que se han registrado detrás de un NAT, hay que enviarle o no solicitudes SIP de tipo OPTIONS, normalmente utilizadas para mantener abierta la comunicación con esos dispositivos. Los parámetros que se utilizan son:

modparam("nathelper", "natping_interval", 30)

modparam("nathelper", "ping_nated_only", 0)

modparam("nathelper", "sipping_bflag", FLB_NATSIPPING)

modparam("nathelper", "sipping_from", "sip:pinger@IP_PUBLICA")

• cada cuantos segundos enviar el OPTIONS

• enviar el OPTIONS a todos los dispositivos registrados (0), solamente a los dispositivos registrados detectados por Kamailio detrás de un NAT (1)

• la bandera de tipo branch que activará el envío de los OPTIONS

• SIP URI desde donde se enviará la solicitud OPTIONS

Luego en el script de enrutamiento, en la ruta dedicada al procesamiento de las solicitudes SIP de tipo REGISTER, se añade este bloque:

#!ifdef WITH_NATSIPPING

# do SIP NAT pinging

setbflag(FLB_NATSIPPING);

#!endif

Esto significa que si antes de este bloque hay una sentencia que lo activa:

#!define WITH_NATSIPPING

a los dispositivos registrados se enviará una solicitud de tipo OPTIONS dependiendo del valor del parámetro ping_nated_only

Ahora, hace poco días, un inscrito a la lista de distribución de Kamailio, escribió que había un BUG (Error) en el Código de Kamailio porque el OPTIONS generado por Kamailio no contiene la Cabecera Max-Forward, cabecera que según la RFC3261 (El documento donde se define el protocolo SIP) es obligatoria en las solicitudes SIP de tipo OPTIONS. De hecho si miramos una:

Efectivamente la cabecera Max-Forwards no está presente; eso explica porque algunos Softphone contestan ese OPTIONS con la siguiente respuesta de error:

eso porque interpretando correctamente la RFC3261 están diciendo que la sintaxis del OPTIONS recibido no es correcta.

A breve debería salir la corrección a este error.