Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Achtergrondinformatie

RTP-bronvalidatie - definitie en toepassingen

RTP-bronvalidatie in IOS-spraakrouters

Bronfilter

Configuratie

Gedrag en detectie

Voice RTP-bronfilter

Configuratie

Gedrag en detectie per protocol

RTP-bronvalidatie op IOS-XE spraakrouters

Gedrag en detectie per protocol

Inleiding

Dit document beschrijft het gedrag van RTP BronBevalidering van de eigenschap in Cisco IOS en IOS-XE Spraakrouters voor verschillende telefoonstromen en versies.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

- IOS en IOS-XE-software

- H,323

- Session Initiation Protocol (SIP)

- Media Gateway Control Protocol (MGCP)

- Sony Call Control Protocol (SCCP)

- Real-time Transport Protocol (RTP)

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

- ISR2900-routers (ISR2900, ISR3900)

- ISR4400-routers (ISR4400 en ISR4300)

- ASR-routers (ASR 1001-X, ASR 1002-X, ASR 1004, ASR 1006 en ASR 1006-X met RP2 en ESP40)

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Achtergrondinformatie

Het is belangrijk om basisbeginselen van VoIP-netwerken en VoIP-signaleringsprotocollen te begrijpen om optimaal gebruik te kunnen maken van dit document.

RTP-bronvalidatie - definitie en toepassingen

RTP-bronvalidatie is een functie die in Cisco-spraakrouters is geïntegreerd waarmee ze onbetrouwbare ingebonden RTP-verkeer kunnen laten vallen.

Het belangrijkste doel van deze optie is om een hoger veiligheidsniveau op het apparaat te hebben en ook om kwesties van CrossTalk op VoIP Networks te vermijden.

Er zijn verschillende kleuren van deze optie in IOS de routers van de spraak en één enkele optie in IOS-XE spraakrouters.

In IOS en IOS-XE, maakt deze optie de routers van de spraak binnenkomend RTP verkeer van onbekende IP adressen of poorten laat vallen, in andere woorden pakketten die van een IP-adres of -poort worden ontvangen die niet door signalering zijn onderhandeld, worden door de Voice Router gedropt.

De manier waarop deze optie in IOS en IOS-XE werkt is een beetje anders door de architectuur van de routers en toen ze in de code werden geïntroduceerd. In de volgende paragrafen worden deze scenario's toegelicht.

RTP-bronvalidatie in IOS-spraakrouters

IOS heeft twee verschillende eigenschappen van deze functie.

- Bron filter, geïntroduceerd in 12.4(6)T

- Voice RTP-bronfilter, dat werd geïntroduceerd in 15.5(3)M9, 15.6(3)M6 en laatste versies

Voorzichtig: Let op dat de scenario's die in de volgende secties worden besproken zijn met Cisco Unified Communications Manager (CUCM) Muziek op Hold (MoH), maar er zijn andere situaties waar het zelfde gedrag de eigenschap om de RTP te laten vallen teweegbrengt zolang aan de vereisten wordt voldaan.

Bronfilter

Deze optie is alleen beschikbaar voor SIP-gespreksstromen.

Als geconfigureerd, als het signaleren in de Call Flow niet onderhandelt over het IP-adres en de poort waar RTP vandaan komt, wordt de Voice Router die pakketten verworpen.

De bron validatie controleert Bron IP Adres en dan BronPort.

Configuratie

voice service voip

sip

source filter

Gedrag en detectie

Een goed voorbeeld zou zijn wanneer CUCM een vraag op Hold and Standaard CUCM-advertenties poort 4000 aanzet door signalering, maar de RTP daadwerkelijk stroomt vanaf een vluchtige poort (32768-61000) aangezien de Service Parameter Streaming Enabled onder Clusterwide parameters standaard uitgeschakeld is .

Debug CCSIP-berichten laten op de spraakrouter een SIP ACK-bericht zien dat wordt ontvangen met Session Description Protocol (SDP) dat de router waarop RTP is gebaseerd, afkomstig is van CUCM-IP-adres en poort 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

Toon Call Active Voice Brief toont geen RX stappen op het been waar RTP van CUCM-IP-Address en Port 4000. RTP van een andere poort wordt ontvangen en door de Spraakrouter is gevallen.

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

Aansluitingen VoIP RTP tonen toont de RmtRTP als 4000 en RemoteIP als CUCM-IP-adres.

De router verwacht dat de RTP uit die zelfde bron komt.

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

Met een snuffelopname kan worden geverifieerd waar de RTP feitelijk vandaan komt, in dit voorbeeld komt de RTP uit poort 24588 in plaats van 4000 zodat de bronvalidatie mislukt en de Voice Router de pakketten neerzet.

Voice RTP-bronfilter

Deze optie is geïntroduceerd in 15.5(3)M9, 15.6(3)M6 IOS-versies.

Het werkt de zelfde manier als BronFilter waar het eerst het BronIP Adres en dan de Bronpoort bevestigt maar twee belangrijke verschillen heeft.

1. Voice RTP-bronfilter voor SIP, H.323, MGCP en SCCP

2. De optie heeft ook een foutbericht toegevoegd in debug VoIP RTP-fout om snel te kunnen detecteren wanneer RTP wordt gevallen vanwege een bron-validatie-storing

Voorzichtig: Deze optie wordt standaard ingeschakeld en verschijnt niet in de configuratie. Uploads naar elke IOS-release die deze functie ondersteunt, kunnen leiden tot audio-problemen als er apparaten zijn die RTP vanuit een andere bron verzenden dan degene die via signalering wordt geadverteerd.

Wanneer deze functie is uitgeschakeld met een Nee voor de opdracht, dan wordt deze weergegeven in de configuratie.

Configuratie

Configuration Terminal

voice rtp source-filter

Gedrag en detectie per protocol

Voor H.323:

Debug H225 ASN1 op spraakrouters toont een openLogicalChannelAck die de router informeert over het adres van de externe media 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

}

}

}

Het tonen van de actieve Keer van de Vraag toont geen RX stappen en het Remote IP adres en de poort worden ingesteld op 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:

Aansluitingen VoIP RTP tonen toont de RmtRTP en RemoteIP als 0.0.0:0 zodat de router de RTP van die bron verwacht.

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

Met een snuffelbedekking kan worden geverifieerd waar de RTP is ontvangen. In dit voorbeeld wordt het ontvangen van poort 24608 en CUCM-IP-Address in plaats van Port 0 en IP Address 0.0.0.

Debug VoIP RTP-fout toont de reden voor die geworpen pakketten zoals ontvangen van CUCM-IP-Address in plaats van 0.0.0, zodat de bronvalidatie faalt.

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

Voor SIP:

Debug CCSIP-berichten tonen op de spraakrouter een SIP ACK-bericht dat met SDP is ontvangen. In dit bericht wordt de router opgedragen om RTP te verwachten van CUCM-IP-adres en poort 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

De tonen van de Actieve Keuze van de Vraag toont geen RX stappen op het been dat RTP verwacht van CUCM-IP-Adres:4000 te ontvangen te zijn.

Aangezien de RTP eigenlijk uit een andere haven komt, wordt het gedropt.

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

Aansluitingen VoIP RTP tonen toont de RmtRTP en RemoteIP als CUCM-IP-Address:4000, verwacht de router dat de RTP uit die bron komt.

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

Met een snuffelopname kan worden geverifieerd waar de RTP feitelijk vandaan komt, in dit voorbeeld komt de RTP uit poort 24634 en CUCM-IP-Address in plaats van CUCM-IP-Address:4000.

Debug VoIP RTP-fout toont de reden voor die geworpen pakketten zoals ontvangen vanuit Port 24634 in plaats van Port 4000, dus heeft deze de bronvalidatie niet voltooid.

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

Voor MGCP:

Debug MGCP Packets toont wanneer de aanvankelijk onderhandelde vraag media, en dan wanneer het op zijn plaats is.

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

<---

De tonen van de Actieve Keuze van de Vraag toont geen RX toename op het been dat RTP van IP-telefoon-IP-adres:23248 verwacht.

Aangezien de RTP daadwerkelijk van een ander IP Adres komt, wordt het ingetrokken.

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

Aansluitingen VoIP RTP tonen toont de RmtRTP en RemoteIP als IP-telefoon-IP-adres:23248, verwacht de router dat de RTP uit die bron komt.

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

Met een snuffelopname kan worden geverifieerd waar de RTP feitelijk vandaan komt, in dit voorbeeld komt de RTP uit poort 24612 en CUCM-IP-Address in plaats van IP-telefoon-IP-Address:23248.

Debug VoIP RTP-fout toont de reden voor die geworpen pakketten zoals ontvangen van CUCM-IP-Address in plaats van IP-telefoon-IP-Address, zodat de bronvalidatie faalt.

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

Voor SCCP:

Debug SCCP Berichten tonen wanneer de oproep op zijn plaats is.

CUCM instrueert u de Voice Router om inactief over te schakelen op media met een Closeontvangkanaal en een 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

Dan verzoekt CUCM de router van de Stem om te schakelen om slechts te ontvangen met een OpenGetChannel.

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

Aansluitingen met SCCP tonen toont het profiel en de rapporten 0.0.0:0; de router verwacht dat de RTP uit die bron komt.

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-fout toont de reden voor die geworpen pakketten zoals ontvangen van CUCM-IP-Address in plaats van 0.0.0, zodat de bronvalidatie faalt.

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

RTP-bronvalidatie op IOS-XE spraakrouters

De belangrijkste dingen om er in IOS-XE op te wijzen zijn.

1. Dit is niet configureerbaar

2. Deze is standaard ingeschakeld

3. Kan niet worden uitgeschakeld

4. De media-richting in de VoIP-signalering is de enige uitzondering waardoor RTP vanuit een onbekende bron kan stromen

Gedrag en detectie per protocol

Voor H.323:

Met dit protocol werkt RTP van MoH niet omdat CUCM altijd het openLogicalChannelAck-bericht verstuurt met IP-adres en poort op nullen die de media uitschakelen.

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

Hetzelfde kan worden geverifieerd met Show Call Active Voice Brief om te controleren hoe de RX stappen-waarde stopt en het Remote media-Adres IP 0.0.0:0 is.

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

Waarschuwing: RX en TX nemen niet toe in IOS-XE platforms tenzij Media Bulk-Stats opdracht is geconfigureerd onder Voice Service VoIP, maar zijn zich ervan bewust dat deze opdracht de prestaties van de router kan beïnvloeden, zodat het wordt aanbevolen om deze alleen mogelijk te maken wanneer er een oplossing voor is gevonden en deze vervolgens uit te schakelen.

Debug VIP Inout toont geen NAT-markering (Network Address Translation) die hier is ingeschakeld omdat de media zijn uitgeschakeld met OpenLogicalChannelAck, kunnen media-uitgeschakeld worden met de berichtzijde: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 actieve optie sbc global | s Totale gevallen pakketten|Verdroging pakketten: presenteert een tabel met alle geworpen pakketten waar Ingreress-stroom instelbare stappen ontvangt terwijl de oproep in de lucht staat.

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

Voor SIP

Wanneer SIP wordt gebruikt, stuurt CUCM in het SDP het CUCM-IP-adres, Port 4000 en media-eigenschap voor Richting als a=sendonly dat de router opgeeft om RTP slechts te ontvangen.

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

De a=sendonly stelt de media richting in om alleen voor het perspectief van de Voice Router te ontvangen en dit leidt tot de NAT vlag functie die de RTP nog steeds toelaat om door te gaan, ook al komt het uit een andere bron.

Dit kan worden gecontroleerd met 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

Als een ander kenmerk voor Media Direction naar de Voice Router wordt verzonden wanneer dit gebeurt, wordt de NAT-vlaggenfunctie niet geactiveerd en worden pakketten verzonden omdat ze uit een andere bron afkomstig zijn.

Debug CCSIP Berichten tonen in dit voorbeeld 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 toont een mediastrame die is ingesteld op rtp_type:3:SENDRECV en geen functie van een NAT-vlag.

//27/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2

Aangezien er geen NAT-vlag is, is de show platform hardware qfp actief en is er geen NAT-vlag, wereldwijd actief | s Totale gevallen pakketten|Drogeerde pakketten: toont stappen in de verkeerde bron voor stroomsectie.

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

Voor MGCP:

Wanneer MGCP wordt gebruikt, verstuurt CUCM een MDCX om de media-richting te veranderen die al is overeengekomen toen de verbinding tot stand kwam, zodat er geen verandering is in IP-adres of -signalering, maar nadat MDCX de RTP vanaf een andere bron is gestroomd.

Sinds m: Inontvangen wordt naar de Spraakrouter verzonden, wordt de NAT-vlaggenfunctie ingeschakeld.

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 toont de mediasturing die is ingesteld op rtp_type:2:RECVONLY en NAT vlaggenfunctie, waardoor de RTP doorstroomt.

//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

Als een ander kenmerk voor Media Direction naar de Voice Router wordt verzonden wanneer dit gebeurt, wordt de NAT-vlaggenfunctie niet geactiveerd en worden pakketten verzonden omdat ze uit een andere bron afkomstig zijn.

Debug MGCP Packets toont in dit voorbeeld 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 toont een mediastrame die is ingesteld op rtp_type:3:SENDRECV en geen functie van een NAT-vlag.

//29/F56119000000/VOIPFPI:():voip_fpi_get_snd_rcv_enable_flag: side:SIDE_A, rtp_type:3:SENDRECV send:1 recv:2

Aangezien er geen NAT-vlag is, is de show platform hardware qfp actief en is sbc wereldwijd actief | s Totale gevallen pakketten|Drogeerde pakketten: toont stappen in de verkeerde bron voor stroomsectie.

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

Voor SCCP:

Debug SCCP Berichten tonen wanneer de oproep op zijn plaats is.

CUCM instrueert u eerst de Voice Router om over te schakelen naar media inactief met een Closeontvangkanaal en een 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

Dan verzoekt CUCM de router van de Stem om slechts met een Openontvangkanaal te veranderen.

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

Aansluitingen met SCCP tonen toont het profiel en de rapporten 0.0.0:0; de router verwacht dat de RTP uit die bron komt.

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 toont de mediasturing die is ingesteld op rtp_type:2:RECVONLY en NAT vlaggenfunctie, waardoor de RTP doorstroomt.

//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

Tip: De berichten van OpenGetChannel worden gebruikt om de router van de Stem op te leiden om RTP te ontvangen en de router van de Voice vertelt CUCM over OpenGetChannelAck waar zij die media wil ontvangen.

Het bericht StartMediaTransmission wordt gebruikt om de spraakrouter op te leiden om RTP naar de gespecificeerde bestemming te sturen.

Met andere woorden, als alleen Openontvangkanaal wordt uitgewisseld, is het een manier om de media te vertellen dat het alleen RTP (recv) ontvangt en als StartMediaTransmission alleen wordt uitgewisseld, dan is het een manier om de media te vertellen dat het alleen RTP (alleen verzenden) verstuurt, maar als beide worden uitgewisseld is het gelijk aan sendrecv.

Als de mediasturing is ingesteld op alleen of sendrecv verzenden en de RTP afkomstig is van een andere bron dan is er geen NAT-vlag geactiveerd en is de actieve functie van het platform hardware qfp sbc mondiaal | s Totale gevallen pakketten|Drogeerde pakketten: toont pakketten die werden verzonden.

Tip: Als er een noodzaak is om RTP toe te staan die afkomstig is van een ander adres dan het adres dat via signalering en ontvangst is overeengekomen, dan kan deze niet worden gebruikt, noch kan deze force-on onder Voice Service Voip worden ingeschakeld, kan Sip worden gebruikt om handmatige expressie toe te voegen. Dit werkte voorheen niet goed, maar werd op een defect bevestigd CSCvo15141 . Houd in gedachten dat dit alleen voor SIP werkt.

Waarschuwing: als pass-thru inhoud sdp onder stemservice voip, sip is geconfigureerd, geeft dit de FPI-laag niet in staat om de NAT-functie te activeren wanneer ontvangst wordt ontvangen.

Tip: In sommige situaties waar NAT Flag actief is voor een vraag en audio werkt fijn, daalde de waarde van pakketten onder tonen platform hardware qfp actieve optie sbc mondiaal | s Totaal geworpen pakketten |Verpakte pakketten: Kan nog steeds stijgen in een veel lager tarief, dit is omdat in sommige situaties en callstromen, Real Time Control Protocol (RTCP) nog steeds naar de Voice Router en van een andere bron kan worden verzonden die dit gedrag kan veroorzaken.