Brkucc 2006

SIP Trunk design and
deployment in Enterprise
UC networks
BRKUCC-2006
Tony Mulchrone
Technical Marketing Engineer
Cisco Collaboration Technology Group
Agenda
Why choose SIP for UC Trunking ?
SIP Basics Session Establishment
Session Description Protocol (SDP) Media Negotiation
Essential CUCM SIP Trunk features
Feature invocation over SIP Trunks
Large scale designs with multiple call controls and SIP Trunks
Appendix Lots of detailed information SIP headers explained, CUCM
features explained etc
3
Housekeeping
We value your feedback- don't forget to complete your online
Session Evaluation
Visit the World of Solutions and Meet the Engineer
Visit the Cisco Store to purchase your recommended readings
Please switch off your mobile phones
After the event dont forget to visit Cisco Live Virtual:
www.ciscolivevirtual.com
4
Agenda
Appendix Lots of detailed information SIP headers explained,
CUCM features explained etc
5
Why Choose SIP ?
Popularity/ Industry demand
These days, most Collaboration vendors spend their development dollars on
SIP rather than H.323 or MGCP
SIP is arguably the most common UC protocol in use by vendors and
customers today
SIP based IP PSTN is growing in popularity
Multi-protocol Interoperability challenge
Even though multi vendor SIP is not without its interop issues, SIP to SIP
interop is easier than SIP to H.323, SIP to MGCP
Cisco UC Protocol Feature Set Comparison
SIP Trunks are more feature rich than H.323 and MGCP Trunks
6
Why recommend SIP as the preferred Trunk Protocol?
Using SIP Trunks only to interconnect UC systems provides real benefits in terms of feature
support and design simplicity e.g. :
UC 7.1 Support for IPv6

UC 8.5 Simplified Call Routing (Run on All Nodes, 16 Dest. Addresses)
UC 8.5 SME clusters which need no Media Resources (MTPs, Xcoders)
UC 8.5 Improved Interoperability with powerful SIP Trunk LUA scripts
UC 8.5 H.264 Video support, UC 8.6 : BFCP and Encrypted Video support
UC 9.0 Codec Preference Lists and Codec Preference Pass through
UC 9.0 ILS URI distribution and URI Call Routing over SIP Trunks
UC 9.1 SME CoW with extended Round Trip Times (Up to 500mS)
UC 10.0 Support for ILS based Global Dial Plan Replication
UC 10.0 SDP Transparency
UC 10.5 Best Effort Early Offer
7
Unified CM Inter Cluster Trunks
SIP Trunks vs H.323 Trunks Feature Comparison
H.323 SIP
Support for + character
Signalling Authentication and Encryption TLS
Media Encryption
Run On All Nodes feature
Up to 16 destination addresses feature
OPTIONS Ping
SME CoW with extended Round Trip Times
G.711, G.722, G.723, G.729 Support
SIP Subscribe / Notify, Publish Presence
Accept Audio Codec Preferences in Received Offer
URI Call Routing, Global Dial Plan Replication
IPv6, Dual Stack, ANAT
BFCP Video Desktop Sharing
8
Legend: Yes Limited support No

CUCM Trunks to IOS Gateways
SIP Trunks, H.323 and MGCP Gateways Feature Comparison
H.323 SIP MGCP
Centralized Provisioning
Centralized Call Detail Records
QSIG Tunneling
ISDN Overlap Sending
Accept Audio Codec Preferences in Received
Offer
Run On All Nodes feature 3 Active Nodes in a 1 Active Node in a
Call Manager Group Call Manager Group
Up to 16 destination addresses feature

SME CoW with extended Round Trip Times
OPTIONS Ping
TCL/VXML Apps (e.g. for CVP Integration)
IPv6, Dual Stack, ANAT
9
Legend: Yes Limited support No

Agenda
10
SIP Basics User Agents
Session Initiation Protocol (SIP) is a text based signalling protocol for creating, modifying, and
terminating sessions with one or more participants (SIP is described in RFC 3261)
SIP uses a Request/Response transaction model between endpoints (User Agents)
A User Agent (UA) For example, a SIP Phone performs two roles :
A User Agent Client (UAC) which sends SIP Requests
A User Agent Server (UAS) which receives SIP Requests and returns Responses
Request Invitation to participate in a session

UAS UAC UAS UAC
Response e.g. OK/ Busy/ Moved
11
SIP Basics SIP Messages - Requests
INVITE - Indicates a client is being invited to participate in a call session
ACK - Confirms that the client has received a final response to an INVITE request
BYE - Terminates a call and can be sent by either the caller or the callee
CANCEL - Cancels any pending request
OPTIONS - Queries the capabilities of servers (OPTIONS Ping)
REGISTER - Registers the address in the To header field with a SIP server (Phones only)
PRACK - Provisional Acknowledgement
SUBSCRIBE - Subscribes for an Event of Notification from the Notifier (Used for KPML & MWI)
NOTIFY - Notify the subscriber of a new Event (Used for KPML & MWI)
PUBLISH - Publishes an event to the Server
INFO - Sends mid-session information that does not modify the session state
UPDATE - Modifies the state of a session before a final response is received
MESSAGE - Transports instant messages using SIP (XMPP more commonly used for IM)
REFER - Asks recipient to issue a SIP Request (Call Transfer) 12
SIP Basics SIP Messages - Responses
Response Categories
Provisional (1xx): Request received and being processed (Unreliable not ACKed)
Success (2xx): The action was successfully received, understood, and accepted.
Redirection (3xx): Further action needs to be taken to complete the request.
Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server.
Server Error (5xx): The server failed to fulfil an apparently valid request.
Global Failure (6xx): The request cannot be fulfilled at any server.
Commonly Used Responses
100 Trying - CUCM has received the INVITE

180 Ringing - Destination user agent has received the INVITE, and is alerting the user
183 Session in Progress - Used to send extra information for a call which is still being set up
200 OK - Indicates the request was successful
486 User Busy
404 Not Found - The server has definitive information that the user does not exist 13
503 Service Unavailable

SIP Basics SIP Servers
SIP Servers Registrar, Redirect Server, Proxy Server
Registrar Provides location mapping for SIP User Agents
Redirect Server Re-directs SIP Requests when a user has moved or is unavailable
Proxy Server SIP message router can be transaction stateful or stateless
SIP Proxy servers can either leave the signalling path when the call is
connected or can enable "Record-route" to stay in the signalling path.
Register 1001@10.1.1.1
INVITE 2002 Register 2002@10.2.2.2
INVITE 2002
200 OK Record 200 OK
Route
Proxy
UAS UAC
BYE BYE
Proxy
Registrar BYE UAS UAC
RTP Media
Proxies are designed to be mostly transparent to UAs (e.g. Can not terminate a call). Proxy servers
can only change messages in specific and limited ways (e.g. Can not change call media info (e.g. 14
codecs)).CUCM is not a Proxy server

CUCM : A Back to Back User Agent (B2BUA)
RFC 3621 does not define the specific functionality of a B2BUA.
A B2BUA is similar to a stateful SIP Proxy Server in that it actively maintains call state, but does not
have the same limitations as a SIP Proxy server. i.e. a B2BUA can disconnect a call and modify media
information sent in the Session Description Protocol (SDP).
How should a SIP call through a B2BUA be viewed ?
As two independent call legs from a SIP perspective :
1) An inbound SIP call arriving at a User Agent and
2) A new outbound call originating from another User Agent
CUCM - B2BUA
UAS UAS
UAC UAC
Why is CUCM a B2BUA ?

Because CUCM provides many other features beyond those of a SIP Proxy Server Call Admission 15
Control, Codec negotiation, interoperability with H323, MGCP and SIP, CTI etc.
CUCM : Line Side and Trunk Side SIP
Register CUCM - B2BUA CUCM - B2BUA
Register
INVITE UAS UAS

INVITE UAS UAS
INVITE
200 OK 200 OK 200 OK
UAC UAC UAC UAC
Line Side SIP Trunk Side SIP
Line Side SIP is more feature rich and generally more proprietary than Trunk Side SIP
Line Side SIP needs to support an extensive set of device features e.g.
Phone/Device Control : Registration, Reset / Restart; CUCM failover and fall back, Call Preservation
during CUCM failover, Erase Config, Apply Config, Send Firmware Load ID and Software version
information, On Hook/Off Hook status notification, CTI interactions, Shared Line interactions, Phone
display commands etc etc
Trunks Side SIP needs to be relatively simple to enable interoperability between vendors, whilst
allowing call features such as hold/ resume, transfer to be invoked
16
This presentation focuses on Trunk side SIP

Establishing a SIP session and an
introduction to SIP headers
17
SIP Basics Typical Call Set Up
SIP Trunk Message exchange The INVITE Request
SIP Trunk
INVITE sip:1001@10.10.199.250:5060
10.10.199.251 10.10.199.250
2002 1001
18
SIP Message Headers INVITE Request with Headers
INVITE sip:1001@10.10.199.250:5060 SIP/2.0 ------------------------------------ Request INVITE to 1001
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:1001@10.10.199.250>
Date: Wed, 18 Feb 2015 18:37:57 GMT
Call-ID: 8fe4f600-b7c13785-3-fbc712ac@10.10.199.251
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER.. SIP Message
CSeq: 101 INVITE
Contact: <sip:2002@10.10.199.251:5060;transport=tcp> Headers
Expires: 180 Some Mandatory
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback Some Optional
Supported: Geolocation
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Session-Expires: 1800
P-Asserted-Identity: <sip:2002@10.10.199.251>
Remote-Party-ID: <sip:2002@10.10.199.251>;party=calling;screen=yes;privacy=off
Max-Forwards: 70
19
Content-Length: 0
SIP Messages INVITE with Headers re-grouped (1 of 3)
Request /Header Request Header Content Category
INVITE sip:1001@10.10.199.250:5060 SIP/2.0 Route and
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb Transaction
CSeq: 101 INVITE related
headers
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5- Identity and

353990242dfe-32552697
Dialog
To: <sip:1001@10.10.199.250> related
Call-ID: 8fe4f600-b7c13785-3-fbc712ac@10.10.199.251 headers
Contact: <sip:2002@10.10.199.251:5060;transport=tcp>
20
See Appendix for detailed descriptions and CUCM related configuration
Request Header Request Header Content Category
Supported: timer,resource-priority,replaces Timer related
Session-Expires: 1800 headers
Min-SE: 1800
Expires: 180
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, Methods and
SUBSCRIBE, NOTIFY Events
Supported: X-cisco-srtp-fallback Cisco related

Supported: Geolocation headers
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
21

SIP Session Expires and Min-SE Headers - Operation
During call set up - Session timers and Session Refresh methods are negotiated and
agreed on each SIP Trunk. Once the call is established the session on each Trunk is
periodically refreshed. If no session refresh request or response is received, the UA
sends a BYE to terminate the session
SME Node
crash
SME
Cluster
Leaf Cluster Leaf Cluster

North America Europe
Media
22
Date: Wed, 18 Feb 2015 18:37:57 GMT Other
Max-Forwards: 70 headers
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-
event;Duration=500"
Content-Length 0
23
SIP Trunk Message exchange The INVITE Request
SIP Trunk
INVITE sip:1001@10.10.199.250:5060
100 Trying
10.10.199.251 10.10.199.250
2002 1001
24
SIP Trunk Message exchange The Ringing Response
SIP Trunk
INVITE
100 Trying
180 Ringing
Caller hears
locally
generated
ringback tone
10.10.199.251 10.10.199.250
SIP 180 Ringing

Indicates that the destination User Agent has received the
2002 INVITE, and is alerting the user. Typically 180 Ringing is the 1001
first Response that contains information about the 25
capabilities of the Called User Agent

SIP Trunk Message exchange 200 OK and ACK
SIP Trunk
INVITE
100 Trying
180 Ringing
200 OK
ACK
10.10.199.251 10.10.199.250
Two Way Media

2002 1001
200 OK - Indicates the Request (INVITE) was successful
26
ACK - Confirms that the client has received a Final Response (200 OK) to the Request
Agenda
27
SIP Basics
SIP Message Exchange and Media Negotiation
SIP Trunk
INVITE sip:1001@10.10.199.250:5060
Media Capabilities Endpoint IP Address, Codecs etc

100 Trying
180 Ringing
200 OK IP Address, Codecs etc
Media Capabilties Endpoint
ACK
10.10.199.251 10.10.199.250
Two Way Media

2002 1001
28
SIP Trunk Signaling - Session Description Protocol (SDP)
The Offer / Answer Model
SDP is the companion protocol of SIP
SDP is used to describe media characteristics; it does not deliver media (for voice and video this is
done using the Real-time Transport Protocol (RTP)), but is used to negotiate the media type, format
and associated parameters of a multimedia session between endpoints.
SDP is described in RFC 4566
The media characteristics of a session are described by a series of one line fields in an SDP message.
Within an SDP message there are three main sections, these detail the session name and purpose, the
time the session is active, the media and information needed to receive the media (addresses, ports,
formats, etc.). Additional information about bandwidth usage and contact information can also be
sent.
Media negotiation using SDP is known as the Offer/ Answer model (described in RFC 3264)
Two key concepts in the Offer / Answer model are the Early Offer and Delayed Offer
29
SIP Trunk Signaling and Media Negotiation
The Offer/Answer model - SIP Early Offer
Information about the calling devices media characteristics are sent with its initial SIP INVITE message
The media characteristics are contained in the Session Description Protocol (SDP) body sent with the
SIP INVITE The Offer in the SDP body contains the IP Address, UDP Port number, list of codecs etc.
supported by the calling device
The called device selects which of the offered codecs it wishes to use for the call and returns it in its
Answer in the SDP body of a SIP response The Answer also contains the IP address and UDP port
number etc of the called device
Once the Answer has been received two way media can be established
Early Offer is widely used (particularly by Service Providers.)
INVITE with SDP (Offer) INVITE with SDP (Offer)
One Way
100 Trying 100 Trying Media
180 Ringing 180 Ringing
200 OK with SDP (Answer) 200 OK with SDP (Answer)
Two Way Media
30
ACK ACK
SIP Trunk Signaling and Basic Operation
The Offer/Answer model - SIP Delayed Offer
No information about the calling devices media characteristics are sent in the initial SIP INVITE
Instead the first set of media characteristics for the call are sent by the called device in the Session
Description Protocol (SDP) body of the next reliable message (200 OK) The called devices Offer
contains its IP Address, UDP Port number, list of codecs etc.
The calling device selects which of the offered codecs it wishes to use for the call and returns its
Answer in the SDP body of a reliable SIP response (ACK) The Answer also contains the IP address
and UDP port number etc of the calling device
Delayed Offer is a mandatory part of the SIP standard (but not supported by all vendors)
Ordinarily, the Offer or Answer cannot be sent reliably in 100 Trying or 180 Ringing as 1XX messages are
unacknowledged This can be resolved using PRACK .. discussed later..
INVITE INVITE
100 Trying 100 Trying
200 OK with SDP (Offer) 200 OK with SDP (Offer)
ACK with SDP (Answer) ACK with SDP (Answer)
31
Two Way Media

SIP Delayed & Early Offer PRACK & Early Media
Using PRACK to reduce media cut through delay
SIP Delayed Offer without PRACK
INVITE INVITE
200 OK with SDP (Offer) 200 OK with SDP (Offer)
ACK with SDP (Answer) ACK with SDP (Answer)
Two Way Media
You can send SDP in 1XX Responses, but they are unreliable as they are not acknowledged.
By enabling PRACK (Provisional Reliable Acknowledgement), 1XX messages will be
periodically re-sent until their receipt is acknowledged by the receiver by sending a PRACK,
which is also acknowledged by the 1XX sender.
Using PRACK can reduce the number of SIP messages that need to be sent before two way
media is established. PRACK is useful in situations where long Round Trip Times between
SIP devices can cause a delay to media cut through or media clipping
32
PRACK can be enabled on the SIP Trunk Profile by setting SIPRel1XX Options
CUCM SIP Trunk Signaling SIP Early Media
Using Provisional Acknowledgement (PRACK)
Early Offer with Early Media Early Offer == Early Media
INVITE w/ SDP Supported:100rel INVITE w/ SDP Supported:100rel
183 Progress w/ SDP Require:100rel 183 Progress w/ SDP Require:100rel
PRACK Two Way Media PRACK

200 OK (PRACK) 200 OK (PRACK)
Delayed Offer with Early Media

INVITE Supported:100rel INVITE Supported:100rel
PRACK w/ SDP PRACK w/ SDP
200 OK (PRACK) Two Way Media 200 OK (PRACK) 33

Media negotiation for Voice
calls
34
SIP Trunk Signaling - Media negotiation for Voice calls : The SDP
Offer SIP Message Headers
..
Content-Type: application/sdp Content-Type : application/SDP
Content-Length: 337 Content-Length : 337 Bytes
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250
s=SIP Call SDP Message Body
c=IN IP4 10.10.199.130
Describes the media characteristics of the
t=0 0 endpoint offering the SDP
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20 Includes :
a=rtpmap:8 PCMA/8000 Endpoint IP address
a=ptime:20 Codecs supported
a=rtpmap:18 G729/8000
a=ptime:20 UDP Port number for RTP
a=sendrecv In Band DTMF support details
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 35
Some SDP lines are REQUIRED some are OPTIONAL, but all MUST appear in exactly the order described in RFC 4566
SIP Trunk Signaling - Media negotiation Voice calls :
The SDP Offer - Details
Description Attribute Content Comments
o= Origin CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250 10.10.199.250 = CUCM IP Address
s= Session Name SIP Call
c= Connection Data IN IP4 10.10.199.130 Phones IP Address
t= Timing 00 Permanent Session
m= Media audio 16444 RTP/AVP 0 8 18 101 UDP Port 16444, RTP Payload Type
Descriptions Codecs : G711U, G711A, G729. DTMF
a= Attribute rtpmap:0 G711U/8000 G.711 U-Law codec offered for this call
a= Attribute rtpmap:8 G711A/8000 G.711 A-Law codec offered for this call
a= Attribute rtpmap:18 G729/8000 G.729 codec offered for this call
a= Attribute ptime:20 RTP packet sampling time (mS)
a= Attribute sendrecv Two way Audio
a= Attribute rtpmap:101 telephone-event/8000 101 DTMF RTP Payload Type number
36
a= Attribute a=fmtp:101 0-15 DTMF tones (Events 0 through 15 )
The SDP Answer - Details
Description Attribute Content Comments
v= Version 0
o= Origin CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.251 10.10.199.251 = CUCM IP Address
m= Media audio 28668 RTP/AVP 18 101 UDP Port 28668, RTP 18 = RTP
Descriptions Payload Type number for G729 codec,
101 = DTMF
a= Attribute rtpmap:18 G729/8000 G.729 codec selected for this call
a= Attribute rtpmap:101 telephone-event/8000 101 DTMF RTP Payload Type number
a= Attribute a=fmtp:101 0-15 DTMF tones (Events 0 through 15 37)
SIP Trunk Signaling
Media negotiation Voice calls The Negotiated Session
10.10.199.250 10.10.199.251
10.10.199.130 10.10.199.179
RTP UDP Port 16444 RTP UDP Port 28668
G.729 codec G.729 codec
Two way Audio Two way Audio
RFC 2833 DTMF RFC 2833 DTMF
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250 o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.251
c=IN IP4 10.10.199.130 c=IN IP4 10.10.199.179
m=audio 16444 RTP/AVP 18 101 m=audio 28668 RTP/AVP 18 101
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=ptime:20 a=ptime:20
a=sendrecv a=sendrecv
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000 38
a=fmtp:101 0-15 a=fmtp:101 0-15

Media negotiation for
Video calls
Summarized slides - See Appendix for Detailed slides
39
SIP Trunk Signaling - Media negotiation for Video calls
Summary
Video is fundamentally different from voice in that there are many use cases where
asymmetric media flows are desirable.
For example, broadband services where the upload and download speeds are different
often by an order of magnitude.
Also because encoding video is more CPU intensive than decoding video - Video endpoints
can typically decode at a higher resolution than they can encode.
Because of the need to support asymmetric video streams the video codec capabilities
sent in an SDP Offer and Answer should be considered to be the receive capabilities of the
respective endpoints rather than the negotiated capabilities in common with both devices
40
SIP Trunk Signaling - Video calls
SDP Offer Abridged Showing Video details
v=0
s=SIP Call SDP Session
b=TIAS:6000000 attributes
t=0 0
m=video 16446 RTP/AVP 98 99

c=IN IP4 10.58.9.86
b=TIAS:6000000 SDP Media
Attributes
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;
max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000 Only Video
related lines are
a=rtpmap:99 H263-1998/90000 shown here (See
a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1 Appendix for full
SDP Offer)
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr 41
SDP Offer Media Attributes for Video
Attribute Description Attribute Content Comments
b= Bandwidth (bps) TIAS:6000000 Transport Independent
Application Specific bandwidth
m= Media Descriptions video 16446 RTP/AVP 98 99 Media/Port#/Protocol/ RTP
Payload Types (H.264, H.263)
c= Connection Data IN IP4 10.58.9.86 Video Phone IP Address
a= Attribute rtpmap:98 H264/90000 H.264 Video Codec
a= H.264 Video Codec fmtp:98 profile-level-id=428016; packetization-mode=1; max-mbps=245000;
receive capabilities max-fs=9000;max-cpb=200; max-br=5000; max-rcmd-nalu-size=3456000; max-
smbps=245000; max-fps=6000
a= Attribute rtpmap:99 H263-1998/90000 H.263 Video Codec
a= H.263 Video Codec fmtp:99 QCIF=1; CIF=1; CIF4=1; CUSTOM=352,240,1
receive capabilities
a= Attribute rtcp-fb:* nack pli RTCP Feedback Packet Loss
a= Attribute rtcp-fb:* ccm tmmbr RTCP Feedback Max Bit Rate 42
SDP Answer Media Attributes for H.264 Video
b= Bandwidth (bps) TIAS:6000000 Transport Independent
Application Specific bandwidth
m= Media Descriptions m=video 2348 RTP/AVP 98 Media/Port#/Protocol/ RTP
Payload Types (H.264)
c= Connection Data IN IP4 10.58.9.222 Video Phone IP Address
a= Attribute rtpmap:98 H264/90000 H.264 Video Codec

a= H.264 Video Codec a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-
receive capabilities mbps=108000;max-fs=3600;max-cpb=200;max-br=5000;max-rcmd-nalu-
size=1382400;max-smbps=108000;max-fps=6000
a= Attribute rtcp-fb:* nack pli RTCP Feedback Packet Loss
a= Attribute rtcp-fb:* ccm tmmbr RTCP Feedback Max Bit Rate
profile-level-id=428016;packetization-mode=1 : Must have symmetric values

43
max-mbps=108000;max-fs=3600 etc : Asymmetric values describing receive capabilties
SIP Trunk Signaling
Voice and Video call with Desktop Sharing and FECC
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
Audio RTP UDP Port 16444 Audio RTP UDP Port 2346
MP4A-LATM Audio codec MP4A-LATM Audio codec
RFC 2833 DTMF Audio RFC 2833 DTMF
Video RTP UDP Port 16446 Video RTP UDP Port 2348
H.264 Video codec Main Video H.264 Video codec
H.264 Video codec Slide Video H.264 Video codec
BFCP UDP Port 5070 BFCP UDP Port 5070
Binary Floor Control
FECC UDP Port 16450 FECC UDP Port 2352
Far End Camera Control
44
RTP Payload Type 107 RTP Payload Type 107

Secured SIP Signaling (TLS) and
Encrypted Media (SRTP)
45
Secure SIP Trunk Signaling and Encrypted Media
Transport Layer Security (TLS) and Secure RTP (SRTP)
SIP over TLS
SRTP
To secure both SIP signalling and related media use TLS on the SIP Trunks and
between each end point and CUCM
Once the SIP signalling path has been authenticated and encrypted, the SRTP
encryption keys are exchanged via SDP using SDES (SDP Security Descriptions
for Media Streams) see RFC 4568
46
SIP Trunk Features
SIP Trunk Security Profile Information
Incoming and Outgoing Transport Types
UDP Connectionless Uses SIP Session
Timers to determine session state
TCP Connection Oriented TCP maintains
connection state
TLS Connection Oriented Encrypted
Signaling Uses X.509 Certificates to
authenticate connections (Match incoming
Cert(s) by Subject Name(s). TLS should be
used if encrypted media (SRTP) is required
Incoming port
The Transport protocol port number CUCM
uses to listen on for inbound SIP connections
SIP Messages that the trunk will accept
Digest Authentication - Less secure than TLS (does not provide integrity or confidentiality)
For a good example of how to set up SIP TLS over CUCM SIP Trunks see :
47
https://supportforums.cisco.com/document/72956/cucm-sip-trunk-tls-configuration-and-troubleshooting
SIP TLS 1.2 Handshake Mutual TLS Client Hello
Client Hello
Client TLS Version Number 3,3 (TLS 1.2)
Client Random Number 4 byte date and time + 28 byte random

number
Session ID : None (New Session)
Client supported Cypher Suites (in preference order) :

TLS_ECDHE_RSA with AES256_GCM_SHA384
TLS_RSA with AES_128_CBC_SHA1
50
SIP TLS 1.2 Handshake Mutual TLS Server Hello
Client Hello
Server Hello
Server TLS Version Number 3,3 (TLS 1.2)
Server Random Number 4 byte date and time + 28 byte random

number
Session ID : abcd1234.wxyz
Use Cypher Suite :

Server always selects and returns one cypher suite from the list
offered by the Client 51
SIP TLS 1.2 Handshake Mutual TLS Server Cert
Client Hello
Server Hello
Server Certificate
Server sends Public Key Certificate:

Server ID
Servers Public Key
Digital Signature
52
SIP TLS 1.2 Handshake Mutual TLS Server Key
Client Hello
Server Hello
Server Certificate
Server Key Exchange
Server sends
Server Diffie Hellman parameter
Signed by the Servers Private Key
The Client uses the Servers Public key to authenticate the server 53
SIP TLS 1.2 Handshake Mutual TLS Client Cert
Client Hello
Server Hello
Server Certificate
Server Key Exchange
Client Certificate Request
Client Certificate
Client sends Public Key Certificate:

Client ID
Clients Public Key
Digital Signature 54
SIP TLS 1.2 Handshake Mutual TLS Client Key
Client Hello
Server Hello
Server Certificate
Server Key Exchange
Client Certificate
Client Key Exchange
Client sends
Client Diffie Hellman parameter
Signed by the Clients Private Key 55
SIP TLS 1.2 Handshake On Prem Mutual TLS
Client Hello
Server Hello
Server Certificate
Server Key Exchange
Client Certificate
Client Key Exchange
Client and Server derive an identical Pre-Master Secret from their

shared Diffie Hellman parameters
The Pre-Master Secret is used to generate symmetric Session Keys which

are used to encrypt and authenticate all subsequent TLS messages 56
Secure SIP Trunk Signalling and Encrypted Media
Transport Layer Security (TLS) and Secure RTP (SRTP)
SIP over TLS
SRTP
SDES Exchange in the SDP Offer and Answer

One Endpoint sends its supported ciphers with their encryption keys in strength order in its SDP Offer
a=crypto:1 AEAD_AES_256_GCM inline:iZLP7bds308s27xmZZ7fMwycIO2FRhnnk/Br1Q/d1zYNd30YIIF9FkGUn3c=
a=crypto:2 AEAD_AES_128_GCM inline:sExqh5iE+ILVuHiQVTuKoDrHCFVWjdv9EXnMcQ
a=crypto:3 AES_CM_128_HMAC_SHA1_32 inline:yK0p2HFCCiMRPe+cBTqqOIyQoIbDRZJQYcBvmPac
The other Endpoint choses one cipher and returns its with their encryption key in its SDP Answer
a=crypto:1 AEAD_AES_256_GCM inline:bmt4MzIzMmYxdnFyaWMds308sMwycIO23d282dGdssR5Z3g0c2k5M3Yx
57
Endpoints send all supported crypto suites - CUCM can filter crypto suites
Agenda
58
Essential SIP Trunk Features
Delayed Offer/ Early Offer/ Best Effort Early Offer

Run on All Unified CM Nodes
Multiple Destination Addresses
SIP OPTIONS Ping
DTMF Settings
Audio Codec Preferences
Identity Presentation and Restriction
59
CUCM SIP Early Offer Using MTP Required
Pre UC 8.5 (Obsolete method)
SIP Line SIP Trunk with Early Offer
MTP
SCCP Line SIP Trunk with Early Offer

MTP
SIP Trunk SIP Trunk with Early Offer
MTP
H323 Trunk SIP Trunk with Early Offer
MTP Recommendation Always use IOS MTPs
MTP
CUCM based MTPs do not have feature parity
MGCP Trunk SIP Trunk with Early Offer
MTP with software and hardware based IOS MTPs
Using the MTP Required option :

SIP Early Offer Trunks use the Trunks Media Termination Point (MTP) resources, inserting an MTP
into the media path for every outbound (and inbound) call sending the MTPs IP Address, UDP port
number and codec in the SDP body of the initial SIP INVITE instead of those of the endpoint.
Disadvantages : MTPs support a single Audio codec only e.g. G711 or G729. The passthru codec is
not supported excluding the use of SRTP and video calls. Since the Trunks MTPs are used - The media
60
path is forced to follow the signaling path.
CUCM SIP Early Offer Insert MTP if Needed UC8.5+
SIP Profile Early Offer checkbox option : Mandatory (insert MTP if needed)

For Calls from trunks and devices that can
Cisco SIP Phones provide their IP Address, UDP port number and
supported codecs - This information is sent in
Newer SCCP Phones the SDP body of the initial SIP Invite on the
MTP
outbound Early Offer Trunk. No MTP is used for
Older SCCP Phones the Early Offer
SIP Early Offer For Calls from trunks and devices that cannot
MTP provide Early Offer information use the calling
SIP Delayed Offer
SIP Trunk with Early Offer
devices MTP resources (first) or the outbound
H323 Trunk
MTP trunks MTPs (second) to create a SIP Offer for an
H323 Slow Start
unencrypted voice call. (SRTP and video can
subsequently be initiated by the called device)
H323 Fast Start
MGCP Trunk SIP Trunk with Early Offer Multiple codecs supported using MTP pass-
61
through codec
MGCP Gateway
CUCM 10.5+ SIP Trunks Best Effort Early Offer (No MTP Inserted)
Cisco SIP Phones
SIP Line Best Effort Early Offer SIP Trunk Early Offer sent
Newer SCCP Phones

SCCP Line Best Effort Early Offer SIP Trunk Early Offer sent
Older SCCP Phones

SCCP Line Best Effort Early Offer SIP Trunk Delayed Offer sent
SIP Delayed Offer

SIP Trunk Best Effort Early Offer SIP Trunk Delayed Offer sent
H323 Slow Start H323 Trunk Best Effort Early Offer SIP Trunk Delayed Offer sent
MGCP Gateway MGCP Trunk Best Effort Early Offer SIP Trunk Early Offer sent
H323 Fast Start H323 Trunk Best Effort Early Offer SIP Trunk Early Offer sent
SIP Early Offer SIP Trunk Best Effort Early Offer SIP Trunk Early Offer sent
62
MTPs are not used to create an EO If the device is not EO capable, DO sent
Summary and Guidance on CUCM SIP Trunk : Using Delayed
Offer/ Early Offer/ Best Effort Early Offer
Summary
Delayed Offer The default setting Voice, Video and Encrypted Calls supported
Early Offer using MTP Required ~Obsolete MTP used for all calls, single voice codec only
Early Offer : Mandatory (insert MTP if needed) MTPs inserted for calls from older devices e.g. 7940
and 7960 phones Voice only on initial call set up, video (N/A) and media encryption set up set up by
sending a SIP Re-INVITE
Early Offer : Best Effort (No MTP inserted) No MTPs used ( if EO cannot be sent Do sent instead,
MTP resources assigned to the Trunk can be used to address DTMF transport mismatches
General Guidance
Do not use MTP Required for Early Offer MTP is inserted for every call
If you are using UC version 10.5 or above Use Best Effort Early Offer
If you are using UC versions 8.5/ 9.X/ 10.0
Type and quantities of the phones in the CUCM cluster :
Mostly older SCCP phones (e.g. 7940s/7960s) ----------- Use Delayed Offer
63
Mostly newer Phones ------------------------------------------- Use Early Offer : Mandatory (insert MTP if needed)
Essential SIP Trunk features that simplify UC designs
Run On All Unified CM Nodes
Up to 16 Destination IP addresses
These features :
Reduce the number of configured SIP Trunks
Simplify call distribution
Simplify call routing through by taking advantage of the Route Local rule..
SIP Trunk A
SIP Trunk B
CUCM SME CUCM SME

64
Essential SIP Trunk features that simplify UC designs
The Route Local Rule
Outbound SIP Trunks and Route Lists can take advantage of the Route Local Rule by using
the Run On All Unified CM Nodes feature
The Route Local Rule
If the CUCM node that the inbound call arrives on also has an instance of the selected
outbound trunk for that call then use this node to onward route the call
The Route Local rule can eliminate call set up traffic between nodes within a cluster
SIP Trunk A
SIP Trunk B
CUCM SME CUCM Route List

65
SIP Trunk Features
SIP OPTIONS Ping Improved Failover.
SIP ICT Trunk

SIP Trunk
OPTIONS Ping is activated on a per SIP Trunk basis

Each node running the SIP Trunk daemon in the originating cluster uses OPTIONS Ping to determine
the availability of each defined destination IP address
- CUCM will not attempt to establish a call to an unavailable remote peer
- SIP Trunk - In Service whilst one remote peer is reachable
- SIP Trunk - Out Of Service state when all remote peers are unreachable 66
CUCM SIP Trunks DTMF Configuration
Send tones using keypad

OOB DTMF OOB DTMF
SME
Cluster
SIP SIP IVR
In Band DTMF RFC 2833

RTP Media
SIP Trunks support the following DTMF configurations :

OOB and RFC2833 Both Out Of Band (OOB) and RFC2833 DTMF must be sent
RFC2833 Inband RFC2833 DTMF only
No Preference Either RFC2833 or OOB can be used
The DTMF capabilities of the endpoint are sent in the Offer
No Preference Default setting (Recommended) 67
If a DTMF mismatch occurs MTP inserted by Leaf cluster

CUCM SIP Trunk
Codec Preference Lists
68
SIP Trunk Features
Audio Codec Preference Lists
Audio Codec Preference Lists simplify Dial Plan and Trunk configuration, by allowing a single SIP
Trunk and Route Pattern to be used by multiple devices that have different codecs preferences e.g.
Fax Machines (G.711), Phones (G.729). Prior to this feature, a SIP Trunk & Route Pattern(s) needed
to be configured for each codec type
An Audio Codec Preference List presents all the codec types supported by CUCM. The codec
preference order in this list can be modified and saved as a custom preference list.
69
SIP Trunk Features
Audio Codec Preference Lists - Audio Codecs Offered
The list of codecs used for codec negotiation during call set up is the subset of
codecs supported by the device and those in the codec preference list, limited
by the maximum audio bit rate for the region/ region pair.
Region A Region A-C Codec Region C

Preference List
(1) G722
(2) G711 SIP INVITE
(3) G729 Codec preference in
(4).. Offer SDP
(1) G711
(2) G729
Codecs Region A-C

supported Maximum
by device Audio SIP Early Offer Trunk
G711 Bitrate
G729 64 kbps
71
SIP Trunk Features
Audio Codec Preference Lists - Audio Codecs Offered
The list of codecs used for codec negotiation during call set up is the subset of
codecs supported by the device and those in the codec preference list, limited
by the maximum audio bit rate for the region/ region pair.
Region A Region A-C Codec Region C

Preference List
(1) G722
(2) G711 SIP INVITE
(3) G729 Codec preference in
(4).. Offer SDP
(1) G729
Codecs Region A-C

supported Maximum
by device Audio SIP Early Offer Trunk
G711 Bitrate
G729 40 kbps
72
SIP Trunk Features
Audio Codec Preference Lists Deployment Recommendations
Region A Region A-C Codec Region C Region D Region D-E Codec Region E
Preference List Preference List
(1) G729
G.729 Voice Call (1) G729
(2) G711 (2) G711
(3) G722 (3) G722
(4) (4)
Region B Inter Cluster Trunk Region F

Region B-C Codec Region D-F Codec
(1) G711 G.711 Fax Call (1) G711
(2) G722 (2) G722
(3) G729 (3) G729
FAX (4). Cluster 1 Cluster 2 (4) FAX
For calls between two Unified CM clusters via SIP Trunks, Audio Codec Preference Lists allow the
codec used for a call to be selected based upon the calling and called devices codec preference.
Note Equivalent Audio Codec Preference Lists for each device type region should be configured in
each cluster to ensure that a common codec is selected for each device types, irrespective of call
direction or Trunk configuration.
73
SIP Trunk Features
Accept Audio Codec Preferences in Received Offer
Accept Audio Codec Preferences in
Received Offer
Region A Region C Region D Region E Region F
Region A-C Codec Region E-F Codec
Preference List G.729 Call Preference List
(1) G729 (1) G729
(2) G711 (2) G711
(3) G722 SME (3) G722
Phones Phones
Region B SIP SIP Region G

Region B-A Codec Region E-G Codec
(1) G711 G.711 Call (1) G711
(2) G722 (2) G722
FAX (3) G729 Cluster 1 Cluster 2 (3) G729 FAX
In deployments where calls can pass through more than one Unified CM cluster, for example SME
deployments; the inter-region Audio Codec Preference List of the intermediary Unified CM cluster can over-
ride the preferred codec selection between the calling and called device. To ensure that the endpoints codec
preferences are honored as calls pass through SME, enable the SIP Profile feature Accept Audio Codec 74
Preferences in Received Offer on all SIP Trunks.

SIP Trunk Features
Unified CM and CUBE SIP Trunk Codec Preference
Region A Region C Inbound Dial-Peer Outbound Dial Peer
Region A-C Codec Voice Class Codec Voice Class Codec
Preference List Preference List Preference List
(1) G729 (1) G729 (1) G729
(2) G711 (2) G711 (2) G711
(3) G722 (3) G722 (3) G722 Phones
(1) G729
G.729 Voice Call (2) G711
Region B SIP Trunk

Region B-A Codec
Preference List
(1) G711
(2) G722
FAX (3) G729 G.711 Fax Call FAX
Cluster 1 (1) G711
Instead of using dedicated SIP Trunks to CUBE for Voice and Fax calls, a single SIP Trunk and a single inbound &
outbound Dial-Peer can be configured on CUBE for all device types. Its recommended to use the same voice
class codec preference list for both the inbound & outbound dial-peer containing the list of codecs that you
want to negotiate with the service-provider.
The order of the codecs will be dictated, first by the order received in the inbound offer and then
by the order defined under voice class codec. 75
Name and Number
Presentation and Restriction
SIP Message Header Message Header Content

Privacy: None
76
Presentation/Restriction of Calling Line ID & Calling Name
From: Bob Jones" <sip:2002@10.10.199.251>
or From: Bob Jones" <sip:localhost>
or From: "Anonymous" <sip:2002@10.10.199.251>
or From: "Anonymous" <sip:localhost>
2002
Bob Jones
Applied at the Trunk Level using
P-Asserted-Identity Privacy Header
settings
If Non-Default - Overrides
Device/Line and Trunk settings
Applied using Line ID and Name Applied at the Trunk Level using Line
Presentation settings in a Translation ID and Name Presentation settings
Pattern associated with the Calling If Non-Default - Overrides 77
Search Space on the Device or Line Device/Line settings
Line/Device - Presentation/Restriction of Calling Line ID and
Calling Name
2002
Bob Jones
Applied via Translation Pattern/ Transformation Pattern Phone Caller ID Values :

Default = Do not change ID/Name
Allowed
Restricted
Applied Translation Pattern
78
SIP Trunk - Calling Line ID and Calling Name
Presentation/Restriction Outbound Calls

2002 or From: "Anonymous" <sip:localhost>
Bob Jones
Trunk settings :
Default
Use calling device values
Allowed
RPID privacy value = Off
Restricted 79
RPID privacy value = Name/URI/Full
SIP Trunk - Calling Line ID and Name Presentation/Restriction
P Asserted Identity (PAI) SIP Privacy header value
2002 From: "Anonymous" <sip:localhost>

Bob Jones P-Asserted-Identity: Bob Jones sip:2002@10.10.199.251
Privacy : ID
The SIP Trunk PAI Privacy header value always overrides Device
and Trunk ID Presentation/ Restriction settings
SIP Trunk configuration :
SIP Privacy Setting
Default Privacy values taken from Trunk/ Device - Presentation/Restriction settings
None Implies Presentation Allowed
ID Presentation restricted for name and number Overrides device setting
80
ID Critical Presentation restricted Must be supported by network, or call fails
CUCM SIP Trunk Features
Outbound Calls Overwriting the Caller DN and Name
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
From: Cisco Systems UK<sip:+442088241000@10.10.199.251>
P-Asserted-Identity: Bob Jones" <sip:2002@10.10.199.251>
Remote-Party-ID: "Bob Jones <sip:2002@10.10.199.251>
Contact: <sip:+442088241000@10.10.199.251:5060>
2002
Bob Jones
The Trunk configuration for Caller Information

allows the From header to be overwritten for
outbound SIP Trunk calls
+442088241000
Cisco Systems UK If Maintain Original Caller ID DN and Name is
X not checked the P-Asserted-Identity and Remote-
Party-ID fields are also overwritten 81
CUCM Phone and Trunk SIP Profile Features
Centralized Trunk Overwriting the Caller DN and Name (1)
From: Cisco Systems<sip:+441315613613@10.10.199.251>
Edinburgh Office
P-Asserted-Identity: Peter Black" <sip:5001@10.10.199.251>
Directory Number = 5001
Name = Peter Black Remote-Party-ID: Peter Black <sip:5001@10.10.199.251>;
Contact: <sip:+441315613613@10.10.199.251:5060>

London Office
Name = Bob Jones Remote-Party-ID: "Bob Jones <sip:2002@10.10.199.251>;
Contact: <sip:+442088241000@10.10.199.251:5060>
With multiple Remote Branches sharing a

centralized PSTN egress :
Caller ID DN and Name can be configured per site

(or per phone if needed) using the Phone settings in
the SIP Profile instead of the Trunk settings 82
Edinburgh Office
Contact: <sip:+441315613613@10.10.199.251:5060>
For each remote site : For Phones in Edinburgh

Create a SIP Profile and configure the Caller
ID DN and Caller Name. Associate this profile
with the phones at this site +441315613613
Cisco Systems
On the Outbound SIP Trunk SIP Profile -

For Outbound Trunk
Check the box to Allow Passthrough of 83
X
configured Line Device Caller Information
LUA Scripts for Interoperability
Developers Guide to SIP Normalization and Transparency
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/sip_tn/9_1_1/sip_t_n.html
84
CUCM SIP Trunk Features Normalization & Transparency
SIP Trunk Normalization
SIP/SCCP SIP Trunk Normalization allows incoming and outgoing SIP
messages to be modified on their way through a CUCM
Script SIP Trunk.
SIP Trunk SIP Trunk
The Normalization feature is designed to improve
IP PSTN
interoperability between CUCM SIP Trunks and SIP based
Script
3rd Party SIP PBXs, Applications & IP PSTN services.
H323 Trunk SIP Trunk
Normalization is independent of what the SIP Trunk
Script connects to on the other side of CUCM. e.g.
MGCP Trunk SIP Trunk
IP PSTN SIP SIP Trunk calls
Skinny SIP Trunk calls
Normalization Script H.323 SIP Trunk calls
Remove display name from SIP Header
MGCP SIP Trunk calls
function fixInboundPai()
local pai = Sip.getHeader("P-Asserted-Identity")
local displayname = getDisplayName(pai) Normalization uses a scripting environment to allow
local uri = getUri(pai) customers to modify SIP messages and SDP content on a
local number = getUserPart(uri) per trunk basis.
if displayname == number 85
then Sip.modifyHeader("P-Asserted-Identity", uri)
Agenda
87
CUCM SIP Trunk Call functions
Hold/Resume
88
CUCM SIP Trunk Signaling and Operation
Hold/Resume Signaling - Hold
SIP Trunk
INVITE with SDP

INVITE with SDP INVITE with SDP
(a=sendonly)
(a=inactive) (a=inactive)
200 OK with SDP 200 OK with SDP

200 OK with SDP (a=inactive)
(a=inactive)
(a=recvonly)
ACK ACK ACK
HOLD
Call In Progress - Two Way Media
Note CUCM SIP Trunks also send c= IN IP4 0.0.0.0 in SDP 89
(Older RFC 2543 Hold method)

Hold/Resume Signaling - Resume
SIP Trunk
INVITE with SDP

INVITE without SDP INVITE without SDP
(a=sendrecv)

200 OK w/ SDP (a=sendrecv)
(a=sendrecv)
(a=sendrecv)
ACK ACK with SDP ACKwith SDP

(a=sendrecv) (a=sendrecv)
RESUME
Call Resumes - Two Way Media
On receipt of a mid call INVITE without SDP the remote User Agent should 90
respond with its full codec list and a=sendrecv

Send Send Receive in mid call INVITE
91
CUCM SIP Trunk Interop Feature (1) - Hold
Send send-receive SDP in mid-call INVITE
SIP Trunk
INVITE with SDP

(a=sendonly)

200 OK with SDP (a=inactive)
(a=inactive)
(a=recvonly)
ACK ACK ACK
HOLD
This feature is used to address a=inactive issues with 3rd Party systems 92
( Issue not widely found - typically with some Service Providers)

CUCM SIP Trunk Interop Feature (2) Resume - The issue
Send send-receive SDP in mid-call INVITE
SIP Trunk
INVITE with SDP

(a=sendrecv)

200 OK w/ SDP (a=INACTIVE)
(a=INACTIVE)
(a=INACTIVE)

RESUME
a=inactive returned Media not resumed

Some 3rd Party UC systems return a=inactive in response to 93
a mid call INVITE without SDP
CUCM SIP Trunk Interop Feature The Fix (1)
Send send-receive SDP in mid-call INVITE Enabled
SIP Trunk
INVITE with SDP

(a=sendonly)

200 OK with SDP (a=sendrecv)
(a=sendrecv)
(a=recvonly)
ACK ACK ACK
HOLD
MTP
When the mid-call INVITE is sent CUCM inserts an MTP to anchors the media to the held device and
94
allow the holding device to disconnect its media (and optionally insert MOH)
CUCM SIP Trunk Interop Feature The Fix (2)
Send send-receive SDP in mid-call INVITE Enabled
SIP Trunk
INVITE with SDP

(a=sendrecv)

200 OK w/ SDP (a=sendrecv)
(a=sendrecv)
(a=sendrecv)

RESUME
MTP
95
Transfer
96
Transfer Call in Progress Hold Initiated
Initiate HOLD SIP Trunk
HOLD Complete
Transfer
RTP
Initiate HOLD
HOLD Complete
97
Transfer Call Transfer Target
HOLD Complete
Dial 2nd Number
Initiate 2nd Call Initiate 2nd Call Initiate 2nd Call
Call Complete Call Complete Call Complete
Initiate HOLD
HOLD Complete
98
Transfer Completing the Transfer
HOLD Complete
Initiate 2nd Call Initiate 2nd Call Initiate 2nd Call
Call Transfer
Complete Call Complete Call Complete
REFER
INVITE INVITE
202 ACCEPTED
NOTIFY (REFER active) 100 Trying 100 Trying
BYE
NOTIFY (REFER Term.) 200 OK with SDP 200 OK with SDP
ACK with SDP ACK with SDP
Initiate HOLD
HOLD Complete Note CUCM consumes REFER from the
INVITE/100/200
INVITE/100
INVITE/100/200/ACK
INVITE
Phone and sends a Re-INVITE to maintain
control of call signalling
99
RTP
CUCM SIP Trunk
Call Features explained
101
The Offer/Answer model - Ringback
INVITE INVITE
Caller hears
locally 200 OK with SDP (Offer) 200 OK with SDP (Offer)
generated ACK with SDP (Answer) ACK with SDP (Answer)
ringback tone
Two Way Media
If SDP is sent in a 18X message CUCM cuts through early media from far end for ringback
INVITE Supported:100rel INVITE Supported:100rel
Caller hears PRACK with SDP (Answer) PRACK w/ SDP(Answer)

ringback tone
from called UC Media Established - Ringback
system 200 OK (PRACK) 200 OK (PRACK)
103
SIP Profile settings - Disable Early Media on 180
By default, Cisco Unified Communications Manager signals the calling phone to play local
ringback if SDP is not received in the 180 or 183 response.
If SDP is included in the 180 or 183 response, instead of playing ringback locally, Cisco
Unified Communications Manager connects media, and the calling phone plays whatever
the called device is sending (such as ringback or busy signal).
If ringback is not received, the device to which you are connecting may be including SDP in
the 180 response, but it is not sending any media before the 200 OK response. In this case,
check this check box to play local ringback on the calling phone and connect the media
upon receipt of the 200 OK response
104
SIP Profile settings - Redirect by Application
Redirect by Application Default setting = unchecked
When checked allows CUCM to apply digit analysis to the redirected contact number to :
a) Make sure that the call gets routed correctly
b) Apply a specific Calling Search Space for Calls of Service/ Call Restriction
c) Prevent DOS attack by limiting the number of redirections
d) Allow other features to be invoked while the redirection is taking place
When unchecked (default) the redirection gets handled at the SIP stack level and the above
features cannot be invoked 105
Redirect by Application Disabled (Default setting)
SIP SIP Trunk
INVITE (1000) INVITE (1000)

1000
302 Temporarily Moved Call
(+15551230000) Forward
All
INVITE (+15551230000) INVITE (+15551230000)

100 Trying 100 Trying 100 Trying
180 Ringing 180 Ringing 180 Ringing
200 OK with SDP 200 OK with SDP 200 OK with SDP
ACK with SDP ACK with SDP ACK with SDP
RTP
106
+15551230000
Redirect by Application Enabled Call Blocked
SIP SIP Trunk
INVITE (1000) INVITE (1000) 1000
Apply 302 Temporarily Moved

Call
Forward
CCS (+15551230000) All
CANCEL CANCEL CANCEL
108
+15551230000
CUCM SIP Trunks
Matching inbound SIP calls to configured SIP Trunks
CUCM SIP Trunks will only accept inbound calls from a device with a source IP address
and port number that has been defined on the matching Trunk
A A
SIP Trunk 1 SIP Trunk 2
B F B F
C G C G
D H D H
E E
Cluster 1 Cluster 2 Cluster 1 Cluster 2
Cluster 1 SIP Trunk 1 Configuration Cluster 2 SIP Trunk 2 Configuration

SIP Trunk 1 has an active SIP daemon on SIP Trunk 2 has an active SIP daemon on
servers A, B, C, D and E servers F, G and H
Cluster 2 servers F, G and H are defined as Cluster 1 servers A, B, C, D and E are 109
Trunk destinations defined as Trunk destinations

SIP Profile settings Reroute request based on
Reroute Incoming Request to New Trunk based on :

Never (Default) - Match inbound call to SIP Trunk based on IP address and port number
Contact header - Match inbound call based on IP address and port number but re-route
the call to another SIP Trunk based on the IP address and port number
received in the contact header
- Can be used to reroute calls from a SIP Proxy to an end user/system
specific CUCM SIP Trunk
Call-Info Header with purpose=x-cisco-origIP
- Used to match inbound calls from CVP to a specific Trunk based on the
IP address and port number contained in the Call-Info header parameter
purpose=x-cisco-origIP (Used for CAC) 110
Agenda
111
Large Scale UC Designs
With more than one SIP Trunk.
CUCM Cluster 1 CUCM Cluster 2
So far we have looked at SIP Trunk features and functions based on a single SIP Trunk
interconnecting two CUCM Clusters
Large scale designs can comprise of multiple call controls from multiple vendors, various UC
applications (Voicemail, Conferencing etc) , Session Border Controllers and Gateways for PSTN
connectivity. Ideally they will all be using SIP Trunks as this will greatly simplify the UC design and
improve interoperability.
Large scale designs need to be considered holistically, particularly when it comes to Trunk
112
Aggregation, DO/EO usage, Codecs, DTMF, Dial Plan and Call Admission Control
Trunk Aggregation using Session Management Edition (SME)
PSTN
CUBE
SBCs SIP
Voicemail Conferencing
System System
Cisco Unified Session Management

Edition Cluster
Leaf Systems
SME can interconnect 1000s of UC systems using SIP Trunks and reduces the number of Trunks needed
by using a hub and spoke topology rather than full mesh. SME allows you centralizing your dial plan and
call routing rules on the SME cluster which allows you to simplify the dial plan and management of the
113
leaf UC systems
Signaling Delay In Global UC networks
Recommendations for media delay are well defined

(ITU Recommendation G.114. < 150mS = acceptable, 150 400mS = acceptable with some impact on quality,
>400mS generally unacceptable)
Recommendations for signaling delay are not well defined
Primarily because the incurred delays are protocol dependent and the impact of long delay generally affects call set
114
up rather than overall voice quality

Global UC Designs
A single SME cluster Clustered Globally over the WAN
UC 9.1+
SME CoW up SME < 500 mS
to 500mS CoW+
RTT
< 500 mS
Latin America Asia Pac
One Globally distributed SME cluster (Up to 16 subscribers supported)

Leaf clusters must have SIP trunks to pointing to all SME nodes (Multiple Trunks /Route Lists)
All SME SIP Trunks must use SIP only with Run on all Unified CM nodes
SME SIP Trunks must use Best Effort Early Offer (Or MTP-less Early Offer (pre UC 10.5))
SME clusters cannot use any media resources (MTPs, Transcoders etc) 116
Up to 500 mS between call processing nodes, Up to 500 mS between Publisher and Subscribers
Large Scale UC designs
Deploying SME clusters with no media resources
Media Resources Media Resources
Leaf Cluster
New York
Media Resources
SME
Cluster
Media Resources
Leaf Cluster
Leaf Cluster Europe
Los Angeles
Ideally, Media Resources such as MTPs, Transcoders, Music on Hold, Conferencing Resources should
never be utilized in the SME cluster as this entails hair-pinning media via the media resource
associated with the SME cluster
This design possible if the SME cluster uses of SIP Trunks only and Best Effort Early Offer Trunk
117
configuration (or for pre UC 10.5 clusters MTP-less Early Offer see Appendix for details)
Media Transparent SME clusters
SME SIP Trunks Best Effort Early Offer/ MTP-less Early Offer
Delayed Offer Delayed Offer
SME
Cluster

North America Early Offer Early Offer Europe
SME Trunks use Best Effort Early Offer (or (pre UC10.5) MTP-less Early Offer)
If a Transcoder is required Inserted by Leaf cluster
If Conferencing resources are required Inserted by Leaf cluster
If MTPs for DTMF mismatch are required Inserted by Leaf cluster
118
No media resources associated with the SME SIP Trunks, IPVMS can be disabled in the SME Cluster
One Global SME cluster Clustered Over the WAN
Call Routing Route Local for SME
DC1 SME Nodes
North America
1st choice Trunk
Leaf Cluster Route List Leaf Cluster

2nd choice Trunk
DC2 SME Nodes

One SME Globally distributed SME cluster Europe
Leaf Clusters
Multiple SIP Trunks in Route Groups provide ordered selection of SME nodes.
Route List Call Distribution priority order nearest data centre 1st, second nearest data centre 2nd etc
SME CoW cluster
Single SIP Trunk with Run on all Nodes enabled pointing to all nodes in each leaf cluster 119
Route local operates in the SME cluster No inter node intra cluster call routing
Summary SIP Trunk
configuration
recommendations for
Multi-Cluster designs
120
Large Scale SIP Trunk Design Recommendations UC versions <10.5
SIP MTP-less Early Offer CUBE
IP
SIP Trunk
SIP Delayed Offer PSTN SIP DO to EO
SIP Early Offer
CUCM 8.5+
Mostly Older
Phones (7940/60s)
CUCM 8.5+
Mostly Newer CUCM 8.5+ SME
Phones
Leaf Cluster SIP ICT Trunks - Voice, Video and Encryption supported
SIP Delayed Offer/Early Offer Mandatory (insert MTP if Needed), Run on All Nodes, Multiple Destination Addresses,
OPTIONS Ping, PRACK
SME Cluster SIP ICT Trunks - Voice, Video and Encryption supported
SIP MTP-less Early Offer, Run on All Nodes, Multiple Destination Addresses, OPTIONS Ping, PRACK, No Media resources
can be assigned to Trunks
CUBE/IOS Gateway/ IP PBX SIP Trunks Typically Voice only, Video and Encryption possible
SIP Delayed Offer/Early Offer (EO commonly used), (EO by sent by the CUBE/ IOS Gateways) OPTIONS Ping, PARCK, Early
Offer usually required by Service Providers (Use CUBE SIP DO to EO) 121
Large Scale SIP Trunk Design Recommendations UC versions 10.5+
SIP Best Effort Early Offer CUBE SIP Trunk
IP
SIP Delayed Offer PSTN SIP DO to EO
SIP Early Offer
CUCM 10.5+
CUCM 10.5+ CUCM 10.5+ SME
Leaf Cluster SIP ICT Trunks - Voice, Video and Encryption supported
SIP Best Effort Early Offer, Run on All Nodes, Multiple Destination Addresses, OPTIONS Ping, PRACK
SME Cluster SIP ICT Trunks - Voice, Video and Encryption supported
SIP Best Effort Early Offer, Run on All Nodes, Multiple Destination Addresses, OPTIONS Ping, PRACK, Media resources not
required
CUBE/IOS Gateway/ IP PBX SIP Trunks Typically Voice only, Video and Encryption possible
SIP Delayed Offer/Early Offer (EO commonly used), (EO by sent by the CUBE/ IOS Gateways) OPTIONS Ping, PRACK, Early
Offer usually required by Service Providers (Use CUBE SIP DO to EO) 122
Call Admission Control (CAC)
123
Call Admission Control using Session Management Edition
PSTN
CUBE
SBCs SIP
Voicemail Conferencing
System System
Cisco Unified Session Management

Edition Cluster
Leaf Systems
In general SME Trunks to not placed into standard Locations for Call Admission Control
SME SIP trunks are generally placed into Phantom Locations for Locations based CAC, or Shadow
Locations for Enhanced Locations based CAC Phantom and Shadow locations do not count 124
calls/bandwidth. Using this method Call Admission Control takes place in the Leaf Cluster/ UC system
Multi Branch Leaf clusters provide Locations based CAC
ICTs in Location Phantom
Phantom Locations allow the Phantom Phantom
originating location of each ICT-CL1 ICT-CL2
call to be sent over ICTs 1 2
Phantom Phantom
SME
ICT-SME ICT-SME
Central Site Central Site

Cluster 1 Cluster 2
Cluster 1 Locations CAC

WAN Cluster 2 Locations CAC
80k Deduction for 80k Deduction for
Location B Location F
SIP Trunk
- 80 kbps - 80 kbps 125
Branch 1 Call Signaling Branch 2
Cluster 1 Media Cluster 2
Multi Branch Leaf clusters - Locations CAC Call Transfer
Phantom Locations allow the Phantom Phantom The originating location of the
ICT-CL1 ICT-CL2
originating location of each inbound transferred call is
1 2
call to be sent over ICTs returned to cluster 1
Phantom Phantom
ICT-SME ICT-SME
Central Site 4 3 Central Site

Cluster 1 Cluster 2
Cluster 1
Locations CAC Cluster 2
0 kbps Deduction for WAN Call Transferred to Cluster 1
Location B Location B
(0 WAN Calls)
Transfer
SIP Trunk
No WAN No WAN calls 126
Branch 1 Call Signaling Branch 2
calls
Cluster 1 Media Cluster 2
UC 9.0 Enhanced Locations CAC - SME and Multi Branch
E-LCAC introduces : Global Topology
Hub Leaf clusters
The concept of Links inter-connecting Hub
Locations
A B C D E F G
Sharing Topology information SME Local Locations
Link X-Hub Link Z-Hub
B/W = 256k B/W = 512k
(Locations/ Links/ Link Bandwidth)
using Location Bandwidth Manager
(LBM) Location Location Location
X Y Z
Dynamic distribution between
clusters of bandwidth usage on Links Leaf Clusters define their Locations
Shadow Shadow
between locations ICT-CL1 ICT-CL2
SME defines all Locations and Links
SME - Transparent Hub Location
Each Cluster builds a global topology
of Locations and Links SME distributes global topology
Locations can be shared information to all clusters
Shadow Shadow
Global Topology ICT-SME ICT-SME Global Topology
Hub Hub
A B C D E F G Central Site WAN Central Site A B C D E F G

Cluster 2 Local Locations
Cluster 1 Local Locations Cluster 1 Cluster 2 127
A B C D D E F G
Deploying Applications in
Large Scale UC networks
128
Large Scale SIP Trunk Design Recommendations Applications
Cisco TelePresence
Unity Server and Conductor
Connection Conferencing
Voicemail System
System
Expressway E & C
Session
Management
Edition Cluster
Jabber MRA Client
Cisco
Cisco Unified Emergency Cisco Operator
Contact Center CER Responder IM &P Console
SIP Line
Cisco Unified CM Cisco Unified CM

Leaf Cluster 1 Leaf Cluster N
General Guidance
Applications that track user state must be connected to the leaf CUCM cluster
129
Other applications such as voicemail and conferencing can be centralized

Centralized Applications - Conferencing
Cisco
TelePresence
SIP Trunk Servers
XML RPC over HTTP/HTTPS Cisco TelePresence Conductor
Rendezvous
Conferences
Session
Management
SIP Trunk and XML Edition SIP Trunk and XML
RPC connections Cluster RPC connections
for Ad Hoc for Ad Hoc
Conferences Conferences
SIP Trunks for Rendezvous

Conferences

Cisco TP Server and TP Conductor can be centralized with SME :

Rendezvous Conference calls can be routed over SIP Trunks via SME to TP Server
130
Ad Hoc Conferences need a direct SIP Trunk and XML RPC connection from the leaf CUCM
Centralized Apps Expressway Mobile Remote Access & B2B
SIP Trunks for B2BUA
SIP Line for MRA clients
Internet Expressway E & C

Session
Management
Edition Cluster
Jabber MRA Client
Jabber MRA Client

Expressway C and E can be centralized with SME :

For B2B connections a SIP Trunk can be used to connect Expressway and SME
131
For Mobile Remote Access MRA clients establish a direct line side connection to their home cluster
Dial Plans
132
Large Scale UC Design Dial Plan
Dial Plan Aggregation using SME Basic Principles
In the SME cluster a unique globalized dial plan should be implemented Inbound number
globalization and outbound number localization can be implemented in the SME cluster
Leaf Cluster SME Cluster Leaf Cluster
In Leaf clusters/ Leaf UC systems a localized dial plan may

be implemented and users may have local dialing habits 133
Internal Directory Numbers, +E.164 SME Dial Plan, Abbreviated
On Net Dialing
Calling Number +44-404-442-4000 Calling Number +44-404-442-4000
Called Number +55-505-559-5000 Called Number +55-505-559-5000
Cluster 1 DNs Cluster 2 DNs

SME Cluster
442-4XXX 559-5XXX
+ E.164 Dial Plan
Calling Number +44-404-442-4000 Calling Number 8-442-4000

Called Number 8-559-5000 Called Number 559-5000
Caller (444-4000) dials 8-559-5000

Leaf Cluster 1 Leaf Cluster 2
Internal Directory Numbers (XXX-YYYY) Internal Directory Numbers (XXX-YYYY) 134
Abbreviated Dialing (8-XXX-YYYY) Abbreviated Dialing (8-XXX-YYYY)

Internal Directory Numbers, +E.164 SME Dial Plan, Abbreviated On Net Dialing. All
number transformations performed on SME cluster
Calling Number +44-404-442-4000 Calling Number 8-442-4000

Called Number +55-505-559-5000 Called Number 559-5000
PBX 1 DNs PBX 2 DNs

SME Cluster
442-4XXX 559-5XXX
+ E.164 Dial Plan
Calling Number 442-4000 Calling Number 8-442-4000

Called Number 8-559-5000 Called Number 559-5000
Caller (444-4000) dials 8-559-5000

PBX 1 PBX 2
Internal Directory Numbers (XXX-YYYY) Internal Directory Numbers (XXX-YYYY) 135
Abbreviated Dialing (8-XXX-YYYY) Abbreviated Dialing (8-XXX-YYYY)

+E.164 Directory Numbers, +E.164 SME Dial Plan, E.164 Dialing

Cluster 1 DNs Cluster 2 DNs

SME Cluster
+44-404-442-4XXX +55-505-559-5XXX
+ E.164 Dial Plan

Caller (+44-404-442-1000) dials 55-505-559-5000

Leaf Cluster 1 Leaf Cluster 2
+ E.164 Directory Numbers + E.164 Directory Numbers 136
E.164 Dialing E.164 Dialing

Inter Cluster look Up Service (ILS)

URI dialing
Numeric dialing - Global Dial Plan Replication (GDPR)
137
URI Dialing
Inter-cluster Lookup Service (ILS) UC 9.0+
ILS runs as a CUCM service and distributes locally registered URIs to other clusters
Cluster to cluster ILS connections can be hub and spoke or full mesh
URIs are associated with a cluster route-string (label) e.g. sanjose-ca.us or london.uk.eu
URIs and their route string are stored locally, partial ILS file updates are supported
URIs from 3rd Party systems can be imported into ILS and distributed
SME Flat File
MSFT Lync 1 San Jose London MSFT Lync 1
Rowan@cisco.com Diane@cisco.com Helen@cisco.com Rowan@cisco.com
Jane@cisco.com Chris@cisco.com Greg@cisco.com Jane@cisco.com
Diane@cisco.com Bryan@cisco.com Bob@cisco.com Fran@cisco.com Bryan@cisco.com Helen@cisco.com
Alicia@cisco.com Anne@cisco.com Eric@cisco.com Alicia@cisco.com
San Jose London

Chris@cisco.com Greg@cisco.com
San Jose London
Diane@cisco.com Helen@cisco.com
Chris@cisco.com Greg@cisco.com
Bob@cisco.com Fran@cisco.com
Anne@cisco.com Eric@cisco.com
Bob@cisco.com MSFT Lync 1 MSFT Lync 1 Fran@cisco.com

Rowan@cisco.com Rowan@cisco.com
Jane@cisco.com Jane@cisco.com
Bryan@cisco.com Bryan@cisco.com
Alicia@cisco.com Alicia@cisco.com 138
ILS scales to 100 of 1000s of URI entries (1,000,000 tested)
URI Dialing
Inter-cluster Lookup Service (ILS) Operation
When a user dials a URI CUCM checks to see if it is registered locally
If not, CUCM looks for the URI in its ILS store a match returns the route string for the
destination cluster associated with the dialed URI e.g. sanjose.ca.us or london.uk.eu
This route string is used to match SIP route pattern to onward route the call
Diane calls
Helen@cisco.com SME
Yes
Does Route String San Jose London
Diane@cisco.com Helen@cisco.com
london.uk.eu match
Is Helen@cisco.com a Chris@cisco.com Greg@cisco.com
Diane@cisco.com Fran@cisco.com Helen@cisco.com
locally No SIP Route
an existing
registered URI Bob@cisco.com
Pattern
?
San Jose Route the URI call to London
Chris@cisco.com london.uk.eu over the
Can Helen@cisco.com Greg@cisco.com
Yes
Route
be found inPatterns
ILSString
? SIP
Return RouteTrunk
london.uk.eu for URI
Helen@cisco.com
London San Jose
Helen@cisco.com Diane@cisco.com
Greg@cisco.com Chris@cisco.com
Fran@cisco.com Bob@cisco.com
Eric@cisco.com Anne@cisco.com 139
ILS scales to 100 of 1000s of entries (1,000,000 tested)
UC 10.0+ Number and Route Pattern support over ILS
Global Dial Plan Replication (GDPR)
Numbers and Patterns can be advertised and assigned to partitions for Class of Service
Default Partitions are assigned to
Enterprise Alternate Numbers (e.g. 82121000)
E.164 Alternate Numbers (e.g. +12125551000)
Enterprise Patterns (e.g. 82121XXX) and E.164 Patterns (e.g. +12125551XXX)
SME Flat File
Avaya FR San Jose London Avaya FR
+33666035542 Diane@cisco.com Helen@cisco.com +33666035542
+33467678921 +14089024567 +442088244567 +33467678921
Diane@cisco.com +33453567619 Bob@cisco.com Fran@cisco.com +33453567619 Helen@cisco.com
+33677687297 +14089021234 +442088241234 +33677687297
+1408902XXXX +44208824XXXX
San Jose London
+14089024567 +442088244567
London Avaya FR Avaya FR San Jose
Helen@cisco.com +33666035542 Diane@cisco.com
+33666035542 +14089024567
+442088244567 +33467678921 +33467678921
+33453567619 Bob@cisco.com 140
Fran@cisco.com +33453567619
+442088241234 +33677687297 +33677687297 +14089021234
+14089021234 +442088241XXX +1408902XXXX +442088241234
Global Dial Plan Replication Number and URI Configuration
Number Mask masks Line DN
Alternate Number product of Line
DN and Number Mask 1XXXXX
Local Partition where the

Enterprise Alternate Number (EAN)
and E.164 Alternate Number are
stored in this cluster
9728131XXXXX
Advertise Globally in ILS
Directory URI can be imported from
LDAP
PSTN failover Number (EAN or E.164
number) supported for EAN, E.164
AN and URI calls
141
Global Dial Plan Replication Number Pattern Configuration
Pattern Type :
Enterprise Alternate Number (these
patterns can also be an internal 164
number pattern) or
E.164 Number Pattern (e.g. PSTN
number ranges)
PSTN failover :
Use pattern as is, or
Strip digits and/or Prepend digits
Note Numbers, URIs and Patterns for 3

3
3rd Party systems can be imported

into ILS GDPR
142
Global Dial Plan Replication
Partitions for Learned Numbers and Patterns
Four default
partitions are
created to store :
Enterprise
Alternate Numbers
E.164 Alternate
Numbers
Enterprise Patterns
E.164 Patterns
Partitions can be
used to provide
Classes of Service
for Learned
143
numbers
ILS Hierarchical Routing & Route String Summarization
Each cluster does an ILS look up and makes a local routing decision to its next hop based on the returned
ILS route string e.g. Helen@cisco.com london.uk.eu ---> SIP Trunk A
Route string summarization allowed e.g. Singapore.Asia.APAC SIP Trunk A
or *.*.APAC SIP Trunk A reducing dial plan size
Routes to :
*.*.EU
*.*.APAC
San Jose.CA.US Global Backbone
New York.NY.US
US SME EU SME Asia CUBE

SBC
San Jose New York London Frankfurt Seoul Singapore

Default Route to
US SME
144
GDPR vs SME
or
GDPR and SME
145
Large Scale UC design - GDPR vs SME
GDPR Only
GDPR uses ILS to advertise a clusters URIs and numbers to every other cluster
One SIP Route pattern is required per remote cluster
Each cluster must create and manage a SIP Trunk to every other cluster
ILS Toronto
SIP
7 clusters using GDPR Boston
San Jose
6 SIP Trunks per cluster
6+ SIP Route patterns per
cluster
URIs and DNs distributed

via ILS a separate (non
Los Angeles New York
SIP) overlay service 146
Seattle Chicago
SME Only Large Scale UC design - GDPR vs SME
Global Dial Plan required on the SME cluster
Many Route Patterns required in SME, one for each unique number range
Each CUCM cluster must create and manage a single SIP Trunk to the SME cluster
At best - one default route to SME on each Leaf CUCM cluster
SME Toronto
SIP
7 CUCM clusters
+ 1 SME cluster San Jose Boston
1 SIP Trunk/CUCM cluster

1 SIP Route Pattern/cluster
Services such as Voicemail,

PSTN and conferencing can be
centralized on SME
147
Seattle Chicago
Large Scale UC design - GDPR and SME
Use GDPR and ILS to advertise URIs & numbers to every CUCM cluster and the SME cluster
Greatly simplified dial plan on the SME cluster - One Route Pattern for each remote CUCM
cluster rather than per number range
A single SIP Trunk between each CUCM cluster and the SME cluster
ILS SME Toronto
SIP
7 CUCM clusters
+ 1 SME cluster San Jose Boston
1 SIP Trunk/CUCM cluster

1 SIP Route Pattern/cluster
Services such as Voicemail,

PSTN and conferencing can be
centralized on SME
148
Seattle Chicago
Summary and key take away points
Use SIP Trunking
Run On All Nodes, Multiple Destination addresses, Options PING, PRACK
Use UC version 10.5+ and Best Effort Early Offer
Combine SME and ILS/GDPR to simplify dial plan and trunk design
Design your architecture so that Media Resources are not required in the SME
cluster
If possible avoid transcoder and MTP usage in general (By using common
codecs and DTMF methods)
149
Thank you
150
Agenda
151
Deep down into SIP
SIP INVITE Request and

Associated Message Headers
152
SIP Message exchange
SIP Trunk
INVITE
100 Trying
180 Ringing
200 OK
ACK
10.10.199.251 10.10.199.250
Two Way Media

2002 1001
153
SIP Messages INVITE Request with SIP Headers
INVITE sip:1001@10.10.199.250:5060 SIP/2.0 ------------------------------------ Request INVITE to 1001
To: <sip:1001@10.10.199.250>
Date: Wed, 18 Feb 2015 18:37:57 GMT
Min-SE: 1800
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER.. SIP Message
CSeq: 101 INVITE
Contact: <sip:2002@10.10.199.251:5060;transport=tcp> Headers
Expires: 180 Some Mandatory
Supported: X-cisco-srtp-fallback Some Optional
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Max-Forwards: 70
154
Content-Length: 0
SIP Headers Categorized :
Identity, Timers, Supported
Methods and Events, Cisco related
and other headers
155
Request /Header Request Header Content Category
INVITE sip:1001@10.10.199.250:5060 SIP/2.0 Route and
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb Transaction
CSeq: 101 INVITE related
headers
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5- Identity and

353990242dfe-32552697
Dialog
To: <sip:1001@10.10.199.250> related
Call-ID: 8fe4f600-b7c13785-3-fbc712ac@10.10.199.251 headers
156
Supported: timer,resource-priority,replaces Timer related
Session-Expires: 1800 headers
Min-SE: 1800
Expires: 180
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, Methods and
SUBSCRIBE, NOTIFY Events
Supported: X-cisco-srtp-fallback Cisco related

Supported: Geolocation headers
157
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Date: Wed, 18 Feb 2015 18:37:57 GMT Other
Max-Forwards: 70 headers
event;Duration=500"
Content-Length 0
158
SIP Request Line :
INVITE
Request Request URI Content

INVITE sip:1001@10.10.199.250:5060 SIP/2.0
159
SIP INVITE Request Line
Request Request Header Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
SIP URI content sip:user@host:port-number Comments
User 1001 Number /Name
The Called User
Host 10.10.199.250 IP Address/ Hostname/ Domain Name
Configured SIP Trunk Destination
Port 5060 TCP/UDP Port Number
SIP Protocol Version 2.0 Incoming and Outgoing Transport Type
Configurable via SIP Trunk Security Profile
How CUCM configuration affects the contents of the INVITE Request :
SIP Trunk destination configured using an IP address - Host portion = IP address

SIP Trunk destination configured using FQDN or DNS SRV - Host portion = Name 160
SIP Trunk destination port number - Default = 5060 - Can be modified

SIP INVITE Related CUCM Configuration affecting the
INVITE Request Line and To Header
CUCM SIP Trunk Request Line/ SIP URI/ SIP Message Header content
Destination SIP Message Header
IP Address Used INVITE Request Line sip:1001@10.10.199.250:5060 SIP/2.0
IP Address Used To : Header <sip:1001@10.10.199.250>
FQDN/DNS SRV Used INVITE Request Line sip:1001@cisco.com:5060 SIP/2.0
FQDN/DNS SRV Used To : Header <sip:1001@cisco.com>
FQDN /DNS SRV resolved to an IP address which is used at the IP Layer 161
SIP Header Categories :
Route and Transaction related
headers
Request /Header Request/ Message Header Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
CSeq: 101 INVITE
162
SIP Sessions : Transactions and Dialogs
A Transaction :
An exchange of messages between User Agents to perform a specific task e.g. Call set up, or
call tear down. A transaction consists of one request and all responses to that request.
A Dialog :
A series of one, or more transactions that take place between two User Agents
Transaction 101 Dialog between UA1 and UA2

Request INVITE
Response 200 OK
RTP Media
UAS UAC Request INVITE (Hold) UAS UAC
Response 200 OK
163
Transaction 102
SIP INVITE - Route and Transaction related Headers :
Via Header
A Mandatory Header in Requests and Responses
The Via header is used to record the SIP route taken by a Request and to route a Response back to the
originator. A User Agent generating a Request records its own address in a Via header field. Multiple
Via Headers can be used to record the route of a Request through several SIP switches
Exactly the same header is used by both client and server User Agents for this transaction
VIA Header content SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
SIP Protocol Version 2.0
Transport Protocol TCP Configurable :TCP/UDP/TLS
Incoming and Outgoing Transport Type
User Agent 10.10.199.251 Address of CUCM generating the SIP Request
(As a B2BUA, CUCM is the UA in this transaction)
Incoming Port Number 5060 Incoming TCP/UDP /TLS Port Number
164
Branch z9hG4bK3395a5cdb Unique Identifier for this transaction

SIP INVITE Command Sequence Header
Request /Header Request Header Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
CSeq: 101 INVITE
Mandatory Header in Requests and Responses

Command Sequence Header - Identifies and Orders Transactions
Consists of a sequence number and method
Sequence number - An arbitrary integer = 101

Method - Method used in the Request = INVITE
The sequence number and method remain the same for each transaction in a dialog
The method matches the Request for the transaction
165
Identity and Dialog related headers
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-
32552697
To: <sip:1001@10.10.199.250>
166
SIP INVITE From and To Headers
INVITE sip:1001@10.10.199.250:5060 SIP/2.0

From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-
32552697
To: <sip:1001@10.10.199.250>
The To and From Headers are mandatory in Requests and Responses
Can optionally include a display name
Calling UA appends the From tag
Called UA appends the To tag
Tags must be globally unique
The From and To tags are used with the Call ID to uniquely identify a Dialog between two UAs
Note : 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 defined to indicate
167
the direction of the request, not the direction of the message.

SIP INVITE Call-ID Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0

Call-ID: 8fe4f600-b7c13785-3-fbc712ac @10.10.199.251
Mandatory Header in all Requests and Responses

The Call-ID header field is an identifier used to keep track of a particular SIP Dialog.
The originator of the Request creates this unique string
The same Call-ID is used in all SIP messages (Requests and Responses) for all transactions
within this dialog
Transactions are tracked by the branch value in the VIA Header

Dialogs are tracked by the Call-ID, From Header tag and To Header tag
168
P-Asserted-ID and Remote-Party-ID Headers
P-Asserted Identity and Remote-Party-ID are optional SIP message headers -

P-Asserted Identity and Remote-Party-ID options are checked by default on a CUCM SIP trunk
P-Asserted Identity and Remote-Party-ID perform the same functions :

1) Delivery of user identity for call trace purposes, when a users identity is anonymized in the
content of the From Header
2) A source of truth if identity headers contain differing information
P-Asserted Identity which additionally supports Authentication, supersedes Remote Party ID.
P-Asserted Identity Privacy Header values can also override Device and Trunk settings for
Name and/or Number presentation and restriction 169
SIP INVITE : P-Asserted-Identity - Related Headers
SIP Message Header Message Header Content /values
From: Bob Jones <sip:2002@10.10.199.251>
P-Asserted-Identity: Bob Jones <sip:2002@10.10.199.251>
P-Preferred-Identity: Bob Jones <sip:2002@10.10.199.251>
Privacy: None/ ID/ ID Critical
The CUCM SIP Trunk can be configured to send User Identity in either the :
P-Asserted-Identity header Where interconnected SIP systems trust one another

or the
P-Preferred-Identity header Where the receiving SIP system can challenge authenticity
The Privacy header can be configured to indicate whether or not privacy (Identity delivery/
Identity blocking in the From header) is invoked for this call.
170
CUCM Config : P-Asserted-Identity Asserted Type
2002
Bob Jones Default = P-Asserted-Identity: Bob Jones <sip:2002@10.10.199.251>
PAI = P-Asserted-Identity: Bob Jones <sip:2002@10.10.199.251>
PPI = P-Preferred-Identity: Bob Jones <sip:2002@10.10.199.251>
SIP Trunk configuration : Used When.

Asserted Identity Type Value
Default Identity is trusted on a per Device or per Trunk call basis
Cisco Phones = Trusted Identity => PAI used
Trunk Calls = Use (trust) screening value in call set up messages
P-Asserted-Identity (PAI) All Identity values are trusted between communicating systems
171
P-Preferred-Identity (PPI) Authentication required between communicating systems
SIP INVITE: P-Asserted-Identity and P-Preferred-Identity
Trusted SIP Realm A Trusted SIP Realm B
P-Preferred Identity
P-Asserted Identity
Digest Auth Challenge from SIP Realm B
Digest Authentication Response
P-Asserted Identity is sent within a Trusted Realm

P-Preferred Identity is sent to/ received from an Untrusted Realm
When CUCM sends P-Preferred-Identity, it will respond to a Digest Authentication Challenge from a
Trunk peer in another SIP Realm.
Digest Authentication takes place at the Trunk Level (Configure the remote Realm, User ID and Digest
password via the CUCM User Management page)
CUCM does not send a Digest Authentication Challenge when a P-Preferred Identity header is received.
Not an issue - as connections to untrusted SIP Realms should always be via a Session Border Controller
172
which handles Authentication.
CUCM Configuration : PAID/PPID SIP Privacy header
2002 From: "Anonymous" <sip:localhost>

Bob Jones P-Asserted-Identity: Bob Jones sip:2002@10.10.199.251
Privacy : ID
P-Asserted-Identity: Bob Jones sip:2002@10.10.199.251
Privacy :None
The PAI Privacy header value always overrides Device and Trunk ID Presentation/ Restriction settings
SIP Trunk configuration :
SIP Privacy Setting
Default Privacy values taken from Trunk/ Device - Presentation/Restriction settings
None Implies Presentation Allowed
ID Presentation restricted for name and number Overrides device setting
173
ID Critical Presentation restricted Must be supported by network, or call fails
SIP INVITE : Remote-Party-ID Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0

Remote-Party-ID differs from PAI in that it has no authentication challenge mechanism

Remote-Party-ID has largely been superseded by P-Asserted-Identity today
Message Header Fields Values

User Identity Name <Number@Host Address> e.g. Bob Jones <2002@10.10.199.251>
Party Called/ Calling
Screen Yes = Identity Trusted by CUCM/ No If Screen=No received over Q.931/SIP
Privacy Name/URI/Full/Off
174
Privacy values taken from Device/ Trunk settings for Identity Presentation and Restriction
Related CUCM Config From Header and Identity Headers
SIP Profile Configuration Use FQDN in SIP Requests
If this box is checked, CUCM will relay an alphanumeric hostname of a caller to the called
endpoint in SIP Identity header information.
If the call is originating from a line device on the CUCM cluster, and is being routed over a
SIP trunk then the configured value for the Enterprise Parameter Organization Top-Level
Domain will be used in the Identity headers. e.g. cisco.com
SIP Message Header Message Header Content Content with Use FQDN in SIP Requests
From: <sip:2002@10.10.199.251> <sip:2002@cisco.com>
P-Asserted-Identity: <sip:2002@10.10.199.251> <sip:2002@cisco.com>
Remote-Party-ID: <sip:2002@10.10.199.251> <sip:2002@cisco.com>
Contact: <sip:2002@10.10.199.251:5060> <sip:2002@cisco.com> 175
Number and Name Presentation information
Header Priority : From/ RPID/ PAI
2002
Bob Jones From: Jim Smith <sip:1001@10.10.199.251>
Displayed
P-Asserted-Identity: Bob Jones <sip:2002@10.10.199.251> Caller
Identity
Remote-Party-ID: May Brown <sip:3003@10.10.199.251> ?
For Calling User Identity and Connected User Identity Presentation. The presented
User Identity is taken from Identity Headers in the following priority order :
1) PAI header
2) RPID header
3) From header 176
UC 10.0 allows this order to be changed

SIP Profile settings CLID Presentation
Calling Line Identification Presentation applies to inbound Requests and Responses

This feature affects :
Calling Party Number and Name for inbound calls
Connected Party Number and Name for outbound calls
Strict From URI presentation : Process Identity using the From header only
Strict Identity Headers : Process Identity using the PAI and RPID Identity headers
177
Name and Number
Presentation and Restriction
Privacy: None
178
Presentation/Restriction of Calling Line ID & Calling Name
2002
Bob Jones
Applied at the Trunk Level using
P-Asserted-Identity Privacy Header
settings
If Non-Default - Overrides
Device/Line and Trunk settings
Applied using Line ID and Name Applied at the Trunk Level using Line
Presentation settings in a Translation ID and Name Presentation settings
Pattern associated with the Calling If Non-Default - Overrides 179
Search Space on the Device or Line Device/Line settings
Line/Device - Presentation/Restriction of Calling Line
ID and Calling Name
2002
Bob Jones
Applied via Translation Pattern/ Transformation Pattern Phone Caller ID Values :

Default = Do not change ID/Name
Allowed
Restricted
Applied Translation Pattern
180
SIP Trunk - Calling Line ID and Calling Name
Presentation/Restriction Outbound Calls

2002 or From: "Anonymous" <sip:localhost>
Bob Jones
Trunk settings :
Default
Allowed
Restricted 181
RPID privacy value = Name/URI/Full
SIP Trunk - Connected Line ID and Connected Name
Presentation/Restriction Inbound Calls
Remote-Party-ID: Jim Brown"sip:1001@10.10.199.250; privacy=Off
or Remote-Party-ID: Jim Brown"sip:1001@10.10.199.250; privacy=Name
or Remote-Party-ID: Jim Brown"sip:1001@10.10.199.250; privacy=URI

or Remote-Party-ID: Jim Brown"sip:1001@10.10.199.250; privacy=Full 1001
2002 Jim Brown
Bob Jones
180/ 183/ 200/Responses
Connected Line ID and Connected Name
Presentation/ Restriction affect the
privacy value in the RPID header sent in :
180, 183 Responses and 200 Responses
Trunk settings :
Default
Allowed
Restricted 182
RPID privacy value = Name/ URI/ Full

SIP Profile settings Reject Anonymous Calls
INVITE sip:2002@10.10.199.251:5060 SIP/2.0
From: "Anonymous" <sip:localhost>
P-Asserted-Identity: Jim Brown <sip:1001@10.10.199.250>
Privacy : ID
Remote-Party-ID: Brown sip:1001@10.10.199.250 ; privacy=full
433 Anonymity Disallowed

2002 1001
Bob Jones Jim Brown
This feature is based on Identity Header Privacy settings, not the values in the From Header
i.e. If the Users identity is anonymized in the From header and PAI Privacy = None, or RPID Privacy = Off
The Call is not Rejected The Call Proceeds
x 183
Outbound Calls Overwriting the Caller DN and Name
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Remote-Party-ID: "Bob Jones <sip:2002@10.10.199.251>
Contact: <sip:+442088241000@10.10.199.251:5060>
2002 2002
Bob Jones Bob Jones
The Trunk configuration for Caller Information

allows the From header to be overwritten for
outbound SIP Trunk calls
+442088241000
Cisco Systems UK If Maintain Original Caller ID DN and Name
X is not checked the P-Asserted-Identity and
Remote-Party-ID fields are also overwritten184
CUCM Phone and Trunk SIP Profile Features
Edinburgh Office
Contact: <sip:+441315613613@10.10.199.251:5060>

London Office
Name = Bob Jones Remote-Party-ID: "Bob Jones <sip:2002@10.10.199.251>;
Contact: <sip:+442088241000@10.10.199.251:5060>
With multiple Remote Branches sharing a

centralized PSTN egress :
Caller ID DN and Name can be configured per site

(or per phone if needed) using the Phone settings in
the SIP Profile instead of the Trunk settings 185
Edinburgh Office
Contact: <sip:+441315613613@10.10.199.251:5060>
London Office
Name = Bob Jones For Phones in Edinburgh
For each remote site :

Create a SIP Profile and configure the Caller ID DN +441315613613
and Caller Name. Associate this profile with the Cisco Systems
phones at this site

On the Outbound SIP Trunk SIP Profile - Check the For Outbound Trunk
box to Allow Passthrough of configured Line X 186
Device Caller Information

SIP INVITE Contact Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0

Contact: sip:2002@10.10.199.251:5060;transport=tcp
Mandatory in INVITE Requests and 2XX Responses

A Contact header field value can contain a display name, a URI with URI parameters, and
header parameters
In a Request - The contact field contains the address at which the Calling UA can be reached
In a Response - The contact field contains the address at which the Called UA can be reached
With CUCM a B2BUA The address in the contact header field is the address of the CUCM
server, not the phone
187
Timer related headers
Request Header Request Header Content
Min-SE: 1800
Expires: 180
188
SIP INVITE Supported Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Should be sent in an INVITE

Indicates new SIP options supported by this UA
Options Supported : timer, resource-priority, replaces
Supported Option Description

Timer Indicates support for session timers as keep-alives to refresh sessions
Resource Priority Used for resource contention resolution, pre-emption
Replaces Replaces header is used to logically replace an existing SIP dialogue with a 189
new SIP dialogue. Can be used in attended Transfers, Call Pick up etc.
Related CUCM Configuration : Supported Header
Supported: timer, resource-priority, replaces
This header indicates support only. i.e. The Trunk will not accept the replaces
and resource-priority options if the corresponding Trunk settings have not been
configured/ enabled 190
SIP INVITE Session Expires and Min-SE Headers
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Session-Expires 1800
Min-SE 1800
Optional Headers - Support indicated via the Supported: timer header option
Session-Expires header used with the Minimum-Session-Expires (Min-SE) header as a session keep-
alive mechanism
Sessions can be refreshed with a Re-INVITE or UPDATE request

Allows the sender to enforce a Minimum session timer - When the call traverses multiple Proxies
Session-Expires value can an be increased or decreased by intermediate Proxies
Min-SE value can only be increased by intermediate Proxies
Called UA responds with a Session-Expires header in a 2XX message and refresher parameter to 191
indicate who (UAS or UAC) is doing the refreshing.

Related CUCM configuration
Min-SE Header, Session Expires Header
SIP Profile :
Configurable Session Refresh method - Invite/Update (Update Preferred)
Service Parameter for Session Timers Affects all SIP Trunks

Min-SE: 1800 seconds (30 mins) Default value (Min 60 secs, Max 86400 secs = 24 hours)
Session Expires: 1800 seconds (30 mins) Default value (Min 90s, Max 86400s = 24 hours)
192
SIP Session Expires and Min-SE Headers - Operation
During call set up - Session timers and Session Refresh methods are
negotiated and agreed on each SIP Trunk. Once the call is established the
session on each Trunk periodically refreshed. If no session refresh request or
response is received the UA sends a BYE to terminate the session
SME
Node
crash
SME
Cluster

Media
193
SIP INVITE Expires Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Expires: 180
Optional Header in INVITE Requests
The Expires header field gives the relative time that the message (INVITE in this case) remains valid in
seconds. Used as the primary no response timeout timer for SIP INVITE messages
If CUCM has not received a final response for the INVITE before this timer expires, CUCM will retry
the SIP INVITE up to the configured retry count (6) and if no response cancel the call.
Service Parameter value in milliseconds Header value in seconds

Default value = 180000 milliseconds = 180 seconds = 3 minutes
Minimum value = 60000 milliseconds = 60 seconds = 1 minute 194
Maximum value = 300000 milliseconds = 3000 seconds = 5 minutes

Methods and Events supported

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
195
SIP INVITE Allow Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
Optional Header - Lists the set of methods supported by the UA sending the message
Note Although supported To be used, some methods also need to be enabled on the SIP
Trunk e.g. PRACK, Accept Presence Subscription, Accept Unsolicited NOTIFY etc
196
SIP INVITE - Allow-Events Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Allow-Events presence, kpml
Optional Header
A UA sending an "Allow-Events" header is advertising that it can process SUBSCRIBE
requests and generate NOTIFY requests for all of the event packages listed in that header.
In the above case : Presence and KPML (Out of Band DTMF)
Default = No Preference Trunk supports either RFC 2833 or OOB DTMF UA capabilities sent
RFC 2833 Will override Allow-Events values from UA 197
OOB and RFC 2833 - Will override Allow-Events values from UA

Cisco and other headers
Supported: X-cisco-srtp-fallback
event;Duration=500"
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Date: Wed, 18 Feb 2015 18:37:57 GMT
Max-Forwards: 70
Content-Length: 0
198
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Optional Header
X-Cisco-srtp fallback proprietary header (can be ignored by other vendors)

Allows an offered SRTP session to fall back to RTP if not supported by both UAs
199
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Optional Header
Geolocation A standardized method to convey geographical location information from one SIP
entity to another SIP entity. Configurable on CUCM SIP Trunks Used for Logical Partitioning
Supported but needs to be configured on the SIP Trunk to be used
200
SIP INVITE Call-Info Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
event;Duration=500"
Optional Header in Requests and Responses
The Call-Info header field provides additional information about the caller or callee, depending on
whether it is found in a request or response. (In the above example - The Calling UA)
method="NOTIFY;Event=telephone-event;Duration=500 indicates support for NOTIFY based out

of band DTMF relay. Duration = time in mS between successive NOTIFY messages
Unsolicited NOTIFY can be used as a Cisco proprietary way to send DTMF Out Of Band
201
SIP INVITE User Agent Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Optional Header - Contains information about the client User Agent originating the request
CUCM configurable : SIP Profile User-Agent and Server header information
202
SIP INVITE
Cisco GUID Header Globally Unique Identifier
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Proprietary Header
Uniquely identifies the call on this Trunk
Typically used in INVITE messages
Maps to the Incoming/ Outgoing ProtocolCallRef in CUCM Call Detail Records
Note : Trunk to Trunk calls on SME have different GUIDs for inbound and outbound calls
203
SIP INVITE Date Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Date: Wed, 18 Feb 2015 18:37:57 GMT
An Optional Header
Date and time the Request or Response sent
Greenwich Mean Time (GMT) only
204
SIP INVITE : Max-Forwards Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Max-Forwards: 70
Mandatory Header in all Requests

Not required in Responses
Max-Forwards serves to limit the number of hops a request can make on the way to its
destination. It consists of an integer that is decremented by one at each hop. If the Max-
Forwards value reaches 0 before the request reaches its destination, it will be rejected with a
483(Too Many Hops) error response. Can be used for loop detection
205
SIP INVITE : Content-Length Header
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
Content-Length: 0
Mandatory Header if TCP transport used, Optional if UDP used
The Content-Length header indicates the size of the message-body sent to the recipient in
decimal number of bytes.
Message-Body For example, the Session Description Protocol (SDP) message body, which if
present would describe the media characteristics supported by the sender. The message body is
appended after the Content-Length header.
206
Deep down into SIP
SIP 180 Ringing Response and

Associated Message Headers
207
SIP Basics Typical call set-up SIP Message exchange
SIP Trunk
INVITE
100 Trying
180 Ringing
200 OK
ACK
10.10.199.251 10.10.199.250
Two Way Media

2002 1001
208
CUCM SIP Trunk Signaling
180 Ringing Response - Ringback
INVITE INVITE
Caller hears
locally 200 OK with SDP (Offer) 200 OK with SDP (Offer)
generated ACK with SDP (Answer) ACK with SDP (Answer)
ringback
tone Two Way Media
SIP/2.0 180 Ringing

Indicates that the destination User Agent has received the INVITE, and is alerting the user.
Typically this is the first Response that contains information about the capabilities of the
Called User Agent
1XX messages are Provisional responses that provide information on the progress of the
request. Provisional messages are not sent reliably (i.e. They are not acknowledged) So the
sender of a provisional response does know that it has been received. 209
SIP Responses 180 Ringing
SIP/2.0 180 Ringing
To: <sip:1001@10.10.199.250>;tag=abee6e2b-75b0-4537-80f3-7a3a37d0fa55-32557664
Date: Wed, 18 Feb 2015 18:37:57 GMT
CSeq: 101 INVITE
Allow-Events: presence
Remote-Party-ID: <sip:1001@10.10.199.250>;party=called;screen=yes;privacy=off
Content-Length: 0
Green Text No Change from INVITE Header

Red Text - Changes
210
SIP 180 Ringing Response
Route and Transaction related
headers
Response Header Response/ Message Header Content
CSeq: 101 INVITE
211
Via Header
Response/Header Response Header Content
SIP/2.0 180 Ringing
A Mandatory Header in Requests and Responses
SIP/2.0 SIP Protocol Version / TCP Transport Protocol
10.10.199.251 IP Address of CUCM generating the Request
5060 TCP Port number for SIP signalling
Branch Unique Identifier for this transaction
This Via header is used by both client and server User Agents for this transaction
Note - This Via Header is exactly the same as that sent in the INVITE and remains the same for all
messages in this transaction
The Via header is used to record the SIP route taken by a Request and to route a Response back to
the originator. A UA generating a Request records its own address in a Via header field. Multiple Via212
Headers can be used to record the route through several SIP switches
Command Sequence Header
Response /Header Response Header Content
SIP/2.0 180 Ringing
CSeq: 101 INVITE

Command Sequence Header - Identifies and Orders Transactions
Consists of a sequence number and method
Sequence number - An arbitrary integer = 101

Method - Method used in the Request = INVITE
The sequence number and method remain the same for each transaction in a dialog
The method matches the Request for the transaction
213
Identity and Dialog related headers
214
180 Ringing Response: From Header and To Header
SIP/2.0 180 Ringing
Mandatory Headers in Requests and Responses

Can optionally include a display name
Calling UA appends the From tag
Called UA appends the To tag
Tags must be globally unique
The From and To tags are used with the Call ID to uniquely identify a dialog between two UAs
Note : 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 defined to indicate
the direction of the request, not the direction of the message
215
SIP 180 Ringing Response: Call-ID Header

SIP/2.0 180 Ringing

The Call-ID header field is an identifier used to keep track of a particular SIP dialog.
The originator of the request creates this locally unique string
The same Call-ID is used in all messages (Requests and Responses) for all transactions
within this dialog
Transactions are tracked by the branch value in the VIA Header

Dialogs are tracked by the Call-ID, From Header tag and To Header tag
216
SIP 180 Ringing Response: Identity Headers
SIP/2.0 180 Ringing
P-Asserted Identity and Remote-Party-ID are optional SIP message headers -

P-Asserted Identity and Remote-Party-ID options are checked by default on a CUCM SIP
trunk
P-Asserted Identity and Remote-Party-ID perform the same functions :

1) Delivery of user identity for call trace purposes, when a users identity is anonymized in
the content of the From Header
2) A source of truth if identity headers contain differing information
P-Asserted Identity which additionally supports Authentication, supersedes Remote Party ID

P-Asserted Identity Privacy Header values can also override Device and Trunk settings for
217
Name and/or Number presentation and restriction
SIP 180 Ringing Response: Contact Header
SIP/2.0 180 Ringing
Optional in 1XX Responses (Mandatory in 2XX Responses)
A Contact header field value can contain a display name, a URI with URI parameters, and
header parameters
In a Request The contact field contains the address at which the calling UA can be reached
In a Response - The contact field contains the address at which the called UA can be reached
With CUCM a B2BUA The address in the contact header field is the address of the CUCM
server, not the phone
218
Methods and Events supported

219
SIP 180 Ringing Response: Allow Header
SIP/2.0 180 Ringing
Optional Header
Lists the set of methods supported by the UA sending the message
Note Although supported To be used, some methods also need to be enabled on the SIP
Trunk e.g. PRACK, Accept Presence Subscription, Accept Unsolicited NOTIFY etc
220
SIP 180 Ringing Response: Allow-Events Header
SIP/2.0 180 Ringing
Optional Header
A UA sending an "Allow-Events" header is advertising that it can process SUBSCRIBE
requests and generate NOTIFY requests for all of the event packages listed in the header.
In this Response : Presence
No KPML in this Response header

KPML was sent in Allow-Events header of the INVITE.
This indicates that In Band DTMF (RFC 2833) is being used for this call.
Implies that far end CUCM Trunk config for DTMF = No Preference or RFC 2833
221
Cisco and other headers
Date: Wed, 18 Feb 2015 18:37:57 GMT
Content-Length: 0
222
SIP 180 Ringing Response: Supported Headers
SIP/2.0 180 Ringing
Optional Headers :
X-Cisco-srtp fallback proprietary header (can be ignored by other vendors)
Allows an offered SRTP session to fall back to RTP if not supported by both UAs
Geolocation standardized method to convey geographical location information from one SIP
entity to another SIP entity. Configurable on CUCM SIP Trunks
223
SIP 180 Ringing Response: Call-Info Header
SIP/2.0 180 Ringing
Optional Header in Requests and Responses
The Call-Info header field provides additional information about the caller or callee, depending on
whether it is found in a request or response. (In the above example - The Called UA)
method="NOTIFY;Event=telephone-event;Duration=500 indicates support for NOTIFY based

out of band DTMF relay. Duration = time in mS between successive NOTIFY messages
Unsolicited NOTIFY used as a Cisco proprietary way to sent DTMF Out Of Band
224
SIP 180 Ringing Response: Date Header
SIP/2.0 180 Ringing
Date: Wed, 18 Feb 2015 18:37:57 GMT
An Optional Header
Date and time the Request or Response sent
Greenwich Mean Time (GMT) only
225
SIP 180 Ringing Response: Content Header
SIP/2.0 180 Ringing
Content-Length: 0
Mandatory Header if TCP transport used, Optional if UDP used
The Content-Length header indicates the size of the message-body sent to the recipient in
decimal number of bytes.
Message-Body For example, the Session Description Protocol (SDP) message body.
The message body is appended after the Content-Length header.
SDP is not usually sent in unreliable 1XX messages.

1XX message can be sent reliably by using PRACK (see later) and can then contain SDP
content
226
Deep down into SDP

Voice calls
227
SIP Trunk Signaling - Media negotiation for Voice calls :
The SDP Offer SIP Message Headers
..
Content-Type: application/sdp Content-Type : application/SDP
Content-Length: 337 Content-Length : 337 Bytes
v=0
s=SIP Call SDP Message Body
c=IN IP4 10.10.199.130
Describes the media characteristics of the
t=0 0 endpoint offering the SDP
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20 Includes :
a=rtpmap:8 PCMA/8000 Endpoint IP address
a=ptime:20 Codecs supported
a=rtpmap:18 G729/8000
a=ptime:20 UDP Port number for RTP
a=sendrecv In Band DTMF support details
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15 228
Some SDP lines are REQUIRED some are OPTIONAL, but all MUST appear in exactly the order described in RFC 4566
Media negotiation for Voice calls
The SDP Offer - SDP Session Attributes
Attribute Description Attribute Content Required/Optional
v= Version 0 Required
o= Origin CiscoSystemsCCM-SIP 2000 1 IN IP4 Required
10.10.199.250 10.10.199.250 = CUCM IP Address
s= Session Name SIP Call Required
c= Connection Data IN IP4 10.10.199.130 Optional
10.10.199.130 = Phones IP Address
t= Timing 00 Required
Session Attribute Details :

Version = Version of SDP protocol Currently only version 0
Origin = <Username><Session-ID><Session Version><Network Type><Address Type><Unicast Address>
Session = Text based session name or s=
Connection = <Network Type><Address Type><Connection-Address> Defines the device (Phone) media address
Timing = <start-time><stop-time> 0 0 = permanent session
229
Media negotiation for Voice calls The SDP Offer
SDP Media Attributes Voice Codecs Offered
m= Media Descriptions audio 16444 RTP/AVP 0 8 18 101 See description below
a= Attribute rtpmap:0 PCMU/8000 G.711 u-law codec
a= Attribute rtpmap:8 PCMA/8000 G.711 a-law codec
a= Attribute rtpmap:18 G729/8000 G.729 codec
m= Media Descriptions = <Media> <Port> <Protocol> <Format> ... Audio 16444 RTP/AVP 0 8 18 101
<Media> audio/ "video/ "text/ "application/ "message Audio

<Port> The transport port to which the media stream is sent UDP Port 16444
<Protocol> The transport protocol UDP/ RTP/AVP / RTP/SAVP RTP/AVP 230
<Format> RTP Payload Type numbers - Codec PTs in preference order 0 8 18 101
SDP Media Attributes Voice Codecs Offered
m= Media Descriptions audio 16444 RTP/AVP 0 8 18 101 Media/Port#/Protocol/ RTP Payload Types
a= Attribute rtpmap:0 PCMU/8000 G.711 u-law codec
a= Attribute rtpmap:8 PCMA/8000 G.711 a-law codec
a= Attribute rtpmap:18 G729/8000 G.729 codec
The Codecs (formats) in the Offer must be listed in preference order. The recipient of the Offer
should use the codec with the highest preference that is acceptable to it in its Answer
By Default CUCM does not honour codec preference However..

Accept Audio Codec Preferences in Received Offer can be configured on SIP Trunks (SIP Profile)
231
SDP Media Attributes - Audio Direction and DTMF
m= Media Descriptions audio 16444 RTP/AVP 0 8 18 101 101 = DTMF RTP Payload Type number
a= Attribute sendrecv Describes Audio Direction (see below)
a= Attribute rtpmap:101 telephone-event/8000 In Band DTMF transport (RFC 2833)
a= Attribute fmtp:101 0-15 DTMF tones
(Events 0 through 15
= 0,1,2,3,4,5,6,7,8 ,9,*,#,A ,B,C,D)
Audio Direction
a=sendrecv Media can be sent by this endpoint, media can be received on this endpoint
a=recvonly Media can only be received on this endpoint, it will not send media
a=sendonly Media can only be sent by this endpoint, it will not receive media
a=inactive Media can not be sent to or received from this device (used for Hold)
If nothing is sent in SDP a=sendrecv is assumed

232
The SDP Answer
v= Version 0 Phones IP Address
o= Origin CiscoSystemsCCM-SIP 2000 1 10.10.199.251 = CUCM IP Address
IN IP4 10.10.199.251
m= Media Descriptions audio 28668 RTP/AVP 18 101 Audio, UDP Port 28668, RTP G729, DTMF
a= Attribute rtpmap:18 G729/8000 G.729 codec selected for this call
a= Attribute rtpmap:101 telephone- 101 DTMF RTP Payload Type number
event/8000
a= Attribute a=fmtp:101 0-15 DTMF tones (Events 0 through 15 ) 233
SIP Trunk Signaling
Media negotiation Voice calls The Negotiated Session
10.10.199.250 10.10.199.251
10.10.199.130 10.10.199.179
RTP UDP Port 16444 RTP UDP Port 28668
G.729 codec G.729 codec
Two way Audio Two way Audio
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250 o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.251
c=IN IP4 10.10.199.130 c=IN IP4 10.10.199.179
m=audio 16444 RTP/AVP 18 101 m=audio 28668 RTP/AVP 18 101
a=rtpmap:18 G729/8000 a=rtpmap:18 G729/8000
a=ptime:20 a=ptime:20
a=sendrecv a=sendrecv
a=rtpmap:101 telephone-event/8000 a=rtpmap:101 telephone-event/8000 234
a=fmtp:101 0-15 a=fmtp:101 0-15

Deep down into SDP

Video calls
235
SIP Trunk Signaling
Video calls
Video is fundamentally different from voice in that there are many use cases where
asymmetric media flows are desirable.
For example, broadband services where the upload and download speeds are
different often by an order of magnitude.
Also because encoding video is more CPU intensive than decoding video - Video
endpoints can typically decode at a higher resolution than they can encode.
Because of the need to support asymmetric video streams the video codec
capabilities sent in an SDP Offer and Answer should be considered to be the receive
capabilities of the respective endpoints rather than the negotiated capabilities in
common with both devices
236
SIP Trunk Signaling
Voice and Video call with BFCP and FECC
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
Audio
Main Video
Slide Video
237
Far End Camera Control

SIP Trunk Signaling
Voice and Video call - Main video channel negotiation
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
Audio
Video
238
SIP Trunk Signaling
Video calls SDP Offer Detail - Video
v=0
s=SIP Call
b=TIAS:6000000
b=AS:6000
t=0 0
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101
c=IN IP4 10.58.9.86
b=TIAS:64000
.attributes of multiple audio codecs in the offer

c=IN IP4 10.58.9.86
b=TIAS:6000000
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-
br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
a=rtpmap:99 H263-1998/90000
a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1
a=rtcp-fb:* nack pli 239
a=rtcp-fb:* ccm tmmbr
SIP Trunk Signaling
Video calls SDP Offer Bandwidth attribute
v=0
s=SIP Call
Session Level
b=TIAS:6000000
b=AS:6000
t=0 0
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101

c=IN IP4 10.58.9.86 Media Level
b=TIAS:64000
b= bandwidth should be considered as the receive bandwidth capability

b= bandwidth Can be applied at the session level (all media streams) or media level
b= <modifier>:<value>
b= <TIAS> Transport Independent Application Specific : <value> bit/sec 240
b= <AS> Application Specific bandwidth : <value> in kbps

SIP Trunk Signaling
Bandwidth attribute - CUCM Related Configuration
The Session Level Bandwidth Modifier specifies the maximum amount of bandwidth supported
when all the media streams are used. There are three Session Level Bandwidth Modifiers:
Transport Independent Application Specific (TIAS),
Application Specific (AS), and
Conference Total (CT)
The bandwidth should be considered as the receive bandwidth capability

(TIAS) - Bandwidth does NOT include the lower layers (e.g. RTP bandwidth only) - bit/sec
(AS) - Bandwidth includes the lower layers (e.g. TCP/UDP and IP) - kbps
(CT) - Max Bandwidth that a Conference Session will use
241
SIP Trunk Signaling
Bandwidth attribute - CUCM Related Configuration
Region Configuration - Maximum Session Bite Rate for Video Calls
Session Level Bandwidth value (kbps)
The Maximum Session Bit Rate for video calls limits media bandwidth for
242
SIP Trunk Signaling
Video calls SDP Offer Bandwidth in this Offer
s=SIP Call
b=TIAS:6000000 Transport Independent Application Specific bandwidth (RTP) in bits/sec
b=AS:6000 Application Specific bandwidth (RTP/UDP/IP) in kbps
t=0 0
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101
b=TIAS:64000

b=TIAS:6000000
For this endpoint the maximum media stream bandwidths that can be received :
= 6 Mbps for all voice and video streams including UDP and IP headers (AS session bandwidth)
= 64kbps for voice RTP traffic not including UDP and IP headers (TIAS audio)
= 6 Mbps for video RTP traffic not including UDP and IP headers (TIAS video)
The bandwidth values in the SDP Answer do not have to be the same 243
SDP Offer H.264 and H.263 Video Codecs

c=IN IP4 10.58.9.86 The Codecs (formats) in the Offer must be listed in
b=TIAS:6000000 preference order. H.264 preferred over H.263
a=rtpmap:98 H264/90000
a=rtpmap:99 H263-1998/90000
The video capabilities sent in the SDP body should be considered as the receive capabilities of the
sending endpoint.
The codecs used by video streams are more complex than audio codecs, particularly for H.264
which is a more recent codec standard that offers significant improvements when compared with
H.263. Today H.263 is considered to be a legacy codec with a lower quality and
resolution for a given bandwidth than H.264
244
SIP Trunk Signaling
Video calls SDP Offer Detail - Video Codecs
m=video 16446 RTP/AVP 98 99 The Codecs (formats) in the Offer must be listed in
c=IN IP4 10.58.9.86
preference order. H.264 preferred over H.263
b=TIAS:6000000
a=rtpmap:98 H264/90000
a=rtpmap:99 H263-1998/90000
a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1 (= Supported Picture Formats/Resolutions)
Two video codecs are offered in SDP by this endpoint : H.263 and H.264
a=rtpmap:98 H264/90000 H.264/ Sampling Rate 90000 Hz
a=rtpmap:99 H263-1998/90000 H.263 version 2/ Sampling Rate 90000 Hz
For each codec type the endpoint sends additional information about the capabilities it supports
The endpoint that responds to this Offer, selects one codec and returns its receive
245
capabilities in its Answer.
SIP Trunk Signaling
Video calls SDP Offer H.264 Video Codec
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-
cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
profile-level-id=428016 The Profile-Level-ID describes the minimum set of features/

capabilities that are supported by this endpoint
packetization-mode=1
max-mbps=245000
max-fs=9000
These parameters describe the features and capabilities
max-cpb=200 beyond those of the profile-level-id that are supported by this
max-br=5000 endpoint
max-rcmd-nalu-size=3456000
max-smbps=245000
max-fps=6000 246
SIP Trunk Signaling H.264 Video calls
The 1st four digits of the Profile level ID The Profile
a=rtpmap:98 H264/90000
profile-level-id=428016
The Profile Level ID is fundamental in describing which H.264 features have been implemented by
the endpoint.
H.264 defines 21 profiles which describe the video capabilities of various classes of application.
The profile can be identified primarily by the first two hex digits of the profile-level-id and also by
the following 3rd and 4th digits. The negotiated profile-level-id for the call must be symmetrical
profile-level-id=4280XX defines the Baseline Profile of H.264 which is commonly used by UC video
endpoints.
The baseline profile supports video encoding features such as Flexible Macroblock Ordering,
Arbitrary Slice Ordering, Redundant Slices. ( not covered in this session ) 247
SIP Trunk Signaling H.264 Video calls
The last 2 digits of the Profile level ID The Level
a=rtpmap:98 H264/90000
profile-level-id=428016
The 5th and 6th hex digits of the profile-level-id describe the Level,
The Level describes the resolution, frame rate and bit rate that the endpoint can support.
16 hex = 22 dec = Level 2.2 = 352 x 480 pixels @ 30 frames per second
Levels range from 1 to 5.1 (128 x 96 @30 fps to 4096 x 2048 @30 fps)
a=fmtp:98 profile-level-id=428016; packetization-mode=1;max-mbps=245000;max-fs=9000;max-

The values after the profile-level-id describe the receive capabilities of the endpoint above and
beyond those described by the profile and level in the profile-level-id
248
Video calls Frames, Slices, Macroblocks, and
Network Abstraction Layer Units (NALUs)
Prior to H.264, video images were compressed into frames.
Depending on the compression type a Frame can be an I, P or B Frame (see notes for info)
H.264 introduces the concept of a Slice - spatially distinct region of a frame that can be
encoded separately from other regions in the frame. H.264 uses I-Slices, P-Slices and B-Slices
Frames and Slices are segmented into Macroblocks (rectangular pixel samples). Several
Macroblocks can be grouped into a Slice such that a video frame can consist of several Slices .
A NALU serves as container for a Slice(s) (groups of macroblocks) of the video frame
Depending up on the packetization mode used :

- A single NALU can be sent in an RTP packet or
- Multiple NALUs can be sent in an RTP packet
The Video Coding Layer (VCL) creates a coded representation of the video image by
partitioning the video frame into Macroblocks (rectangular samples) and then
encoding them using spatial and temporal prediction. 249
SIP Trunk Signaling
Video calls SDP Offer H.264 Video Codec Detail (1)
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-
profile-level-id=428016 Baseline profile, Level 2.2 = 352 x 480 pixels @ 30 fps
packetization-mode=1 Values (0,1,2)

0 = a single NALU packet sent in an RTP packet, no fragments
1= multiple NALUs can be sent in decoding order. Fragments allowed
2= multiple NALUs can be sent out of decoding order. Fragments allowed
The negotiated packetization mode for the call must be symmetrical
max-mbps=245000 Max Decoding speed = Max Macroblocks/sec = 245000

(Baseline profile level 2.2 value = 20250)
max-fs=9000 Max Frame Size = 9000 Macroblocks

(Baseline profile level 2.2 value = 1620)
250
SIP Trunk Signaling
Video calls SDP Offer H.264 Video Codec Detail 2
a=rtpmap:98 H264/90000
profile-level-id=428016 Baseline profile, Level 2.2 = 352 x 480 pixels @ 30 fps
max-cpb=200 Max Coded Picture Buffer size = 200 kbits

Baseline profile level 2.2 value = 4 kbits
max-br=5000 Max video bit rate = 5000 kbps,

Baseline profile level 2.2 value = 4000 kbps
max-rcmd-nalu-size=3456000 Max NALU packet size (bytes) that the receiver can handle
max-smbps=245000 Max Static Macroblock processing rate macroblocks/second
max-fps=6000 Max Frames Per Second in 1/100s of a frame/second = 60 fps

Baseline profile level 2.2 value = 30 fps
251
SIP Trunk Signaling
Video calls SDP Offer H.264 Video Codec - RTCP
a=rtcp-fb:* nack pli rtcp-fb RTP Control Protocol (RTCP) - Feedback

* RTCP-Feedback for any of the offered video codecs
NACK Negative Acknowledgement
indicates the loss of one or more RTP packets
PLI Picture Loss Indication
a=rtcp-fb:* ccm tmmbr rtcp-fb RTCP-Feedback

* RTCP-Feedback for any of the offered video codecs
ccm indicates support of codec control using RTCP feedback messages
"tmmbr" indicates support of the Temporary Maximum Media Stream Bit
Rate Request/Notification
RTCP is used for video rate adaption when congestion/ packet loss encountered
252
SIP Trunk Signaling
Video calls SDP Answer Detail = Video Only
v=0
s=SIP Call
b=TIAS:6000000 Symmetric Bandwidth requirements at the session level
b=AS:6000 TIAS = 6Mbps, AS = 6Mbps
t=0 0
m=audio 2346 RTP/AVP 102 101

c=IN IP4 10.58.9.222
b=TIAS:64000 Symmetric Bandwidth requirements for voice = 64kbps
. Attributes of one audio codec and DTMF
m=video 2348 RTP/AVP 98 H.264 codec selected for video

c=IN IP4 10.58.9.222
b=TIAS:5936000 = 6000kpbs 64kbps (voice bandwidth deducted from video stream)
a=rtpmap:98 H264/90000 H.264 codec details

a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=108000;max-fs=3600;max-cpb=200;max-br=5000;max-
rcmd-nalu-size=1382400;max-smbps=108000;max-fps=6000
a=rtcp-fb:* nack pli Symmetric RTCP attributes

253
a=sendrecv
SIP Trunk Signaling
H.264 Video Codec - Offer/Answer Compared
Offer H.264 and H.263 Offered
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;
max-br=5000; max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
a=rtpmap:99 H263-1998/90000
Answer H.264 selected Symmetric Attributes - Asymmetric attributes

a=rtpmap:98 H264/90000
max-br=5000; max-rcmd-nalu-size=1382400;max-smbps=108000;max-fps=6000
For the selected H.264 Codec :

- The Profile-level-IDs are the same for both endpoints (428016 = Baseline Profile, Level 2.2)
- The Packetization Mode (=1) is the same for both endpoints
- Note Each device supports different receive values for Max-Macroblocks/second, Max Frame
Size, Max Recommended NALU Size, Max Static Macroblock processing rate. 254
SIP Trunk Signaling Negotiated Media
Voice and Video call
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
Audio RTP UDP Port 16444 Audio Audio RTP UDP Port 2346
Bandwidth 64kbps Bandwidth 64kbps
Video RTP UDP Port 16446 Video Video RTP UDP Port 2348
H.264 Video codec H.264 Video codec
Asymmetric Receive values Asymmetric Receive values
Bandwidth 6Mbps Bandwidth (6Mbps - 64kbps)
255
SIP Trunk Signaling
Video calls Binary Floor Control Protocol (BFCP)
BFCP a protocol to manage access to shared resources in a conference, such as the right for a
user to send media to a particular media session (e.g. using a video channel for desktop sharing).
With BFCP in a video call, two additional media channels are negotiated one video channel to
share content, the other for floor control (BFCP)
m=application 5070 UDP/BFCP * Media description=application port-number transport

c=IN IP4 10.58.9.86 Endpoint IP address
a=floorctrl:c-s Floor Control values : c-only floor control client only
s-only floor control server only
c-s floor control client and server
a=floorid:2 mstrm:12 Floor ID and associated Media Stream ID
a=confid:1 Conference ID
a=userid:8 User ID
RFC 4582 BFCP, RFC 4583 SDP format for BFCP

256
SIP Trunk Signaling Media Negotiation
Voice and Video call with BFCP
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
Audio
Main Video
Slide Video
257

SIP Trunk Signaling
Video calls SDP Offer part 1: Detail = BFCP only
v=0
s=SIP Call
b=TIAS:6000000
b=AS:6000 Note - Session Bandwidth value = 6 Mbps total
t=0 0
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101

c=IN IP4 10.58.9.86
b=TIAS:64000

c=IN IP4 10.58.9.86
b=TIAS:6000000
.attributes of multiple main video codecs and RTCP functions in the offer
...
a=content:main Content = Main Video Stream
a=label:11 Label 11 used to identify the Main Video Stream
258
SIP Trunk Signaling
Video calls SDP Offer part 2: Detail = BFCP
m=video 16448 RTP/AVP 98 99 Offered Video Codecs for Desktop Presentation channel
c=IN IP4 10.58.9.86
b=TIAS:6000000
a=rtpmap:98 H264/90000
max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
a=rtpmap:99 H263-1998/90000
a=label:12 Label 12 used to identify Slides Video Stream
a=content:slides Content :Slides (desktop presentation) Video Stream
m=application 5070 UDP/BFCP *

c=IN IP4 10.58.9.86
a=floorctrl:c-s Floor Control = c-s = floor control client and server
a=floorid:2 mstrm:12 mstrm:12 maps to a=label:12 to identify the media channel
a=confid:1 Conference ID = 1
a=userid:8 User ID = 8 259
SIP Trunk Signaling
Video calls SDP Answer part 1: Detail = BFCP Only
v=0
s=SIP Call
b=TIAS:6000000
b=AS:6000 Note - Session Bandwidth value = 6 Mbps total
t=0 0

c=IN IP4 10.58.9.222
b=TIAS:64000
. Attributes of selected audio codec and DTMF RFC2388
m=video 2348 RTP/AVP 98

c=IN IP4 10.58.9.222
b=TIAS:5936000
. Attributes of selected main video codec and RTCP functions
a=label:11 Label 11 used to identify the Main Video Stream

a=content:main Content = Main Video Stream
260
SIP Trunk Signaling
Video calls SDP Answer part 2 : Detail = BFCP Only
m=video 2350 RTP/AVP 98 Selected Video Codec for Desktop Presentation channel
c=IN IP4 10.58.9.222
b=TIAS:5936000
a=label:12 Label 12 used to identify Slides Video Stream
a=rtpmap:98 H264/90000 H.264 Codec selected - receive differences
max-br=5000;max-rcmd-nalu-size=1474560;max-smbps=108000;max-fps=6000
a=content:slides Content :Slides (desktop presentation) Video Stream

c=IN IP4 10.58.9.222
a=floorctrl:s-only Floor Control = s-only = floor control server only
a=floorid:2 mstrm: 12 mstrm:12 maps to a=label:12 to identify the media channel
a=confid:1 Common Conference ID = 1
a=userid:6 Different User ID
261
Voice and Video call with BFCP
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
Asymmetric Receive values Main Video Asymmetric Receive values
Asymmetric Receive values Slide Video Asymmetric Receive values
262
Conference 1 User 8 Conference 1 User 6
SIP Trunk Signaling
Video calls Far End Camera Control (FECC)
Far End Camera Control (FECC)
A simple protocol based on ITU H.281 frames carried in H.224 packets in an RTP UDP channel
FECC allows a user to select a video source and to control camera actions such as Pan, Tilt,
Zoom and Focus
m=application 16450 RTP/AVP 107 UDP port-number = 16450 , RTP Payload Type = 107
c=IN IP4 10.58.9.86 Endpoint IP address

a=rtpmap:107 H224/0 Attribute H.224 for the transport of FECC messages
H.281 A Far End Camera Control For Video-Conferences using H.224

H.224 A real time control protocol (ITU-T Recommendation)
RFC 4573 MIME Type registration for RTP Payload Format for H.224
263
SIP Trunk Signaling
Video calls SDP Offer : Detail = FECC only
v=0
.
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101
m=video 16446 RTP/AVP 97 98 99 34 31

.attributes of multiple main video codecs and RTCP functions in the offer
m=video 16448 RTP/AVP 97 98 99 34 31

.attributes of multiple BFCP slides video codecs and RTCP functions in the offer

..attributes of BFCP session in the offer
m=application 16450 RTP/AVP 107 UDP port-number = 16450 , RTP Payload Type = 107
c=IN IP4 10.58.9.86
a=rtpmap:107 H224/0
264
SIP Trunk Signaling
Video calls SDP Answer : Detail = FECC Only
v=0
.
. Attributes of selected audio codec and DTMF RFC2388

. Attributes of selected main video codec and RTCP functions

. Attributes of selected BFCP slides video codec and RTCP functions

. Attributes of selected BFCP session functions
m=application 2352 RTP/AVP 107 UDP port-number = 2352, RTP Payload Type = 107
c=IN IP4 10.58.9.222
a=rtpmap:107 H224/0
265
Voice and Video call with BFCP & FECC
10.10.199.250 10.10.199.251
10.58.9.86 10.58.9.222
H.264 Video codec Main Video H.264 Video codec
H.264 Video codec Slide Video H.264 Video codec
FECC UDP Port 16450 FECC UDP Port 2352
266
RTP Payload Type 107 Far End Camera Control RTP Payload Type 107
SIP Trunk Signaling Video Call
Complete SDP Offer : Voice, Video, BFCP and FECC
v=0 a=rtpmap:99 H263-1998/90000
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6 a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1
s=SIP Call a=rtpmap:34 H263/90000
a=fmtp:34 QCIF=1;CIF=1;CIF4=1
b=TIAS:6000000 a=rtpmap:31 H261/90000
b=AS:6000 a=fmtp:31 CIF=1;QCIF=1
t=0 0 a=content:main
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101 a=rtcp-fb:* ccm tmmbr
c=IN IP4 10.58.9.86 m=video 16448 RTP/AVP 97 98 99 34 31
b=TIAS:64000 c=IN IP4 10.58.9.86
b=TIAS:6000000
a=rtpmap:102 MP4A-LATM/90000 a=label:12
a=fmtp:102 bitrate=64000;profile-level-id=24;object=23 a=rtpmap:97 H264/90000
a=rtpmap:103 MP4A-LATM/90000 a=fmtp:97 profile-level-id=428016;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-
a=fmtp:103 bitrate=56000;profile-level-id=24;object=23 a=rtpmap:98 H264/90000
a=rtpmap:104 MP4A-LATM/90000 a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-
a=fmtp:104 bitrate=48000;profile-level-id=24;object=23 br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
a=rtpmap:99 H263-1998/90000
a=rtpmap:9 G722/8000 a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1
a=ptime:20 a=rtpmap:34 H263/90000
a=rtpmap:105 G7221/16000 a=fmtp:34 QCIF=1;CIF=1;CIF4=1
a=rtpmap:31 H261/90000
a=fmtp:105 bitrate=32000 a=fmtp:31 CIF=1;QCIF=1
a=rtpmap:106 G7221/16000 a=content:slides
a=fmtp:106 bitrate=24000 a=rtcp-fb:* nack pli
a=rtpmap:0 PCMU/8000 m=application 5070 UDP/BFCP *
a=ptime:20 c=IN IP4 10.58.9.86
a=rtpmap:8 PCMA/8000 a=floorctrl:c-s
a=floorid:2 mstrm:12
a=ptime:20 a=confid:1
a=rtpmap:101 telephone-event/8000 a=userid:8
a=fmtp:101 0-15 m=application 16450 RTP/AVP 107
c=IN IP4 10.58.9.86
m=video 16446 RTP/AVP 97 98 99 34 31 a=rtpmap:107 H224/0
c=IN IP4 10.58.9.86
b=TIAS:6000000
a=label:11
a=rtpmap:97 H264/90000
a=fmtp:97 profile-level-id=428016;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000 267
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=245000;max-fs=9000;max-cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
SIP Trunk Signaling Video Call
Complete SDP Answer : Voice, Video, BFCP and FECC
v=0
o=CiscoSystemsCCM-SIP 112480 1 IN IP4 10.58.9.44 a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-
s=SIP Call mbps=108000;max-fs=3840;max-cpb=200;max-br=5000;max-rcmd-
b=TIAS:6000000 nalu-size=1474560;max-smbps=108000;max-fps=6000
b=AS:6000 a=content:slides
t=0 0 a=rtcp-fb:* nack pli
m=audio 2346 RTP/AVP 102 101 a=rtcp-fb:* ccm tmmbr
c=IN IP4 10.58.9.222
b=TIAS:64000
c=IN IP4 10.58.9.222
a=rtpmap:102 MP4A-LATM/90000
a=floorctrl:s-only
a=fmtp:102 bitrate=64000;profile-level-id=24;object=23
a=rtpmap:101 telephone-event/8000 a=floorid:2 mstrm:12
a=fmtp:101 0-15 a=confid:1
m=video 2348 RTP/AVP 98 a=userid:6
c=IN IP4 10.58.9.222 m=application 2352 RTP/AVP 107
b=TIAS:5936000 c=IN IP4 10.58.9.222
a=label:11 a=rtpmap:107 H224/0
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=108000;max-fs=3600;max-cpb=200;max-br=5000;max-rcmd-nalu-
a=content:main
c=IN IP4 10.58.9.222
b=TIAS:5936000
268
a=label:12
a=rtpmap:98 H264/90000
Deploying an SME cluster with no Media Resources
UC 8.5+ SME SIP Trunks MTP-less Early Offer
UC 10.5+ SME SIP Trunks Best Effort Early Offer
269
Reasons to use SIP Trunks on SME
SME clusters with no Media Resources
Leaf Cluster
New York
Media Resources
SME
Cluster
Media Resources
Leaf Cluster
Leaf Cluster Europe
Los Angeles
Ideally, Media Resources such as MTPs, Transcoders, Music on Hold, Conferencing

Resources should never be utilized in the SME cluster as this entails hair-pinning
media via the media resource associated with the SME cluster
Is this design possible ? Yes, but it requires the use of SIP Trunks only 270
configured to use either Best Effort Early Offer or MTP-less Early Offer
Enabling SIP Early Offer MTP Required Pre UC 8.5
MTP

MTP
MTP
MTP Recommendation Always use IOS MTPs
MTP
CUCM based MTPs do not have feature parity
MGCP Trunk SIP Trunk with Early Offer
MTP with software and hardware based IOS MTPs
Using the MTP Required option :

SIP Early Offer Trunks use the Trunks Media Termination Point (MTP) resources, inserting an MTP
into the media path for every outbound (and inbound) call sending the MTPs IP Address, UDP port
number and codec in the SDP body of the initial SIP INVITE instead of those of the endpoint.
Disadvantages : MTPs support a single Audio codec only e.g. G711 or G729. The passthru codec is
not supported excluding the use of SRTP and video calls. Since the Trunks MTPs are used - The media
271
path is forced to follow the signaling path.
Enabling SIP Early Offer Method 2 UC 8.5+
SIP Profile Early Offer support for voice and video calls
(insert MTP
SIP Line
if needed)
Cisco SIP Phones

For Calls from trunks and devices that can
SCCP Line SIP Trunk with Early Offer provide their IP Address, UDP port number and
Newer SCCP Phones
supported codecs - This information is sent in
SCCP Line SIP Trunk with Early Offer the SDP body of the initial SIP Invite on the
MTP
Older SCCP Phones
outbound Early Offer Trunk. No MTP is used for
SIP Trunk SIP Trunk with Early Offer the Early Offer
SIP Early Offer
MTP
For Calls from trunks and devices that cannot
SIP Delayed Offer provide Early Offer information use the calling
MTP
devices MTP resources (first) or the outbound
H323 Slow Start trunks MTPs (second) to create a SIP Offer for an
unencrypted voice call. (SRTP and video can
H323 Fast Start
subsequently be initiated by the called device)
MGCP Trunk
272
MGCP Gateway
Deploying SME with no Media Resources - UC 8.5+
SME SIP Trunks MTP less Early Offer
SME
Cluster

All SME Trunks configured as SIP Early Offer for Voice and video (Insert MTP if needed)
No media resources (MTPs, Transcoders etc) associated to the SME Trunks
Takes advantage of SIP Trunk behaviour based on the following Service Parameter
273
Deploying SME with no Media Resources UC 8.5+
MTP less Early Offer
SME
Cluster

Early Offer Early Offer Europe
North America
All SME Trunks configured as SIP Early Offer for Voice and Video (Insert MTP if needed)
If an inbound DO call received on SME SIP Trunk outbound SIP Trunk sends DO
If an inbound EO call received on SME SIP Trunk outbound SIP Trunk sends EO
This EO/DO pass-through feature also affects media negotiation 274
Media choices (e.g. codec/ DTMF transport decision) made by the leaf systems
SME MTP less Early Offer Delayed Offer Call
Media Resources
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
This EO/DO pass-through feature also affects media negotiation
With Delayed Offer Calls - Media choices (e.g. codec decision/ DTMF transport decision)
made by the Leaf cluster originating the call 275
Media resources (if needed) are inserted by the originating Leaf cluster
SME MTP less Early Offer Early Offer Call
Early Offer Early Offer
Media Resources
INVITE with SDP (Offer)
200 OK with SDP (Answer)

This EO/DO pass-through feature also affects media negotiation
With Early Offer Calls - Media choices (e.g. codec decision/ DTMF transport decision) made
by the Leaf cluster receiving the call
276
Media resources (if needed) are inserted by the Leaf cluster receiving the call
SME SIP Trunks MTP less Early Offer - Summary
SME
Cluster

Leaf systems can use SIP Early Offer or Delayed Offer

Use Codec Preference Lists to avoid transcoding
If MOH, Announcement service is required Inserted by Leaf cluster
Inserted by Leaf cluster
277
If MTPs for DTMF mismatch are required
SME/CUCM SIP Trunk Signaling UC 10.5 +
Best Effort Early Offer
Early Offer support for voice and video calls Best Effort (no MTP inserted)
Recommended configuration for all 10.5+ CUCM and SME SIP Trunks
With Best Effort Early Offer MTPs are never used to create an Offer
Early Offer is sent only if the media characteristics of the calling device can be determined,
If the media characteristics of the device cannot be determined a Delayed Offer is sent.
Best Effort Early Offer is preferred over MTP-less Early Offer in SME clusters
Best Effort Early Offer has the same media transparency effect as MTP-less Early Offer in
SME clusters, but the feature is simpler and easier to configure
278
CUCM 10.5+ SIP Trunks Best Effort Early Offer
SIP Line Best Effort Early Offer SIP Trunk Early Offer sent
Cisco SIP Phones

SCCP Line Best Effort Early Offer SIP Trunk Early Offer sent
Newer SCCP Phones

SCCP Line Best Effort Early Offer SIP Trunk Delayed Offer sent
Older SCCP Phones SIP Trunk Best Effort Early Offer SIP Trunk Delayed Offer sent
SIP Delayed Offer

H323 Trunk Best Effort Early Offer SIP Trunk Delayed Offer sent
H323 Slow Start MGCP Trunk Best Effort Early Offer SIP Trunk Early Offer sent
MGCP Gateway
H323 Trunk Best Effort Early Offer SIP Trunk Early Offer sent
H323 Fast Start SIP Trunk Best Effort Early Offer SIP Trunk Early Offer sent
279
SIP Early Offer
SME SIP Trunks Best Effort Early Offer - Summary
SME
Cluster

Leaf systems can use SIP Early Offer/Delayed Offer/Best Effort Early Offer (recommended )
Use Codec Preference Lists to avoid transcoding
If MOH, Announcement service is required Inserted by Leaf cluster
Inserted by Leaf cluster
280
If MTPs for DTMF mismatch are required
SME with no Media Resources
Possible with SIP Delayed Offer Trunks Everywhere ?
Media Leaf Cluster

Leaf Cluster Early Offer Decision Delayed Offer
made
here
All SME Trunks configured as Delayed Offer

All Leaf Systems configured as Delayed Offer ?
If an inbound DO call received on SME SIP Trunk outbound SME Trunk sends DO
Not always possible.. Some UC systems always send Early Offer e.g. IOS gateways
281
SME with no Media Resources
Possible with Early Offer SIP Trunks Everywhere ?
Early Offer Early Offer

All SME Trunks configured as Early Offer

All Leaf Systems configured as Early Offer ?
If an inbound EO call received on SME SIP Trunk outbound SME Trunk sends EO
Possible.. But may introduce limitations e.g. For older SCCP based phones (e.g. 7940/
7960) the Leaf cluster will insert an MTP to create an Early Offer over the outbound SIP
Trunk MTP single codec limitation - voice calls only
282
SME cluster with no Media Resources
Why H323 Inter Cluster Trunks cannot be used.
283
Reasons to use SIP Trunks only
H323 Slow Start Trunks Media Negotiation
TCS TCS = Terminal Capability Set
Leaf Cluster TCS Leaf Cluster

To support calls with voice, video and encryption H323 Slow Start Trunks must be used.
Endpoint Media capabilities are sent over H323 Trunks through the exchange of Terminal
Capability Set (TCS) messages. The choice of which codec and DTMF transport method is
used for the call is determined after Master Slave Determination (MSD).
Unlike SIP Trunks, for H323 Inter Cluster Trunks the choice which cluster choses the media
characteristics for the call is not configurable, as the cluster that initiates the TCS exchange
284
and determination of which cluster is Master and Slave is random
Reasons to use SIP Trunks only
H323 Slow Start Trunks Media Negotiation
MSD MSD = Master/ Slave Determination
Slave
Media
Decision
SME
made
Cluster
here
Leaf Cluster MSD Leaf Cluster

Master
Because the cluster that initiates the TCS exchange and determination of which cluster is
Master and Slave is randomly selected
This can lead to situations where, when a DTMF transport mismatch, or Codec mismatch
occurs between the endpoints in call The SME cluster will try to insert media resources
Without SME media resources the call, or DTMF transport for the call, will fail
285
Therefore - H323 Trunks cannot be used in SME deployments without media resources
Global SME Deployments
286
Signaling Delay and SME based UC networks
SME
Recommendations for media delay are well defined

(ITU Recommendation G.114. < 150mS = acceptable, 150 400mS = acceptable with some impact on
quality, > 400mS generally unacceptable)
Recommendations for signaling delay are not well defined
Primarily because the incurred delays are protocol dependent and the impact of long delay generally 287
affects call set up rather than overall voice quality

Impact of Signaling Delay on Call Set Up
Messages exchanged before the
caller hears ringback tone
One way signalling Delay
INVITE INVITE
200 OK w/ SDP (Offer) 200 OK w/ SDP (Offer)
ACK w/ SDP (Answer) SME ACK w/ SDP (Answer)
Two Way Media

Delay before the caller hears the Messages exchanged before called user hears
called user after ringback stops the caller after picking up their handset
The diagram above shows an example of call set up delays and their impact on the users experience.
(Note Phone to Call Agent signaling delay has been assumed to be minimal)
Delays during call set up will vary based on the protocol(s) used, the trunk configuration and call agent
operation making it difficult to calculate the time taken to establish each stage of the call set up.
In most cases, signaling delays do not noticeably affect user experience. If signaling delays are a 288
concern enable PRACK on SIP Trunks.
Reducing Signaling Delay
Pre UC 9.1 - Multiple regional SME clusters
SME SME
Signalling Path
SME SME
SME cluster per region - SME clusters fully meshed

Leaf clusters have one trunk to nearest SME and optional Trunks to other regional SMEs
SIP Trunks only with Run on all Unified CM nodes and multiple destination addresses
SME clusters without Media Resources - Recommended 289
SME MTP-less EO SIP Trunks - Recommended

UC 9.1 - One Global SME cluster UC 9.1
SME CoW
Clustered over the WAN with extended RTT (1) up to
500mS RTT
< 500 mS
SME
CoW+
< 500 mS
One SME Globally distributed SME cluster (mega cluster supported)

Leaf clusters must have one trunk to pointing to nearest regional SME nodes
Leaf clusters must have additional redundant Trunks to all other regional SME nodes
All Trunks run SIP only with Run on all Unified CM nodes and multiple destination addresses 290
Up to 500 mS between call processing nodes, Up to 500 mS between Publisher and Subscribers
UC 9.1 - One Global SME cluster UC 9.1
SME CoW
Clustered over the WAN with extended RTT (2) up to
500mS RTT
< 500 mS
SME
CoW+
< 500 mS
One SME Globally distributed SME cluster (mega cluster supported)

Up to 500 mS Round Trip Time between nodes
SME clusters without Media Resources - Mandatory
MTP-less EO or Best Effort EO (10.5) SIP Trunks - Mandatory 291
SIP trunks only with Run on all Nodes enabled - Mandatory

SME - Clustering over the WAN with extended RTT
Upgrade considerations
The database process on the

publisher of the SME CoW+
cluster is provided with more
UC 9.1 < 500 mS
SME CoW SME
CPU threads (using a CLI
up to CoW+ command) prior to upgrade
500mS RTT to reduce DB Replication
time this does not impact
< 500 mS
call processing
The upgrade process for an SME cluster consists of two key parts: Version switch-over, where the call
processing node is re-booted and initialized with the new software version (this takes approximately 45
minutes per server), and database replication, where the subscriber's database is synchronized with
that of the publisher node. The time taken to complete this database replication phase depends on the
RTT between the publisher and subscriber nodes and the number of subscribers in the cluster. The
database replication process has a minimal impact on the subscriber's call processing capability and 292
typically can be run as a background process during normal SME cluster operation.
One Global SME CoW cluster
Trunk config from Leaf cluster to SME cluster
DC1 SME Nodes
North America
1st choice Trunk 2nd choice Trunk
UC 9.1
SME CoW Route List
Route List
up to Leaf Cluster Leaf Cluster
500mS RTT
1st choice Trunk

2nd choice Trunk
DC2 SME Nodes

Europe
One Globally distributed SME cluster
One Leaf cluster SIP Trunk to each pair of SME nodes in every regional data centre
Each Leaf Cluster SIP Trunk uses Run on all Unified CM nodes
Leaf Cluster SIP Trunk 1 - Multiple destination addresses to each call processing node in DC1
Leaf Cluster SIP Trunk 2 - Multiple destination addresses to each call processing node in DC2
293
Leaf Cluster Trunks placed into Route Lists and Route Groups for redundancy
Trunk config from SME cluster to Leaf clusters
DC1 SME Nodes
North America
UC 9.1
SME CoW
up to Europe
North America
500mS RTT
DC2 SME Nodes

One Globally distributed SME cluster Europe
One SIP Trunk from SME to each Leaf cluster

SIP Trunks configured without media resources Best Effort or MTP-less Early Offer
Each SME SIP Trunk uses Run on all Unified CM nodes
Each SME SIP Trunk uses multiple destination addresses pointing to every call
294
processing node in the destination leaf cluster
Call Routing Route Local for SME
DC1 SME Nodes
North America
1st choice Trunk
UC 9.1
SME CoW Route List
up to Europe
North America
500mS RTT
2nd choice Trunk
DC2 SME Nodes

One SME Globally distributed SME cluster Europe
Leaf Clusters
Multiple Trunks in Route Groups provide ordered selection of SME nodes.
Route List Call Distribution priority order nearest data centre 1st, second nearest data centre 2nd etc
SME CoW cluster
Single Trunk with Run on all Nodes enabled pointing to all nodes in each leaf cluster 295
Route local operates in the SME cluster No inter node intra cluster call routing

Brkucc 2006

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Brkucc 2006

Diunggah oleh

Hak Cipta:

Format Tersedia

SIP Trunk design and

UC 7.1 Support for IPv6

Legend: Yes Limited support No

Up to 16 destination addresses feature

Legend: Yes Limited support No

Request Invitation to participate in a session

Response e.g. OK/ Busy/ Moved

Commonly Used Responses

100 Trying - CUCM has received the INVITE

503 Service Unavailable

codecs)).CUCM is not a Proxy server

Why is CUCM a B2BUA ?

INVITE UAS UAS

Line Side SIP Trunk Side SIP

This presentation focuses on Trunk side SIP

From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5- Identity and

Supported: X-cisco-srtp-fallback Cisco related

See Appendix for detailed descriptions and CUCM related configuration

Leaf Cluster Leaf Cluster

SIP 180 Ringing

capabilities of the Called User Agent

Two Way Media

Media Capabilities Endpoint IP Address, Codecs etc

Two Way Media

Two Way Media

PRACK Two Way Media PRACK

Delayed Offer with Early Media

200 OK (PRACK) Two Way Media 200 OK (PRACK) 33

a=fmtp:101 0-15 a=fmtp:101 0-15

m=video 16446 RTP/AVP 98 99

a= Attribute rtpmap:98 H264/90000 H.264 Video Codec

profile-level-id=428016;packetization-mode=1 : Must have symmetric values

RTP Payload Type 107 RTP Payload Type 107

Client TLS Version Number 3,3 (TLS 1.2)

Client Random Number 4 byte date and time + 28 byte random

Session ID : None (New Session)

Client supported Cypher Suites (in preference order) :

Server TLS Version Number 3,3 (TLS 1.2)

Server Random Number 4 byte date and time + 28 byte random

Use Cypher Suite :

Server sends Public Key Certificate:

Server Key Exchange

Server Key Exchange

Client Certificate Request

Client sends Public Key Certificate:

Server Key Exchange

Client Certificate Request

Client Key Exchange

Server Key Exchange

Client Certificate Request

Client Key Exchange

Client and Server derive an identical Pre-Master Secret from their

The Pre-Master Secret is used to generate symmetric Session Keys which

SDES Exchange in the SDP Offer and Answer

Delayed Offer/ Early Offer/ Best Effort Early Offer

SCCP Line SIP Trunk with Early Offer

Using the MTP Required option :

SIP Line SIP Trunk with Early Offer

Newer SCCP Phones

Older SCCP Phones

SIP Delayed Offer

CUCM SME CUCM SME

CUCM SME CUCM Route List