Validation de la source RTP dans les routeurs vocaux IOS et IOS-XE
Contenu
Introduction
Ce document décrit le comportement de la fonction de validation de source RTP dans les routeurs vocaux Cisco IOS et IOS-XE pour différents flux d'appels et versions.
Conditions préalables
Conditions requises
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Logiciel IOS et IOS-XE
- H.323
- Session Initiation Protocol (SIP)
- MGCP (Media Gateway Control Protocol)
- SCCP (Skinny Call Control Protocol)
- Protocole de transport en temps réel (RTP)
Components Used
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
- Routeurs ISRG2 (ISR2900, ISR3900)
- Routeurs ISRG3 (ISR4400 et ISR4300)
- Routeurs ASR (ASR1001-X, ASR1002-X, ASR1004, ASR1006 et ASR1006-X avec RP2 et ESP40)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Il est important de comprendre les notions de base sur les réseaux VoIP et les protocoles de signalisation VoIP afin de pouvoir tirer pleinement parti de ce document.
Définition et utilisation de la validation de la source RTP
La validation de la source RTP est une fonctionnalité intégrée aux routeurs vocaux Cisco qui leur permet de supprimer les trafics RTP entrants non fiables.
L'objectif principal de cette fonctionnalité est d'avoir un niveau de sécurité plus élevé sur le périphérique et d'éviter les problèmes de CrossTalk sur les réseaux VoIP.
Il existe différentes versions de cette fonctionnalité dans les routeurs vocaux IOS et une seule option dans les routeurs vocaux IOS-XE.
Dans IOS et IOS-XE, cette fonctionnalité fait que les routeurs vocaux abandonnent le trafic RTP entrant à partir d'adresses IP ou de ports inconnus, en d'autres termes, les paquets reçus d'une adresse IP ou d'un port qui n'a pas été négocié par la signalisation, sont abandonnés par le routeur vocal.
La manière dont cette fonctionnalité fonctionne dans IOS et IOS-XE est un peu différente en raison de l'architecture des routeurs et de leur introduction dans le code ; Les sections suivantes expliquent ces scénarios.
Validation de la source RTP dans les routeurs vocaux IOS
IOS a deux saveurs différentes de cette fonctionnalité.
- Filtre source introduit dans 12.4(6)T
- Voice RTP Source-Filter introduit dans les versions 15.5(3)M9, 15.6(3)M6 et ultérieures
Filtre source
Cette fonctionnalité n'est disponible que pour les flux d'appels SIP.
Lorsqu'elle est configurée, si la signalisation utilisée dans le flux d'appels n'a pas négocié l'adresse IP et le port d'où provient le RTP, le routeur vocal rejette alors ces paquets.
La validation de la source vérifie l'adresse IP source, puis le port source.
Configuration
voice service voip sip source filter
Comportement et détection
Un bon exemple serait quand CUCM met un appel en attente et par défaut, CUCM annonce le port 4000 via la signalisation mais diffuse en fait le RTP à partir d'un port éphémère (32768-61000) puisque le paramètre de service Duplex Streaming activé sous Paramètres de cluster est désactivé par défaut.
Le débogage des messages CCSIP indique sur le routeur vocal un message SIP ACK reçu avec le protocole SDP (Session Description Protocol) qui indique au routeur que le protocole RTP provient de CUCM-IP-Address et du port 4000.
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:6002@Router-IP-Address:5060 SIP/2.0
Via: SIP/2.0/UDP CUCM-IP-Address:5060;branch=z9hG4bK4a424fed85
From: <sip:65002@CUCM-IP-Address>;tag=4091~842780d9-7186-4740-ada2-23e5d1b91316-46404063
To: <sip:6002@Router-IP-Address>;tag=2FF652-51D
Date: Thu, 18 Apr 2019 19:59:50 GMT
Call-ID: 3EDDD9E4-614B11E9-800D9C4B-C5465DB2@Router-IP-Address
User-Agent: Cisco-CUCM12.0
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Session-ID: 4978aa3900105000a000006cbcbcfda2;remote=836b14b48c77bfe681c0780c54ab4091
Content-Type: application/sdp
Content-Length: 191
v=0
o=CiscoSystemsCCM-SIP 4091 3 IN IP4 CUCM-IP-Address
s=SIP Call
c=IN IP4 CUCM-IP-Address (MoH Server)
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:0 PCMU/8000
a=sendonly
Show Call Active Voice Brief n'affiche pas les incréments RX sur le segment où RTP est attendu de CUCM-IP-Address et du port 4000. Le protocole RTP est reçu d’un port différent et abandonné par le routeur vocal.
11EC : 3 3143250ms.1 (14:59:02.516 CDT Thu Apr 18 2019) +1960 pid:0 Answer 6002 active dur 00:47:29 tx:2330/391440 rx:64875/10380000 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/0/0:23 (3) [0/0/0.23] tx:2803960/1263780/0ms g711ulaw noise:-65 acom:3 i/0:-60/-64 dBm 11EC : 4 3143250ms.2 (14:59:02.516 CDT Thu Apr 18 2019) +1950 pid:1 Originate 65002 connected dur 00:47:29 tx:1686/269760 rx:2330/372800 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP CUCM-IP-Address:4000 SRTP: off rtt:1ms pl:46150/0ms lost:0/0/0 delay:55/55/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00
Show VoIP RTP Connections montre le RmtRTP comme 4000 et RemoteIP comme CUCM-IP-Address.
Le routeur s’attend à ce que le protocole RTP provienne de cette même source.
show voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS
1 4 3 16386 4000 Router-IP-Address CUCM-IP-Address NO
Found 1 active RTP connections
Avec une capture de renifleur, il peut être vérifié d'où vient réellement le RTP, dans cet exemple il vient du port 24588 au lieu de 4000 donc la validation de la source échoue et le routeur vocal abandonne les paquets.
Filtre source RTP voix
Cette fonctionnalité a été introduite dans les versions 15.5(3)M9, 15.6(3)M6 IOS.
Il fonctionne de la même manière que le filtre source où il valide d'abord l'adresse IP source puis le port source mais présente deux différences majeures.
- Voice RTP Source-Filter fonctionne pour SIP, H.323, MGCP et SCCP
- La fonctionnalité a également ajouté un message d'erreur dans Debug VoIP RTP Error afin de détecter facilement quand le RTP est abandonné en raison d'un échec de validation de la source
Configuration
Configuration Terminal voice rtp source-filter
Comportement et détection par protocole
Pour H.323 :
Le débogage H225 Asn1 sur les routeurs vocaux montre un openLogicalChannelAck reçu qui informe le routeur de l'adresse de support distant 0.0.0.0:0.
H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 1
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
mediaChannel unicastAddress : iPAddress :
{
network 'Router-IP-Address'H
tsapIdentifier 16404 (Router's UDP Port for the RTP)
}
mediaControlChannel unicastAddress : iPAddress :
{
network 'Router-IP-Address'H
tsapIdentifier 16405 (Router's UDP Port for the RTCP)
}
flowControlToZero FALSE
}
}
Received openLogicalChannelAck has network and tsapIdentifier for the mediaChannel in zeros which means IP Address 0.0.0.0 and port 0.
H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 2
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
sessionID 1
mediaChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 0
}
mediaControlChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 1
}
}
}
Show Call Active Voice Brief n'affiche pas les incréments RX et l'adresse IP distante et le port sont définis sur 0.0.0.0:0.
11F5 : 21 18903090ms.1 (16:00:48.794 CDT Fri Apr 19 2019) +1070 pid:2 Answer 6002 active dur 00:00:43 tx:376/63168 rx:899/137074 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/0:23 (21) [0/1/0.1] tx:35340/14230/0ms g711ulaw noise:-68 acom:3 i/0:-64/-63 dBm 11F5 : 22 18903090ms.2 (16:00:48.794 CDT Fri Apr 19 2019) +1070 pid:1 Originate 36004 active dur 00:00:43 tx:152/23047 rx:376/60160 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/65/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 LocalUUID: RemoteUUID: VRF:
Show VoIP RTP Connections affiche le RmtRTP et le RemoteIP 0.0.0.0:0 de sorte que le routeur attend le RTP de cette source.
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 22 21 16404 0 Router-IP-Address 0.0.0.0 NO NA
Found 1 active RTP connections
Avec une capture de renifleur, il est possible de vérifier où le RTP est reçu. Dans cet exemple, il est reçu du port 24608 et de l'adresse IP CUCM au lieu du port 0 et de l'adresse IP 0.0.0.
Debug VoIP RTP Error indique la raison pour laquelle ces paquets abandonnés ont été reçus de CUCM-IP-Address au lieu de 0.0.0.0, de sorte qu'il échoue la validation de la source.
voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address
Pour SIP :
Debug CCSIP Messages affiche sur le routeur vocal un message SIP ACK reçu avec SDP qui indique au routeur d'attendre RTP de l'adresse IP CUCM et du port 4000.
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:6002@Router-IP-Address:5060 SIP/2.0
Via: SIP/2.0/UDP CUCM-IP-Address:5060;branch=z9hG4bK16712e94eda
From: <sip:65002@CUCM-IP-Address>;tag=5931~842780d9-7186-4740-ada2-23e5d1b91316-46404140
To: <sip:6002@10.201.160.54>;tag=FE677E-E12
Date: Fri, 19 Apr 2019 23:53:48 GMT
Call-ID: 32798F13-623511E9-805BC9D5-801BF5C7@Router-IP-Address
User-Agent: Cisco-CUCM12.0
Max-Forwards: 70
CSeq: 102 ACK
Allow-Events: presence
Session-ID: 5fdd1bc300105000a000006cbcbcfda2;remote=761410b40eed518a94bd5f7bbccfbe40
Content-Type: application/sdp
Content-Length: 191
v=0
o=CiscoSystemsCCM-SIP 5931 3 IN IP4 CUCM-IP-Address
s=SIP Call
c=IN IP4 CUCM-IP-Address (MoH Server)
t=0 0
m=audio 4000 RTP/AVP 0
a=X-cisco-media:umoh
a=ptime:20
a=rtpmap:0 PCMU/8000
a=sendonly
Show Call Active Voice Brief n'affiche pas les incréments RX sur le segment qui attend que RTP soit reçu de CUCM-IP-Address:4000.
Puisque le RTP vient en fait d'un autre port, il est abandonné.
11F0 : 29 16672630ms.1 (18:53:43.109 CDT Fri Apr 19 2019) +1450 pid:0 Answer 6002 active dur 00:00:07 tx:169/28392 rx:265/42400 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/0/0:23 (29) [0/0/0.23] tx:4020/4020/0ms g711ulaw noise:-74 acom:3 i/0:-64/-64 dBm 11F0 : 30 16672630ms.2 (18:53:43.109 CDT Fri Apr 19 2019) +1450 pid:1 Originate 65002 connected dur 00:00:07 tx:64/10240 rx:169/27040 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP CUCM-IP-Address:4000 SRTP: off rtt:0ms pl:3200/0ms lost:0/0/0 delay:0/55/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 LocalUUID:5fdd1bc300105000a000006cbcbcfda2 RemoteUUID:761410b40eed518a94bd5f7bbccfbe40 VRF: NA
Show VoIP RTP Connections affiche les RmtRTP et RemoteIP en tant que CUCM-IP-Address:4000, le routeur attend que le RTP provienne de cette source.
show voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 30 29 16430 4000 Router-IP-Address CUCM-IP-Address NO NA
Found 1 active RTP connections
Avec une capture de renifleur, il peut être vérifié d'où vient réellement le RTP, dans cet exemple, il vient du port 24634 et CUCM-IP-Address au lieu de CUCM-IP-Address:4000.
Debug VoIP RTP Error indique la raison pour laquelle ces paquets abandonnés ont été reçus du port 24634 au lieu du port 4000, de sorte qu'il échoue la validation de la source.
voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634 voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634 voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634 voip_rtp_recv_fs_input:ERROR Port validation failed, dropping RTP packet. Expected port: 4000, Received port: 24634
Pour MGCP :
Déboguer les paquets MGCP indique quand l'appel a initialement négocié le support, puis quand il est mis en attente.
When the call initially connects, it negotiates the media capabilities through SDP.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1324 S0/SU1/DS1-1/23@3945-A.luirami2.lab MGCP 0.1 C: D000000002c4139b000000F500000008 I: 10 X: 17 L: p:20, a:PCMU, s:off, t:b8 M: sendrecv R: D/[0-9ABCD*#] S: Q: process,loop v=0 o=- 16 0 IN EPN S0/SU1/DS1-1/23@3945-A.luirami2.lab s=Cisco SDP 0 t=0 0 m=audio 23248 RTP/AVP 0 c=IN IP4 IP-Phone-IP-Address <--- MGCP Packet sent to CUCM-IP-Address:2427---> 200 1324 OK <---
Then when it is placed on hold, CUCM only changes the direction of the media.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1325 S0/SU1/DS1-1/23@3945-A.luirami2.lab MGCP 0.1 C: D000000002c4139b000000F500000008 I: 10 X: 17 M: recvonly R: D/[0-9ABCD*#] Q: process,loop <--- MGCP Packet sent to CUCM-IP-Address:2427---> 200 1325 OK <---
Show Call Active Voice Brief n'affiche pas les incréments RX sur le segment qui attend que RTP provienne de IP-Phone-IP-Address:23248.
Puisque le protocole RTP provient d’une autre adresse IP, il est abandonné.
11FD : 38 31140580ms.1 (19:24:46.254 CDT Fri Apr 19 2019) +0 pid:0 Originate connecting dur 00:00:36 tx:289/46240 rx:272/43520 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP IP-Phone-IP-Address:23248 SRTP: off rtt:1ms pl:5440/70ms lost:0/0/0 delay:0/55/65ms g711ulaw TextRelay: off Transcoded: No ICE: Off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00 LocalUUID: RemoteUUID: VRF: 11FD : 37 31140580ms.2 (19:24:46.252 CDT Fri Apr 19 2019) +0 pid:0 Originate active dur 00:00:36 tx:272/45696 rx:1832/293120 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/1:23 (37) [0/1/1.23] tx:36630/36630/0ms g711ulaw noise:-68 acom:6 i/0:-65/-60 dBm
Show VoIP RTP Connections affiche les RmtRTP et RemoteIP en tant qu'adresse IP-Téléphone :23248, le routeur s'attend à ce que le RTP provienne de cette source.
show voip rtp connections
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 1
Port range not configured
Min Max Ports Ports Ports
Media-Address Range Port Port Available Reserved In-use
------------------------------------------------------------------------------
Global Media Pool 16384 32766 8091 101 1
------------------------------------------------------------------------------
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP MPSS VRF
1 38 37 16420 23248 Router-IP-Address IP-Phone-IP-Address NO NA
Found 1 active RTP connections
Avec une capture de renifleur, il peut être vérifié d'où vient réellement le RTP, dans cet exemple, il vient du port 24612 et CUCM-IP-Address au lieu de IP-Phone-IP-Address:23248.
Debug VoIP RTP Error indique la raison pour laquelle ces paquets abandonnés ont été reçus de CUCM-IP-Address au lieu de IP-Phone-IP-Address, de sorte qu'il échoue la validation de la source.
voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: IP-Phone-IP-Address, Received addr: CUCM-IP-Address
Pour SCCP :
Messages SCCP de débogage indique quand l'appel est mis en attente.
CUCM demande d'abord au routeur vocal de basculer vers un support inactif avec un CloseReceiveChannel et un StopMediaTransmission.
SCCP:rcvd CloseReceiveChannel CloseReceiveChannelMsg Info: conference_id = 33554439, pass_through_party_id = 33554541, call_ref = 46404215, port_handling = 0 SCCP:rcvd StopMediaTransmission StopMediaTransmissionMsg Info: conference_id = 33554439, pass_through_party_id = 33554541, call_ref = 46404215, port_handling = 0
Ensuite, CUCM demande au routeur vocal de basculer vers Récupérer uniquement avec un OpenReceiveChannel.
SCCP:rcvd OpenReceiveChannel OpenReceiveChannelMsg Info: conference_id = 33554439, pass_through_party_id = 33554542 msec_pkt_size = 20, compression_type = 4 qualifier_in.ecvalue = 0, g723_bitrate = 0, call_ref = 46404215 stream_pass_through_id = 16777216, rfc2833_payload_type = 0 codec_dynamic_payload = 0, codec_mode = 0 Encryption Info :: algorithm_id 0, key_len 0, salt_len 0 requestedAddrType = 0, source_ip_addr.ipAddrType = 0, source_ip_addr = CUCM-IP-Address, source_port_number = 4000, audio_level_adjustment = 0 SCCP:send OpenReceiveChannelAck OpenReceiveChannelAck Info: pass_through_party_id=33554542, status=0(ok), host_ip_addr= Router-IP-Address, port=16390
Show SCCP Connections affiche le ripaddr et les rapports 0.0.0.0:0; le routeur attend que le RTP provienne de cette source.
show sccp connections sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx 33554439 33554542 mtp recvonly g711u 16390 0 0.0.0.0 33554439 33554540 mtp sendrecv g711u 16386 16384 10.201.160.54 Total number of active session(s) 1, and connection(s) 2
Debug VoIP RTP Error indique la raison pour laquelle ces paquets abandonnés ont été reçus de CUCM-IP-Address au lieu de 0.0.0.0, de sorte qu'il échoue la validation de la source.
000147: Apr 24 11:49:22.499: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address 000148: Apr 24 11:49:22.519: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address 000149: Apr 24 11:49:22.539: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address 000150: Apr 24 11:49:22.559: voip_rtp_recv_fs_input:ERROR IP address validation failed, dropping packet. Expected addr: 0.0.0.0, Received addr: CUCM-IP-Address
Validation de la source RTP sur les routeurs vocaux IOS-XE
Les éléments les plus importants à souligner dans IOS-XE sont les suivants :
- Il n'est pas configurable
- Il est activé par défaut
- Impossible de désactiver
- La direction du support dans la signalisation VoIP est la seule exception qui permet au RTP de circuler à partir d'une source inconnue
Comportement et détection par protocole
Pour H.323 :
Avec ce protocole, le protocole RTP de la musique d'attente ne fonctionne pas car CUCM envoie toujours le message openLogicalChannelAck avec l'adresse IP et le port définis sur zéro, ce qui désactive le support.
H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= response : openLogicalChannelAck :
{
forwardLogicalChannelNumber 6
forwardMultiplexAckParameters h2250LogicalChannelAckParameters :
{
sessionID 1
mediaChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 0
}
mediaControlChannel unicastAddress : iPAddress :
{
network '00000000'H
tsapIdentifier 1
La même chose peut être vérifiée avec Show Call Active Voice Brief afin de vérifier comment la valeur d'incréments RX s'arrête et l'adresse du support distant est IP 0.0.0.0:0.
11F3 : 17 8703830ms.1 (13:00:22.060 CDT Tue Apr 23 2019) +2150 pid:2 Answer 6002 active dur 00:15:22 tx:19014/9213600 rx:1/3836010 dscp:0 media:0 audio tos:0x0 video tos:0x0 Tele 0/1/1:23 (17) [0/1/1.23] tx:158740/106870/0ms g711ulaw noise:-68 acom:22 i/0:-57/-61 dBm 11F3 : 18 8703830ms.2 (13:00:22.060 CDT Tue Apr 23 2019) +2150 pid:1 Originate 55002 active dur 00:15:22 tx:19709/3836010 rx:46068/9213600 dscp:0 media:0 audio tos:0xB8 video tos:0x0 IP 0.0.0.0:0 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711ulaw TextRelay: off Transcoded: No ICE: Off media inactive detected:n media contrl rcvd:n/a timestamp:n/a long duration call detected:n long duration call duration:n/a timestamp:n/a LostPacketRate:0.00 OutOfOrderRate:0.00
L'entrée FPI Voip de débogage n'affiche pas l'indicateur NAT (Network Address Translation) activé ici lorsque le support a été désactivé avec l'openLogicalChannelAck, le support désactivé peut être vérifié avec le message side:SIDE_A, rtp_type:0:.
//18/7F507F32800A/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:0: send:0 recv:0 //18/7F507F32800A/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: destAddr == 0, rcv and send both set to FALSE
show platform hardware qfp active feature sbc global | s Nombre total de paquets abandonnés|Paquets abandonnés : présente une table avec tous les paquets abandonnés où le flux d'entrée reçoit des incréments désactivés lorsque l'appel est en attente.
show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: Total packets dropped = 138512 Dropped packets: No associated flow = 0 Wrong source for flow = 0 Ingress flow receive disabled = 138512 Egress flow send disabled = 0 Not conforming to flowspec = 0
Pour SIP
Lorsque SIP est utilisé, CUCM envoie dans le SDP l'adresse IP CUCM, le port 4000 et l'attribut media pour la direction sous a=sendonly qui indique au routeur de recevoir RTP uniquement.
v=0 o=CiscoSystemsCCM-SIP 72019 3 IN IP4 CUCM-IP-Address s=SIP Call c=IN IP4 CUCM-IP-Address (MoH Server) t=0 0 m=audio 4000 RTP/AVP 0 a=X-cisco-media:umoh a=ptime:20 a=rtpmap:0 PCMU/8000 a=sendonly
La a=sendonly définit la direction du support sur recvonly pour la perspective du routeur vocal, ce qui déclenche la fonction NAT flag qui permet toujours au RTP de passer par même s'il provient d'une source différente.
Ceci peut être vérifié avec Debug VoIP FPI Inout.
//25/3EAF69800000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:2:RECVONLY send:0 recv:2 //25/3EAF69800000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: recvonly mode - setting NAT flag
Si un attribut différent pour la direction du support est envoyé au routeur vocal lorsque cela se produit, la fonction NAT flag ne sera pas activée et les paquets seront abandonnés parce qu'ils proviennent d'une autre source.
Les messages CCSIP de débogage s'affichent dans cet exemple a=sendrecv.
v=0 o=CiscoSystemsCCM-SIP 72019 3 IN IP4 CUCM-IP-Address s=SIP Call c=IN IP4 CUCM-IP-Address (MoH Server) t=0 0 m=audio 4000 RTP/AVP 0 a=X-cisco-media:umoh a=ptime:20 a=rtpmap:0 PCMU/8000 a=sendrecv
Debug VoIP FPI Inout affiche la direction du support définie sur rtp_type:3:SENDRECV et aucune fonction NAT.
//27/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
Comme il n'y a pas d'indicateur NAT, la commande show platform hardware qfp active feature sbc global | s Nombre total de paquets abandonnés|Paquets abandonnés : affiche les incréments dans la mauvaise source pour la section flux.
4351-A#show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: Total packets dropped = 33496 Dropped packets: No associated flow = 0 Wrong source for flow = 33196 Ingress flow receive disabled = 0 Egress flow send disabled = 0 Not conforming to flowspec = 0
Pour MGCP :
Lorsque le protocole MGCP est utilisé, CUCM envoie un MDCX afin de modifier la direction du support déjà négociée lorsque l'appel est connecté à l'origine, de sorte qu'aucune modification de l'adresse IP ou de la signalisation n'est apportée, mais après le MDCX, le RTP est maintenant diffusé à partir d'une autre source.
Depuis M : recvonly est envoyé au routeur vocal, la fonction NAT flag est activée.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1529 S0/SU1/DS1-1/23@4351-A.luirami2.lab MGCP 0.1 C: D000000002c4151d000000F50000000a I: B X: 17 M: recvonly R: D/[0-9ABCD*#] Q: process,loop <---
Debug VoIP FPI Inout affiche la direction du support définie sur rtp_type:2:RECVONLY et la fonction NAT, ce qui permet au RTP de passer.
//30/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:2:RECVONLY send:0 recv:2 //30/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: recvonly mode - setting NAT flag
Si un attribut différent pour la direction du support est envoyé au routeur vocal lorsque cela se produit, la fonction NAT flag ne sera pas activée et les paquets seront abandonnés parce qu'ils proviennent d'une autre source.
Le débogage des paquets MGCP montre dans cet exemple M : sendrecv.
MGCP Packet received from CUCM-IP-Address:2427---> MDCX 1530 S0/SU1/DS1-1/23@4351-A.luirami2.lab MGCP 0.1 C: D000000002c4151d000000F50000000a I: B X: 17
M: sendrecv R: D/[0-9ABCD*#] Q: process,loop <---
Debug VoIP FPI Inout affiche la direction du support définie sur rtp_type:3:SENDRECV et aucune fonction NAT.
//29/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2
Comme il n'y a pas d'indicateur NAT, la commande show platform hardware qfp active feature sbc global | s Nombre total de paquets abandonnés|Paquets abandonnés : affiche les incréments dans la mauvaise source pour la section flux.
show platform hardware qfp active feature sbc global | s Total packets dropped|Dropped packets: Total packets dropped = 33596 Dropped packets: No associated flow = 0 Wrong source for flow = 33296 Ingress flow receive disabled = 0 Egress flow send disabled = 0 Not conforming to flowspec = 0
Pour SCCP :
Messages SCCP de débogage indique quand l'appel est mis en attente.
CUCM demande d'abord au routeur vocal de basculer vers un support inactif avec un CloseReceiveChannel et un StopMediaTransmission.
SCCP:rcvd CloseReceiveChannel
CloseReceiveChannelMsg Info:
conference_id = 33554436, pass_through_party_id = 33554500, call_ref = 46405010, port_handling = 0
SCCP:rcvd StopMediaTransmission
StopMediaTransmissionMsg Info:
conference_id = 33554436, pass_through_party_id = 33554500, call_ref = 46405010, port_handling = 0
Ensuite, CUCM demande au routeur vocal de basculer vers la récupération uniquement avec un OpenReceiveChannel.
SCCP:rcvd OpenReceiveChannel
OpenReceiveChannelMsg Info:
conference_id = 33554436, pass_through_party_id = 33554501
msec_pkt_size = 20, compression_type = 4
qualifier_in.ecvalue = 0, g723_bitrate = 0, call_ref = 46405010
stream_pass_through_id = 16777216, rfc2833_payload_type = 0
codec_dynamic_payload = 0, codec_mode = 0
Encryption Info :: algorithm_id 0, key_len 0, salt_len 0
requestedAddrType = 0, source_ip_addr.ipAddrType = 0, source_ip_addr = CUCM-IP-Address, source_port_number = 4000,
audio_level_adjustment = 0
SCCP:send OpenReceiveChannelAck
OpenReceiveChannelAck Info:
pass_through_party_id=33554501, status=0(ok), host_ip_addr= Router-IP-Address, port=8028
Show SCCP Connections affiche le ripaddr et les rapports 0.0.0.0:0; le routeur attend que le RTP provienne de cette source.
show sccp connections sess_id conn_id stype mode codec sport rport ripaddr conn_id_tx 33554436 33554501 mtp recvonly g711u 8028 0 0.0.0.0 33554436 33554499 mtp sendrecv g711u 8022 8024 Router-IP-Address Total number of active session(s) 1, and connection(s) 2
Debug VoIP FPI Inout affiche la direction du support définie sur rtp_type:2:RECVONLY et la fonction NAT, ce qui permet au RTP de passer.
//18/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:1:SENDONLY send:1 recv:0
//15/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_B, rtp_type:3:SENDRECV send:1 recv:2
//19/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:2:RECVONLY send:0 recv:2
//19/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: recvonly mode - setting NAT flag
//15/xxxxxxxxxxxx/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_B, rtp_type:3:SENDRECV send:1 recv:2
Si la direction du média est définie sur sendonly ou sendrecv et que le RTP provient d'une source différente, alors aucun indicateur NAT n'est activé et la show platform hardware qfp active feature sbc global | s Nombre total de paquets abandonnés|Paquets abandonnés : affiche les paquets abandonnés.
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)