terça-feira, 25 de setembro de 2012

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! :)

Nenhum comentário:

Postar um comentário