MGCP - Parte 4 (Troubleshooting 3 - Failover)

E finalmente vamos ver o último troubleshooting de MGCP. Dessa vez, falarei sobre uma situação de failover. Ou seja, o call-agent principal cai e o secundário assume no meio de uma chamada. Continuamos utilizando os dois debugs abaixo:

1. debug ccm-manager backhaul packets

2. debug mgcp packets

3. MGCP Failover

Então nesse cenário, temos uma chamada em andamento entre um IP Phone e a PSTN. O subscriber (10.10.210.11), que é o call-agent principal, fica down. E o publisher (10.10.210.10) assume.

! -- Após perceber que o Subscriber está fora, o gateway bloqueia os circuitos em idle e espera que as conexões ativas sejam encerradas.
Sep 15 21:59:27.524: MGCP Packet sent to 10.10.210.11:2427--->
RSIP 622536905 *@SiteA-RTR MGCP 0.1
RM: graceful
<---

! -- O call-agent backup assume e inicia um processo de restart, desbloqueando os canais ativos.
Sep 15 21:59:27.528: MGCP Packet sent to 10.10.210.10:2427--->
RSIP 622536907 *@SiteA-RTR MGCP 0.1
RM: restart
<---

! -- O Publisher agora envia mensagens do tipo AUEP (Audit End Point) para o gateway a fim de verificar os status dos canais da E1/T1. Ele manda um AUEP para cada canal. Para não ficar muita coisa, vou mostrar apenas ele pedindo as informações do Canal 1, 2 e 8 (onde temos uma chamada ativa):

! -- Canal 1. Nenhuma chamada ativa.
Sep 15 21:59:27.688: MGCP Packet received from 10.10.210.10:2427--->
AUEP 1 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
F: X, A, I
<---

Sep 15 21:59:27.692: MGCP Packet sent to 10.10.210.10:2427--->
200 1
I:
X: 0
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;
SiteA-RTR(confFXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---

! -- Canal 2. Nenhuma chamada ativa.
Sep 15 21:59:27.692: MGCP Packet received from 10.10.210.10:2427--->
AUEP 2 S0/SU0/DS1-0/2@SiteA-RTR MGCP 0.1
F: X, A, I
<---

Sep 15 21:59:27.692: MGCP Packet sent to 10.10.210.10:2427--->
200 2
I:
X: 0
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---

! -- Canal 8. Uma chamada ativa. Sabemos disso porque na resposta do gateway para o CUCM, ele preenche o campo I com o valor C, que é um identificador da chamada.
Sep 15 21:59:27.708: MGCP Packet received from 10.10.210.10:2427--->
AUEP 8 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
F: X, A, I
<---

Sep 15 21:59:27.712: MGCP Packet sent to 10.10.210.10:2427--->
200 8
I: C
X: 8
L: p:10-20, a:PCMU;PCMA;G.nX64, b:64, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-220, a:G.729;G.729a;G.729b, b:8, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-110, a:G.726-16;G.728, b:16, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-70, a:G.726-24, b:24, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:10-50, a:G.726-32, b:32, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-270, a:G.723.1-H;G.723;G.723.1a-H, b:6, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
L: p:30-330, a:G.723.1-L;G.723.1a-L, b:5, e:on, es-cci, gc:1, s:on, t:10, r:g, nt:IN;ATM;LOCAL, v:T;G;D;L;H;ATM;FXR
M: sendonly, recvonly, sendrecv, inactive, loopback, conttest, data, netwloop, netwtest
<---

! -- Como no exemplo temos uma T1, o Publisher vai checar todos os 23 canais, independente se ele está idle, block, active. Caso a gente esteja utilizando uma T1 fracionada, os canais não configurados no gateway serão retornados ao CUCM como Endpt Unknown (no exemplo, o canal 9 não está configurado):
Sep 15 21:59:27.712: MGCP Packet received from 10.10.210.10:2427--->
AUEP 9 S0/SU0/DS1-0/9@SiteA-RTR MGCP 0.1
F: X, A, I
<---

Sep 15 21:59:27.712: MGCP Packet sent to 10.10.210.10:2427--->
500 9 Endpt Unknown
<---

! -- Agora o CUCM sabe que tem uma chamada ativa na porta 8. Então ele vai pedir mais informações sobre essa conexão com a mensagem AUCX (audit conection), e o gateway vai passar o Call Identification Number (C) e o Connection Mode (M):
Sep 15 21:59:27.732: MGCP Packet received from 10.10.210.10:2427--->
AUCX 24 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
I: C
F: C, M
<---

Sep 15 21:59:27.732: MGCP Packet sent to 10.10.210.10:2427--->
200 24
C: D000000002520877000000F50000000a
M: sendrecv
<---

! -- CUCM envia um RQNT (request notification) porque a conexão notificou um ICMP Unreachable (R/iu). E o gateway envia um 200 OK.
Sep 15 21:59:27.772: MGCP Packet received from 10.10.210.10:2427--->
RQNT 25 S0/SU0/DS1-0/8@SiteA-RTR MGCP 0.1
X: 8
R: R/iu, FXR/t38
Q: process,loop
<---

Sep 15 21:59:27.772: MGCP Packet sent to 10.10.210.10:2427—>
200 25 OK
<—

! -- O CUCM confirma o status da chamada com a PSTN para ver se ela foi preservada. Essa verificação é feita via Q.931
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: STATUS ENQ
        | Q.931 message = 0802000A75
Sep 15 21:59:27.792:
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 = 12
        | Q.931 message type: STATUS
        | Q.931 message = 0802800A7D0802809E14010A

! -- A chamada foi preservada e continua ativa com o Publisher sendo o call-agent ativo.

E assim encerro os posts sobre MGCP! :)

MGCP - Parte 3 (Troubleshooting 2 - Chamada entrante)

Hoje vamos ver mais um troubleshooting de MGCP, continuando o post anterior. Lembrando que os dois debugs no gateway que estamos utilizando são:

1. debug ccm-manager backhaul packets

2. debug mgcp packets

2. Chamada entrante

Nesse cenário, um telefone da PSTN faz uma chamada para o IP Phone. Vamos ver o que acontece.

! -- Primeiramente, a PSTN envia um SETUP via método Q.931, que como podemos ver, é encaminhado para o CUCM. Novamente podemos pegar a informação contida em "message" e extrair o número de destino, removendo os "3" da string 32303235353532303032: 2025552002. No CUCM, o gateway MGCP está configurado para considerar os últimos 4 dígitos apenas.

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 = 43
        | Q.931 message type: SETUP
        | Q.931 message = 080200800504038090A21803A983811E0285836C09418034363738313234700BA132303235353532303032

! -- Recebendo essa solicitação, o CUCM envia uma mensagem ao Gateway solicitando a criação de uma nova conexão (CRCX).

Sep 15 22:23:36.920: MGCP Packet received from 10.10.210.11:2427--->
CRCX 230 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
X: 1
L: p:20, a:PCMU, s:off, t:00
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

! -- E o gateway responde com um 200 OK, enviando junto o SDP, com as informações de mídia (IP, porta para o RTP, Codec, etc)
Sep 15 22:23:36.936: MGCP Packet sent to 10.10.210.11:2427--->
200 230 OK
I: D

v=0
o=- 13 0 IN IP4 10.10.200.3
s=Cisco SDP 0
c=IN IP4 10.10.200.3
t=0 0
m=audio 18878 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
<---

! -- O CUCM agora faz a conexão com o IP Phone destino, e envia via Q.931 as sinalizações de CALL PROCEEDING e ALERTING para a PSTN.

bh_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 = 10
        | Q.931 message type: CALL PROCEEDING
        | Q.931 message = 08028080021803A98381
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 = 9
        | Q.931 message type: ALERTING
        | Q.931 message = 08028080011E028088

! -- Nesse momento, sabemos que o IP Phone está tocando, então o CUCM instrui o gateway através de um RQNT a tocar um ringback tone para a PSTN. A instrução S: G/rt que diz isso (rt = ringback tone). E o gateway responde com um 200 OK

Sep 15 22:23:36.944: MGCP Packet received from 10.10.210.11:2427--->
RQNT 231 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
X: 1
R: D/[0-9ABCD*#]
S: G/rt
Q: process,loop

Sep 15 22:23:36.948: MGCP Packet sent to 10.10.210.11:2427--->
200 231 OK

! -- Quando a PSTN atende, ela envia um CONNECT via Q.931, que é respondido com um CONNECT_ACK:

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 = 12
        | Q.931 message type: CONNECT
        | Q.931 message = 080280800728054851504832

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 ACK
        | Q.931 message = 080200800F

! -- O CUCM agora fala para o gateway MGCP as informações de mídia (SDP), enviando o IP do telefone, porta, codec, etc:

Sep 15 22:23:44.552: MGCP Packet received from 10.10.210.11:2427--->
MDCX 233 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I: D
X: 1
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=- 13 0 IN EPN S0/SU0/DS1-0/1@SiteA-RTR
s=Cisco SDP 0
t=0 0
m=audio 24686 RTP/AVP 0
c=IN IP4 192.168.14.12
a=X-sqn:0
a=X-cap:1 image udptl t38
<---

! -- Nesse momento, a chamda está ativa. Telefone e gateway trocam RTP.

! -- O IP Phone desconecta a chamada, e o CUCM instrui o gateway a parar de enviar RTP, que é respondido com um 200 OK:

Sep 15 22:23:55.832: MGCP Packet received from 10.10.210.11:2427--->
MDCX 234 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I: D
X: 1
M: recvonly
R: D/[0-9ABCD*#]
Q: process,loop
<---

Sep 15 22:23:55.836: MGCP Packet sent to 10.10.210.11:2427--->
200 234 OK
<---

! -- Agora, via Q.931, o CUCM manda um DISCONNECT para a PSTN, que é respondido com um RELEASE:

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 = 9
        | Q.931 message type: DISCONNECT
        | Q.931 message = 080280804508028290
Sep 15 22:23:55.852:
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
        | Q.931 message = 080200804D

! -- O CUCM informa o gateway que a conexão deve ser deletada (DLCX), e o gateway responde com um 250 OK, como falamos no post anterior:

Sep 15 22:23:55.852: MGCP Packet received from 10.10.210.11:2427--->
DLCX 235 S0/SU0/DS1-0/1@SiteA-RTR MGCP 0.1
C: D00000000252087e000000F580000080
I:
SiteA-RTR#D
X: 1
S:
<---

Sep 15 22:23:55.880: MGCP Packet sent to 10.10.210.11:2427--->
250 235 OK
P: PS=564, OS=90240, PR=560, OR=89600, PL=0, JI=7, LA=0
<---

! -- E finalmente, o CUCM responde o RELEASE com um RELEASE_COMPLETE:

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: RELEASE COMPLETE
        | Q.931 message = 080280805A

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.

MGCP - Parte 1 (Configuração)

Hoje vou falar um pouco sobre a configuração do MGCP. É um post relativamente simples para quem já está estudando para o CCIE. Mas o objetivo dele é fazer uma introdução, porque no próximo post falarei sobre o troubleshooting do MGCP, que aí sim é um tema um pouco mais complexo.

Muita gente prefere configurar o MGCP com o modo automático do "ccm-manager config". Com essa feature, o gateway baixa toda a sua configuração do CUCM via TFTP, e teoricamente, com 2 comandos você tem tudo up and running. Mas não é bem assim que as coisas são... vou falar sobre as desvantagens desse método logo mais.
Bom, basicamente para configurar o MGCP dessa forma, você precisa primeiro provisionar o gateway no CUCM. Informações como Domain Name, Switch Type, Channel Selection Order são importantes. Feito isso, basta executar os seguintes comandos no roteador:

ccm-manager config server <PUB> ! -- TFTP Server

ccm-manager config              ! -- Instrui o Gateway a baixar 

                                o arquivo <Hostname>.cnf.xml do CUCM

E pronto! Mas olha só que coisa... O comando colocou lá um monte de comando no seu roteador, mas alguns importantes não foram colocados, e você vai ter que se lembrar de fazer isso na mão. Esses comandos são:

network-clock-select 1 T1 0/0/0

mgcp bind control source <interface>

mgcp bind media source <interface>

ccm-manager switchback <immediate/graceful>

ccm-manager fallback-mgcp ! - Opcional. Só se o GW for SRST

mgcp dtmf-relay voip codec all mode out-of-band

E além disso, o comando sempre vai configurar a sua E1 ou T1 como full. Ou seja, ele sempre vai configurar a E1 com 30 canais e a T1 com 23. Se por algum motivo você quiser uma E1/T1 fracionada, você vai ter que ajustar isso na mão. E aí para alterar isso dá o maior trabalho... você tem que "shutar" a voice-port, depois a interface serial, depois remover o comando isdn bind-l3 ccm-manager, depois "shutar" a controller, e finalmente remover o pri-group e criar denovo. E aí adicionar o bind-l3 novamente na serial.

Por esses motivos, eu não acho uma boa ideia utilizar esse modo automatico de configuração. Sim, pode te salvar algum tempo, mas se você tiver os comandos do MGCP na veia (o que é esperado de um candidato a CCIE), você não vai levar mais do que 2 minutos para configurar tudo. E acaba sendo até mais rápido do que o modo automático, que você tem que ajustar um monte de coisa.

A configuração de MGCP que eu costumo fazer nos gateways é:

network-clock-participate wic 0

network-clock-select 1 T1 0/0/0

isdn switch-type primary-ni

controller t1 0/0/0

 pri-group timeslots 1-X service mgcp ! - X dependendo se for  

                                          fracionada ou não

interface serial 0/0/0:23

 isdn bind-l3 ccm-manager

 isdn outgoing display-ie

ccm-manager music-on-hold

ccm-manager redundant-host <PUB>

ccm-manager switchback immediate

ccm-manager fallback-mgcp

ccm-manager mgcp

mgcp call-agent <SUB>

mgcp dtmf voip codec all mode out

mgcp bind control source <interface> 

mgcp bind media source <interface>

mgcp ip qos dscp cs3 sig

mgcp

Se você ficar praticando isso, verá que é extremamente rápido de se configurar. O macete que eu uso para me lembrar de todos os comandos é saber que são 5 de ccm-manager e 6 de mgcp. Então quando eu termino a config (no notepad!), eu sempre conto antes de aplicar no gateway para ver se não está faltando nada.

No próximo post falarei sobre troubleshooting de MGCP, que é bem mais interessante...