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