Lo que me ha llevado a escribir este artículo ha sido la numerosas veces que he buscado información sobre esto. Quizás sea problema de mi forma de buscar, aunque finalmente comprendí que esta tipo de configuraciones se consideran también como “Asterisk as sip client”, pero en cualquier caso con los pedacitos de información que he ido encontrando, quería poner un ejemplo concreto para configurar un TRUNK SIP entre dos Asterisk.

Asterisk PBX

### AsteriskPBX_A
;register => user[:secret[:authuser]]@host[:port][/extension]
;register => fromuser@fromdomain:secret@host
;register => fromuser@fromdomain:secret:authuser@host:port/extension
;;
;; register se utiliza para dos cosas:
;; si a) queremos ser llamados, y b) si aparecemos en el otro extremo como dynamic en la parte de host.
;;
register => userB:passwordB@ipB/contextA
;; contextA - indica la extensión del Asterisk en A para recepción de llamadas.

[authentication]

[contextA]
type=friend
secret=passwordA
context=default
host=dynamic
username=userA
fromuser=ServerB
disallow=all
allow=alaw
qualify=yes
canreinvite=no
nat=no
insecure=port,invite

### AsteriskPBX_B

;; register => user[:secret[:authuser]]@host[:port][/extension]
register => userA:passwordA@ipA/contextB

[authentication]

[contextB]
type=friend
secret=passwordB
context=default
host=dynamic
username=userB
fromuser=ServerA
disallow=all
allow=alaw
qualify=yes
canreinvite=no
nat=no
insecure=port,invite

Comandos de Asterisk CLI de utilidad:

*CLI> sip show registry
*CLI> sip show peer
*CLII> sip show peer

Las opciones que más me llaman la atención son (quizás me llamen la atención porque fueron las menos intuitivas):

### insecure

Esta opción indica si por cada llamada se debe autenticar o validar algún valor.

Acepta los valores de very, yes,port:

insecure=yes ; To match a peer based by IP address only and not port
insecure=very ; To allow registered hosts to call without re-authenticating
port: ignore the port number where request came from
invite: don’t require authentication of incoming INVITEs
port,invite: don’t require initial INVITE to authenticate and ignore the port where the request came from

### canreinvite

Este parámetro tiene que ver con la forma en SIP/RTP trabaja. Asterisk no es un proxy sip, es decir Asterisk debe preocuparse por algo más que la señalización [SIP], debe preocuparse por el media [RTP - real time protocol]. Asterisk debe permanecer en medio de las conexiones para poder aportar características como grabación de llamadas, canal espía, etc… Con este parámetro indicamos si en algunos caso podemos delegar RTP a los dos peers de una llamada [teléfono - teléfono]. El SIP seguiría pasando a través de Asterisk, pero el RTP sería “punto a punto”.

El concepto de reinvite viene del método SIP INVITE, que es el que lanza Asterisk contra con SIP Phone para establecer una llamada, con este INVITE indicamos al SIP Phone varios parámetros: codecs, cual es la ip del otro extremo, etc… Normalmente le envíamos la IP de la centralita para que SIP/RTP pasen por ella, pero Asterisk puede enviar un re-INVITE para indicarle nuevos parámetros, como la IP del otro SIP Phone, y dejarles todo el trabajo RTP a ellos.

Esto es adecuado sobre todo en conexiones con NAT, y sobre todo cuando queramos tener todo el control de la llamada en Asterisk.

canreinvite = yes “allow RTP media direct”
canreinvite = no “deny re-invites”
canreinvite = nonat “allow reinvite when local, deny reinvite when NAT”
canreinvite = update “use UPDATE instead of INVITE”
canreinvite = update,nonat “use UPDATE when local, deny when NAT”

El canreinvite=no nos facilita la vida a los administradores de Firewall porque solo tendríamos que añadir las siguientes reglas de firewall:

SRC=Redes_SIP_Phones DST=PBX-Asterisk PORT=5060 PROTO=UDP – ACCEPT

SRC=Redes_SIP_Phones DST=PBX-Asterisk PORT-RANGE=10000:20000 PROTO=UDP – ACCEPT

De la otra forma tendríamos que abrir estos mismos puertos entre todas las redes de telefonía, que cuando son redes de usuario (porque utilizan softphone) nos puede fastidiar la política de seguridad. Siempre recomendaría hacer VLAN’s, sean softphone o hardphones. Los protocolos SIP/RTP siguen siendo muy débiles por si mismos.

Referencias: http://www.voip-info.org/wiki/view/Asterisk+config+sip.conf

Referencias: http://www.voip.unam.mx/mediawiki/index.php/Conectando_dos_Asterisk_mediante_el_protocolo_SIP