Sip Cucm

Configure and Troubleshoot Call Forward to the
PSTN using SIP Trunks

Introduction
With the increased usage of mobility features and work from home scenarios, there is
increased demand for the ability to transfer incoming calls from the PSTN back out to
different PSTN destinations. When using SIP trunks for PSTN connectivity these calling
scenarios often fail due to call validation. This document is a guide to configuration and
troubleshooting of these call flows.
Core Issue
All outbound PSTN SIP calls are validated by the SIP Trunk provider to ensure the calls are
valid and not toll fraud attempts. The methods of call validation can vary from provider to
provider, and many involve multiple methods for the same call. This becomes a concern
when using the default settings in a CUCM w/CUBE topology and attempting to call forward
an inbound PSTN call back out to the PSTN. One of the most common validation methods
is for the SIP provider to examine the "From" field in the incoming INVITE of a call and make
sure it matches to a known DID number for that customer. The default setting in CUCM for
forwarding calls is to maintain the CLID of the calling originator. This causes the "From" field
of an outgoing INVITE to contain the CLID number of the original PSTN caller, and not a
valid DID belonging to the customer. When the provider sees this with no additional
information, it typically will reject the call setup attempt or ignore it completely.
Resolution
There are three common solutions to this issue.
The first is to alter the "From" field so that the CUCM will send the information of the
redirecting number instead of the call originator. In this scenario the "From" field will contain
a valid customer DID number, and the call will validate. The advantage of this technique is
that it works with virtually all SIP providers. The disadvantage is that the receiving party of
the forwarded call will only see the caller-ID of the number that was set to forward (typically
their own office DID number). They will not see the caller-ID of the original caller, and
therefore will not know who is calling prior to answering the call.
Here are the steps to use the first method:

-Navigate to the SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Change the value in the drop down entitled "Calling Party Selection" to "Last Redirect
Number (External)"
-Save the change, and apply the change (may drop calls why you press apply, so be careful
with this change during business hours)
A second method is also often used, though it requires the SIP provider to validate calls
through a different method. This technique involves adding a p-asserted identity line in the
outbound INVITE containing a valid DID. The advantage of this technique is that the "From"
field retains the calling originator's information so that the recipient of the call can see who is
calling on their caller-ID. The disadvantage of this technique is that it is not universally used,
and customers need to check with their SIP providers to make sure they will validate calls
based on the p-asserted identity value instead of the "from" field value.
Here are the steps to use the second technique when using a CUBE gateway:
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing
SIP profiles, or add it to your outbound SIP profile in use. Also make sure to use a valid DID
number and SBC URL information.)
voice class sip-profiles 1
request INVITE sip-header P-Asserted-Identity add "P-AssertedIdentity:<sip:1111111111@sbc.sipprovider.com>"
-Add the following configuration line to the dial-peer being matched to place the outbound
call to the SIP provider:
voice-class sip profiles 1
Make sure that the SIP Profile contains a valid DID with your SIP provider. Also, most
providers will look for a fully qualified domain name in the PAI, as opposed to an IP
address. Be use to use the FQDN in the profile, even if you are routing the calls directly to
the provider's IP address.
The third method is similar to the second but instead of a PAI line, this uses a Diversion
Header. The Diversion Header is added to the outbound INVITE and contains a DID
number that the provider can validate the call with. Like with the second option, the
advantage of this technique is that the "From" field retains the calling originator's information
so that the recipient of the call can see who is calling on their caller-ID. The disadvantage of
this technique is that it is not universally used, and customers need to check with their SIP
providers to make sure they will validate calls based on the diversion header value instead of
the "from" field value.
Here are the steps to use the third technique when using a CUBE gateway:
-Navigate to SIP Trunk page in CUCM
-Navigate to "Outbound Calls" section of the page
-Check the "Redirecting Diversion Header Delivery - Outbound" Check box
-Save the change, and apply the change (may drop calls why you press apply, so be careful
with this change during business hours)
-Log into the CUBE router
-Add the following SIP profile (make sure to use a unique profile number if you have existing
SIP profiles, or add it to your outbound SIP profile in use. Also make sure to use a valid DID
number and SBC URL information.)
request INVITE sip-header Diversion modify "<sip:(.*)@(.*)>"
"<sip:1111111111@sbc.sipprovider.com>"
-Add the following configuration line to the dial-peer being matched to place the outbound
call to the SIP provider:
Make sure that the SIP Profile contains a valid DID with your SIP provider. Also, most
providers will look for a fully qualified domain name in the diversion header, as opposed to
an IP address. Be use to use the FQDN in the profile, even if you are routing the calls
directly to the provider's IP address.
Troubleshooting
The following debugs are useful in this call scenario:
debug ccsip messages
debug voip ccapi inout
When reading these debugs keeping the different call legs straight can get confusing. It is
recommended to use an application such as Notepad ++, and to mark the Call ID of each
call leg traversing the CUBE. The goal of these debugs is to check that the outbound
INVITE for the forwarded call contains either the correct "from" field, or the correct "passerted identity" or "diversion header" field. If using the "from" field method, check that the
SIP INVITE coming from the CUCM contains the full 10 digit DID number for the last
redirecting party, and that this value is the same in the INVITE going to the provider. If using
either the "p-asserted identity" method or the "diversion header" method, make sure that the
outgoing call is matching the correct dial-peer that has the voice-class sip profile set on it. If
it is matching a different dial-peer, add the sip profile to that dial-peer.
Incoming Dial-peer matching on IP Address

Introduction
Starting IOS version 15.1(2)T, we can match inbound dial-peers via IP Address or
hostname. This enables CUBE/TDM-SIP to connect to two or more different ITSPs allowing
specific call routing, codec selection, digit manipulation, CAC, QoS, or security policies for
each ITSP.
Feature Overview
Dial-peer selection is based on immediate SIP neighbor's address information
and applicable only to incoming SIP calls. The address information is retrieved from the VIA
header of the incoming message, which is then used to lookup the dial-peer that has the
best match for the criteria selected. The lookup will first attempt to match a dial-peer with
the address information in the following order:
Via header
Request URI
To URI
From URI
Called Number
If none of the parameters match, then the default inbound dial-peer is matched.
This feature also allows for Generic DNS Caching framework for faster FQDN to IP
Address lookup. For a configured FQDN, the DNS Caching framework resolves the FQDN
and stores the corresponding set of IP addresses for it. The framework also takes care of
the regular DNS refreshes for the FQDN. For a dial-peer match to be done, if the incoming
Via header has an IP address and the configuration has an FQDN, then the
corresponding resolved addressed of this FQDN is queried from the DNS
Caching Framework.
Call Flow
ITSP1 ---> SIP --> Call from source address 172.16.1.10 ----->
| ----> CUBE - SIP CUCM - IP Phones
ITSP2 ---> SIP --> Call from source address 172.31.10.10 --->
Sample Config
!To handle incoming calls from ITSP1
voice class uri 1001 sip
host ipv4:172.16.1.10
dial-peer voice 1 voip
description Calls from ITSP1
session protocol sipv2
incoming uri via 1001
max-connection 10
codec g711ulaw
acc-qos controlled-load
req-qos controlled-load
!To handle incoming calls from ITSP2
voice class uri 1002 sip
host ipv4:172.31.10.10

description Calls from ITSP1
incoming uri via 1002
max-connection 30
codec g729r8
How to Check Active Call Count on SIP

Problem Description
Requirement / Issue:
Service Provider is using ISR 3945 as a CUBE to connect to his interconnect Service
Provider over SIP trunks. ISP is interested to know the total active SIP Calls on the trunk
(not call legs). Is there a way we could arrive at the total active calls from the call legs and
identify the SIP-to-SIP calls on Cisco Unified Border Element (CUBE)?
Solution
Show commands to Identify the active call count on SIP:
Show commands
SBC03#Show call active voice compact
Number of call-legs counted during viewing: 1448
SBC03#Show voip rtp connections
Found 1459 active RTP connections
SBC03#show call active voice brief | incl call-legs
Telephony call-legs: 0
SIP call-legs: 1053
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 410
Multicast call-legs: 0
Total call-legs: 1463
SIP call-legs: 1050
H323 call-legs: 0
SCCP call-legs: 410
Total call-legs: 1460
is not equal to the initial count. Some call-legs were
Number of call-legs counted during viewing: 1460
SBC03#
SBC03#
SBC03#
SBC03#sh sip-ua call su
Total SIP call legs:1066, User Agent Client:526, User Agent Server:540
SBC03#sh call active voice summary

SIP call-legs: 38
H323 call-legs: 0
SCCP call-legs: 0
Total call-legs: 38
SBC03#sh sip-ua calls summary
Total SIP call legs:44, User Agent Client:19, User Agent Server:25
SBC03#sh call active voice summary
SIP call-legs: 38
H323 call-legs: 0

SCCP call-legs: 0
Total call-legs: 38
Since the above example is only on SIP-SIP calls you can see from active call Summary
No. of SIP-SIP Calls = SIP call leg / 2 = 19
But there can be more on total legs as there can some calls being generated. If you have
MTP/transcoder / conference then those legs will be more than the actual call leg. So we should take
of SIP legs /2 for SIP-SIP calls.
Working concept of SCCP & SIP Phones and the Dial

rules
Introduction
This document intends to help the beginners to understand the basics of IP Telephony. It
explains the working concept of the SCCP & SIP Phones and the Dial rules, digit forwarding methods
to initiate a call.
IP Phone Registration Process

As a prerequisite understand the IP Phone Registration Process. Refer the below link to
understand the SCCP & SIP Phone Registration Process.
IP Phone, SCCP & SIP Phone Registration Process with CUCM
SCCP & SIP Phone Digit forwarding methods

Digit forwarding methods supported,
SCCP Phones: Digit-by-Digit
SIP Phones: Enbloc, KPML (default on newer phones), SIP dial rules
What is KPML?
It is nothing but Keypad Markup Language (KPML). Call came from an SIP Phone using
KPML, CUCM receives, interprets and analyzes the dial plan on a digit-by-digit basis. Cisco
SIP Phones that support KPML use digit-by-digit dialing by default. KPML is not supported
on older SIP Phones. Type A phones.
How SCCP & SIP Phone Works?

SCCP Phones:
Cisco IP Phones using SCCP, TCP port 2000 report every user input even to CUCM
immediately.
As soon as the user goes off-hook, a signaling message is sent from the phone to the
CUCM server with which it is registered. A user goes off-hook and then dials extension
1000. Each event is reported to CUCM in real time.
All the call progress feedback provided by CUCM to the end user on the Cisco IP Phone,
Screen display messages showing calling or called party, dial tone, secondary dial tone,
ring back, reorder tone and so on is initiated by an SCCP message sent from CUCM to
the Cisco IP Phone.
Skinny Client Control Protocol (SCCP) is a stimulus/response protocol where the endpoint
sends user input (stimulus) and expects some type of response from the server instructing
the endpoint about what to do.
Note: - It is not possible to configure dial plan information (dial rules) on Cisco IP Phones
using SCCP. All dial plan functionality is contained in the CUCM cluster with an SCCP
phone.
A user dialing an international pattern that is denied by the end user's CoS deployed in
CUCM will result in the reorder tone ie busy signal that is played to the calling party letting
the party know that the "Call could not be completed as dialed".
If calls to the 976 area code are denied based on the calling party's configured CoS, a
reorder tone is sent to the calling party phone as soon as the user dials 91976.
SIP IP Phones:
Type A SIP Phones: Cisco Unified IP Phone models 7905, 7912,
7940 and 7960
Type A SIP Phones support SIP dial rules, which are configured in CUCM and downloaded
to the IP Phone at boot time. It does not support KPML. SIP dial rules will enable dial tone
and traditional phone functionality on CUCM.
Type A SIP Phones: No Dial rules
Type A Cisco IP Phones using SIP firmware without SIP dial rules do not deliver a dial tone
to the calling party when the calling party goes off-hook with the handset or speaker phone.
All digits are sent to CUCM enbloc after the user completes the dialing and press the Dial
softkey.
Figure shows, User making a call to extension 1000. The user dials 1000 followed by
pressing the Dial soft key. The Cisco IP Phone sends a SIP INVITE message to CUCM with
all dialed digits (enbloc). CUCM performs digit analysis and provides a call progress
message to the IP Phone.
Type A SIP Phones: Dial rules

SIP dial rules allow SIP Phones to emulate the functionality of an SCCP Phone with dial tone
and digit-by-digit pattern analysis. When SIP dial rules are leveraged, a user receives dial
tone when going off-hook. This functionality is different than the default functionality on Cisco
Type A phones converted to SIP, where there are no local dial rules.
Dialed digits are processed against the local SIP dial rules in real time. If a user dials a
phone number that is rejected by the local SIP dial rules, for example pay dialing beginning
with 9-1900 the call is dropped without being forwarded to CUCM. SIP dial rules can help
minimized overhead bandwidth consumption and CUCM processor overhead.
A SIP INVITE message with enbloc signaling is sent from the Cisco SIP IP Phone to CUCM
when the SIP dial rule of the Cisco IP Phone recognizes and permits the dialed pattern. End
user do not need to press the Dial key like they had to on Cisco SIP type A phones. SIP dial
rules allow Type A Phones to emulate SCCP and traditional phone systems while also
providing processing and signaling overhead benefits.
Figure illustrates a phone configured to recognize all four-digit patterns beginning with a
leading digit of 1. This pattern has an associated timeout value of 0. All user input actions
matching the pattern will trigger the sending of the SIP INVITE message to CUCM
immediately, without requiring the user to press the Dial key.
Type B SIP Phones: Cisco IP Phone models 79x1, 79x2, 79x5,

7970 and 7960
Type B and new model phones supports KPML and SIP dial rules. KPML is turned on by
default on all Type B phone models 79x1, 79x2, 79x5, 7970 and7960
Type B SIP Phones: No Dial Rules
Cisco Type B SIP IP Phones offer functionality based on the KPML standard to report user
activities. Each user input event (dialed digit or softkey/button) generates a KPML message
to CUCM. This mode of operation emulates a similar end-user experience to that of phones
using SCCP.
Type B SIP Phones: Dial Rules

Cisco Type B SIP Phones offer functionality based SIP INVITE Message. Every key the end
user presses triggers an individual SIP message. The first event is communicated with a SIP
INVITE, but subsequent messages use SIP NOTIFY messages. The SIP NOTIFY messages
send KPML events corresponding to any buttons or soft keys pressed by the user. Cisco
Type B SIP IP Phones with SIP dial rules operate in the same manner as Cisco Type A
phones with dial rules.
Figure illustrates the enbloc signaling used with SIP dial rules.
Note: Cisco SIP Phones that support KPML use digit-by-digit dialing by default. KPML is not
supported on older Cisco Type A SIP Phones. Type A phones only support enbloc dialing
when using SIP firmware.
UNDERSTANDING SIP TRACES

SIP traces provide key information in troubleshooting SIP Trunks, SIP endpoints and other
SIP related issues. Even though these traces are in clear text, these texts can be gibberish
unless you understand fully what they mean.
This document attempts to break down each component of the SIP interaction using a
practical approach. We will look at various logs, the SIP messages, headers, SDP information
and try to figure out what is going on in a sip voice call transaction.
In as much as I will try to define the under lying layer of the SIP messaging, this document
will not go into in-depth analysis of the SIP protocol, so it is advisable to understand SIP
protocol technology to be able to understand sip traces.
One key element of troubleshooting is this: To fix a problem, you need to understand the
issue, how it works before you can restore it to order.
One popular debug used in troubleshooting a sip solution on a cisco IOS router is
Debug ccsip messages.
To understand The output generated by this debug..We need to understand the

Key/fundamental sip messages exchanged during a sip voice call..
1. Invite
2. Trying
3. Ringing
4. ACK
5. OK
We will look at these messages as we try to understand the debugs. These messages are key
in knowing whats going on. They help us to understand the language been spoken so we
are not lost like a non French speaking man in Paris!
Ok enough of grammars, lets dive in! Ready?
INVITE:
An Invite is a SIP requests called methods. There are Six SIP methods described in the SIP
specification document RFC 3261 [1].
The INVITE, REGISTER, BYE, ACK, CANCEL, and OPTIONS methods are the original six
methods
in SIP.
The INVITE method is used to establish media sessions between user agents. In
telephony, it is similar to a Setup message in ISDN
An INVITE usually has a message body containing the media information

of the caller. The message body can also contain other session information, such
as a resource list in the case of an early offer. If an INVITE does not contain media
information, the ACK contains the media information of the UAC.
To identify the caller, the called number, the media information and resources advertised in
the Invite, SIP invites use headers. Headers are key parameters within the SIP invite and we
shall look at them so as to gain full clarity of whats going on.
Lets look at a sample SIP trace from CUCM. Note this is very similar to what a debug ccsip
messages will produce on a CUBE gateway.
Here is the call setup for this trace
CUCM----------sip trunk------>CUBE---------SIP Trunk--------------->ITSP

(10.105.80.114)
(10.105.80.174)
INVITE with SDP.
INVITE sip:14107154522807@10.105.80.174:5060 SIP/2.0

Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6
From: "Solihull" <sip:01214248526@10.105.80.114>;tag=25526~ffa80926-5fac-4dd6-b4052dbbc56ae9a2-551664735
To: <sip:14107584528207@10.105.80.174>
Date: Mon, 02 Apr 2012 18:12:31 GMT
Call-ID: 68781700-f791ec0f-2d26-e28690a@10.105.80.114
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:10.105.80.114:5060>;method="NOTIFY;Event=telephoneevent;Duration=500"
Cisco-Guid: 1752700672-0000065536-0000007823-0237529354
Session-Expires: 84600
Contact: <sip:01214248526@10.105.80.114:5060>
Max-Forwards: 70
Content-Length: 0
Content-Type: application/sdp
Content-Length: 238
v=0
o=CiscoSystemsCCM-SIP 811669 1 IN IP4 10.105.40.14
s=SIP Call
c=IN IP4 10.133.92.102
t=0 0
m=audio 25268 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Now lets break it up or dissect this piece of information.
As we can see there are lots of headers in this invite
Via
To
From
Call-ID
CSeq
Contact
Max-Forwards
Expires
The INVITE header

INVITE sip:14107584528207@10.105.80.174:5060 SIP/2.0
This is the first part of the trace usually refrred to as the Request-URI This shows four key
things
1. The called number

2. The device responsible for the called number or the device through which the called
number will be routed
3. SIP Port number
4. Sip Version..
So here we see the called number is: 14107584528207

The gateway responsible for routing to this number is 10.105.80.174
SIP port is 5060 and the Sip version is 2.0
The Via Header:
Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6
The required Via header field is used to record the SIP route taken by a request
and is used to route a response back to the originator. A UA generating a request
records its own address in a Via header field.
Here we see that CUCM is the UA generating this invite and it stamps it IP on the call. This
helps identify the origin of the call.
Via header fields contain protocol name, version number, and transport
(SIP/2.0/UDP, SIP/2.0/TCP, etc)
The To and From Headers
From: <sip:01214248526@10.105.80.114>;tag=25526~ffa80926-5fac-4dd6-b4052dbbc56ae9a2-551664735
To: sip:14107584528207@10.105.80.174
The next header fields are the To and From header fields, which show the
originator and destination of the SIP request.
Note that the To and From header fields are not reversed in the response message as one
might expect them to be. This is because the To and From header fields in SIP are defi ned
to indicate the direction of the request, not the direction of the message. Since
<sip:01214248526@10.105.80.114 initiated this request, all responses to this INVITE will
read
To: sip:14107584528207@10.105.80.174
From: <sip:01214248526@10.105.80.114.
Date Header:
A key component of the sip message. Its tells us the time of the sip request.
Call ID:
Call-ID: 68781700-f791ec0f-2d26-e28690a@10.105.80.114
The Call-ID header field is an identifier used to keep track of a particular SIP session. The
originator of the request creates a locally unique string. Some older implementations also
add an @ and its host name to the string. The initiator of the session that generates the
establishing INVITE generates the unique Call-ID and From tag.
The Call ID is one of the key components used in troubleshooting. Each UA generates its
own Call ID. Sowhen a call originates from CUCM, CUCM generates its own call id and when
a call origate from the CUBE, CUBE generate its own call ID.
Cseq Header:
CSeq: 101 INVITE
The command sequence CSeq header field is a required header field in every request. The
CSeq header field contains a decimal number that increases for each request. Usually, it
increases by 1 for each new request, with the exception of CANCEL and ACK requests, which
use the CSeq number of the INVITE request to which it refers. The CSeq count is used by
UASs to determine out-of-sequence requests or to differentiate between a new request
(different CSeq) or a retransmission (same CSeq). The CSeq header fi eld is used by UACs to
match a response to the request it references
User Agent Header:
User-Agent: Cisco-CUCM8.6
This header identifies the UA that is originating this request/response. In this trace we can
see that the UA above is CUCM version 8.6.The user agent header helps identify the
originator of the request/response.
SDP Extensions and Attributes
The SDP extensions used in the application/SDP header lists the media capabilities the
calling party is willing to receive or negotiate or support for the session. The table below
shows the SDP attributes in this test call and the meaning of each attribute/extension.
Please note that The RFC 3264[17] specifies that the attributes containing a=rtpmap
should be used for each media field
SDP Parameter Parameter
Name
v=0
Version Number
o=CiscoSystemsCCM-SIP 811669 1 IN IP4

10.105.40.14
Origin
s=SIP Call
Call Subject
c=IN IP4 10.133.92.102
Connection/IP address for RTP stream
t=0 0
time
Media
a=rtpmap:18 G729/8000
Attributes-media
a=ptime:20
Attributes-Packetization
Dtmf attributes
a=fmtp:101 0-15
Dtmf tones
Lets look at media attributes below
m=audio 25268 RTP/AVP 18 0 8 101
This line defines the media attribtes that will be used for the call.
Audio:
Video call
25268:
means that this is an Audio call, we can also have m=video in case of a
Is the dynamic RTP port used for the call
RTP/AVP: Represents the RTP/AVP profile number for each of the profiles listed.
The profile numbers are explained below
18=G729
0=PCMU
8=PCMA
101=rtp-nte payload
DISSECTING A SIP TRACE
Now we have looked at the basics of sip headers and messages, lets use this to understand
the following sip trace
The call flow for this call is as shown:
PSTN-------->ITSP------->CUBE--------------->CUCM---------------->IP PHONE
ITSP: 10.10.33.132
CUBE:10.100.0.74
CUCM:10.100.0.14
1. An inbound call is received on the CUBE from the ITSP. This invite was sent with SDP. NB
that this inbound leg of this call will have a unique call ID that shows the origin of the call,
highlighted below.
Received:
INVITE sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bK9377fo00cg5ha7l0g3t0.1
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=15264387271338998848384To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267841 INVITE
Contact: <sip:07455900064@10.10.33.24:5070;transport=udp>
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY
Accept: multipart/mixed,application/media_control+xml,application/sdp
Supported:
Max-Forwards: 69
Content-Length: 207
v=0
o=BroadWorks 161384582 1 IN IP4 10.10.33.132
s=c=IN IP4 10.10.33.132
t=0 0
m=audio 11164 RTP/AVP 18 0 8 101
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
+++From our understanding of the traces, we see that the call originates from a device
called Broadworks, which advertises G711a, G711u, G729 and uses rtp-nte for DTMF. We
also see the IP address for the CUBE to stream its RTP to.+++++
2. A new Invite Sent to CUCM.

After the CUBE receives the invite, it sends an invite to cucm based on the dial-peers
configured.
NB: that this new invite is sent with a new CALL-ID. This is very important in understanding
the order of thigs especially when troubleshooting issues. We can also see that the CUBE
advertises all its SDP attributes, codec, dtmf supported, fax etc.
002791: Jun 6 16:07:28.394: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

Sent:
INVITE sip:901926653485@10.100.0.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953C1859
Remote-Party-ID: <sip:07455900064@10.100.0.74>;party=calling;screen=no;privacy=off
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: 8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2352544350-2938638817-2514718541-1568562753
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1338998848
Contact: <sip:07455900064@10.100.0.74:5060;transport=tcp>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 68
Content-Disposition: session;handling=required
Content-Length: 355
v=0
o=CiscoSystemsSIP-GW-UserAgent 8773 2764 IN IP4 10.100.0.74
s=SIP Call
c=IN IP4 10.100.0.74
t=0 0
m=audio 19264 RTP/AVP 18 0 8 100 101
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=fmtp:101 0-15
3. Next the CUBE sends a trying to ITSP. Trying simply means: I am looking for the number
you have requested.

Sent:
SIP/2.0 100 Trying
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=15264387271338998848384To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID:
BW1807283840606121067600210@212.136.178.216

Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
4. Next the CUBE receives a trying from CUCM. The call-ID help us to know where these
responses are coming from.

Received:
SIP/2.0 100 Trying
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0
5. Next the CUBE receives ringing from CUCM This informs the CUBE that the called
endpoint is ringing

Received:
SIP/2.0 180 Ringing
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
To: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b4052dbbc56ae9a2-477917854
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID:
8C394872-AF2811E1-95E98F4D-5D7E5E41@10.100.0.74
CSeq: 101 INVITE

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: presence
Content-Length: 0
6. The CUBE relays this message to the calling party

Sent:
SIP/2.0 180 Ringing
From: <sip:07455900064@212.136.178.216:5060;user=phone>;tag=15264387271338998848384To: "voice-lab-aokanlawon"<sip:441127653485@pbx.emea.ipcom.com>;tag=4C85763E1CF8
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID:
BW1807283840606121067600210@212.136.178.216

Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off
Contact: <sip:901127653485@10.100.0.74:5060>
Content-Length: 0
7. Now the CUBE receives a 200 ok from CUCM. Please note that some elements of the SDP
has changed
c=IN IP4 10.100.20.10------------------------IP address to send RTP stream to

t=0 0 -------------------------------------------Duration of the call
m=audio 16730 RTP/AVP 18 101---------Codec to use for call and DTMF type to use
a=rtpmap:18 G729/8000-------------------Codec = G729

Received:
SIP/2.0 200 OK
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
Supported: replaces
Session-Expires: 84600;refresher=uas
Require: timer
Content-Length: 237
v=0
s=SIP Call
c=IN IP4 10.100.20.10
t=0 0
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=fmtp:101 0-15
8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message

Sent:
ACK sip:901127653485@10.105.40.14:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7953DC95
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
Max-Forwards: 70
CSeq: 101 ACK
Content-Length: 0
9. CUBE then sends a 200 OK to ITSP with the SDP attributes to use for the Call based on
what it received from CUCM.
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.14:5060;branch=z9hG4bK198a0b7ee5d33c
From: <sip:901127653485@10.100.0.14>;tag=811674~ffa80926-5fac-4dd6-b4052dbbc56ae9a2-477917854
To: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
CSeq: 101 SUBSCRIBE
Content-Length: 0
Expires: 7200
Sent:
SIP/2.0 200 OK
Date: Wed, 06 Jun 2012 16:07:28 GMT
Call-ID: BW1807283840606121067600210@212.136.178.216

Remote-Party-ID: <sip:901926653485@10.100.0.74>;party=called;screen=no;privacy=off
Contact: <sip:441127653485@10.100.0.74:5060>
Supported: replaces
Supported: sdp-anat
Supported: timer
Content-Length: 270
v=0
s=SIP Call
c=IN IP4 10.100.0.74
t=0 0
c=IN IP4 10.100.0.74
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
10. CUBE then receives an ACK

002803: Jun 6 16:07:28.594: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
ACK sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0.1
Call-ID:
BW1807283840606121067600210@212.136.178.216
CSeq: 558267841 ACK
Contact: <sip:07455900064@10.10.33.24:5070;transport=udp>
Max-Forwards: 69
Content-Length: 0
11. Finally the call is ended. Now when troubleshooting the direction of call termination is
important. In this case we can see that the CUBE receives a BYE, which is the sip method for
call termination. However who sent the BYE, is it CUCM or ITSPThe answer is in the Call-ID.
As we call can see the CALL-ID is for the leg from the ITSP. So we see that the call was
terminated from the ITSP side.
Next important thing is the cause code. The reason why the call was terminated.
CSeq: 558267842 BYE

Reason: Q.850;cause=16
Here we see as normal call clearing Cause=16.
Received:
BYE sip:441127653485@10.100.0.74:5060 SIP/2.0
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1
Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267842 BYE
Max-Forwards: 69
Content-Length: 0
002809: Jun 6 16:07:34.470: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.33.24:5070;branch=z9hG4bKfj8rji3008r0m4lbg7e0cd1hhq713.1
Date: Wed, 06 Jun 2012 16:07:34 GMT

Call-ID: BW1807283840606121067600210@212.136.178.216
CSeq: 558267842 BYE
P-RTP-Stat: PS=295,OS=5900,PR=292,OR=5840,PL=0,JI=0,LA=0,DU=5
Content-Length: 0
Sent:
BYE sip:901127653485@10.100.0.14:5060;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:28 GMT
Max-Forwards: 70
CSeq: 103 BYE
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.100.0.74:5060;branch=z9hG4bK7954021A8
From: <sip:07455900064@10.100.0.74>;tag=4C85762C-1A2D
Date: Wed, 06 Jun 2012 16:07:34 GMT
CSeq: 103 BYE
Content-Length: 0
Below are a few of the Threads that we have used the indepth understanding of sip trcaes
to help resolve thier issues. Please take a look as this will help you to understand better sip
traces and how they play a key part in troubleshooitng issues
Introduction
This document explains the basic SIP Call flow between the PBX, Gateways and SIP
Phones in detail. Idea of creating this document is to help the beginners to
understand the Various SIP Call flows and messages. Also this document covers the
SIP Troubleshooting commands.
Prerequisites
Basic knowledge about the SIP Protocol and the call flow Messages.
Call Flow Examples

1. Call Flow between PBX to Cisco SIP IP PhoneSuccessful
Setup and Disconnect
Below diagram illustrates a successful gateway-to-Cisco SIP IP phone call setup and
disconnect. In this scenario, the two end users are User A and User B. User A is located at
PBX A. PBX A is connected to Gateway 1 (SIP Gateway) via a T1/E1. User B is located at a
Cisco SIP IP phone. Gateway 1 is connected to the Cisco SIP IP phone over an IP network.
The call flow is as follows:
1. User A calls User B.
2. User B answers the call.
3. User B disconnects the call.
Step
Action
Description
1.
SetupPBX A to
Gateway 1
Call Setup is initiated between PBX A and Gateway 1. The

Call Setup includes the standard transactions that take place
as User A attempts to call User B.
2.
INVITEGateway
1 to Cisco SIP IP
phone
Gateway 1 maps the SIP URL phone number to a dial peer.

The dial peer includes the IP address and the port number of
the SIP-enabled entity to contact. Gateway 1 sends a SIP
INVITE request to the address it receives as the dial peer,
which, in this scenario, is the Cisco SIP IP phone.
In the INVITE request:
The IP address of the Cisco SIP IP phone is inserted in the

Request-URI field.
PBX A is identified as the call session initiator in the From

field.
A unique numeric identifier is assigned to the call and is
inserted in the Call-ID field.
The transaction number within a single call leg is identified

in the CSeq field.
The media capability User A is ready to receive is specified.
The port on which the Gateway is prepared to receive the

RTP data is specified.
3.
Call Proceeding
Gateway 1 to PBX
A
Gateway 1 sends a Call Proceeding message to PBX A to

acknowledge the Call Setup request.
4.
100 TryingCisco
SIP IP phone to
Gateway 1
The Cisco SIP IP phone sends a SIP 100 Trying response to

Gateway 1. The 100 Trying response indicates that the
INVITE request has been received by the Cisco SIP IP
phone.
5.
180 Ringing
Cisco SIP IP phone
to Gateway 1
The Cisco SIP IP phone sends a SIP 180 Ringing response

to Gateway 1. The 180 Ringing response indicates that the
user is being alerted.
6.
AlertingGateway
1 to PBX A
Gateway 1 sends an Alert message to User A. The Alert

message indicates that Gateway 1 has received a 180
Ringing response from the Cisco SIP IP phone. User A hears
the ringback tone that indicates that User B is being alerted.
7.
200 OKCisco
SIP IP phone to
Gateway 1
The Cisco SIP IP phone sends a SIP 200 OK response to

Gateway 1. The 200 OK response notifies Gateway 1 that the
connection has been made.
8.
ConnectGateway
1 to PBX A
Gateway 1 sends a Connect message to PBX A. The

Connect message notifies PBX A that the connection has
been made.
9.
Connect ACK
PBX A to Gateway
1
PBX A acknowledges Gateway 1's Connect message.
10.
ACKGateway 1
to Cisco SIP IP
phone
Gateway 1 sends a SIP ACK to the Cisco SIP IP phone. The

ACK confirms that Gateway 1 has received the 200 OK
response. The call session is now active.
11.
BYECisco SIP IP
phone to Gateway
1
User B terminates the call session at his Cisco SIP IP phone

and the phone sends a SIP BYE request to Gateway 1. The
BYE request indicates that User B wants to release the call.
12.
Disconnect
Gateway 1 to PBX
A
Gateway 1 sends a Disconnect message to PBX A.
13.
ReleasePBX A
to Gateway 1
PBX A sends a Release message to Gateway 1.
14.
200 OKGateway
1 to Cisco SIP IP
phone
Gateway 1 sends a SIP 200 OK response to the Cisco SIP IP

phone. The 200 OK response notifies the phone that
Gateway 1 has received the BYE request.
15.
Release
Complete
Gateway 1 to PBX
A
Gateway 1 sends a Release Complete message to PBX A

and the call session is terminated.
2. Call flow between Gateway-to-Cisco SIP IP Phone Call

Successful Call Setup and Call Hold
Below diagram illustrates a successful gateway-to-Cisco SIP IP phone call setup and call
hold. In this scenario, the two end users are User A and User B. User A is located at PBX A.
PBX A is connected to Gateway 1 (SIP Gateway) via a T1/E1. User B is located at a Cisco
SIP IP phone. Gateway 1 is connected to the Cisco SIP IP phone over an IP network.
The call flow is as follows:
3. User B puts User A on hold.
4. User B takes User A off hold.
Step
Action
Description
1.
SetupPBX A to
Gateway 1
Call setup is initiated between PBX A and Gateway 1. The

call setup includes the standard transactions that take place
as User A attempts to call User B.
2.
INVITEGateway
1 to Cisco SIP IP
phone
Gateway 1 maps the SIP URL phone number to a dial peer.

The dial peer includes the IP address and the port number of
the SIP enabled entity to contact. Gateway 1 sends a SIP
INVITE request to the address it receives as the dial peer,
which, in this scenario, is the Cisco SIP IP phone.
The IP address of the Cisco SIP IP phone is inserted in the

Request-URI field.
PBX A is identified as the call session initiator in the From

field.
The transaction number within a single call leg is identified

in the CSeq field.
The port on which the gateway is prepared to receive the

RTP data is specified.
3.
Call Proceeding
Gateway 1 to PBX
A
Gateway 1 sends a Call Proceeding message to PBX A to

acknowledge the Call Setup request.
4.
100 TryingCisco
SIP IP phone to
Gateway 1
The Cisco SIP IP phone sends a SIP 100 Trying response to

Gateway 1. The 100 Trying response indicates that the
INVITE request has been received by the Cisco SIP IP
phone.
5.
180 Ringing
Cisco SIP IP phone
to Gateway 1
The Cisco SIP IP phone sends a SIP 180 Ringing response

to Gateway 1. The 180 Ringing response indicates that the
user is being alerted.
6.
AlertingGateway
1 to PBX A
Gateway 1 sends an Alert message to User A. The Alert

message indicates that Gateway 1 has received a 180
Ringing response from the Cisco SIP IP phone. User A hears
the ringback tone that indicates that User B is being alerted.
7.
200 OKCisco
SIP IP phone to
Gateway 1
The Cisco SIP IP phone sends a SIP 200 OK response to

Gateway 1. The 200 OK response notifies Gateway 1 that the
connection has been made.
8.
ConnectGateway
1 to PBX A
Gateway 1 sends a Connect message to PBX A. The

Connect message notifies PBX A that the connection has
been made.
9.
ACKGateway 1
to Cisco SIP IP
phone
Gateway 1 sends a SIP ACK to the Cisco SIP IP phone. The

ACK confirms that User A has received the 200 OK response.
The call session is now active.
10.
Connect ACK
PBX A to Gateway
1
PBX A acknowledges Gateway 1's Connect message.
11.
INVITECisco SIP
IP phone to
Gateway 1
User B puts User A on hold. The Cisco SIP IP phone sends a

SIP INVITE request to Gateway 1.
12.
200 OKGateway
1 to Cisco SIP IP
phone

phone. The 200 OK response notifies the Cisco SIP IP phone
that the INVITE was successfully processed.
13.
ACKCisco SIP IP
phone to Gateway
1
The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The

ACK confirms that the Cisco SIP IP phone has received the
200 OK response. The call session is now temporarily
inactive. No RTP packets are being sent.
14.
INVITECisco SIP
IP phone to
Gateway 1
User B takes User A off hold. The Cisco SIP IP phone sends
a SIP INVITE request to Gateway 1.
15.
200 OKGateway
1 to Cisco SIP IP
phone

phone. The 200 OK response notifies the Cisco SIP IP phone
that the INVITE was successfully processed.
16.
ACKCisco SIP IP
phone to Gateway
1
The Cisco SIP IP phone sends a SIP ACK to Gateway 1. The

ACK confirms that the Cisco SIP IP phone has received the
200 OK response. The call session is now active.
3. Call flow between Cisco SIP IP Phone-to-Cisco SIP IP

Phone Simple Call Hold
Below diagram illustrates a successful call between Cisco SIP IP phones in which one of the
participants places the other on hold and then returns to the call. In this call flow scenario,
the two end users are User A and User B. User A and User B are both using Cisco SIP IP
phones, which are connected via an IP network.
The call flow scenario is as follows:
3. User B places User A on hold.

4. User B takes User A off hold.
5. The call continues.
Step
1.
Action
Description
INVITECisco
SIP IP phone A
to Cisco SIP IP
phone B
Cisco SIP IP phone A sends a SIP INVITE request to Cisco SIP

IP phone B. The INVITE request is an invitation to User B to
participate in a call session.
The phone number of User B is inserted in the Request-URI

field in the form of a SIP URL. The SIP URL identifies the
address of User B and takes a form similar to an e-mail
address (user@host, where user is the telephone number
and host is either a domain name or a numeric network
address). For example, the Request-URI field in the INVITE
request to User B appears as "INVITE sip:5550002@companyb.com; user=phone." The "user=phone"

parameter distinquishes that the Request-URI address is a
telephone number rather than a username.
Cisco SIP IP phone A is identified as the call session initiator

in the From field.

The transaction number within a single call leg is identified in

the CSeq field.
2.
180 Ringing
Cisco SIP IP
phone B to
Cisco SIP IP
phone A
Cisco SIP IP phone B sends a SIP 180 Ringing response to

Cisco SIP IP phone A.
3.
200 OKCisco
SIP IP phone B
to Cisco SIP IP
phone A
Cisco SIP IP phone B sends a SIP 200 OK response to Cisco

SIP IP phone A. The 200 OK response notifies Cisco SIP IP
phone A that the connection has been made.
ACKCisco
SIP IP phone A
to Cisco SIP IP
phone B
Cisco SIP IP phone A sends a SIP ACK to Cisco SIP IP phone

B. The ACK confirms that Cisco SIP IP phone A has received
the 200 OK response from Cisco SIP IP phone B.
4.
If Cisco SIP IP phone B supports the media capability advertised

in the INVITE message sent by Cisco SIP IP phone A, it
advertises the intersection of its own and Cisco SIP IP phone A's
media capability in the 200 OK response. If Cisco SIP IP phone
B does not support the media capability advertised by Cisco SIP
IP phone A, it sends back a 400 Bad Request response with a
304 Warning header field.
The ACK might contain a message body with the final session
description to be used by Cisco SIP IP phone B. If the message
body of the ACK is empty, Cisco SIP IP phone B uses the
session description in the INVITE request.
A two-way RTP channel is established between Cisco SIP IP phone A and Cisco SIP IP
phone B.
5.
INVITECisco
SIP IP phone B
to Cisco SIP IP
phone A
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP

phone A with new Session Description Protocol (SDP) session
parameters (IP address), which are used to place the call on
hold.
Call_ID=1
SDP: c=IN IP4 0.0.0.0
The c= SDP field of the SIP INVITE contains an 0.0.0.0. This

places the call in hold.
6.
200 OKCisco
SIP IP phone A
to Cisco SIP IP
phone B
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco

SIP IP phone B.
7.
ACKCisco
SIP IP phone B
to Cisco SIP IP
phone A
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone

A. The ACK confirms that Cisco SIP IP phone B has received
the 200 OK response from Cisco SIP IP phone A.
The RTP channel between Cisco SIP IP phone A and Cisco SIP IP phone B is torn down.
8.
INVITECisco
SIP IP phone B
to Cisco SIP IP
phone A
Cisco SIP IP phone B sends a mid-call INVITE to Cisco SIP IP

phone A with the same call ID as the previous INVITE and new
SDP session parameters (IP address), which are used to
reestablish the call.
Call_ID=1
SDP: c=IN IP4 181.23.250.2
To reestablish the call between phone A and phone B, the IP

address of phone B is inserted into the c= SDP field.
9.
200 OKCisco
SIP IP phone A
to Cisco SIP IP
phone B
Cisco SIP IP phone A sends a SIP 200 OK response to Cisco

SIP IP phone B.
10.
ACKCisco
SIP IP phone B
to Cisco SIP IP
phone A
Cisco SIP IP phone B sends a SIP ACK to Cisco SIP IP phone

A. The ACK confirms that Cisco SIP IP phone B has received
the 200 OK response from Cisco SIP IP phone A.
A two-way RTP channel is reestablished between IP phone A and IP phone B.
Defining SIP Port in Cisco Unified Communications Manager
SIP Troubleshooting
On Unified Communications Manager use RTMT to check SIP traces in UC Manager
"debug ccsip calls"
"debug ccsip all"
"debug ccsip error"
"debug ccsip events"
"debug ccsip messages"
"debug ccsip states"
"show sip-ua call"

- Displays active UAC and user agent server (UAS) information on sip calls
" show call active voice brief"

- Displays active call information for voice calls or fax transmission in progress
Check MTP configuration

- MTP is required for Early offer
- MTP is required on older UC Manager versions to provide supplementary services
Check layer 2/3 variables
Dial-peer Codec Selection, CUCM Region Settings

And Transcoders IN A SIP Deployment
INTRODUCTION
This document is to demonstrate how codec negotiation is done between calls involving
CUBE, SIP Trunks, CUCM, IP Phones and Cisco Unity connection. In some scenarios a
transcoder will be invoked and we shall look at why and how to properly design your
network to know if you need a transcoder or not.
This will be based on a very practical approach as seen from a production environment. The
call flow will be divided into different call scenarios and we will examine what codec is used
for each call and if a transcoder is needed or not. Each of the call scenarios will also be
discussed based on the direction of the call; Inbound or Outbound. This is because different
rules apply depending on which direction the call originates and terminate.
The region settings involved in each of the call flow will also be considered as they play a key
role in codec negotiation.
NB: Some of the call scenario use voice-class codec on the dial-peers. There is a general
good practice on using voice-class codec on CUBE.
for voice-class codec to work well on cube, ensure the codec preference and order is the same on
both inbound and outbound dial-peer.
THE ENVIRONMENT
This environment is a cluster of 8 CUCM servers with four call processing servers (CUCM
service activated), two Unity connection clustered servers and two CUBES
CUCM version: 8.6.2.21900-5
CUBE IOS version:c3900e-universalk9-mz.SPA.151-4.M4.bin
IP Phones: 7940 and 7960

Unity connection with Sip trunk Integration:8.6.2.21900-5
CUBE is configured with early offer forced; hence all traffic from CUBE goes out with
advertised SDP.
Voice service voip
sip
early-offer forced
CUCM does delayed offer.
INBOUND CALLS
Lets start with inbound calls:
CALL SCENARIO 1, CALL FLOW
ITSP--------sip----------->CUBE--------sip----->CUCM----sccp---->IP Phone
SCENARIO 1------Inbound call to an IP Phone(no xcoder invoked)
++++Inbound dial-peer to CUBE++++
modem passthrough nse codec g711ulaw
incoming called-number .
voice-class codec 1
dtmf-relay sip-kpml rtp-nte
+++++Outbound dial-peer config to CUCM++++
description Inbound calls to CUCM
translation-profile outgoing IN_PORT
destination-pattern 44T
session target ipv4:10.10.4.74
session transport tcp
dtmf-relay rtp-nte digit-drop h245-alphanumeric
voice-class codec 1
fax rate disable
Region between phone and cube is set to use G711. Inbound and outbound dial-peer set to
use voice class codec with g729 as preferred codec
CALL ANALYSIS
1. Call arrives on CUBE and matched inbound DP=1 with voice-class codec set.
2. Call matches outbound dial-peer 50, voice-class codec set
3. When a voice-class is configured on a DP, the codec used will depend on the region
setting between the source and the destination. Here, the source is cube (sip trunk), the
destination is an IP Phone. Because the region setting between the CUBE and IP Phone is
G711, the call will use G711. The region setting becomes the prevailing factor here. CUCM
will send a 200 OK to the invite received from CUBE with the codec set between the
endpoint and destination. In actual fact whatever the region setting between the IP phone
and the CUBE is, thats the codec that will be used. If its G729, then the call will use G729.
An abbreviated trace is shown below:
Cube receives invite from ITSP with early offer and all supported codecs
Received:
INVITE sip:441925573222@10.10.4.174:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKeao3hl307oi03u4716b0.1
From: <sip:078969786543@212.136.178.216:5060;user=phone>;tag=4516878931338998863036To: " -SPK TestGrid"<sip:441925573222@pbx.testGridemea.globalipcom.com>
v=0
s=c=IN IP4 10.10.10.10
t=0 0
m=audio 15382 RTP/AVP 18 0 8 101-------------Advertised CODECS
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends invite to cucm with early offer and codecs matched on voice-class codec
Sent:
INVITE sip:901925573222@10.10.4.14:5060 SIP/2.0

Via: SIP/2.0/TCP 10.10.4.174:5060;branch=z9hG4bK7954A198F
From: <sip:078969786543@10.10.4.174>;tag=4C85AF62-DA1
To: <sip:901925573222@10.10.4.14>
v=0
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 16668 RTP/AVP 18 0 8 100 101--------->CUBE advertises Codec to CUCM
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:100 192-194
a=fmtp:101 0-15
After a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint
codec and IP.
Codec chosen based on the region between endpoint and CUBE sip trunk (CUBECUBE in this case)
Received:
SIP/2.0 200 OK
To: <sip:901925573222@10.10.4.14>;tag=811681~ffa80926-5fac-4dd6-b4052dbbc56ae9a2v=0
s=SIP Call
c=IN IP4 10.54.117.13------RTP sent directly to IP Phone
t=0 0
a=rtpmap:0 PCMU/8000---------------G711Ulaw selected to use for the call
a=ptime:20
a=fmtp:101 0-15
A show voip rtp connection shows the flow of RTP stream for the two call legs
Sh voip rtp connection:
13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 (ITSP-CUBE)
14 91499 91498 17432 25092 10.10.4.174 10.54.117.13 (CUBE to IP phone)
Scenario 2, Call Flow
ITSP--------sip----------->CUBE(1)--------sip----->CUCM---->Ip Phone
<---------------------G729-------------------------> (Reg btw IP phone-Cube)
SCENARIO 2------Inbound call to an IP Phone(xcoder invoked)
voice-class codec 1

codec g711ulaw
fax rate disable
Region between phone and cube is set to use G729. Outbound dial-peer is hard coded to
use g711ulaw
CALL ANALYSIS
2. Call matches outbound dial-peer 50, codec set to G711ulaw
3. At this point regardless of the region setting between the ip phone and cube or sip trunk
to the CUBE, G711u will be used. This is because the CUBE sends an early offer with only
g711ulaw advertised. So CUCM is forced to send an ACK back with only g711u as the codec
to use for the call. The region setting between the phone and cube will now determine if a
xcoder is invoked or not. Since the region setting between the phone and CUBE is set to
G729 in this case, a xcoder must be invoked and available otherwise the call will fail.
The two call legs look like this:
Callleg1=g711..inbound call leg to CUBE (DP Is set to G711ulaw
Callleg2=G729.outbound call leg to ip phone (region between phone and cube=g729).
In this case which I looked at, the system was not properly designed; hence there was no
transcoder available for use in the MRGL of the cube.
NB: There was a transcoder in the MRG but the region between the CUBE and the
transcoder was set to G729. Hence the CUBE couldnt use it. CUCM however found a
transcoder in the default MRGL which was an unassigned transcoder. The problem with this
is, the system administrators had no idea that calls were been redirected to this transcoder.
After a while users started reporting that calls come into their phone and they are unable to
pick up. When they pickup the headset, calls dont connect. This was because the remote
transcoder in use didnt have enough sessions on it to support the call traffic redirected to
it. The system was not designed for this transcoder to be used; hence no one made such
provisions.
This is why its crucial to design your system very well and to understand each element of
your solution and how they interact.
Received:
INVITE sip:441925573222@10.10.4.174:5060 SIP/2.0

v=0
s=c=IN IP4 10.10.10.10
t=0 0
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends invite to cucm with early offer and G711 as the only advertised codec
Sent:
INVITE sip:901925573222@10.10.4.14:5060 SIP/2.0
To: <sip:901925573222@10.10.4.14>
v=0
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 16668 RTP/AVP 0 100101-------->CUBE advertises G711u Codec to CUCM

c=IN IP4 10.10.4.174
a=fmtp:100 192-194
a=fmtp:101 0-15
CUCM sends a 200 OK, agreeing on G711ulaw as the codec to use and the Xcoder IP
for RTP streaming
Received:
SIP/2.0 200 OK
s=SIP Call
c=IN IP4 10.10.10.40------>RTP sent directly to Xcoder
t=0 0
a=rtpmap:0 PCMU/8000--------------->G711Ulaw selected to use for the call
a=ptime:20
a=fmtp:101 0-15
A show voip rtp connection shows the flow of RTP stream for the two call legs
Show voip rtp conn on CUBE

VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 175914 175915 17600 19092 10.10.4.174 10.10.10.10 (ITSP-->CUBE)
2 175915 175914 28214 29680 10.10.4.174 10.10.10.40 (CUBE--->Xcoder)
Show sccp conn on transcoder
sess_id conn_id stype mode codec sport rport ripaddr

536967492 537049324 xcode sendrecv g729ab 31246 16384 10.24.14.79 (region to xcoder
=g729)
536967492 537049323 xcode sendrecv g711u 29680 28214 10.10.4.174 (reg to
xcoder=G711)This is the device that invoked the xcoder
Scenario 3, Call Flow

ITSP--------sip----------->CUBE(1)--------sip----->CUCM---->IP Phone---CFWDall--->CUBE(2)---->ITSP
<----------------G729-------------------->(cubetoiphone=g729)
<------------------------------G729------------------------------------->(cubetocube=g729)
SCENARIO 3------CALL FORWARDING
Scenario 3, an inbound call comes to an IP phone via CUBE. The IP phone has a CFWdall set
to a cell phone.
Configurations:
+++Voice-class codec++++
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711ulaw
codec preference 3 g711alaw
voice-class codec 1

codec g711ulaw
fax rate disable
Region Settings between CUBE= G.729, region setting between cube and IP Phone=g729
CALL ANALYSIS
1. Call arrives on CUBE and matched DP=1 with voice-class codec set.

g711ulwa advertised. So CUCM is forced to send an ACK back with only g711u as the codec
to use for the c all.
4. When the call arrived on ip phone, it was cfwdall to a cell, hence the call goes out via the
same CUBE again (hairpinned)
5. Hence RTP connection is setup inbound to cube and outbound to cube. So in this case the
second call leg of the call will be between CUBE-CUBE
Now the region setting between CUBE-CUBE=G729.
So we have a call flow like this:
Callleg1=g711
Callleg2=G729
Hence a xcoder is needed. The CUBE invokes a xcoder. If there is no transcoder available,
then this call will fail.
Here is a trace for the call with only the relevant bits shown:
Invite received from ITSP with early offer and SDP capabilities
Received:
INVITE sip:441708659780@10.10.4.20:5060 SIP/2.0
Via: SIP/2.0/UDP 10.106.33.24:5070;branch=z9hG4bKefn9r620a8p1h5dr1681.1
From: <sip:17086598000@212.136.178.216:5060;user=phone>;tag=2866522691336598892064To: "solihull-SPK TestGrid"<sip:441708659780@pbx.testGridemea.globalipcom.com>
Content-Length: 207
v=0
s=c=IN IP4 10.10.10.10

t=0 0
m=audio 17652 RTP/AVP 18 0 8 101
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
Invite sent to CUCM with only G711u advertised
Sent:
INVITE sip:901708659780@10.10.4.14:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.4.20:5060;branch=z9hG4bK375566FA
From: <sip:17086598000@10.10.4.20>;tag=306F1686-1BE5
To: <sip:901708659780@10.10.4.14>
Date: Wed, 09 May 2012 21:28:12 GMT
Call-ID: B6C874A3-995411E1-973ED5AE-7283D592@10.10.4.20
Min-SE: 1800
Cisco-Guid: 3066570383-2572423649-2537084334-1921242514
v=0
s=SIP Call
c=IN IP4 10.10.4.20
t=0 0
m=audio 29550 RTP/AVP 0 100 101
c=IN IP4 10.10.4.20
a=rtpmap:0 PCMU/8000-----------------G711Ulaw advertised
a=fmtp:100 192-194
a=fmtp:101 0-15
a=ptime:20
CUCM sends a 200 OK, agreeing on G711ulaw as the codec to use
Received:
SIP/2.0 200 OK
Via: SIP/2.0/TCP 10.10.4.20:5060;branch=z9hG4bK375566FA
From: <sip:17086598000@10.10.4.20>;tag=306F1686-1BE5
Date: Wed, 09 May 2012 21:28:12 GMT
Call-ID: B6C874A3-995411E1-973ED5AE-7283D592@10.10.4.20
CSeq: 101 INVITE
Content-Length: 214
v=0
s=SIP Call
c=IN IP4 10.10.10.40--------->CUCM informs CUBE to send RTP to Transcoder
t=0 0
a=rtpmap:0 PCMU/8000------------------>G711ulaw accepted
a=ptime:20
a=fmtp:101 0-15
So on the first call leg G711ulaw is used
Below is the Sh sccp connection on the Xcoder
Tag13=ITSP--->CUBE call leg
Tag14= CUBE--->Xcoder Call leg
Sh voip rtp connection:
13 91498 91499 31298 23516 10.10.4.174 10.10.10.10

14 91499 91498 17432 25092 10.10.4.174 10.10.10.40
Observe that the region between the IP phone and the CUBE does not even come into play
here. This is because the call was diverted, hence no RTP stream is sent to the phone.It is
the destination where RTP stream will be sent to that codec negotiation will be considered
for
In this call setup, a xcoder at a remote site was used even though transcoder resources are
configured on the CUBE and registered to CUCM.
This is because the region setting between the Xcoder and the CUBE were wrongly
configured. Hence the CUBE found an available transcoder in the default MRGL. This is a
very crucial part of your design. Ensure that:The region setting between a XCODER and the
Device invoking it is G711.
sh sccp connections on the transcoder:
NB: that the codec section has two main distinctions
1. The leg that invokes a xcoder will always be G711
2. The other leg of the call will use whatever region setting is configured between it and the
xcoder. So if its G711, you will see G711, if its G729, you will see G729.
536967470 469864467 xcode sendrecv g711u 32106 16882 10.10.4.174
536967470 469864466 xcode sendrecv g711u 25092 17432 10.10.4.174
We are seeing the CUBE ip here duplicated because this is a hairpinned call. The same CUBE
is sending rtp connection to the xcoder.
SCENARIO 4
Scenario 4 is similar to scenario 3 but the region settings are different and we use voice class
codec on the outbound dial-peer to CUCM.An inbound call comes to an IP phone via CUBE.
The Ip phone has a CFWdall set to a cell phone.
ITSP------->CUBE--------->CUCM---->Ip Phone---CFWDall--->CUBE----->ITSP
<----------------G729-------------------->(cubetoiphone=g729)
<------------------------------G711------------------------------------->(cubetocube=g711)
Configurations:
voice class codec 1

voice-class codec 1
+++++Outbound dial-peer config to CUCM+++++
voice-class codec 1
fax rate disable
Region Settings between CUBE(s)= G.711, region setting between cube(s) and IP
Phone=g729
CALL ANALYSIS
2. Call matches outbound dial-peer 50, voice-class codec set

3. When a voice-class is configured on a DP, the codec used will depend on the region
setting between the source and the destination. Here, the source is cube (sip trunk), the
destination is another cube (or the same cube depends on which cube cucm chose for the
outbound leg of thecall (we have two cubes in our environment). The region setting
between the CUBES is G711, hence the call will use G711 all the way.
4. RTP connection is setup inbound to cube and outbound to cube. So in this case both call
legs will look like this
Callleg1=g711---inbound call to cube
Callleg2=G711..outbound calleg to cube from cube
Received:
INVITE sip:441925573222@10.10.4.174:5060 SIP/2.0

v=0
s=c=IN IP4 10.10.10.10
t=0 0
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends invite to cucm with early offer and codecs matched on voice-class code
Sent:
INVITE sip:901925573222@10.10.4.14:5060 SIP/2.0
To: <sip:901925573222@10.10.4.14>
v=0
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 16668 RTP/AVP 18 0 8 100 101---------CUBE advertises Codec to CUCM

c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:100 192-194
a=fmtp:101 0-15
After a couple of trying and ringing CUBE gets a 200 ok from cucm with endpoint
codec and IP.
Codec chosen based on the region between endpoint and CUBE sip trunk (CUBECUBE in this case)
Received:
SIP/2.0 200 OK
s=SIP Call
c=IN IP4 10.10.4.174------>RTP sent directly to CUBE (no xcoder involved)
t=0 0
a=rtpmap:0 PCMU/8000--------------->G711Ulaw selected to use for the call
a=ptime:20
a=fmtp:101 0-15
In this call scenario we can see that no transcoder is involved because of the homogeneity
of the codecs used.
SCENARIO 5, Call Flow

ITSP------------->CUBE---------->CUCM---->Ip Phone---CFWD--->UCXN
<----------------G729------------------->(cubetoiphone=g729)
<-----------------------------G711---------------------------------->(cubetocube=g711)
SCENARIO 5------CALL FORWARDING TO Voice Mail (Xcoder Invoked)
+++++=Calls forwarded to Unity connection from CUBE+++ using a xcoder
Configurations:
voice class codec 1
voice-class codec 1
codec g711u
fax rate disable
CALL ANALYSIS
1. Call arrives on CUBE and matched DP=1 with voice-class codec set.
g711ulwa advertised. So CUCM is forced to send an ACK back with only g711u as the codec
to use for the c all.
4. When the call arrived on ip phone, it was cfwd to voice mail,
5. Hence RTP connection is setup inbound to cube and outbound to unity connection. So in
this case the second call leg of the call will be between CUBE->Unity connection
Now the region setting between CUBE-Unity Connection=G729.
So we have a call flow like this
Callleg1=g711
Callleg2=G729
Hence a xcoder is needed. The CUBE invokes a xcoder. If there is no transcoder available,
then this call will fail.
show sccp connections on transcoder:

536967470 469864467 xcode sendrecv g711u 32106 16882 10.10.4.70UCXN Server
536967470 469864466 xcode sendrecv g711u 25092 17432 10.10.4.174------CUBE
Show voip rtp connection on CUBE

13 91498 91499 31298 23516 10.10.4.174 10.10.10.10 (ITSP->CUBE)
14 91499 91498 17432 25092 10.10.4.174 10.10.10.40 (CUBE->Xcoder)
NB: This is a really bad design. You dont want calls to unity connection using a transcoder.
This is happening because the codec and region configurations were poorly done without
the consideration of how they interact.
Now we have covered quite a few scenarios that are involved in our day to day call
requirements on the inbound direction. Here is a quick recap
In summary, rule on dial-peer and region settings is this
When voice-class codec is used, the codec set on the region between the calling device and called
device wil be used. E.g Cube calling ip phone and region set to G729, G729 will be used.
If the same call is forwarded, then the ff: will happen
If the region between the calling CUBE/Gateway, and the gateway used to make the Forwarded
call is set to g729, then G729 will be used.
If the region set between calling gateway and the gw making forwarded call = G711, then G711
will be used
If the DP=G711 hard coded, and the region between the gateways is G729, then a xcoder will be
invoked. as explained above
If DP=g729 and region between gateways is G711, then g729 will be used (its as if G711 can step
down to G729)
Next lets look at Outbound Calls
OUTBOUND CALLS
IP phone----sccp----------->CUCM---------sip---------->CUBE--------sip----->ITSP
In the outbound direction...............

The advertised codec to ITSP will be used; because ITSP is the one making decision which
codec to use based on advertised codec. So here with voice class codec, the preferred codec
in the list will be selected by the ITSP and this will be used for the call regardless of what the
region setting is on the phone to the cube gateway.
If the codec is hardcoded, if its set to g711, then g711 response will be obtained from the
ITSP and that codec will be used for the call. If its g729 then it will be g729.
So the outbound leg is independent of the region settings because it is the far end that is
choosing what codec to use for the call.
It is important to understand this so that you know that the region setting will not
determine what codec will be used for your outbound call leg.
So if you want to choose a codec for your outbound leg, you have to either set it as
preferred in your voice class list or hardcode it such that it is the codec been advertised as
the preferred to your ITSP
Configurations:
voice class codec 1
voice-class codec 1
+++++Outbound dial-peer config to ITSP++++
description Voice Calls To Verizon SIP Trunk
translation-profile outgoing OUT_PORT
destination-pattern .T
session target sip-server

session transport udp
voice-class codec 1
fax rate disable
ip qos dscp cs3 signaling
no vad
Abbreviated trace below:
Invite sent to ITSP From CUBE
Sent:
From: "codec test" <sip:447777777777@10.10.4.174>;tag=4C8AB41A-1D46
To: <sip:5555555501@10.106.33.24>
Date: Wed, 06 Jun 2012 16:40:14 GMT
Call-ID: 1FD8C261-AF2D11E1-8E25FE93-B3867CA6@10.10.4.174
Min-SE: 1800
Contact: <sip:447777777777@10.10.4.174:5060>
v=0
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 21956 RTP/AVP 18 0 8 100 101----Codecs advertised in the order preferred
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:100 192-194
a=fmtp:101 0-16
CUBE receives Session progress from ITSP
NB that the provider is only sending G729 back. (based on the preferred codec in our list)
Received:
SIP/2.0 183 Session Progress
v=0
s=c=IN IP4 10.10.10.10
t=0 0
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends 183 to CUCM with G729
Sent:
SIP/2.0 183 Session Progress
v=0
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 29694 RTP/AVP 18 100 101
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:100 192-194
a=fmtp:101 0-15
a=ptime:20
We received 200 ok from ITSP
Received:
SIP/2.0 200 OK
v=0
s=-
c=IN IP4 10.10.10.10

t=0 0
a=fmtp:101 0-15
a=ptime:20
a=fmtp:18 annexb=no
CUBE sends 200 OK to CUCM with only G729 advertised
sent:
SIP/2.0 200 OK
v=0
s=SIP Call
c=IN IP4 10.10.4.174
t=0 0
m=audio 29694 RTP/AVP 18 100 101
c=IN IP4 10.10.4.174
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:100 192-194
a=fmtp:101 0-15
And the most important part cucm sends ACK with SDP with endpoint codec and IP
NB: Even though the region between ip phone and Cube was set to G711, cucm sends
ACK with G729.
Received:
ACK sip:55555555555@10.10.4.174:5060 SIP/2.0
CSeq: 101 ACK
v=0
s=SIP Call
c=IN IP4 10.50.17.20
t=0 0
a=rtpmap:18 G729/8000
a=ptime:20
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=ptime:20
SUMMARY/CONCLUSION
Finally, Summarising both call scenario,
In both cases the codec selected by the far end will determine what codec is used for the
call.
Inbound leg, far end is CUCM, region takes effect
Outbound leg, far end is ITSP, prefered codec in advertised codec will take effect. Simples!
Using Dummy SIP Trunk to get REFER based

transfers working
Using Dummy SIP Trunk to get REFER based transfers working

In CUCM Versions below 9.X, we have a limitation of SIP Route Pattern not allowing us to
point to a SIP Trunk that is already associated with a route group. This creates problems in
call scenarios such as below :
SCENARIO :
[ Home-1 Cluster] User Calls 7777 --> CUSP ( via SIP Trunk CUSP1) --> CVP --> ICM
(Script Runs, If no agents available = Kick out to 110011 = Hunt Pilot on Home-2 Cluster) -->
CVP --> CUSP ( via SIP Trunk CUSP1) --> Home-2 Cluster Hunt Pilot 110011 [Fails]
If we use a RE-INVITE method of performing a transfer, this scenario can be quite easy to
achieve. However, at times customers would like to use the REFER mechanism for transfer.
During such a scenario, CUCM has the capability of accepting the INBOUND REFER and
handles this call based on the SIP Route Pattern configuration.
In the above case, as an example this is what should happen ideally from signalling
perspective :
CUCM
CUSP1 Trunk
--INVITE-->
<--TRYING-<--200 OK--
-- ACK-->
<--REFER---202 ACCEPTED-->
*Note REFER here will have "Refer to" header with the destination IP Address that CUCM
needs to send the new INVITE to for transfer purpose. CUCM will generate this new INVITE
based on the "IPAddress Routing" type SIP Route Pattern that is configured.
ISSUE we face during configuration :

Note that once the REFER comes, the "Refer to" header would have the destination IP
Address same as the destination IP Address of the CUSP1 Trunk that CUCM originally
initiated the INVITE to. Say we have a set up as below:
Route Pattern 7777 --> Route List (RL-1) --> Route Group --> DEVICE 1: CUSP1 || DEVICE
2: CUSP2
Now to get the REFER transfer working for above call scenario, we will need CUSP1 to be
configured under the SIP Route Pattern. Since it is associated to a route group, this
configuration is a restriction on CUCM. The only workaround would be to point the SIP
Route Pattern to RL-1( Route List), however this is a feature made possible on CUCM
Versions 9 and above only.
WORKAROUND :
Configure an alternate SIP Trunk CUSPTEST that has the same destination IP Address
as that of CUSP1. Since we cannot create two SIP Trunks with same destination IP
Address, associate the new SIP Trunk with a SIP TRUNK SECURITY Profile
"TEST_PROFILE" that has incoming port as any dummy port such as 5065.
We don't need to bother about the dummy incoming port because CUSP is never going to
talk to CUCM on that port for incoming messages.
Once we have associated the new SIP Trunk CUSPTEST with the "TEST_PROFILE" we
can now successfully associate this SIP Trunk to the SIP Route Pattern to get the above
call flow working.
This is a great example of how a dummy SIP Trunk can be used to get a simple REFER
transfer working in such a deadlock situation.
Hope this helps!
Regards,
Avinash
Modifying the User Agent SIP Header with SIP

Profiles
Introduction
This document explains "How to Add/Modify the User-Agent SIP header in the SIP Profiles
?" . Sometimes SIP header Modification is required in a Service provider network where the
Device rejects an unknown header and expects optional header value or parameter.
Problem description
When we register the Cisco Router as SIP Gateway, the Provider will see the Router's
Registered name as "User-Agent: Cisco-SIPGateway/IOS-12.x" in the SIP header. Is it
possible to Rename the SIP User-Agent Name ?
Sample SIP INVITE message with the User-Agent name ( field is highlighted in bold):
*Mar 1 00:34:45.515: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:9000@172.16.13.87:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.184.83:5060;branch=z9hG4bK1E1E51
From: <sip:8000@172.16.184.83>;tag=85E9C7C8-A4C
To: <sip:9000@172.16.13.87>;tag=1EDC10-2436
Date: Tue, 28 Feb 2006 23:44:38 GMT
Call-ID: D110EA36-2BE211D6-801CEF21-DD62106B@172.16.13.87
Max-Forwards: 70
CSeq: 103 BYE
Content-Length: 0
*Mar 1 00:34:45.535: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.184.83:5060;branch=z9hG4bK1E1E51
From: <sip:8000@172.16.184.83>;tag=85E9C7C8-A4C
To: <sip:9000@172.16.13.87>;tag=1EDC10-2436
Date: Fri, 01 Mar 2002 00:34:45 GMT
Call-ID: D110EA36-2BE211D6-801CEF21-DD62106B@172.16.13.87
CSeq: 103 BYE
Content-Length: 0
Solution
Yes, It is possible to Rename the default SIP User-Agent name by Modifying the User Agent
in SIP Header using Sip profile.
Configuration To Modify the User Agent SIP header

The following configuration modifies the User Agent - SIP header Cisco-SIPGateway/IOS12.x to Cisco-SIP-Gateway
Message: INVITE
Action: Modify the User-Agent SIP header
Rules:
request INVITE sip-header User-Agent modify Cisco-SIPGateway/IOS-12.x Cisco-SIPGateway
Configuration Setps
voice service voip
media flow-around
allow-connections sip to sip
sip
sip-profiles 100
request INVITE sip-header User-Agent modify Cisco-SIPGateway/IOS-12.x Cisco-SIPGateway
Configuration To Add the User Agent SIP header

The following configuration Adds the User Agent SIP header User-Agent: CiscoSystemsSIP-GW-UA"
Message: 200 Response
Action: Add the User-Agent SIP header
Rules:
response 200 sip-header User-Agent add "User-Agent: CiscoSystems-SIP-GW-UA"
Configuration Steps
voice service voip
media flow-around
allow-connections sip to sip
sip
sip-profiles 100
response 200 sip-header User-Agent add "User-Agent: CiscoSystems-SIP-GW-UA"

Sip Cucm

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sip Cucm

Încărcat de

Drepturi de autor:

Formate disponibile

Configure and Troubleshoot Call Forward to the

PSTN using SIP Trunks

Here are the steps to use the first method:

Incoming Dial-peer matching on IP Address

dial-peer voice 1 voip

How to Check Active Call Count on SIP

SBC03#sh call active voice summary

Call agent controlled call-legs: 0

Working concept of SCCP & SIP Phones and the Dial

IP Phone Registration Process

SCCP & SIP Phone Digit forwarding methods

SCCP Phones: Digit-by-Digit

How SCCP & SIP Phone Works?

Type A SIP Phones: Dial rules

Type B SIP Phones: Cisco IP Phone models 79x1, 79x2, 79x5,

Type B SIP Phones: Dial Rules

UNDERSTANDING SIP TRACES

Debug ccsip messages.

To understand The output generated by this debug..We need to understand the

An INVITE usually has a message body containing the media information

Here is the call setup for this trace

CUCM----------sip trunk------>CUBE---------SIP Trunk--------------->ITSP

INVITE with SDP.

INVITE sip:14107154522807@10.105.80.174:5060 SIP/2.0

Now lets break it up or dissect this piece of information.

As we can see there are lots of headers in this invite

The INVITE header

1. The called number

So here we see the called number is: 14107584528207

The Via Header:

Via: SIP/2.0/UDP 10.105.80.114:5060;branch=z9hG4bK98e4117d52a6

The To and From Headers

CSeq: 101 INVITE

User Agent Header:

SDP Extensions and Attributes

SDP Parameter Parameter

o=CiscoSystemsCCM-SIP 811669 1 IN IP4

c=IN IP4 10.133.92.102

Connection/IP address for RTP stream

m=audio 25268 RTP/AVP 18 101

Lets look at media attributes below

m=audio 25268 RTP/AVP 18 0 8 101

DISSECTING A SIP TRACE

The call flow for this call is as shown:

2. A new Invite Sent to CUCM.

002791: Jun 6 16:07:28.394: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

002792: Jun 6 16:07:28.394: //260862/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

CSeq: 558267841 INVITE

002793: Jun 6 16:07:28.396: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

002794: Jun 6 16:07:28.412: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

CSeq: 101 INVITE

6. The CUBE relays this message to the calling party

CSeq: 558267841 INVITE

c=IN IP4 10.100.20.10------------------------IP address to send RTP stream to

002796: Jun 6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

8. CUBE sends an ACK to CUCM to acknowledge the last 200 Ok message

002797: Jun 6 16:07:28.556: //260863/8C38FA5E95E3/SIP/Msg/ccsipDisplayMsg:

NOTIFY, INFO, REGISTER

10. CUBE then receives an ACK

CSeq: 558267841 ACK

CSeq: 558267842 BYE

Here we see as normal call clearing Cause=16.

002809: Jun 6 16:07:34.470: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: