Contents

Introduction

Prerequisites

Requirements

Components Used

Background Information

Protocols

ISDN Q.931 (T1 / E1 / BRI)

H.323

SIP

MGCP

SCCP

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

Voice Ports

E1 R2

Cisco Specific Ringback Details

Internal Transfers (SIP Trunks and CUC)

Contact Center Mobile Agents

Contact Center Enterprise (UCCE) and VXML

Troubleshoot

Delay in Ringback

debug voip ccapi inout Analysis

Signaling is Okay, but there is no ringback?

Introduction

The Purpose of this document is to provide an in depth explanation of audio rinback tones commonly reffered to as Call Progress tones or CPtones for short.

This document will attempt to discuss and provide an analysis of how ringback works within any and all Voice over IP (VoIP) and Analog Signaling protocols.

Prerequisites

Requirements

While there is no formal prerequisite needed to read this document; it was written with the expectation that the reader already has some working knowledge of underlying voice signaling protocols that are used to establish and connect phone calls. These protocols are referenced many times throughout this document.

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

Media Protocols:Real Time Protocol (RTP), voice codecs, video codecs.

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

Components Used

The information in this document is based on these software and hardware:

Cisco IOS and IOS-XE Gateways (2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / ASR100X) running any versions of IOS/IOS-XE.

Cisco Unified Communications Manger (CUCM) versions 9.X and above

Cisco Unity Connection (CUC) versions 9.x and above

Customer Voice Portal (CVP) version 9.x and above

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. If your network is live, ensure that you understand the potential impact of any command or configuration.

Background Information

Rinback is not a VoIP or Analog protocol but it is present in every phonecall made by cellphones, landlines, desk phones, and soft clients. Thus understanding how it works, where it comes from, and how to troubleshoot ringback issues is an important part of a Collaboration Engineers toolbet.

Ringback is a sequence of tones played to the person making a phone call which lets the caller know that the called party is actually ringing. The absence of ringtone is to be considered a bad sign as the caller would assume the called party is not actually ringing. Ringback / CPtones vary country by country. If a person where to call a United States number they would be played a different set of ringback than if that same person called a United Kingdom Number.

In most scenarios Ringback is played by the remote Called party to the Calling party. For this to occur audio must be cut through in the backwards direction (Called to Calling).

Protocols

This document  examines the different protocols and how they negotiate ringback as well as how to manipulate ringback when using that protocol.

ISDN Q.931 (T1 / E1 / BRI)

ISDN Q.931 utilized the concept of Progress Indicators (PIs) which can be viewed in the Q.931 signaling. This is viewable on Cisco Voice Gateways by running debug isdn q931. Progress indicators can be sent in Alert, Progress, Call Proceeding, Setup Ack, and Disconnect messages. A Progress Indicator value of 1 or 8 will cut through backwards audio for ringback and error messages. Progress Indicator values of 0, 2, and 3 will not cut through backwards media. A DSP assigned to the ISDN channel can play ringback to the ISDN line if the remote called party is unable to do so.

Known Caveats with ISDN Ringback

- SIP to ISDN calls requir Early Offer so that when the Gateway receives ISDN with a valid PI to open backwards media it has the IP of the CUCM/IP Phone to send media towards.

Q931 Progress Indicators

Value

Definition

Q.931 Message

Progress Indicator = 0

out-of-band

Setup

Progress Indicator = 1

Call is not end-end ISDN. Further call progress information can possibly be available in-band

Alert, Connect, Progress, Setup

Progress Indicator = 2

Destination address is non-ISDN.

Alert, Connect, Progress

Progress Indicator = 3

Destination address is non-ISDN.

Setup

Progress Indicator = 8

In-band information or an appropriate pattern is now available.

Alert, Connect, Progress, Disconnect

Examples of ISDN Q.931 In-Band Progress Indicators

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

Configuration

ISDN ringback works reliably by default so no addditional configuration is required. However there do exists commands to change the behavior in the event of an interopability requirement.

Manually Changing the progress_ind value.

Important Notes:

- This is disabled by default

- This can only be applied to outbound dial-peers

- This CAN be applied to both VOIP and POTS dial-peers.

Full Command Syntax: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

!

Require that a Voice Gateway always send Alerting messages

If an administrator needs to require a voice gateway always send Alerting message before a Connect the command isdn send-alerting can be configured under a Serial interface. This is disabled by default

Full Command Syntax: 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

!

Debugs

debug isdn q931

debug voip ccapi inout

H.323

H.323 and more specifically the H.225 VOIP signaling protocol was built upon ISDN's Q.931 protocol. As a result they share a lot of common elements. Many of the commands present and ideas behind Q.931 ringback are present in H.323/H.225. This includes Progress Indicator Values, Message types, and the commands.

Example H.225 message for Rinback

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

value H323_UserInformation ::=

{

h323-uu-pdu

{

h323-message-body alerting :

Configuration

H.323 and H.225 require no configuration for ringback out of the box. However the commands specified in the ISDN Q.931 section are also applicable to H.323 Ringback. Additionally there are commands availabe for H.323 signaling.

Command

Definition

voice call send-alert

- Configured in global configuration.

- This command is disabled by default.

- This command enables the terminating gateway to send an alert message instead of a progress message after it receives a call setup.

- This command can emplloyed this when "Voice Call Send Alert=FALSE" is in the CCAPI debugs to make the value TRUE.

- Additinally this can be used used foron ISDN to SIP where 183 w/SDP was recieved but far end device was not actually playing ringback.

- It changes the TX Progress to TX Alerting with the same PI info. PSTN then played rinback.

voice rtp send-recv

Opens RTP audio channel in both directions.

!

dial-peer voice 1 voip

tone ringback alert-no-pi

!

dial-peer voice 2 pots

tone ringback alert-no-pi

!

- This command causes the gateway to generate ringback towards the calling party if an alert is received on the IP call leg with no PI present.

- It differs from the progress_ind setup command in that the outbound H.225 setup message does not contain a PI of 3 with the tone ringback command.

- It is possible that some devices do not accept setup messages when a PI is included.

CUCM Configurations

There exist some specific H.323 Configurations for ringback within CUCM>

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

Value

Definition

Use ANN for Ring Back

Use Cisco SCCP Annunciator to play ringback tone (available in Cisco CallManager release 4.0 and later)

User Info for Call Progress Tone

Send H.225 user information message to IOS gateway to play ringback tone or tone on hold (This is the default.)

H225 Info for Call Progress Tone

Send H.225 information message to IOS gateway to play ringback tone or tone on hold

Debugs

debug voip ccapi inout

debug h225 asn1

This is also a great document on Troubleshooting H.323 Ringback

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

SIP

SIP ringback usualy involves one of two messages. 180 and 183. RFC 3261 states that 0, 1, or more of these 1XX messages may be recieved after an INVITE therefore it is not against RFC to not recieve one of these messages. If none are recieved there will be no ringback. So if a caller is expecting ringback in some form then a 180 or 183 are required.

Both a 180 and 183 can contain Session DescriptionProtocol (SDP) that CUBE will treat as early media. When SDP is present in a 18X message CUBE and CUCM will expect the far end device sending the 18X with SDP to play ringback from the IP specified in the SDP. There is no configuration to change this behavior in either CUCM or CUBE. Some devices require a PRACK (rel1xx) exchange on the 18X message before ringback is sent.

RFC3960 dives into further details about Ringback Signaling with SIP.

It is important to note that for SIP to ISDN and SIP to H.323 calls a 18X with SDP maps to an In-Band Progress Indicator while a 18X without SDP maps to an Alerting.

Sample 183 with 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

Sample 180 without 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

Configuration

Command

Definition

!

sip-ua

disable-early-media 180

!

Used to specify which call treatment, early media or local ringback, is provided for 180 responses with 180 responses with Session Description Protocol (SDP)

!

voice service voip

sip

block {180 | 181 | 183} sdp {present | absent}

!

Blocks specific messages pertaining to ringback

SIP Profile to change a 183 Session In Progress into a 180 Ringing.

!

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

!

Enabling PRACK (rel1xx) in CUCM.

- PRACK is disabled by default on CUCM SIP Profiles

System Menu Path: Device > Device Settings > Sip Profile > Choose a SIP profile > SIP Rel1XX

Options

- Disabled (Default)

- Send PRACK if 1xx Contains SDP

- Send PRACK for all 1xx Messages

Enabling PRACK (rel1xx) on Gateawys

- By default rel1xx is enabled on Voice Gateways. If a CUBE recieves a require: 100rel header it will PRACK

Debugs

debug voip ccapi inout

debug ccsip messages

MGCP

MGCP is the VOIP side that controls FXS and ISDN T1 / E1 Ports. You can check if CUCM is sending the proper ringback signaling to the specific port  but ther is not a lot of configuration that can be done.

Sample MGCP Ringback Message from CUCM to a 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: = Signaled Events and g/rt = Generic Package / Ringback Tone

CUCM Configuration

System Menu Path: System > Service Parameters > Pub > CallManager > Disable Alerting Progress Indicator

- This parameter determines whether the alerting progress indicator to Inband Information is reported to digital PRI gateways.

- Valid values specify True (disable the alerting progress indicator) or False (send the alerting progress indicator).

- To receive ring back in certain configurations, you may have to set this field to False to force media cut-through.

Gateway Configuration

- None

Debugs

debug mgcp packet

debug voip ccapi nout

debug vpm signal

debug voip vtsp session

SCCP

For SCCP IP Phones registered to CUCM or CME there is a "StartToneMessage" sent to the IP Phone which tells the local phone to play ringback to the person making the call.

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

Ringback debugs for all analog voice ports:

debug voip ccapi inout

debug vpm signal

debug voip vtsp session

Voice Ports

- The local DSP will be respoinsible for providing ringback for the voice-port.

- A custom CPtone is configurable under the voice-port of choice.

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

Output from debug ccapi inout, debug vpm signal and debug voip vtsp session for E1 R2 call showing ringback.

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 Specific Ringback Details

Internal Transfers (SIP Trunks and CUC)

- During an internal transfer across a sip trunk or to/from CUC CUCM annunciator will be the one providing ringback.

- Ensure an MRGL and Annunciator are assigned to the trunk and the IPVMS service is started.

Contact Center Mobile Agents

- In order for an agent to hear call progress tones for agent initiated calls, additional configuration is required if MTP Required is not enabled. If instead you have dynamic MTP allocation by forcing mismatched DTMF settings, then the Unified CM should be configured to enable Early Offer.

- Ringback and other call progress tones are not generated by the Cisco Annunciator, as is the case for regular phones and softphones. Instead, Mobile Agent relies on these tones being generated by the called party (and the early offer setting triggers these tones to be sent to the agent).

Documentation:

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) and VXML

CVP will signal the VXML gateway to play ringback by sending an INVITE with a specific specific number.

Example: 9191

The SDP of this INVITE will be where we want the VXML gateway to send ringback.

This will match a dial-peer configured with a ringback service configured.

Troubleshoot

Delay in Ringback

Delay in ringback cut through is usually caused by a delay in the underlying signaling. Debugs and logs for the specific device and protocols being used will need to be consulted to find out why there is a delay in signaling.

For Voice gateway's signaling failure on dial-peers and dial-peer re-hunting can cause considerable delay as the device tries to find a next hop for the call.

debug voip ccapi inout Analysis

As you can see throughout the document gathering ccapi debugs is very important for ANY ringback issue.

the Call Control Api (CCAPI) is responsible for bridging two sides of a call on a voice gateway and as a result also stitching together ringback from one call-leg to another.

Examples of debug output from CCAPI for ringback

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

Signaling is Okay, but there is no ringback?

Depending on your signaling everything may look okay. However there may still be no ringback. If the signal indicates a specific party is to be sending ringback to your device it is worth grabbing a packet capture or PCM capture from the voice-port to verify if ringback is in fact played or not.

It is also important to check Layer 3 routing from the source and destination. if they cannot send RTP packets to your device you will not hear audio. Adiditionally if you cannot send packets to a specific device they are not going to hear your ringback.

Useful Layer 3 routing commands

show ip route

show ip cef <remote_ip>

ping a.b.c.d source <interface>

traceroute a.b.c.d

PCM Capture Documentation:

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