You are on page 1of 10

Descripción Servicio

SIP Trunk IP o TDM

TELEFÓNICA EMPRESAS CHILE S.


G. de Productos y Digitalización Movistar Empresas
Fecha de emisión del documento: v2 Octubre 2020
Tabla de Contenidos:

1 Introducción ....................................................................................... 4
2 Objetivo ............................................................................................. 4
3 Descripción de la solución ................................................................. 4
Características del servicio................................................................... 5
Front End Systen (FES) ....................................................................... 6
4 Validación del tráfico de la PABX IP .................................................. 7
Validación de ANI ................................................................................. 7
Validación de IP ................................................................................... 7
5 Protocolos y Códec´s ......................................................................... 8
6 Formato de la numeración ................................................................. 9
7 MARCADOR pREDICTIVO ............................................................... 8
8 Referencias ....................................................................................... 8
Introducción

El servicio SIP Trunk permite dar conectividad de voz a las PABX´s


IP/TDM con la RTPC (Red Telefónica Pública Conmutada), utilizando la
red IP MPLS y la NGN (Next Generation Networking) de Telefónica como
elemento de interconexión.

Objetivo
El presente documento tiene por objetivo entregar los requisitos que debe
cumplir la PABX IP/TDM para la correcta operación del servicio.

Descripción de la solución

El servicio SIP Trunk permite establecer llamadas desde usuarios de


PABX´s IP/TDM con la Red Telefónica Pública Conmutada (RTPC) y
desde la RTPC hacia usuarios de PABX´s IP/TDM utilizando la red IP
MPLS y NGN de Telefónica como elemento de interconectividad.

Para la implementación del servicio el cliente debe disponer de una VPN


sobre infraestructura IP (basada en tecnología MPLS) de Telefónica.

En el caso de que la PABX IP no maneje toda la señalización SIP y trafico


RTP, la solución requiere un dispositivo IP tipo Front End Systems (FES)
o IP-to-IP GWs para que maneje toda la señalización SIP, y trafico RTP
entre la red del cliente y la NGN. Este equipo es de cliente.

En la figura N°1 se tiene un diagrama esquemático de la solución., donde


se enfatiza el funcionamiento ‘peer-to-peer’ y B2BUA por temas de
seguridad y control requeridos en los nodos de red.

Entre el SBC de Telefónica y la PABX IP o FES se establece todo el tráfico


de señalización SIP y RTP.
Figura N°1
SIP Trunk IP

Características del servicio (PABX IP)

Las principales características del servicio son:

a. El servicio utiliza protocolo SIP (Session Initiation Protocol) para el


establecimiento y control de llamadas (RFC 3261).

b. El servicio utiliza el protocolo RTP (Real-time Transport Protocol) para


el transporte de la media (RFC 3551)

c. La solución no considera la entrega de servicios suplementarios


(desvíos, bloqueos, etc.), los cuales son entregados por la PABX IP
de cliente.

d. La solución no contempla el discado directo entre anexos de diferentes


PABX´s IP.

e. La conectividad entre la red de voz de cliente y la NGN de Telefónica


se realiza través de una VPN IP privada de Telefónica.
f. El tráfico SIP y RTP de cada uno de sus dispositivos IP del cliente (IAD,
IP Phone, Softphone, MS, etc) debe pasar primero por la PABX IP o
FES para estandarizar y centralizar la conectividad con la NGN.

g. Del lado cliente, tanto la señalización y media deberán provenir de una


misma dirección IP.

h. La IP de la PABX o FES es la única válida para cursar tráfico SIP y


RTP.

i. debe pasar primero por la PABX IP o FES para centralizar y


estandarizar la conectividad con la NGN.

j. El trafico SIP y RTP desde la PABX se debe enviar a un Proxy SIP.

k. EL SBC de Telefónica trabaja en modalidad de peering (no se requiere


registro SIP) para el tráfico de la PABX IP.

Front End Systen (FES)

En el caso de que la PABX IP no maneje toda la señalización SIP y trafico


RTP, la solución requiere un dispositivo IP tipo Front End Systems (FES)
o IP-to-IP GWs para que maneje toda la señalización SIP, y trafico RTP
entre la red del cliente y la NGN. Este equipo es de cliente.

a. El FES (o SBC de cliente) se localiza en las instalaciones del cliente


con el objeto centralizar y de estandarizar los protocolos de
interrelación con la NGN de Telefónica y poder soportar cualquier
variante de configuración en los dispositivos telefónicos del cliente.

b. El FES actúa como B2BUAs, permitiendo definir parámetros de


configuración independientes para las llamadas entre el cliente y la
NGN.

c. El FES es el encargado de recibir las llamadas que el cliente realiza (o


recibe) efectuando la adecuación de las mismas para que puedan ser
enviadas a la NGN (o hacia el Cliente) apropiadamente :
Por ejemplo entre las configuraciones que se deben considerar en
el FES están:
• Con el códec adecuado (transcoding)
• Adecuación de formato de numeración
• Negociación de Silence Supresión (SS)
• Protocolo de transporte de SIP
• Tipo de Payload para RFC-2833,
• Método de fax T.38
• Método de Módem V.152

En el caso de que la PABX maneje toda la señalización SIP y tráfico RTP


el FES podría no ser requerido.

Validación del tráfico de la PABX IP

Para las llamadas desde la PABX hacia la RTPC, el SBC de Telefónica


además de cumplir funciones de seguridad, realiza la validación de ANI
y dirección IP de PABX IP o FES del cliente, cualquier de estas dos
condiciones que no se cumpla la llamada no se cursa.
Validación de ANI
• Para las llamadas desde la PABX IP hacia la RTPC, el SBC permite el
paso de la llamada dependiendo del ANI recibido.

• Para aquellas llamadas en donde el ANI recibido no está dentro del


rango definido (numeración SDA) la llamada no se cursa. Pueden
haber rangos múltiples y disjuntos por cada cliente.

• La validación del ANI para las llamadas desde la PABX IP hacia la


RTPC se realiza según lo siguientes campos del mensaje INVITE:

1. Diversion Header
2. P-Asserted-Identity Header
3. Remote-Party-ID Header
4. From Header

• El orden de validación es el indicado, y si ninguno de ellos realiza


match la llamada no se cursa, si alguno de ellos realiza match la
llamada se cursa. El formato en que se espera del número del ANI se
indica en capítulo 6.
Validación de IP
Además de la validación del ANI, se valida la IP origen
correspondiente al transporte Layer 3. Si la dirección IP origen es
distinta a la definida, la llamada no se cursa.
Protocolos y Códec´s

Los protocolos y códec que se permiten entre la NGN de Telefónica y la


PABX IP de Cliente (o FES) son:

a. El servicio utiliza protocolo SIP (Session Initiation Protocol) para el


establecimiento y control de llamadas (RFC 3261).

b. El servicio utiliza el protocolo RTP (Real-time Transport Protocol) para


el transporte de la media (RFC 3551).

c. Códec de audio:
• Códec audio: G.711 a-law (PCMA)
• 2 muestras de voz por frame
• Se debe considerar un BW de 96,8 Kbps para cada flujo RTP
• Silence supression (VAD): OFF

Formato SDP:
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): fmtp:8 vad=no

d. Dígitos DTMF (telephone-event)


• Según RFC 2833, Payload type: 100

Formato SDP:
Media Attribute (a): rtpmap:100 telephone-event/8000 Media Attribute
(a): fmtp:100 0-15

e. Datos sobre IP:


• Soporte de V.152 para Voice Band Data (VBD)
• Offer of G.711 a-law, Payload type: 96

Formato SDP:
Media Attribute (a): rtpmap:96 PCMA/8000 Media Attribute (a):
gpmd:96 vbd=yes

f. FAX:
• Protocolo T.38

Formato SDP:
Media Attribute (a): pmft: T38
Ejemplo formato SDP:
Media Description, name and address (m): audio 50008 RTP/AVP 8 18
100 96
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): fmtp:8 vad=no
Media Attribute (a): rtpmap:100 telephone-event/8000
Media Attribute (a): fmtp:100 0-15
Media Attribute (a): rtpmap:96 PCMA/8000
Media Attribute (a): gpmd:96 vbd=yes
Media Attribute (a): sendrecv
Media Attribute (a): pmft: T38
Media Attribute (a): ptime:20

g. Las otras negociaciones se basan según las RFC indicadas en


referencia (Punto 7).

Formato de la numeración (PABX IP/TDM)

Para las llamadas entrantes y salientes al servicio SIP Trunk, el formato


de la numeración debe cumplir:

Para llamadas desde la PABX/GW hacia la PSTN:

a. El número llamante (A):

Formato Nacional (9 dígitos)

b. El número llamado (B):

Formato Nacional (9 dígitos)

Para llamadas desde la RTPC hacia la PABX/GW

a. El numero llamante (A):

Formato Nacional (9 dígitos)

b. El numero llamado (B):


Formato Nacional (9 dígitos)

Marcador Predictivo

El servicio SIP Trunk IP soporta los marcadores predictivo, para lo cual


existe la siguiente limitante al momento de configurar dicho Marcador
Predictivo:

a) 2 CAPS por cada 30 DS0 con un máximo de 10 CAPS POR


CLIENTE.

Otra Opción dentro del servicio es SIP Trunk TDM, el cual tiene posee
las mismas condiciones técnicas, lo que varía es el modelo de
comercialización en 30, 60 y 120 canales donde se instala un equipo
Media Gateway.

Figura N°2
SIP Trunk TDM

Media Gateway

Para el servicio servicio SIP Trunk TDM, la PABX con E1/PRI que se
conecta al Media Gateway (MG) instalado por TCH, debe cumplir con:
• Protocol Type: E1 EURO ISDN
• Clock Master: Generated (The device is clock master)
• Framming Method: E1 FRAMING MFF CRC4 EXT (detecta en forma
automática CRC4, de lo contrario se apaga)
• ISDN Termination Side: Network Side

Con estos parámetros se configura el MG instalado por TCH.

Referencias

El Servicio SIP Trunk debe cumplir con las siguientes especificaciones y


recomendaciones:

• “Session Initiation Protocol (SIP)”, RFC 3261, Junio 2002


• “Session Description Protocol (SDP)” RFC 4566, July 2006
• "An Offer/Answer Model with the Session Description Protocol (SDP)",
RFC 3264, June 2002.
• “Provisional Response Acknowledgement”, RFC 3662, Junio 2002
• "RTP Payload for Comfort Noise", RFC 3389, September 2002.
• “RTP Payload Format for a 64 kbit/s Transparent Call”, RFC 4040, April
2005
• “Procedures for supporting voice band data over IP networks”, ITU-T
V.152 (2005)
• "RTP Profile for Audio and Video Conferences with Minimal Control",
RFC 3551, July 2003.
• “MIME Type Registration of RTP Payload Formats”, RFC3555,
September 2002
• UIT-T T.38 Fax Relay Specification.
“RTP Payload for DTMF Digits”, RFC 2833. May 2000.

You might also like