Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Définition et utilisation de la validation de la source RTP

Validation de la source RTP dans les routeurs vocaux IOS

Filtre source

Configuration

Comportement et détection

Filtre source RTP voix

Configuration

Comportement et détection par protocole

Validation de la source RTP sur les routeurs vocaux IOS-XE

Comportement et détection par protocole

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

Attention : sachez que les scénarios décrits dans les sections suivantes sont liés à la musique d'attente de Cisco Unified Communications Manager (CUCM), mais que dans d'autres situations, le même comportement déclenche la suppression de la fonctionnalité RTP tant que les conditions requises sont remplies.

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.

1. Voice RTP Source-Filter fonctionne pour SIP, H.323, MGCP et SCCP

2. 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

Attention : Cette fonctionnalité est activée par défaut et n'apparaît pas dans la configuration. Les mises à niveau vers toute version IOS prenant en charge cette fonctionnalité peuvent entraîner des problèmes audio si des périphériques envoient RTP depuis une source différente de celle annoncée par signalisation.

Lorsque la fonction est désactivée par avec un No devant la commande, elle apparaît dans la configuration.

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 :

1. Il n'est pas configurable

2. Il est activé par défaut

3. Impossible de désactiver

4. 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

Avertissement : RX et TX ne s'incrémentent pas dans les plates-formes IOS-XE à moins que la commande Media Bulk-Stats soit configurée sous Voice Service VoIP, mais sachez que cette commande peut affecter les performances du routeur. Il est donc recommandé de l'activer uniquement lors du dépannage et de la désactiver ultérieurement.

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

Conseil : les messages OpenReceiveChannel sont utilisés pour demander au routeur vocal de recevoir RTP et le routeur vocal indique à CUCM sur l'OpenReceiveChannelAck où il souhaite recevoir ce support.

Le message StartMediaTransmission est utilisé pour indiquer au routeur vocal d'envoyer RTP à la destination spécifiée.

En d'autres termes, si seul OpenReceiveChannel est échangé est un moyen de dire à la ressource média qu'elle ne reçoit que RTP (recvonly) et si seulement StartMediaTransmission est échangé, c'est un moyen de dire à la ressource média qu'elle envoie seulement RTP (sendonly), mais si les deux sont échangé il est égal à .

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.

Astuce : S'il est nécessaire d'autoriser RTP provenant d'une adresse différente de celle négociée via la signalisation et recvonly ne peut pas être utilisé, nat force-on sous Voix Service, Sip peut être utilisé pour ajouter une attente manuelle. Cela ne fonctionnait pas correctement auparavant, mais a été corrigé sur un défaut CSCvo15141 . Gardez à l'esprit que cela ne fonctionne que pour SIP.

Avertissement : si pass-thru content sdp sous voice service voip, sip est configuré, cela ne permet pas à la couche FPI d'activer la fonction NAT Flag lors de la réception de recvonly.

Astuce : Dans certaines situations où NAT Flag est actif pour un appel et que l'audio fonctionne correctement, la valeur des paquets abandonnés sous show platform hardware qfp active feature sbc global | s Nombre total de paquets abandonnés|Paquets abandonnés : peut encore augmenter à un taux beaucoup plus faible, car dans certaines situations et flux d'appels, le protocole RTCP (Real Time Control Protocol) peut encore être envoyé au routeur vocal et à partir d'une source différente, ce qui provoquerait ce comportement.