TEMA:

IMPLEMENTACION DE UNA CENTRAL TELEFONICA CON LA OPCION

CANREINVITE

CURSO:

REDES VOZ IP

DOCENTE:

JESUS ALBERTO VILCHEZ SANDOVAL

INTEGRANTES:

MORY CARHUAPOMA, KELWIN LEANDRO

GRUPO:

2018
 INTRODUCCION

En un sistema Asterisk la señalización SIP para el establecimiento de una llamada se

produce siempre entre el servidor de Asterisk y las extensiones que participan en dicha
llamada. Una vez que la llamada ha sido establecida, el tráfico rtp puede circular
también a través del servidor de Asterisk o puede circular de forma directa entre las
extensiones que participan en la llamada. Ambos sistemas tienen ventajas e
inconvenientes:

 Si el tráfico rtp circula directamente entre las extensiones que participan en una
llamada, la ventaja es que el servidor de Asterisk no tiene que soportar esa carga
de trabajo, que en determinados casos puede ser muy importante, como por
ejemplo cuando se trata de una PBX Asterisk con decenas o cientos de llamadas
de forma simultánea.
 Si el tráfico rtp circula directamente entre las extensiones que participan en una
llamada, el inconveniente es que Asterisk no reconocerá ningún código marcado
en las extensiones una vez iniciada la llamada. Por lo tanto, no funcionarán en
ningún caso aquellas aplicaciones de Asterisk que se activan mediante
determinados códigos de marcado, como por ejemplo las transferencias de
llamadas.
1. TOPOLOGIA

EXT 401
Juan Rojas

EXT 402
Leandro Mory

EXT 403
Jose Huaroc

ASTERISK
10.52.40.193
EXT 404
Carlos Cahuana
2. CONFIGURACION

Sip.conf
[general]
bindport=5060
bindaddr=0.0.0.0
language=es
canreinvite=no
nat=yes
;de la misma forma se puede definir mas parametros

[mi_plantilla](!)
type=friend
secret=123456
host=dynamic
context=usuarios

[401](mi_plantilla)
callerid=Juan Rojas <401>
mailbox=401@default

[402](mi_plantilla)
callerid=Leandro Mory <402>
mailbox=402@default

[403](mi_plantilla)
callerid=Jose Huaroc <403>
mailbox=403@default

[404](mi_plantilla)
callerid=Carlos Cahuana <404>
mailbox=404@default

extensions.conf
[general]
[globals]

[usuarios]
include=>anexos

[anexos]
exten => 401,1,Dial(SIP/401,10)
same => n,VoiceMail(401@default)
same => n,HangUp()

exten => 402,1,Dial(SIP/402,10)

same => n,VoiceMail(402@default)
same => n,HangUp()

exten => 403,1,Dial(SIP/403,10)

same => n,VoiceMail(403@default)
same => n,HangUp()

exten => 404,1,Dial(SIP/404,10)

same => n,VoiceMail(404@default)
same => n,HangUp()
3. CAPTURAS (CORE SET VERBOSE 5)

3.1. SIN CANREINVITE

3.2. CON CANREINVITE

4. CAPTURA WIRESHARK
4.1. SIN CANREINVITE
4.2. CON CANREINVITE

5. FLUJODRAMA

5.1 SIN CANREINVITE

5.2 CON CANREINVITE
6. ANALISIS DEL MENSAJE CAPTURADO

En primero lugar, se quiere que funcionen las transferencias de llamadas y otras

funciones que dependen de la marcacion (desvíos, no molestar, grabación de la llamada,
etc) es imprescindible que el tráfico de voz (rtp) circule también a través de Asterisk. La
activación de esta característica se hacía en versiones anteriores de Asterisk mediante
el parámetro canreinvite en el fichero sip.conf. Con la opción canreinvite=yes el trafico
rtp circula directamente entre las extensiones que toman parte en una llamada, y con la
opción canreinvite=no el tráfico rtp pasará a través de Asterisk. En el siguiente diagrama
se muestra un ejemplo práctico de un sistema Asterisk con dos extensiones y la forma
en que va el tráfico rtp cuando se ajusta canreinvite=yes y cuando se ajusta
canreinvite=no

Cuando se llama desde la extensión 401 a la 403 con el parámetro canreinvite=no, la

captura de paquetes mediante un analizador de protocolos de red como Wireshark es
la siguiente:
Señalización SIP con la opción canreinvite=no

En la captura anterior vemos en primer lugar que la extensión 401 (10.22.81.22) envía un
paquete INVITE al servidor de Asterisk (10.52.40.193) y éste a su vez envía otro paquete
de INVITE a la extensión 403 (10.22.81.47). Después de completar la fase de señalización SIP
(100 Trying, 180 Ringing, 200 Ok,…..) comienza el tráfico de paquetes rtp entre ambas
extensiones pasando a través del servidor de Asterisk, es decir, por la IP 10.52.40.193 . La
señalización SIP producida queda representada en el siguiente diagrama:

ASTERISK
INVITE 10.52.40.193
100 Trying INVITE
180 Ringing
180 Ringing
200 OK
200 OK
ACK ACK
EXT 401 RTP EXT 404
Juan Rojas Carlos Cahuana
RTP

Señalización SIP en el establecimiento de una llamada

En cambio, si modificamos el fichero sip.conf y ajustamos el parámetro canreinvite
a canreinvite=yes, el resultado será el siguiente:

Señalización SIP con la opción canreinvite=yes

Se observa en este caso que el tráfico de paquetes rtp va directo entre ambas extensiones
(zona enmarcada en color azul) y se observa también que una vez que la extensión 401
envía el primer INVITE al servidor de Asterisk y éste envía el correspondiente INVITE
a la extensión 404, el servidor de Asterisk envía un nuevo INVITE a cada una de las
extensiones (zonas enmarcadas en color azul). Estos nuevos invites son en realidad unos
reinvites que efectúa el server de Asterisk a las extensiones y de aquí viene el nombre
tan curioso de este parámetro: canreinvite=yes.

Si analizamos el contenido de estos mensajes de INVITE podemos ver que cuando el

tráfico pasa por el servidor de Asterisk (canreinvite=no), las extensiones que participan
en la llamada reciben la dirección IP del servidor de Asterisk como dirección IP a donde
tienen que enviar sus paquetes rtp.
 Invite del servidor de Asterisk a la extensión 404

En cambio si examinamos el contenido de los mensajes de reinvite (canreinvite=yes)

podemos observar que el servidor de Asterisk informa a cada una de las extensiones de
la dirección IP de la otra extensión, a fin de que el tráfico rtp pueda ir de forma directa
entre ellas:

reinvite del servidor de Asterisk a la extensión 401

Es importante también tener en cuenta que en determinados casos Asterisk ignorará el

ajuste canreinvite=yes y funcionará como si se hubiera ajustado a canreinvite=no. Este
comportamiento “autónomo” de Asterisk se dará en los siguientes casos:

1. Si una cualquiera de las extensiones está configurada con la opción

canreinvite=no.
2. Si las extensiones que participan en una llamada soportan codecs de voz no
compatibles entre sí. En este caso el flujo de paquetes rtp con la voz digitalizada
pasará por el servidor de Asterisk y éste realizará la oportuna conversión de codecs
de voz. Atención: No olvidar que independientemente de la conversión de codecs
que realice Asterisk, en la definición de cada extensión en el fichero sip.conf
 deberán de estar habilitados los respectivos codecs. Si una extensión trabaja solo
con el codec alaw y otra lo hace con el codec ulaw, en la definición de las
extensiones en el sip.conf habrá que indicar allow=alaw para la primera de ellas
y allow=ulaw para la segunda.
3. Si en el DialPlan aparece la opción de transferencia de llamada, mediante los
parámetros ”t”, ”T”. Para que Asterisk pueda realizar una transferencia de
llamadas tiene que poder detectar el código que introducirá el usuario cuando
desee realizar la transferencia y eso solo es posible si el tráfico rtp pasa a través
del propio Asterisk.
4. Si en el DialPlan aparece cualquiera de las siguientes opciones “h”, “H” (permiso
para colgar la llamada pulsando * al usuario llamante y al usuario llamado), “W”,