SIP-Aufzeichnung (SIPREC) auf CUBE konfigurieren

(1)

SIP-Aufzeichnung (SIPREC) auf CUBE konfigurieren

Inhalt

Einführung

Voraussetzungen Anforderungen

Verwendete Komponenten Hintergrundinformationen Konfigurieren

Methode 1 Methode 2

Netzwerkdiagramm Konfigurationen Überprüfen Fehlerbehebung Arbeitsszenario

Szenarios mit nicht funktionierenden Szenarien

Einführung

In diesem Dokument wird der Prozess zur Konfiguration des CUBE (Cisco Unified Border

Element) beschrieben, das als Aufzeichnungs-Client mit einem Aufzeichnungsserver verwendet wird.

Mitarbeiter: Hector Luna Ponce, Cisco TAC Engineer.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

Grundkenntnisse der Konfiguration und Verwendung von Cisco IOS-Sprachfunktionen

●

Grundkenntnisse der Konfiguration und Verwendung von CUBE

●

Cisco Unified Communication Manager (CUCM)

●

Aufzeichnungsserver

●

Session Initiation Protocol (SIP) - SIP-Anrufflüsse

●

Verwendete Komponenten

Integrated Service Router (ISR)G2/ISR4K mit entsprechendem UC-Technologiepaket, konfiguriert als CUBE im Flow-Through-Modus und mit Cisco IOS/IOS-XE Version 15.2

●

(2)

Aufzeichnungsserver

●

CUCM 11.5(1)

●

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten

Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Kommunikationssitzung ist der Begriff, der sich auf die gerade aufgezeichnete Sitzung bezieht.

Eine Kommunikationssitzung kann ein Point-to-Point- oder Multipoint-Konferenzgespräch sein.

Wenn Medien-Streams, die zur Kommunikationssitzung gehören, kopiert und an den

Aufzeichnungsserver gesendet werden, wird dies als Medienforking bezeichnet. Diese Aufgabe wird von Aufzeichnungs-Clients ausgeführt.

Ein Session Recording Client (SRC) ist ein SIP-Gerät, das Medienaufzeichnungs-Streams erzeugt.

Ein Session Recording Server (SRS) ist ein SIP-Gerät, das die Medienaufzeichnungs-Streams empfängt und speichert.

Aufzeichnungssitzung: Eine Aufzeichnungssitzung ist eine SIP-Sitzung zwischen dem

Aufzeichnungs-Client und dem -Server. Beispielsweise die SIP-Sitzung zwischen dem SBC und dem Medienrekorder.

Aufzeichnung von Metadaten: Die Aufzeichnungsmetadaten enthalten detaillierte Informationen über die aufgezeichnete Kommunikationssitzung, z. B. Verzeichnisnummern oder URIs aller Teilnehmer und die Medienrichtung (senden, empfangen, inaktiv) sowie den Inhaltstyp jedes einzelnen Medienstreams innerhalb der Kommunikationssitzung.

Konfigurieren

Sie können CUBE mit zwei verschiedenen Methoden konfigurieren:

Methode 1

Schritt 1: Das Medienprofil-Recorder-Tag speichert das Dial-Peer-Tag, das verwendet wird, um auf den Aufzeichnungsserver zu verweisen. In diesem Beispiel wird mit dem Dial-Peer 20 auf den Aufzeichnungsserver verwiesen.

CUBE (config)# media profile recorder 10000 CUBE (config-profile)# media-recording 20 CUBE (config-profile)# media-type audio

Schritt 2: Das Medienklassen-Tag wird zum Speichern des oben erstellten Rekorder-Profiltags verwendet.

CUBE (config)# media class 3

CUBE (config-media)# recorder profile 10000 siprec

(3)

Schritt 3: Dieser Dial-Peer wird zum Einrichten des SIP-Dialogs mit dem Aufzeichnungsserver verwendet. Die als Sitzungsziel verwendete IP-Adresse ist die IP-Adresse des

Aufzeichnungsservers.

CUBE (config)#dial-peer voice 20 voip

CUBE (config-dial-peer)#description Dial-peer that points to the recording server

Schritt 4: Dabei kann es sich um ein beliebiges Dummy-Zielmuster handeln. Es wird nicht verwendet, um diesen DFÜ-Peer abzugleichen.

CUBE (config-dial-peer)#destination-pattern 99999 CUBE (config-dial-peer)#session protocol sipv2

CUBE (config-dial-peer)#session target ipv4:10.0.0.10 CUBE (config-dial-peer)#session transport tcp

Schritt 5: Der Medienklassentag wird dann unter dem Dial-Peer angewendet, der für den Anruf verwendet wird, der aufgezeichnet werden muss.

CUBE (config-dial-peer)#description Dial-peer for the call that needs to be recorded CUBE (config-dial-peer)#media-class 3

Alternativ können Sie die Methode 2 verwenden, um CUBE für Medienforking zu konfigurieren.

Methode 2

Schritt 1: Konfigurieren Sie ein Medienklassen-Tag, das das Dial-Peer-Tag speichert, das verwendet wird, um unter der CLI des Rekorder-Parameters auf den Aufzeichnungsserver zu zeigen.

CUBE (config)# media class 3

CUBE (config-media)# recorder parameter siprec CUBE (config-media-recorder)# media-recording 20

Schritt 2: Konfigurieren Sie den Dial-Peer für den Aufzeichnungsserver.

CUBE (config-dial-peer)#description Dial-peer to the recording server CUBE (config-dial-peer)#destination-pattern 99999

CUBE (config-dial-peer)#session protocol sipv2

CUBE (config-dial-peer)#session target ipv4:10.0.0.10

Schritt 3: Die Medienklasse-Tag wird unter dem Dial-Peer angewendet, der für den Anruf verwendet wird, der aufgezeichnet werden muss.

CUBE (config-dial-peer)#description Dial-peer for the call that needs to be recorded CUBE (config-dial-peer)#media-class 3

Netzwerkdiagramm

Ein Beispiel für das Netzwerkdiagramm für diese Konfiguration ist in der Abbildung dargestellt:

(4)

Konfigurationen

Dies ist ein Beispiel für SIPREC für die CUBE-Methode 1:

media profile recorder 10000 siprec media-recording 20

media-type audio

!

media class 3 recorder profile 10000 !

dial-peer voice 1 voip description Outbound Dial-peer for the call that needs to be recorded destination-pattern 200. session protocol sipv2 session target ipv4:10.0.0.20 media-class 3 codec g711ulaw no vad !

dial-peer voice 20 voip description Dial-peer to recording server destination-pattern 99999 session protocol sipv2 session target ipv4:10.0.0.10

Dies ist ein Beispiel für SIPREC für die CUBE-Methode 2:

media class 3

recorder parameter siprec media-recording 20

!

dial-peer voice 1 voip description Dial-peer for the call that needs to be recorded media-class 3

dial-peer voice 20 voip

description Dial-peer to recording server destination-pattern 99999

session protocol sipv2

sipv2 session target ipv4:10.0.0.10

Überprüfen

Verwenden Sie den Befehl show voip rtp connections, um zu überprüfen, ob die Konfiguration des Medienforkings korrekt ist:

CUBE#show voip rtp connections VoIP RTP active connections :

No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP

(5)

1 36 37 18358 19362 209.165.201.5 209.165.201.10

2 37 36 17294 17690 10.0.0.5 10.0.0.20 3 39 38 19812 42196 172.16.0.10 10.0.0.10 4 40 38 24230 60234 172.16.0.10 10.0.0.10 Found 4 active RTP connections

In diesem Beispiel hat der Anruf zwischen den beiden Telefonen zu zwei RTP-Streams (1 und 2) geführt. Die 2 RTP-Streams (3 und 4) sind die aufgezeichneten Streams, die an den

Aufzeichnungsserver gesendet werden (in diesem Beispiel 10.0.0.10). Der

Anrufaufzeichnungsserver empfängt einen duplizierten RTP-Stream, der den aufgezeichneten Anruf darstellt. Verwenden Sie den Befehl show voip recmsp session, um Folgendes zu

überprüfen:

CUBE#sh voip recmsp session RECMSP active sessions:

MSP Call-ID AnchorLeg Call-ID ForkedLeg Call-ID

143 141 145 Found 1 active sessions

Um weitere Details zu den Streams zu erhalten, führen Sie den Befehl show voip recmsp session detail call-id <der oben angegebene Wert> aus:

CUBE#show voip recmsp session detail call-id <the value specified in the above o/p>

CUBE#show voip recmsp session detail call-id 143 RECMSP active sessions:

Detailed Information

=========================

Recording MSP Leg Details:

Call ID: 143

GUID : 7C5946D38ECD AnchorLeg Details:

Call ID: 141

Forking Stream type: voice-nearend Participant: 2001

Non-anchor Leg Details:

Call ID: 140

Forking Stream type: voice-farend Participant: 1001

Forked Leg Details:

Call ID: 145

Near End Stream CallID 145 Stream State ACTIVE

Far End stream CallID 146 Stream State ACTIVE Found 1 active sessions

Wo:

Stream-Status: Dies zeigt den Status des Anrufs an. Dieser kann sich entweder im AKTIVEN oder im HALTEN-Status befinden.

●

(6)

Anrufer-Leg-Anruf-ID: Dies ist die Anruf-ID des Ankerabschnitts (Dial-Peer, bei dem das Gabelen aktiviert ist), der sich ebenfalls im System befindet. Die Ausgabe in brief beschreibt die Teilnehmernummer und den Streamtyp als Voice-Near-End, das als Party-Side

bezeichnet wird.

●

Anruf-ID ohne Anker: Dies ist die Anruf-ID des Nicht-Anker-Beins (Dial-Peer, bei dem das forking nicht aktiviert ist).

●

Gefälschte Anruf-ID: Diese forking-leg-Anruf-ID zeigt Details zur Anruf-ID des Nahbereichs- und des Gegenstandes mit dem Status des Streams.

●

Wenn Sie die Remote-IPs und -Ports für die nahe gelegenen und die am anderen Ende liegenden Beine kennen möchten, verwenden Sie den Befehl show voip rtp forking:

CUBE#show voip rtp forking VoIP RTP active forks:

Fork 1

stream type voice-only (0): count 0 stream type voice+dtmf (1): count 0 stream type dtmf-only (2): count 0 stream type voice-nearend (3): count 1

remote ip 10.0.0.10, remote port 38526, local port 18648 codec g711ulaw, logical ssrc 0x53

packets sent 29687, packets received 0 stream type voice+dtmf-nearend (4): count 0 stream type voice-farend (5): count 1

remote ip 10.0.0.10, remote port 50482, local port 17780 codec g711ulaw, logical ssrc 0x55

packets sent 29686, packets received 0 stream type voice+dtmf-farend (6): count 0 stream type video (7): count

Remote-IP/-Port ist die IP- und Port-Adresse des Aufzeichnungsservers. Codec gibt an, welcher Codec ausgehandelt wird, um den Anrufabschnitt aufzuzeichnen. Die gesendeten Pakete geben die Anzahl der Pakete an, die von jedem Stream an den Aufzeichnungsserver gesendet werden.

Fehlerbehebung

Die nächste Konfiguration dient zur Erläuterung des SIPREC-Betriebs auf IOS/IOS-XE-Sprach- Routern.

media class 777

recorder parameter siprec media-recording 777

!

dial-peer voice 11 voip description CUCM session protocol sipv2

session target ipv4:10.0.0.15 destination e164-pattern-map 164 media-class 777

codec g711ulaw

!

dial-peer voice 777 voip destination-pattern AAAA session protocol sipv2

session target ipv4:10.0.0.10

(7)

codec g711ulaw

Arbeitsszenario

Wenn der Anruf verbunden ist, spielen die Ein-/Ausgehende-Info-Beine eine wichtige Rolle, um zu verstehen, dass ein Aufzeichnungsanruf initiiert wurde. Hier sendet der ausgehende

Anrufabschnitt 4536 eine Medienforking-Startanzeige an seinen Peer-Inbound-Leg 4535, der dieses Ereignis ignoriert, da es nicht der Ankerbereich ist (in diesem Beispiel wird der Befehl media-class auf dem ausgehenden Dial-Peer konfiguriert. Peer-ID 4536).

017895: May 13 15:32:45.273:

//4536/2FD863BAA01F/SIP/Info/info/32768/ccsip_trigger_media_forking: MF: EO leg. set the pending flag. wait for peer leg to indicate start

017896: May 13 15:32:45.273:

//4536/2FD863BAA01F/SIP/Info/info/32768/ccsip_trigger_media_forking: MF: posting CC_EV_H245_MEDIA_FORKING_START_IND.

017901: May 13 15:32:45.273: //4535/2FD863BAA01F/SIP/Info/notify/32768/ccsip_event_handler:

CC_EV_H245_MEDIA_FORKING_START_IND: peer ID 4536, event = 217 type = 1

017902: May 13 15:32:45.273: //4535/2FD863BAA01F/SIP/Info/verbose/32768/ccsip_event_handler:

Ignoring the event on non-anchor leg

Ebenso sendet die 4536 für ausgehende Anrufe eine Medienforking-Startanzeige an die Leitung für eingehende Anrufe (Leg 5435).

018221: May 13 15:32:45.290: //4536/2FD863BAA01F/SIP/Info/notify/32768/ccsip_event_handler:

CC_EV_H245_MEDIA_FORKING_START_IND: peer ID 4535, event = 217 type = 1

Im ausgehenden Bereich wird das Ereignis verarbeitet und die Aufzeichnungssitzung ausgelöst.

018222: May 13 15:32:45.290: //4536/2FD863BAA01F/SIP/Info/verbose/32768/ccsip_event_handler:

Peer leg has indicated start. Trigger Media Forking.

018229: May 13 15:32:45.290: //-1/xxxxxxxxxxxx/Event/recmsp_api_create_session: Event:

E_REC_CREATE_SESSION anchor call ID:4536, msp call ID:4537

018230: May 13 15:32:45.290: //-1/xxxxxxxxxxxx/Inout/recmsp_api_create_session: Exit with Success

Aufnahme der DFÜ-Peer-Suche.

018320: May 13 15:32:45.293: //4537/2FD863BAA01F/RECMSP/Inout/recmsp_get_dp_tag_list: REC DP: = 777

018390: May 13 15:32:45.296: //-

1/xxxxxxxxxxxx/SIP/Info/verbose/5120/sipSPIGetOutboundHostAndDestHostPrivate: CCSIP: target_host : 10.0.0.10 target_port : 5060

Erstellen von XML-Metadaten

018513: May 13 15:32:45.301:

//4538/2FD863BAA01F/SIP/Info/info/32768/ccsip_ipip_mf_create_xml_metadata: MF: XML metadata Len:

[1763]

<?xml version="1.0" encoding="UTF-8"?>

<datamode>complete</datamode>

(8)

<sipSessionID>a0b9b2a1e4db51f082e777c0df9015e5;remote=6bea155500105000a0002c31246a214b</sipSessi onID>

<start-time>2019-05-13T15:32:45.293Z</start-time>

</session>

</nameID>

</participant>

<participantses**MSG 00003 TRUNCATED**

**MSG 00003 CONTINUATION #01**sionassoc participant_id="MIhBMXTLEemWFqQi1vyb4Q=="

session_id="MIgZ2nTLEemWFaQi1vyb4Q==">

<associate-time>2019-05-13T15:32:45.293Z</associate-time>

</participantsessionassoc>

</stream>

<name xml:lang="en">Emergency</name>

</nameID>

</participant>

<participantsessionassoc participant_id="MIhBMXTLEemWF6Qi1vyb4Q=="

<asso**MSG 00003 TRUNCATED**

**MSG 00003 CONTINUATION #02**ciate-time>2019-05-13T15:32:45.293Z</associate-time>

</stream>

<send>MIlSKnTLEemWG6Qi1vyb4Q==</send>

<recv>MIlSKnTLEemWHKQi1vyb4Q==</recv>

</participantstreamassoc>

<send>MIlSKnTLEemWHKQi1vyb4Q==</send>

<recv>MIlSKnTLEemWG6Qi1vyb4Q==</recv>

</participantstreamassoc>

</recording>

INVITE zur Aufzeichnung mit Metadaten im XML-Format wird gesendet, wenn:

Das nameID-Attribut stellt den Namen und die SIP/SIPS/tel-URI (auch als Aufzeichnungsadresse bezeichnet) jedes Teilnehmers dar.

●

Das teilnehmer_id-Attribut gibt die eindeutige ID an, die jedem Teilnehmer in der Aufzeichnungssitzung zugewiesen wurde.

●

Das stream_id-Attribut gibt die eindeutige ID an, die jedem Medienstream in der Aufzeichnungssitzung zugewiesen wurde.

●

Das session_id-Attribut wird verwendet, um auf die Kommunikationssitzung zu verweisen, zu der ein bestimmter Medienstream gehört.

●

Das Label-Metadatenattribut gibt den Wert des a=label-Attributs an, das diesem

Medienstream im SDP der SIP-Anforderung und den Antworten der Aufzeichnungssitzung zugewiesen wurde. Es spielt eine Schlüsselrolle beim Zuordnen eines Medienstreams zu seinen Metadateninformationen.

●

018628: May 13 15:32:45.306: //4538/2FD863BAA01F/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:AAAA@10.0.0.10:5060 SIP/2.0

(9)

Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bK11BD2CA From: <sip:y.y.y.y>;tag=F75AD7F-2065

To: <sip:AAAA@10.0.0.10>

Date: Mon, 13 May 2019 15:32:45 GMT

Call-ID: 3089C795-74CB11E9-961DA422-D6FC9BE1@y.y.y.y

Supported: 100rel,timer,resource-priority,replaces,sdp-anat Require: siprec

Min-SE: 1800

Cisco-Guid: 0802710458-1959465449-2686421522-1015028268 User-Agent: Cisco-SIPGateway/IOS-16.10.2

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 101 INVITE Max-Forwards: 70 Timestamp: 1557761565

Contact: <sip:y.y.y.y:5060>;+sip.src Expires: 180

Allow-Events: telephone-event

Session-ID: a62dd6d8be0059c38d142bae9b46880b;remote=00000000000000000000000000000000 Session-Expires: 1800

Content-Type: multipart/mixed;boundary=uniqueBoundary Mime-Version: 1.0

Content-Length: 2470 --uniqueBoundary

Content-Type: application/sdp

Content-Disposition: session;handling=required v=0

o=CiscoSystemsSIP-GW-UserAgent 5511 2889 IN IP4 y.y.y.y s=SIP Call

c=IN IP4 y.y.y.y t=0 0

m=audio 8086 RTP/AVP 0 101 19 c=IN IP4 y.y.y.y

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16

a=rtpmap:19 CN/8000 a=ptime:20

a=sendonly a=label:1

m=audio 8088 RTP/AVP 0 101 19 c=IN IP4 y.y.y.y

a=rtpmap:0 PCMU/8000

a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16

a=rtpmap:19 CN/8000 a=ptime:20

a=sendonly a=label:2

--uniqueBoundary

Content-Type: application/rs-metadata+xml Content-Disposition: recording-session

<?xml version="1.0" encoding="UTF-8"?>

<datamode>complete</datamode>

<sipSessionID>a0b9b2a1e4db51f082e777c0df9015e5;remote=6bea155500105000a0002c31246a214b</sipSessi onID>

<start-time>2019-05-13T15:32:45.293Z</start-time>

(10)

</session>

<nameID aor="sip:1234@10.0.0.15">

</nameID>

</participant>

<participantsessionassoc participant_id="MIhBMXTLEemWFqQi1vyb4Q=="

<associate-time>2019-05-13T15:32:45.293Z</associate-time>

session_id="MIgZ2nTLEemWFaQi1vyb4Q==">

1 </stream> <participant participant_id="MIhBMXTLEemWF6Qi1vyb4Q=="> <

nameID aor="sip:911@209.165.201.1"> <name xml:lang="en">Emergency</name> </nameID>

</participant> <participantsessionassoc

participant_id="MIhBMXTLEemWF6Qi1vyb4Q==" session_id="MIgZ2nTLEemWFaQi1vyb4Q=="> <associate- time>2019-05-13T15:32:45.293Z</associate-time> </participantsessionassoc>

session_id="MIgZ2nTLEemWFaQi1vyb4Q==">

2 </stream> <participantstreamassoc participant_id="MIhBMXTLEemWFqQi1vyb4Q==">

<send>MIlSKnTLEemWG6Qi1vyb4Q==</send> <recv>MIlSKnTLEemWHKQi1vyb4Q==</recv>

</participantstreamassoc> <participantstreamassoc participant_id="MIhBMXTLEemWF6Qi1vyb4Q==">

<send>MIlSKnTLEemWHKQi1vyb4Q==</send> <recv>MIlSKnTLEemWG6Qi1vyb4Q==</recv>

</participantstreamassoc> </recording> --uniqueBoundary--

In 200 OK Rekorder sendet Medien a=recvonly und Media Forking wird gestartet.

018638: May 13 15:32:45.307: //4538/2FD863BAA01F/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/UDP y.y.y.y:5060;branch=z9hG4bK11BD2CA From: <sip:y.y.y.y>;tag=F75AD7F-2065

To: <sip:AAAA@10.0.0.10>;tag=7

Call-ID: 3089C795-74CB11E9-961DA422-D6FC9BE1@y.y.y.y CSeq: 101 INVITE

Contact: <sip:10.0.0.10:5060;transport=UDP>

Content-Type: application/sdp Content-Length: 207

v=0

o=user1 53655765 2353687637 IN IP4 10.0.0.10 s=-

c=IN IP4 10.0.0.10

(11)

t=0 0

m=audio 6000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly

m=audio 8002 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly

018809: May 13 15:32:45.313: //4537/2FD863BAA01F/RECMSP/Event/recmsp_api_connect: Event:

E_REC_CC_CONNECTmsp call ID:4537 in recmsp_api_connect

Szenarios mit nicht funktionierenden Szenarien Das Problem der Aufzeichnung, die nicht von CUBE initiiert wird, wird in der Regel in neuen Bereitstellungen gemeldet, und die

Hauptursache ist eine falsche Konfiguration. Beispiele:

Es liegt eine falsche DFÜ-Peer-Übereinstimmung für eingehende Anrufe vor (d. h. dem ausgewählten DFÜ-Peer ist keine Medienklasse zugeordnet).

●

Das Zielmuster im DFÜ-Peer ist ein Muster für reguläre Ausdrücke anstelle einer einfachen Verzeichnisnummer (1.. statt 1234).

●

Es liegt eine falsche IP-Adresse des Aufzeichnungsservers vor, oder der Hostname des Servers wurde nicht erfolgreich in eine IP-Adresse aufgelöst.

●

Fehler in Bereitstellungen nach der Produktion können an den Aufzeichnungsserver adressiert werden, der aufgrund von Netzwerkverbindungsproblemen nicht verfügbar oder nicht erreichbar ist. SIP-Antworten wie "503 Service Unavailable" (Dienst nicht verfügbar) und "500 Server Internal Error" (Interner Fehler des 500 Servers) werden als Antwort auf die INVITE-Nachricht vom

Aufzeichnungsserver empfangen. In solchen Situationen empfiehlt es sich, der Befehlsliste für das Debuggen debug ip tcp-Transaktionen hinzuzufügen, um festzustellen, ob TCP-Verbindungen korrekt eingerichtet werden.In anderen Fällen können Dateien nicht aufgezeichnet werden. Das Versäumnis von Aufzeichnungsdateien liegt in der Verantwortung des Aufzeichnungsservers. Es empfiehlt sich daher, zu überprüfen, ob CUBE RTP-Pakete an den Aufzeichnungsserver

überträgt, während ein Anruf aufgezeichnet wird. Verwenden Sie show voice rtp connections, und geben Sie show voip rtp forking 3-5 mal in a row ein, um sicherzustellen, dass Pakete, die den Zählerwert erreichen, inkrementiert werden.Es gibt nützliche Debugger, um SIPREC auf CUBE zu beheben.

debug voip ccapi inout debug ccsip message debug ccsip events debug ccsip error debug ccsip info

debug voip recmsp event

debug voip recmsp error debug voip recmsp inout