Detaillierte Ringback-Analyse für alle VoIP- und analogen Protokolle

Einführung

Dieses Dokument enthält eine ausführliche Erläuterung der Tonsprinbacktöne, die allgemein als Anruffortschrittstöne oder kurz als CPtones bezeichnet werden.

In diesem Dokument wird versucht, die Funktionsweise des Rückrufs in allen VoIP- (Voice over IP) und analogen Signalisierungsprotokollen zu erörtern und eine Analyse dieser Protokolle bereitzustellen.

Voraussetzungen

Anforderungen

Das Lesen dieses Dokuments erfordert jedoch keine formelle Voraussetzung. Es wurde mit der Erwartung geschrieben, dass der Leser bereits einige funktionierende Kenntnisse der zugrunde liegenden Sprachsignalisierungsprotokolle besitzt, die zum Herstellen und Verbinden von Telefongesprächen verwendet werden. Auf diese Protokolle wird in diesem Dokument häufig verwiesen.

Signalisierungsprotokolle:Session Initiation Protocol (SIP), H323 (h225/h245), Media Gateway Control Protocol (MGCP), Skinny Client Control Protocol (SCCP), ISDN Q931, E1 R2.

Medienprotokolle:Real Time Protocol (RTP), Sprach-Codecs, Video-Codecs.

Analog Technologies: Ear and Mouth (E&M), Foreign Exchange Subscriber (FXS), Foreign Exchange Office (FXO) und E1 R2.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der folgenden Software und Hardware:

Cisco IOS- und IOS-XE-Gateways (2800/3800/2900/3900/4300/4400/CSR1000v/ASR100X) mit beliebigen Versionen von IOS/IOS-XE.

Cisco Unified Communications Manager (CUCM) Version 9.X und höher

Cisco Unity Connection (CUC) Version 9.x und höher

Customer Voice Portal (CVP) Version 9.x und höher

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 oder einer Konfiguration verstehen.

Hintergrundinformationen

Rinback ist kein VoIP- oder Analogprotokoll, sondern wird in jedem Telefongespräch von Mobiltelefonen, Festnetztelefonen, Schreibtischtelefonen und Softclients verwendet. Ein wichtiger Bestandteil der Collaboration Engineers-Toolbet ist daher, die Funktionsweise, den Ursprung und die Behebung von Problemen mit Rückrufen zu verstehen.

Der Rückruf ist eine Folge von Signaltönen, die an die Person abgespielt werden, die einen Anruf tätigt. Dadurch wird der Anrufer darauf hingewiesen, dass der angerufene Teilnehmer tatsächlich klingelt. Das Fehlen eines Klingeltons ist ein schlechtes Zeichen, da der Anrufer davon ausgehen würde, dass der angerufene Teilnehmer nicht tatsächlich klingelt. Die Klingeltöne/CP-Töne unterscheiden sich je nach Land. Wenn eine Person, die eine Nummer aus den Vereinigten Staaten anruft, eine andere Gruppe von Rückrufen als eine Telefonnummer aus dem Vereinigten Königreich (United Kingdom Number, Vereinigtes Königreich) erhält.

In den meisten Fällen wird Ringback vom angerufenen Remote-Teilnehmer zum anrufenden Teilnehmer wiedergegeben. Um dies zu erreichen, muss die Audioübertragung in die Richtung "Abwärts" durchgeschnitten werden (angerufen).

Protokolle

In diesem Dokument werden die verschiedenen Protokolle und ihre Aushandlung von Rückrufen sowie die Bearbeitung von Rückrufen bei Verwendung dieses Protokolls erläutert.

ISDN Q.931 (T1/E1/BRI)

ISDN Q.931 nutzte das Konzept der Fortschrittsanzeigen (PIs), die in der Q.931-Signalisierung angezeigt werden können. Dies ist auf Cisco Voice Gateways sichtbar, indem Sie debug isdn q931 ausführen. Statusanzeigen können in den Meldungen Alert, Progress, Call Proceeding, Setup Ack (Warnung), Progress (Fortschritt), Call Proceeding (Anrufweiterleitung), Disconnect (Einrichten) und Disconnect (Trennen) gesendet werden. Bei einem Fortschrittsindikator-Wert von 1 oder 8 wird der Rückruf- und Fehlermeldungen rückwärts gespart. Die Werte für Statusanzeigen 0, 2 und 3 werden nicht durch rückwärts gerichtete Medien abgeschnitten. Ein DSP, der dem ISDN-Kanal zugewiesen ist, kann einen Rückruf an die ISDN-Leitung wiedergeben, wenn der externe Angerufene dies nicht tun kann.

Bekannte Probleme mit ISDN-Rückruf

• SIP-ISDN-Anrufe erfordern ein frühzeitiges Angebot, sodass das Gateway beim Empfang einer ISDN mit einem gültigen PI zum Öffnen von Medien mit rückwärts gerichtetem Code über die IP des CUCM/IP-Telefons verfügt, an das Medien gesendet werden.

Q931-Statusanzeigen

Wert	Definition	Q.931-Nachricht
Statusanzeige = 0	Out-of-Band	Einrichtung
Statusanzeige = 1	Der Anruf ist keine End-to-End-ISDN. Weitere Anruffortschrittsinformationen können in-band verfügbar sein.	Warnung, Verbindung, Fortschritt, Einrichtung
Statusanzeige = 2	Die Zieladresse lautet nicht ISDN.	Warnung, Verbindung, Fortschritt
Statusanzeige = 3	Die Zieladresse lautet nicht ISDN.	Einrichtung
Statusanzeige = 8	In-Band-Informationen oder ein geeignetes Muster sind jetzt verfügbar.	Warnung, Verbindung, Fortschritt, Trennen

Beispiele für ISDN Q.931 In-Band-Statusanzeigen

Jun 22 15:16:36.790: ISDN Se0/2/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x80A3
        Progress Ind i = 0x8188 - In-band info or appropriate now available

Nov 28 21:25:41.754: ISDN Se0/1/1:15 Q931: TX -> PROGRESS pd = 8  callref = 0x805C 
	Progress Ind i = 0x8188 - In-band info or appropriate now available 

  

Konfiguration

ISDN-Rückruf funktioniert standardmäßig zuverlässig, sodass keine zusätzliche Konfiguration erforderlich ist. Es gibt jedoch Befehle, um das Verhalten im Falle einer Interoperabilitätsanforderung zu ändern.

Manuelles Ändern des progress_ind-Werts.

Wichtige Hinweise:

• Dies ist standardmäßig deaktiviert.
• Dies kann nur auf ausgehende Dial-Peers angewendet werden.
• Dies KANN auf VOIP- und POTS-DFÜ-Peers angewendet werden.

Vollständige Befehlssyntax:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-p2.html#wp1001337490

!
progress_ind { alert | callproc } { enable pi-number | disable | strip [strip-pi-number] }
progress_ind { connect | disconnect | progress | setup } { enable pi-number | disable }

!
dial-peer voice 1 pots
 destination-pattern 8675309$
 progress_ind alert enable 8
 progress_ind callproc enable 8
 progress_ind connect enable 8
 progress_ind disconnect enable 8
 progress_ind progress enable 8
 progress_ind progress setup 1
!
dial-peer voice 2 pots
 destination-pattern 8675309$
 progress_ind alert strip 8
 progress_ind callproc strip 8
!
dial-peer voice 3 pots
 destination-pattern 8675309$
 progress_ind alert disable
 progress_ind callproc disable
 progress_ind connect disable
 progress_ind disconnect disable
 progress_ind progress disable
 progress_ind progress disable
!

Ein Voice Gateway muss immer Alerting-Nachrichten senden.

Wenn ein Administrator ein Voice-Gateway benötigt, sendet er immer eine Alerting-Nachricht, bevor eine Verbindung hergestellt wird. Der Befehl isdn send-Alerting kann unter einer seriellen Schnittstelle konfiguriert werden. Dies ist standardmäßig deaktiviert.

Vollständige Befehlssyntax: http://www.cisco.com/c/en/us/td/docs/ios/dial/command/reference/dia-cr-book/dia_i2.html

!
interface Serial0/0/0:23
 isdn send-alerting
!

Debugger

debug isdn q931
debug voip ccapi inout

H.323

Das H.323-Protokoll und insbesondere das H.225-VOIP-Signalisierungsprotokoll basieren auf dem Q.931-Protokoll von ISDN. Infolgedessen teilen sie viele gemeinsame Elemente. Viele der Befehle, die hinter dem Q.931-Rückruf vorkommen, sind in H.323/H.225 enthalten. Dazu gehören Werte für Statusanzeigen, Meldungstypen und Befehle.

Beispiel einer H.225-Nachricht für Rückleitung

*Jun 22 11:32:52.080: H225.0 INCOMING PDU ::=

value H323_UserInformation ::= 
    {
      h323-uu-pdu 
      {
        h323-message-body alerting : 

Konfiguration

Für H.323 und H.225 ist keine Konfiguration für den unverschlüsselten Rückruf erforderlich. Die im Abschnitt ISDN Q.931 angegebenen Befehle gelten jedoch auch für H.323-Ringback. Zusätzlich sind Befehle für die H.323-Signalisierung verfügbar.

Befehl	Definition
Voicemail-Benachrichtigung	In globaler Konfiguration konfiguriert. Dieser Befehl ist standardmäßig deaktiviert. Mit diesem Befehl kann das Terminierungs-Gateway eine Warnmeldung anstatt einer Statusmeldung senden, nachdem es eine Anrufeinrichtung erhalten hat. Dieser Befehl kann diese Vorlage verwenden, wenn "Voice Call Send Alert=FALSE" in den CCAPI-Debuggen vorhanden ist, um den Wert TRUE zu setzen. Darüber hinaus kann dies für ISDN zu SIP verwendet werden, wobei 183 w/SDP empfangen wurde, das Gerät der Gegenstelle jedoch keinen Rückruf abspielte. Es ändert den TX-Fortschritt in TX-Alerting mit den gleichen PI-Informationen. PSTN spielte dann eine Rückspülung ab.
Voice RTP Send-Recv	Öffnet den RTP-Audiokanal in beide Richtungen.
! Dial-Peer-Voice 1 VoIP Ton-Rückruf-Alarm-no-pi ! Dial-Peer-Voice-2-Ports Ton-Rückruf-Alarm-no-pi !	Dieser Befehl bewirkt, dass das Gateway einen Rückruf zum anrufenden Teilnehmer generiert, wenn im IP-Anrufabschnitt eine Warnung ohne PI eingeht. Der Befehl progress_ind unterscheidet sich dadurch, dass die ausgehende H.225-Setup-Nachricht keine PI 3 mit dem Ton-Rückruf-Befehl enthält. Es ist möglich, dass einige Geräte keine Setup-Meldungen akzeptieren, wenn eine PI enthalten ist.

CUCM-Konfigurationen

Es gibt einige spezifische H.323-Konfigurationen für Rückrufe in CUCM>

Navigationspfad: CUCM > System > Service Parameters > Pub > CallManager > Send H225 User Info Message > Use ANN For Ringback

Wert	Definition
ANN für Freizeichensymbol verwenden	Verwenden Sie den Cisco SCCP Annunciator, um den Freizeichenton wiederzugeben (verfügbar ab Cisco CallManager Version 4.0).
Benutzer-Info zum Anruffortschrittston	Senden Sie eine H.225-Benutzerinformationsmeldung an das IOS-Gateway, um einen Freizeichenton oder einen gehaltenen Ton abzuspielen (dies ist die Standardeinstellung).
Ton "H225 Info for Call Progress" (Informationen für Anruffortschritt)	Senden Sie die H.225-Informationsmeldung an das IOS-Gateway, um den Freizeichenton oder den gehaltenen Ton wiederzugeben.

Debugger

debug voip ccapi inout
debug h225 asn1

Dies ist auch ein hervorragendes Dokument zur Fehlerbehebung bei H.323-Rückruf.

http://www.cisco.com/c/en/us/support/docs/voice/h323/22983-ringback.html

SIP

Der SIP-Rückruf umfasst in der Regel eine von zwei Nachrichten. 180 und 183. Laut RFC 3261 können 0, 1 oder mehr dieser 1XX-Nachrichten nach einer INVITE-Nachricht empfangen werden. Daher ist es nicht gegen RFC, eine dieser Nachrichten nicht zu erhalten. Wenn keine Antwort empfangen wird, wird kein Rückruf mehr ausgegeben. Wenn also ein Anrufer einen Rückruf erwartet, ist ein Rückruf von 180 oder 183 erforderlich.

Sowohl ein 180 als auch ein 183 können Session Description Protocol (SDP) enthalten, das CUBE als Early Media behandelt. Wenn SDP in einer 18-fachen Nachricht vorhanden ist, erwartet CUBE und CUCM, dass das Gegenstelle den 18X mit SDP sendet, um einen Rückruf von der im SDP angegebenen IP wiederzugeben. Es gibt keine Konfiguration, um dieses Verhalten in CUCM oder CUBE zu ändern. Einige Geräte benötigen einen PRACK-Austausch (rel1xx) bei der 18x-Nachricht, bevor ein Rückruf gesendet wird.

RFC3960 geht näher auf die Ringback-Signalisierung mit SIP ein.

Beachten Sie, dass für SIP-ISDN und SIP-H.323-Anrufe ein 18-facher Anruf mit SDP einem In-Band-Statusindikator zugeordnet wird, während ein 18-faches ohne SDP einer Alerting-Meldung zugeordnet ist.

Beispiel 183 mit SDP

SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bK6350828126b1a
From: <sip:8675309@10.10.10.10>;tag=85512413~796a13c3-49d2-74ec-19db-f4258d9eef64-40934478
To: <sip:123456789@10.10.10.1>;tag=BA0FA04C-97B
Date: Wed, 22 Jun 2016 11:32:51 GMT
Call-ID: 575b0c00-76a177e1-57ea4-2009000a
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: <sip:8675309@10.10.10.10>;party=called;screen=no;privacy=off
Contact: <sip:8675309@10.10.10.10:5060;transport=tcp>
Supported: sdp-anat
Server: Cisco-SIPGateway/IOS-15.4.3.M2
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 250

v=0
o=CiscoSystemsSIP-GW-UserAgent 9474 3602 IN IP4 172.16.37.129
s=SIP Call
c=IN IP4 10.10.10.10
t=0 0
m=audio 17606 RTP/AVP 8 101
c=IN IP4 10.10.10.10
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

Beispiel 180 ohne SDP

SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.10.10.10:5060;branch=z9hG4bKd34f2a2080
From: <sip:2002@10.10.10.10>;tag=17170~21823a7a-6ec3-4a2f-9307-df98bca4b011-23314477
To: <sip:3001@10.10.10.1> ;tag=1ADFB1AC-3CB
Date: Tue, 26 Jan 2016 22:05:06 GMT
Call-ID: d859d700-6a71ed8f-26-a21030e
CSeq: 102 INVITE
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Remote-Party-ID: < sip:3001@10.10.10.10> ;party=called;screen=yes;privacy=off
Contact: < sip:3001@10.10.10.10:5060;transport=tcp>
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0

Konfiguration

Befehl	Definition
! Sip-ua Deaktivierung von Early Media 180 !	Hiermit wird festgelegt, welche Anrufbearbeitung (Early Media oder Local Ringback) für 180 Antworten mit 180 Antworten mit Session Description Protocol (SDP) bereitgestellt wird.
! Voice Service-VoIP  Schluck   Block {180 | 181 | 183} sdp {gegenwärtig | abwesend} !	Blockiert spezifische Nachrichten zum Rückruf

SIP-Profil, um eine laufende 183-Sitzung in eine 180-Sitzung zu ändern.

!
voice service voip
 sip
  sip-profiles inbound
!
voice class sip-profiles 777
 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session Progress" "SIP/2.0 180 Ringing"
!
dial-peer voice 777 voip
 voice-class sip profile 777 inbound
!

Aktivieren von PRACK (rel1xx) in CUCM.

• PRACK ist in CUCM SIP-Profilen standardmäßig deaktiviert.

Pfad des Systemmenüs: Gerät > Geräteeinstellungen > SIP-Profil > SIP-Profil auswählen > SIP Rel1XX

Optionen 

• Deaktiviert (Standard)
• Senden von PRACK, wenn 1xx SDP enthält
• Senden von PRACK für alle 1xx-Nachrichten

Aktivieren von PRACK (rel1xx) auf Gateways

• Standardmäßig ist rel1xx auf Voice-Gateways aktiviert. Wenn ein CUBE eine Anforderung erhält: 100rel Header wird PRACK

Debugger

debug voip ccapi inout
debug ccsip messages

  

MGCP

MGCP ist die VOIP-Seite, die FXS- und ISDN T1/E1-Ports steuert. Sie können überprüfen, ob CUCM die richtige Rückruf-Signalisierung an den bestimmten Port sendet. Es kann jedoch nicht viel konfiguriert werden.

Beispiel für eine MGCP-Ringback-Nachricht vom CUCM an einen VG224-FXS-Port

Apr 29 01:01:38.264: MGCP Packet received from 14.50.244.2:2427--->
RQNT 37 AALN/S2/1@vg224 MGCP 0.1
X: 1b
R: L/hu
S: G/rt
Q: process,loop
<---

S: = Signalereignisse und g/rt = generisches Paket/Rufton

CUCM-Konfiguration

Pfad des Systemmenüs: System > Dienstparameter > Pub > CallManager > Statusanzeige für Warnmeldungen deaktivieren

• Dieser Parameter legt fest, ob die Alerting-Fortschrittsanzeige für In-Band-Informationen an digitale PRI-Gateways gemeldet wird.
• Gültige Werte geben True (Deaktivieren der Statusanzeige für Warnmeldungen) oder False (Senden der Statusanzeige für Warnmeldungen) an.
• Um in bestimmten Konfigurationen einen Rückruf zu erhalten, müssen Sie dieses Feld möglicherweise auf False festlegen, um die Mediendurchwahl zu erzwingen.

Gateway-Konfiguration

• Keine

Debugger

debug mgcp packet
debug voip ccapi nout
debug vpm signal 
debug voip vtsp session

SCCP

Bei SCCP-IP-Telefonen, die für CUCM oder CME registriert sind, wird eine "StartToneMessage" an das IP-Telefon gesendet, die das lokale Telefon anweist, Rückruf an die anrufende Person zu senden.

Analog (FXS/FXO/E&M/E1 R2)

Ringback-Debug für alle analogen Sprach-Ports:

debug voip ccapi inout
debug vpm signal
debug voip vtsp session

  

Sprach-Ports

• Der lokale DSP stellt Rückrufe für den Sprach-Port bereit.
• Ein benutzerdefinierter CPtone kann unter dem bevorzugten Sprach-Port konfiguriert werden.

GATEWAY(config)#voice-port 0/2/0
GATEWAY(config-voiceport)#cptone ?
  locale   2 letter ISO-3166 country code

AR Argentina            IN India                PA Panama
AU Australia            ID Indonesia            PE Peru
AT Austria              IE Ireland              PH Philippines
BE Belgium              IL Israel               PL Poland
BR Brazil               IT Italy                PT Portugal
CA Canada               JP Japan                RU Russian Federation
CL Chile                JO Jordan               SA Saudi Arabia
CN China                KE Kenya                SG Singapore
CO Colombia             KR Korea Republic       SK Slovakia
C1 Custom1              KW Kuwait               SI Slovenia
C2 Custom2              LB Lebanon              ZA South Africa
CY Cyprus               LU Luxembourg           ES Spain
CZ Czech Republic       MY Malaysia             SE Sweden
DK Denmark              MT Malta                CH Switzerland
EG Egypt                MX Mexico               TW Taiwan
FI Finland              NP Nepal                TH Thailand
FR France               NL Netherlands          TR Turkey
DE Germany              NZ New Zealand          AE United Arab Emirates
GH Ghana                NG Nigeria              GB United Kingdom
GR Greece               NO Norway               US United States
HK Hong Kong            OM Oman                 VE Venezuela
HU Hungary              PK Pakistan             ZW Zimbabwe
IS Iceland

E1 R2

Ausgabe von debug ccapi Inout, debug vpm signal und debug voip vtsp session für E1 R2-Aufruf mit Rückruf.

042446: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert:
   Interface=0x3ECE2770, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
042447: May 12 14:51:15.816 GMT: //2475488/47922BA59254/CCAPI/cc_api_call_alert:
   Call Entry(Retry Count=0, Responsed=TRUE)
042448: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert:
   Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
042449: May 12 14:51:15.816 GMT: //2475487/47922BA59254/CCAPI/ccCallAlert:
   Call Entry(Responsed=TRUE, Alert Sent=TRUE)htsp_alert_notify
042450: May 12 14:51:15.816 GMT: r2_reg_event_proc(0/0/1:1(1)) ALERTING RECEIVED
042451: May 12 14:51:15.816 GMT: R2 Incoming Voice(0/1): DSX (E1 0/0/1:0): STATE: R2_IN_WAIT_REMOTE_ALERT R2 Got Event R2_ALERTING
042452: May 12 14:51:15.816 GMT: rx R2_ALERTING in r2_comp_wait_remote_alert
042453: May 12 14:51:15.816 GMT: r2_reg_generate_digits(0/0/1:1(1)): Tx digit '1'
042454: May 12 14:51:16.672 GMT: //2475487/47922BA59254/VTSP:(0/0/1:1):0:1:1/vtsp_report_cas_digit:
   End Digit=2, Mode=CC_TONE_R2_MF_BACKWARD_MODE
042455: May 12 14:51:16.672 GMT: htsp_digit_ready(0/0/1:1(1)): Rx digit='#'

Cisco spezifische Rückruf-Details

Interne Übertragungen (SIP-Trunks und CUC)

• Bei einer internen Weiterleitung über einen SIP-Trunk oder zum/vom CUC-CUCM-Ansager wird der Anruf zurückgegeben.

• Stellen Sie sicher, dass dem Trunk ein MRGL und ein Signalgeber zugewiesen sind und der IPVMS-Dienst gestartet wird.

Mobile Contact Center-Agenten

• Damit ein Agent Anruffortschrittstöne für vom Agenten initiierte Anrufe hören kann, ist eine zusätzliche Konfiguration erforderlich, wenn MTP Required nicht aktiviert ist. Wenn Sie stattdessen über eine dynamische MTP-Zuweisung verfügen, indem Sie falsch zugeordnete DTMF-Einstellungen erzwingen, sollte der Unified CM so konfiguriert werden, dass das Early Offer-Tool aktiviert wird.
• Rufton und andere Anruffortschrittstöne werden vom Cisco Annunciator nicht generiert, wie dies bei normalen Telefonen und Softphones der Fall ist. Stattdessen setzt Mobile Agent darauf, dass diese Töne vom angerufenen Teilnehmer generiert werden (und bei der Einstellung des frühzeitigen Angebots werden diese Töne an den Agenten gesendet).

Dokumentation:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_9_0_1/user/guide/UCCE_BK_UFAEED16_00_ucce-mobile-agent-guide/UCCE_BK_UFAEED16_00_ucce-mobile-agent-guide_chapter_010.html#UCCE_RF_E40E25C8_00

Contact Center Enterprise (UCCE) und VXML

CVP signalisiert dem VXML-Gateway, einen Rückruf wiederzugeben, indem es eine INVITE-Nachricht mit einer bestimmten Nummer sendet.
Beispiel: 9191
Im SDP dieser INVITE-Nachricht soll das VXML-Gateway einen Rückruf senden.

Dies entspricht einem Dial-Peer, der mit einem konfigurierten Rückruf-Service konfiguriert wurde.

Fehlerbehebung

Rückruf-Verzögerung

Die Verzögerung des Durchschnitts von Rückrufen wird in der Regel durch eine Verzögerung der zugrunde liegenden Signalisierung verursacht. Debugger und Protokolle für das verwendete Gerät und die verwendeten Protokolle müssen konsultiert werden, um festzustellen, warum die Signalisierung verzögert wird.

Bei Signalisierungsfehlern des Voice-Gateways bei DFÜ-Peers und der Neusuche nach DFÜ-Peers kann es zu erheblichen Verzögerungen kommen, wenn das Gerät versucht, einen nächsten Hop für den Anruf zu finden. 

debuggen voip ccapi in-out Analysis

Wie Sie im gesamten Dokument sehen können, ist das Sammeln von ccapi-Debuggen sehr wichtig für jedes Rückrufproblem.

Die Anrufsteuerungs-API (Call Control API, CCAPI) ist dafür zuständig, zwei Seiten eines Anrufs auf einem Sprach-Gateway zu überbrücken und infolgedessen auch den Rückruf von einer Anrufverbindung zu einer anderen zu kombinieren.

Beispiele für die Debugausgabe von CCAPI für den Rückruf

Feb  2 21:27:18.884: //22/9285F23E801B/CCAPI/cc_api_call_alert:
   Interface=0x3AB79E8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)

Jun 23 13:32:34 EDT: //1204/77232A800001/CCAPI/cc_api_call_cut_progress:
   Interface=0x7FD5FD1CEE10, Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2),
   Cause Value=0

Jun 23 13:32:34 EDT: //1203/77232A800001/CCAPI/ccCallCutProgress:
   Progress Indication=INBAND(8), Signal Indication=INTERCEPT(2), Cause Value=0
   Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)

Jun 22 11:32:52.096: //204706/575B0C000000/CCAPI/ccCallAlert:
   Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)

Nov 28 21:25:41.748: //43495/0C82F2F380B7/CCAPI/cc_api_call_cut_progress:
   Interface=0x7F8028B60F90, Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1),
   Cause Value=0

Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccCallCutProgress:
   Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1), Cause Value=0
   Voice Call Send Alert=FALSE, Call Entry(Alert Sent=FALSE)

Nov 28 21:25:41.749: //43494/0C82F2F380B7/CCAPI/ccGenerateToneInfo:
   Stop Tone On Digit=FALSE, Tone=Null,
   Tone Direction=Network, Params=0x0, Call Id=43494

Signalisierung ist in Ordnung, aber es gibt keinen Rückruf?

Je nach Signalisierung sieht alles in Ordnung aus. Es kann jedoch auch vorkommen, dass kein Rückruf eingeht. Wenn das Signal anzeigt, dass eine bestimmte Partei einen Rückruf an Ihr Gerät sendet, sollten Sie eine Paketerfassung oder PCM-Erfassung vom Sprach-Port erfassen, um festzustellen, ob der Rückruf tatsächlich wiedergegeben wird.

Außerdem muss das Layer-3-Routing von der Quelle und vom Ziel aus überprüft werden. Wenn sie keine RTP-Pakete an Ihr Gerät senden können, hören Sie keine Audiowiedergabe. Wenn Sie Pakete nicht an ein bestimmtes Gerät senden können, hören sie außerdem nicht den Rückruf.

Nützliche Layer-3-Routing-Befehle

show ip route
show ip cef <remote_ip>
ping a.b.c.d source <interface>
traceroute a.b.c.d

PCM-Erfassungsdokumentation:

http://www.cisco.com/c/en/us/support/docs/voice/h323/116078-technologies-technote-commandrefe.html