El escenario que se va a describir es el aconsejado cuando se quieren instalar 2 o más Kamailio distribuidos geográficamente con un Asterisk detrás de los Proxy SIP. En Asterisk, canal PJSIP, se activará el protcolo PATH soportado desde la versión 13 de la PBX. La configuración descrita se basa en Kamailio 5.4.5 y Asterisk PBX 16.17.0. Kamailio se encargará de la autenticación de las solicitudes SIP mientras Asterisk se encargará de las llamadas entre extensiones y de todos los servicios que puede ofrecer, colas, IVR, Conferencias, etc.

Para no alargar mucho los datos de configuración del lado de Kamailio se configura el modulo PATH de la siguiente manera:

loadmodule "path.so"

modparam("path", "use_received", 1)

y en el bloque donde se procesan los REGISTER (que se autentican a nivel de Kamailio):

route[REGISTRAR] {

if (!is_method("REGISTER")) return;

if(isflagset(FLT_NATS)) {

setbflag(FLB_NATB);

#!ifdef WITH_NATSIPPING

# do SIP NAT pinging

setbflag(FLB_NATSIPPING);

#!endif

}

if (!save("location")) {

sl_reply_error();

}

append_hf("Supported: path\r\n");

add_path();

rewritehostport("AsteriskPBXIP:5060");

forward();

exit;

}

las dos lineas importantes son:

append_hf("Supported: path\r\n");

add_path();

con la primera se añade una cabecera SIP con nombre Supported: y valor path. Esto para que Asterisk PBX sepa que el Proxy SIP desde donde llega la solicitud soporta el protocolo PATH. A lo largo de mis pruebas me di cuenta que sin este parametro, Asterisk no devolvía la solicitudes a Kamailio, esto en la versión 13 de la PBX; no se si esto ha cambiado desde la 16 pero añadir el valor no está de sobra. Con la segunda se añade a la solicitud enviada a Asterisk la cabecera PATH indicando la SIP URI de kamailio y el valor lr que está por loose routing y ayudará a Asterisk a construir la solicitud SIP enviada a Kamailio.

Otra parte importante es el procesamiento de los INVITE y NOTIFY procedentes de Asterisk PBX cuyo bloque se explicará más adelante:

if (is_method("NOTIFY|INVITE") && $si=="AsteriskPBXIP") {

loose_route();

t_relay();

exit;

}

Del lado de Asterisk, mostrando la configuración de un endpoint PJSIP:

[1000]

type=endpoint

context=kamailio

subscribe_context=subscribe

disallow=all

allow=ulaw,g722

accountcode=1000

language=es

mailboxes=1000@default

dtmf_mode=rfc4733

callerid=1000 <1000>

direct_media=no

force_rport=yes

rtp_symmetric=yes

call_group=1

pickup_group=1

transport=no-nat

aors=1000

[aut1000]

type=auth

auth_type=userpass

password=password

username=1000

[1000]

type=aor

max_contacts=5

remove_existing=yes

qualify_frequency=30

mailboxes=1000

support_path=yes

Como de manera predefinida Asterisk no tiene activado el protocolo PATH hay que hacerlo en el bloque de tipo aor de cada endpoint, parámetro support_path=yes.

Una vez realizada la configuración se registra el usuario 1000 configurando el Teléfono SIP con la IP de Kamailio como REGISTRAR:

El REGISTER de Kamailio a Asterisk PBX:

Lado Asterisk:

asterisk -rvvvvvvvvvvvv

CLI> database show:

/registrar/contact/1000;@45decdd6ec4695e8e375dcb9302f9c1e: {"via_addr":"10.0.0.150","qualify_timeout":"3.000000","call_id":"76589YjVkMDc4YzA5OWM0YmRhZjU5MzNiMTg1NDdmZGY4MDk","reg_server":"","prune_on_boot":"no","path":"<sip:159.203.101.46;lr>","endpoint":"1000","via_port":"57888","authenticate_qualify":"no","uri":"sip:1000@98.199.82.170:57888;rinstance=27283ce1aa9ac4ee","qualify_frequency":"30","user_agent":"X-Lite release 4.8.4 stamp 76589","expiration_time":"1620082468","outbound_proxy":""}

Como las llamadas se procesarán a nivel de Asterisk PBX, cuando se marcará de la extensión 1000 a la extensión 1001, la llamada saliente de Asterisk hacia la extensión 1001, que pasará por Kamailio, aparecerá de la siguiente manera:

El INVITE saliente de Asterisk contendrá en la cabecera Route: el mismo valor presente en la cabecera Path: del REGISTER enviado a Asterisk. Esa cabecera será procesada por Kamailio en la siguiente ruta:

if (is_method("NOTIFY|INVITE") && $si=="AsteriskPBXIP") {

loose_route();

t_relay();

exit;

}

Cuya lógica es: si la solicitud SIP recibida es de tipo NOTIFY o INVITE y la IP de procedencia es Asterisk, utilizar la función loose_route para buscar la Primera cabecera Route presente: si en esa cabecera aparece la IP del Proxy mismo, Kamailio la elimina y reenvía la solicitud al destino final con la función t_relay. En este caso el destino final es el contenido en la Request URI, es decir la linea con el circulo blanco.

Si tienes dudas, escriban un comento a esta entrada. Este tema es parte del proximo curso de Kamailio Recargado programado para Junio 2021