In Depth Analysis of Ringback for all VoIP and Analog Protocols

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

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.

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

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

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