Guest

IP Telephony/Voice over IP (VoIP)

SIP Reliable Provisional Response on CUBE and CUCM Configuration Example

Document ID: 116086

Updated: May 16, 2013

Contributed by Robin Cai, Cisco TAC Engineer.

   Print

Introduction

This document describes how the Session Initiation Protocol (SIP) reliable provisional response feature works and how to confiugred it on Cisco Unified Border Element (CUBE) and Cisco Unified Communications Manager (CUCM).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

  • Cisco Unified Border Element (CUBE) Enterprise
  • Cisco Unified Communications Manager Express (CUCME)
  • Cisco Unified Communications Manager (CUCM)
  • Session Initiation Protocol (SIP)

Components Used

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

  • Cisco IOS Release 15.1(4)M4 on Cisco Integrated Services Routers (ISR): Series 2800, 3800, 2900, 3900
  • Cisco IOS Release 15.1(3)S4 on Cisco ASR 1000 Series Aggregation Services Routers

Note: This configuration example is not limited to the software versions and hardware platforms listed above; this configuration also works with Cisco IOS Release 12.4(24)T5 on Cisco AS5400XM Universal Gateway.

Background Information

SIP reliable provisional response was introduced in order to better integrate with a public switched telephone network (PSTN). The most common scenario is to establish the voice/audio path before completion of the call; therefore, the caller hears the announcement or music generated by the PSTN.

For example, in below topology, the IP phone calls a PSTN conference bridge or some toll free numbers, and the callee plays a prompt before it answers the call. If the CUCM initiates the call with a delay offer (INVITE does not contain Session Description Protocol (SDP)), the caller will not hear the prompt.

116086-configure-cube-cucm-sip-01.png

In other cases, the PSTN side generates a ringback tone. If media is not cut through before the call connects, the caller might not hear the ringback tone.

SIP reliable provisional response can be used to resolve the above issue without involving extra media resources (such as Media Transfer Protocol (MTP)), as these provisional responses and PRACK messages provide additional opportunities for offer/answer exchanges.

CUBE Configuration

By default, CUBE supports reliable response with this configuration:

voice service voip
sip
rel1xx supported 100rel

This means, as a User Agent Client (UAC), if it receives 180/183 messages with header Require: 100rel, it will respond with PRACK; however, as a User Agent Server (UAS), it will not send out 180/183 with the header Require: 100rel.

In order to force CUBE to send 18X with  Require: 100rel (so that it will wait for PRACK from UAC), here is the configuration example:

Global level:

voice service voip
sip
rel1xx require 100rel

Dial-peer level:

dial-peer voice 1000 voip
voice-class sip rel1xx require 100rel

Note: The dial-peer setting takes precedence over the global setting.

CUCM Configuration

By default, CUCM does not support reliable response. However, you can change the SIP trunk profile in order to configure it:

  1. In the CUCM Administration interface, go to Device > Device Setting > SIP Profile.
  2. Open the SIP profile used by a given SIP trunk.
  3. Choose Send PRACK for all 1xx Messages from the SIP Rel1XX Options drop-down list.
  4. Reset the SIP trunk profile for the given SIP trunk.

116086-configure-cube-cucm-sip-02.png

Note: If the given SIP trunk uses the default SIP trunk profile (Standard SIP Profile), it is best to copy to a new profile and apply to the SIP trunk; otherwise, the default SIP trunk profile will affect all SIP trunks.

Note: Even if you make the above change, CUCM can support reliable responses only by sending PRACK as a UAC; however, for now, it cannot send 180/183 with the Require: 100rel header as a UAS.

Typical SIP Messages

If reliable repsonse is configured in the incoming dial-peer on CUBE, a typical call will be similar to this:

// CUBE receives INVITE with delay offer from CUCM. INVITE sip:2002@10.66.75.246:5060 SIP/2.0
Date: Thu, 04 Apr 2013 05:30:27 GMT
Call-Info: <sip:10.66.75.171:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
Allow-Events: presence, kpml
P-Asserted-Identity: <sip:4832@10.66.75.171>
Supported: 100rel,timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 7200
Cisco-Guid: 3228672256-0000065536-0000000027-2873836042
Remote-Party-ID: <sip:4832@10.66.75.171>;party=calling;screen=yes;privacy=off
Content-Length: 0
User-Agent: Cisco-CUCM8.6
To: <sip:2002@10.66.75.246>
Contact: <sip:4832@10.66.75.171:5060;transport=tcp>
Expires: 180
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246d9521aba1b
CSeq: 101 INVITE
Session-Expires: 7200
Max-Forwards: 70
SIP/2.0 100 Trying
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246d9521aba1b
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>
Date: Thu, 04 Apr 2013 05:50:29 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
CSeq: 101 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-15.2.4.M2.8
Content-Length: 0
// CUBE responds 183 with SDP which also contains Require: 100rel.
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246d9521aba1b
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>;tag=42CF0134-1BC8
Date: Thu, 04 Apr 2013 05:50:29 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
CSeq: 101 INVITE
Require: 100rel
RSeq: 3344
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Contact: <sip:2002@10.66.75.246:5060;transport=tcp>
Supported: sdp-anat
Supported: X-cisco-srtp-fallback
Server: Cisco-SIPGateway/IOS-15.2.4.M2.8
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 330

v=0
o=CiscoSystemsSIP-GW-UserAgent 4874 2535 IN IP4 10.66.75.246
s=SIP Call
c=IN IP4 10.66.75.246
t=0 0
m=audio 16442 RTP/AVP 8 0 18 101 19
c=IN IP4 10.66.75.246
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
// CUBE receives PRACK from CUCM with SDP
PRACK sip:2002@10.66.75.246:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246da4c33fa3e
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>;tag=42CF0134-1BC8
Date: Thu, 04 Apr 2013 05:30:27 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
CSeq: 102 PRACKRAck: 3344 101 INVITE
Allow-Events: presence, kpml
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 213

v=0
o=CiscoSystemsCCM-SIP 169850 1 IN IP4 10.66.75.171
s=SIP Call
c=IN IP4 10.66.75.89
t=0 0
m=audio 26662 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
// CUBE acknowledges the PRACK.
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.66.75.171:5060;branch=z9hG4bK246da4c33fa3e
From: <sip:4832@10.66.75.171>;tag=169850~fb41edd8-7bc7-4ced-b8b0-9b10a31db5c4-19845894
To: <sip:2002@10.66.75.246>;tag=42CF0134-1BC8
Date: Thu, 04 Apr 2013 05:50:29 GMT
Call-ID: c071a100-15d10ff3-24695-ab4b420a@10.66.75.171
Server: Cisco-SIPGateway/IOS-15.2.4.M2.8
CSeq: 102 PRACK
Content-Length: 0
// The call is not anwered until now; however, calling and called parties have exchanged SDP,
// and media path is established.
// Other messages omitted.

Troubleshooting

In order to troubleshoot this issue on CUBE, these debugs must be enabled:

debug voip ccapi inout
debug ccsip message

Symptom 1: CUBE sends out 180/183 without the Require: 100rel header.

Verify that rel1xx require 100rel is configured under the approprate dial-peer or voice service voip.

Symptom 2: CUBE continues to send 180/183 with the Require: 100rel header to CUCM.

This issue usually occurs when CUCM does not support reliable response. In order to resolve this issue, enable Rel1xx on CUCM.

Related Information

Updated: May 16, 2013
Document ID: 116086