quinta-feira, 20 de setembro de 2012

MGCP - Parte 2 (Troubleshooting 1 - Chamada sainte)

Uma parte muito importante do atual Blueprint de voz é o Troubleshooting. Diferente da prova de R&S, essa sessão não é uma parte separada da prova. As questões de troubleshooting estão misturadas dentro do próprio exame. Nesses items, a prova pode te pedir para corrigir alguma coisa (ou pode nem te pedir tão claramente, mas você tem que sacar que está errado), ou coletar debugs/traces e postar em um txt com a sua explicação dos fatos.

Hoje vou falar sobre o troubleshooting do MGCP no gateway de voz. Mas antes de começar, precisamos lembrar que o MGCP trabalha com uma arquitetura centralizada, isto é, ele depende de um call-agent (no nosso caso, o Call Manager) para controlá-lo. Com o MGCP, o gateway repassa as informações de Layer 3 (Q.931) do ISDN vindas da PSTN para o CUCM (backhaul), que por sua vez envia mensagens ao roteador orientando-o sobre o que fazer. Em outras palavras, o gateway se torna um dispositivo burro, e o CUCM é quem coordena toda a comunicação.

Então por exemplo, em uma chamada entrante, a PSTN envia a sinalização Q.931 (aquela que contém os métodos de SETUP, CALL_PROC, ALERTING, etc.) e o gateway repassa tudo para o CUCM (no gateway, conseguimos ver essas mensagens com o comando debug ccm-manager backhaul packets). O CUCM trata as mensagens e orienta o gateway a criar a conexão e trocar mídia (RTP) com o telefone destino (conseguimos ver essas mensagens com o comando debug mgcp packets).

Portanto, os dois debugs que utilizaremos para o troubleshooting de MGCP no gateway são:
1. debug ccm-manager backhaul packets
2. debug mgcp packets
Para facilitar, vou marcar de azul tudo que for referente ao primeiro, e de verde tudo que for referente ao segundo.

Então vamos ao nosso nosso primeiro cenário:

1. Chamada saínte

Nesse cenário, um IP Phone qualquer vai fazer uma chamada para a PSTN. Vamos ver o que acontece:

! -- O gateway recebe uma solicitação de criar uma conexão (CRCX) do CUCM (10.10.210.11). O CUCM está informando, entre outras coisas, as features de mídia: 
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38 (p = sampling rate, a = codec, s = vad, t = type of service)

Sep 15 21:58:03.892: MGCP Packet received from 10.10.210.11:2427--->
CRCX 197 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
X: 8
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop

! -- O gateway envia uma confirmação (200 OK), juntamente com o SDP. No SDP o gateway vai informar qual é o IP que ele vai falar mídia (definido no comando mgcp bind media source <interface>), a porta que ele vai falar RTP, e codec. O 0 ao lado de RTP/AVP significa G.711u).
Sep 15 21:58:03.908: MGCP Packet sent to 10.10.210.11:2427--->
200 197 OK
I: B
v=0
o=- 11 0 IN IP4 10.10.200.3
s=Cisco SDP 0
c=IN IP4 10.10.200.3
t=0 0
m=audio 17952 RTP/AVP 0 100
a=rtpmap:100 X-NSE/8000
a=fmtp:100 200-202
a=X-sqn:0
a=X-cap: 1 audio RTP/AVP 100
a=X-cpar: a=rtpmap:100 X-NSE/8000
a=X-cpar: a=fmtp:100 200-202
a=X-cap: 2 image udptl t38

! -- E aí vemos o SETUP sendo enviado para a PSTN por uma mensagem "backhauled" do CUCM. Veja que no corpo do SETUP, temos um número gigante terminado por: "34363738313234". E veja também que sempre tem um "3" intercalando cada número dessa string. Olha o que acontece se apagarmos todos os 3: "4678124". Esse é o número que o IP Phone está ligando!
Outra coisa importante a se observar nesse debug é o "sending" e "receiving". Essa comunicação é entre gateway e CUCM, e é na visão do gateway. Ou seja, quando é "Sending backhaul msg" quer dizer que a PSTN mandou, e o gateway está encaminhando para o CUCM. Quando é "Receiving backhaul msg" quer dizer que o CUCM mandou, e o gateway está encaminhando para a PSTN.
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
        | bk_msg_type = DATA_REQ
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 43
        | Q.931 message type: SETUP
        | Q.931 message = 080200090504038090A21803A98388280548515048326C090081353535323030327008C134363738313234

! -- Depois da PSTN receber o SETUP, ela responde com um CALL PROCEEDING e ALERTING, como ocorre normalmente nas chamadas ISDN. Essas mensagens são todas encaminhadas para o CUCM:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
        | bk_msg_type = DATA_IND
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 10
        | Q.931 message type: CALL PROCEEDING
        | Q.931 message = 08028009021803A98388
Sep 15 21:58:03.960:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
        | bk_msg_type = DATA_IND
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 9
        | Q.931 message type: ALERTING
        | Q.931 message = 08028009011E028188
Sep 15 21:58:04.320: MGCP Packet received from 10.10.210.11:2427--->

! -- Como a PSTN mandou um ALERTING, sabemos que o lado de lá está chamando. Então o CUCM manda um MDCX (Modify Connection) para o Gateway, mudando o status de recvonly para sendrecv, orientando o Gateway a começar a enviar mídia. E depois o gateway responde com um 200 OK. O CUCM também informa qual é o IP do telefone e porta, para eles falarem RTP (192.168.14.12 / 24682).
Sep 15 21:58:04.320: MGCP Packet received from 10.10.210.11:2427--->
MDCX 198 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
L: p:20, a:PCMU, s:off, t:b8, fxr/fx:t38
M: sendrecv
R: D/[0-9ABCD*#], FXR/t38
S:
Q: process,loop

v=0
o=- 11 0 IN EPN S0/SU0/DS1-0/8@SiteA-RTR
s=Cisco SDP 0
t=0 0
m=audio 24682 RTP/AVP 0
c=IN IP4 192.168.14.12
a=X-sqn:0
a=X-cap:1 image udptl t38

Sep 15 21:58:04.324: MGCP Packet sent to 10.10.210.11:2427--->
200 198 OK

! -- Agora a PSTN atende a chamada, e envia um CONNECT, que é enviado ao CUCM:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
        | bk_msg_type = DATA_IND
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 5
        | Q.931 message type: CONNECT
        | Q.931 message = 0802800907
Sep 15 21:58:13.324:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
        | bk_msg_type = DATA_REQ
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 5
        | Q.931 message type: CONNECT ACK
        | Q.931 message = 080200090F

! -- Nesse momento, o telefone está trocando RTP com o Gateway, e a chamada está em andamento.

! -- Agora a PSTN desconecta a chamada, e envia um DISCONNECT via Q.931, que é enviado para o CUCM:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
        | bk_msg_type = DATA_IND
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 9
        | Q.931 message type: DISCONNECT
        | Q.931 message = 080280094508028290

! -- O CUCM inicia o processo de desconexão, enviando um MDCX ao gateway mudando o status dele para recvonly. Ou seja, ele está falando para o gateway parar de mandar RTP. E o roteador manda um 200 OK confirmando:
Sep 15 21:58:27.516: MGCP Packet received from 10.10.210.11:2427--->
MDCX 199 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop

Sep 15 21:58:27.520: MGCP Packet sent to 10.10.210.11:2427--->
200 199 OK

! -- Agora o CUCM solicita a deleção da conexão com um DLCX (Delete Conection):
Sep 15 21:58:27.524: MGCP Packet received from 10.10.210.11:2427--->
DLCX 200 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
C: D000000002520875000000F500000009
I: B
X: 8
S: 

! -- E o gateway agora manda um 250 OK. Esse 250 é um pouco diferente dos outros ACKs. Nessa mensagem, ele manda uma estatística da chamada, informando a quantidade de Pacotes Enviados (PS), Recebidos (PR), Octetos enviados (OS), recebidos (OR), pacotes perdidos (PL), Jitter (JI) e Latencia (LA):
Sep 15 21:58:27.552: MGCP Packet sent to 10.10.210.11:2427--->
250 200 OK
P: PS=1160, OS=185600, PR=1154, OR=184640, PL=0, JI=6, LA=0

! -- E finalmente uma mensagem Q.931 de Release é enviada para a PSTN:
cmbh_rcv_callback: <-- Receiving backhaul msg for Se0/0/0:23 :
        | bk
SiteA-RTR#_msg_type = DATA_REQ
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 5
        | Q.931 message type: RELEASE
        | Q.931 message = 080200094D
Sep 15 21:58:27.568:
cmbrl_send_pak: --> Sending backhauled msg for Se0/0/0:23 :
        | bk_msg_type = DATA_IND
        | bk_chan_id (slot:port) = 0:0
        | Q.931 length = 5
        | Q.931 message type: RELEASE COMPLETE
        | Q.931 message = 080280095A

 Com isso, concluímos a análise de uma chamada sainte. Nos próximos posts veremos uma chamada entrante, e situações de failover, quando um call-agent fica fora no meio de uma chamada.

Nenhum comentário:

Postar um comentário