Media Codecs
Implementar “Call Admission Control – CAC” en Skype for Business. Parte 2
Implementar “Call Admission Control – CAC” en Skype for Business. Parte 1
Continuamos con la implementación de Call Admission Control – CAC en Skype for Business, algo que como ya conté en la Parte.1 del articulo, es raro encontrarse en la implementaciones de Skype/Lync, al menos en las que yo he trabajado, es algo que el si no pide expresamente el cliente, los propios administradores o implementadores no solemos poner.
En esta segunda parte, sobre un ejemplo de una infraestructura voy a explicar como diseñar CAC.
Diseño de Skype for Business
Imaginemos que tenemos el siguiente diseño en Skype for Business.
En este diseño tenemos una implementación de SKYPE FOR BUSINESS con un SITE Principal que esta en Madrid, con su Pool de Edge que actuará como ruta principal para la Federación de todo el entorno, además tenemos un SIP TRUNK que será por el que sacaremos las llamadas.
También tenemos dos sitios remotos, una oficina en Barcelona, con su salida a la PSTN y otro en UK, concretamente en la oficina estará en Londres. También con salida a la PSTN.
El Pool principal con sus Sitios Remotos estará conectado a través de una WAN.
Como ya vimos en el articulo anterior, CAC actuara sobre la WAN de estos Sitios Remotos.
Diseño de “Call Admission Control – CAC”
Una vez que ya tenemos nuestra infraestructura de Skype diseñada, podremos empezar a pensar en el diseño de CAC, normalmente el cliente nos podrá dar que anchos de banda y limites quiere, pero si no nos tocara a nosotros hacer el calculo. Para ello tendremos que tener en cuenta la tabla de Anchos de Banda y Consumos de Skype y sus códec.
UTILIZACION DE ANCHO DE BANDA SEGUN EL CODEC
UTILIZACION DE ANCHO DE BANDA SEGUN EL ESCENARIO
Para nuestro ejemplo en el que estamos trabajando vamos a usar para los sitios de Barcelona y Londres la misma configuración de CAC
| Audio Limit | 3072 Kb |
| Audio Session Limit | 175 Kb |
| Video Limit | 2048 Kb |
| Video Session Limit | 384 Kb |
Para implementar CAC debemos tener claro los siguientes términos:
Para diseñar nuestro CAC deberemos determinar cual será nuestra Regiones de Red (Network Región) por ejemplo, podemos tener una Región de Red para Europa y otra para America del Norte, después en cada Región de Red tendremos el Sitio Central (Central Site), por ejemplo, para la Región de Europa, el Central Site será Madrid y para Norte América será Chicago. Además tendremos nuestros Sitios de Red (Network Sites), que será donde apliquemos la limitación de CAC. En nuestro caso es, Barcelona y Londres.
Para el ejemplo en el que estamos trabajando, tenemos el siguiente diseño
| Network Region | Central Site | Network Sites |
| EMEA | Madrid | Barcelona |
| London |
SIP/2.0 488 Invalid incoming Gateway SDP: Gateway ParseSdpOffer Error: No DTMF support on Gateway side.
En el siguiente artículo quiero abordar un problema que nos encontramos no hace mucho. Concretamente lo detectamos en algunas llamadas entrantes que no llegaban a los usuarios Lync de destino.
Concretamente se detectó que tras la implementación de la solución de Comunicaciones Unificadas de Microsoft, las llamadas entrantes desde una empresa concreta no llegaban y según les habían avisado la llamada se cortaba sin más.
Lo primero que hicimos fue sacar unas trazas con el Wireshark en los propios Mediation Server y haciendo pruebas de llamadas desde el origen concreto que fallaba, el resultado fue el siguiente:
91DDDDDDD;ext=8100 – Numero Destino
91OOOOOOO – Numero Origen
Sep 11 13:42:20.336 On XX.XX.XX.XX:32507 sent to XX.XX.XX.XX:5068
INVITE sip:+3491DDDDDDD;ext=8100@mediationserver.mrlync.com:5068;transport=tcp SIP/2.0
Via: SIP/2.0/TCP XX.XX.XX.XX:5066;branch=z9hG4bKnm3l563060ngul4dl4m1.1
From: <sip:+3491OOOOOOO@mrlync.com:32507>;tag=a16b6ae8-a0110ac-13c4-55013-768715-4170812a-768715
To: <sip:+3491DDDDDDD;ext=8100@mrlync.com:5068>
Call-ID: a11013e8-a0110ac-13c4-55013-768715-1bba52cc-768715
CSeq: 1 INVITE
Contact: <sip:91OOOOOOO@XX.XX.XX.XX:5066;user=phone;transport=tcp>
Max-forwards: 68
User-agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17
P-asserted-identity: <sip:91OOOOOOO@mrlync.com;user=phone>
Privacy: none
History-info: <sip:8101@mrlync.com;user=phone?reason=sip%3bcause%3d302%3btext%3d%22Moved%20Temporarily%22>;index=1
History-info: <sip:89998100@mrlync.com;user=phone>;index=2
Allow: INVITE, ACK, BYE, REGISTER, REFER, NOTIFY, CANCEL, PRACK, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Alert-Info: <cid:external@mrlync.com>
Content-Length: 143
Supported: x-nortel-sipvc, replaces
v=0
o=- 127866 1 IN IP4 XX.XX.XX.XX
s=-
c=IN IP4 XX.XX.XX.XX
t=0 0
m=audio 53890 RTP/AVP 8 0
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000————————————-
FROM: <sip:+3491OOOOOOO@mrlync.com:32507>;tag=a16b6ae8-a0110ac-13c4-55013-768715-4170812a-768715
TO: <sip:+3491DDDDDDD;ext=8100@mrlync.com:5068>
CSEQ: 1 INVITE
CALL-ID: a11013e8-a0110ac-13c4-55013-768715-1bba52cc-768715
VIA: SIP/2.0/TCP XX.XX.XX.XX:5066;branch=z9hG4bKnm3l563060ngul4dl4m1.1
CONTENT-LENGTH: 0
—————————————-
Sep 11 13:42:20.388 On XX.XX.XX.XX:32507 received from XX.XX.XX.XX:5068
SIP/2.0 488 Invalid incoming Gateway SDP: Gateway ParseSdpOffer Error: No DTMF support on Gateway side.
FROM: <sip:+3491OOOOOOO@mrlync.com:32507>;tag=a16b6ae8-a0110ac-13c4-55013-768715-4170812a-768715
TO: <sip:+3491DDDDDDD;ext=8100@mrlync.com:5068>;epid=42EFB206DA;tag=2adf8e80cc
CSEQ: 1 INVITE
CALL-ID: a11013e8-a0110ac-13c4-55013-768715-1bba52cc-768715
VIA: SIP/2.0/TCP XX.XX.XX.XX:5066;branch=z9hG4bKnm3l563060ngul4dl4m1.1
CONTENT-LENGTH: 0
SERVER: RTCC/5.0.0.0 MediationServer
Poniendo una traza en el SBC para ver la parte del operador con el que el cliente tiene contratado el SIP TRUNK, vimos que algunas llamadas que fallaban llegaban con la siguiente información.
m=audio 47674 RTP/AVP 18 8
a=ptime:20
a=fmtp:18 annexb=no
Para que Lync acepte llamadas, el destino de la misma debe aceptar el envío de DTMFs y claramente en las trazas faltaba la información:
m=audio 55608 RTP/AVP 8 0 18 101
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
m=image 58894 udptl t38
a=T38FaxVersion:0
a=T38FaxMaxBuffer:1100
a=T38FaxMaxDatagram:612
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
Lo normal en esta ocasión era hablarlo directamente con el operador, pero al poder gestionar nosotros mismos en SBC del cliente, por parte de nuestro ingeniero especializado en SBC de ORACLE se determinó que la mejor opción era modificar el “Codec-Policy” del propio SBC, sustituyendo este:
codec-policy
name ToLync
allow-codecs G729:no T.38:no PCMA PCMU telephone-event
add-codecs-on-egress PCMA PCMU
order-codecs
force-ptime disabled
packetization-time 20
dtmf-in-audio disabled
last-modified-by admin@
last-modified-date 2013-09-16 10:14:40
Por el siguiente:
codec-policy
name ToLync
allow-codecs G729:no T.38:no PCMA PCMU telephone-event
add-codecs-on-egress PCMA PCMU telephone-event
order-codecs
force-ptime disabled
packetization-time 20
dtmf-in-audio disabled
last-modified-by admin@10.10.105.55
last-modified-date 2013-09-16 10:14:40
De esta manera conseguimos que el SBC entregara la llamada correctamente a Lync y este las aceptara y entregara al destino.
Os recomiendo el siguiente artículo de Jeff Schertz, donde se explica el “Media Codecs” de Lync
http://blog.schertz.name/2014/03/media-codecs-in-lync-2013/
Cualquier problema al respecto que tengáis o que os podáis encontrar no dudéis en escribirme e intentare orientaros en lo posible, sé que muchos administradores de Lync/Skype no somos grandes expertos en protocolos pero a base de sacar y ver trazas al final podemos saber interpretarlas, pero desde luego la ayuda de un ingeniero especializado en este asunto nos puede salvar de más de algún problema.
