Sip Trunk

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
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
BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
Agenda
Appendix Lots of detailed information SIP headers explained,
CUCM features explained etc
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
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
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
Legend: Yes Limited support No

2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 8
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
Legend: Yes Limited support No 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 9
Agenda
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
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)
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
503 Service Unavailable BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 13
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 Register 2002@10.2.2.2
UAS UAC UAS UAC

Registrar
INVITE 2002 INVITE 2002

200 OK 200 OK
UAS
Proxy UAC
UAC UAS
RTP Media

200 OK Record 200 OK
Route
UAS UAC UAS UAC
Proxy
RTP Media

200 OK Record 200 OK
Route
UAS UAC
BYE Proxy BYE UAS UAC
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.
codecs)).CUCM is not a Proxy server BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 14
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
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
This presentation focuses on Trunk side SIP BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 19
Establishing a SIP session and an
introduction to SIP headers
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
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
Content-Length: 0 BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 22
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>
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
See Appendix for detailed descriptions and CUCM

2017 Ciscorelated configuration
and/or its affiliates. All rights reserved. Cisco Public 24
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. (Note - In CUCM 11.5 this behaviour can be
overridden by the new SIP Call Preservation Expires Timer (Default = 0 sec (call is not
terminated) Max value 24hrs)
SME
Cluster
Leaf Cluster Leaf Cluster

North America Europe
Media
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. (Note - In CUCM 11.5 this behaviour can be
overridden by the new SIP Call Preservation Expires Timer (Default = 0 sec (call is not
terminated) Max value 24hrs)
SME Node
crash
SME
Cluster


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
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
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
capabilities of the Called User Agent BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 29
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
ACK - Confirms that the client has received a Final Response (200 OK) to the Request
Agenda
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, Codec etc
Media Capabilities Endpoint
ACK
10.10.199.251 10.10.199.250
Two Way Media

2002 1001
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
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
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 next..
INVITE INVITE
100 Trying 100 Trying
200 OK with SDP (Offer) 200 OK with SDP (Offer)
ACK with SDP (Answer) ACK with SDP (Answer)
Two Way Media 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 35
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
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)

Media negotiation for
Voice calls
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
UDP Port number for RTP
a=ptime:20
a=sendrecv In Band DTMF support details
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Some SDP lines are REQUIRED some are OPTIONAL, but all MUST appear in exactly theand/or
2017 Cisco order described
its affiliates. All rights reserved. in RFC
Cisco Public 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
a= Attribute a=fmtp:101 0-15 DTMF tones (Events 0 through 15 )
2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
40
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
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
a=fmtp:101 0-15 a=fmtp:1010-15
Video calls
Summarized slides - See Appendix for Detailed slides
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
SIP Trunk Signaling - Video calls
The 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
The 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 BRKUCC-2006
RTCP Feedback Max Bit Rate 46
The 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

max-mbps=108000;max-fs=3600 etc : Asymmetric values describing receive capabilities
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
RTP Payload Type 107 Far End Camera Control RTP Payload Type 107
Secured SIP Signaling (TLS) and
Encrypted Media (SRTP)
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
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 :
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
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 one cypher suite from the list offered by the Client
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
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
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
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
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
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
Endpoints send all supported crypto suites - CUCM can filter crypto suites 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 61
Agenda
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
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 MTP Recommendation Always use IOS MTPs
H323 Trunk SIP Trunk with Early Offer
MTP CUCM based MTPs do not have feature parity
MGCP Trunk SIP Trunk with Early Offer with software and hardware based IOS MTPs
MTP
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
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-
through codec
MGCP Gateway BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 65
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
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 by
sending a SIP Re-INVITE
Early Offer : Best Effort (No MTP inserted) No MTPs used for EO generation ( if EO cannot be sent
DO sent instead), Trunk MTP resources 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
Mostly newer Phones ------------------------------------------- Use Early Offer : Mandatory (insert MTP if needed) 67
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
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
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
Trunk destinations defined as Trunk destinations
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
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)
If a DTMF mismatch occurs MTP inserted by Leaf cluster
CUCM SIP Trunk
Codec Preference Lists
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.
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
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
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.
SIP Trunk Features
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
Preferences in Received Offer on all SIP Trunks. BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 79
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. BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 80
Name and Number
Presentation and Restriction
SIP Message Header Message Header Content
Privacy: None
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
Search Space on the Device or Line Device/Line settings 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 82
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
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
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
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
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
CUCM SIP Trunk Features Normalization & Transparency
SIP Trunk Normalization
SIP/SCCP SIP Trunk
Normalization allows incoming and outgoing SIP
Script messages to be modified on their way through a CUCM
SIP Trunk
SIP Trunk.
SIP Trunk
IP PSTN
The Normalization feature is designed to improve
Script
interoperability between CUCM SIP Trunks and SIP based
H323 Trunk SIP Trunk 3rd Party SIP PBXs, Applications & IP PSTN services.
Script Normalization is independent of what the SIP Trunk

MGCP Trunk SIP Trunk
connects to on the other side of CUCM. e.g.
IP PSTN
SIP SIP Trunk calls
Normalization Script
Skinny SIP Trunk calls
Remove display name from SIP Header
function fixInboundPai()
H.323 SIP Trunk calls
local pai = Sip.getHeader("P-Asserted-Identity") MGCP SIP Trunk calls
local displayname = getDisplayName(pai)
local uri = getUri(pai) Normalization uses a scripting environment to allow
local number = getUserPart(uri) customers to modify SIP messages and SDP content on a
if displayname == number per trunk basis.
then Sip.modifyHeader("P-Asserted-Identity", uri)
Agenda
CUCM SIP Trunk Call functions
Hold/Resume
CUCM SIP Trunk Signaling and Operation
Hold/Resume Signaling - Hold
SIP Trunk
Call In Progress - Two Way Media
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
Note CUCM SIP Trunks also send c= IN IP4 0.0.0.0 in SDP

(Older RFC 2543 Hold method) 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 94
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
respond with its full codec list and a=sendrecv
CUCM SIP Trunk Call functions
Send Send Receive in mid call INVITE
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
( 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)
ACK
ACK with SDP
ACKwith SDP
RESUME
a=inactive returned Media not resumed

Some 3rd Party UC systems return a=inactive in response to
a mid call INVITE without SDP 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 99
CUCM SIP Trunk Interop Feature The Fix (1)
Send send-receive SDP in mid-call INVITE Enabled
SIP Trunk
INVITE with SDP

(a=sendonly)
(a=sendrecv) (a=sendrecv)

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
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)
ACK ACK with SDP ACKwith SDP

(a=sendrecv)
(a=sendrecv)
RESUME
MTP
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)
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 device plays whatever
the called device is sending in the returned media stream (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
Agenda
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
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 to centralize
your dial plan and call routing rules on the SME cluster, which helps to simplify the dial plan and
management of the leaf UC systems 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 119
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
up rather than overall voice quality 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 120
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)
Up to 500 mS between call processing nodes, Up to 500 mS between Publisher and Subscribers
Large Scale UC designs X-Coding, DTMF Translation etc
Deploying SME clusters with no media resources
Media Resources
Leaf Cluster
New York
SME
Cluster
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
configuration (or for pre UC 10.5 clusters MTP-less Early Offer see Appendix for details)
Large Scale UC designs X-Coding, DTMF Translation etc
Deploying SME clusters with no 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
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
Media Resources Media Resources
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
With no media resources associated with the SME SIP Trunks, IPVMS can be disabled in the SME Cluster
Summary SIP Trunk
configuration recommendations
for Multi-Cluster designs
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, PRACK, Early Offer usually required by Service Providers (Use CUBE SIP DO to EO)
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)
Call Admission Control (CAC)
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 SIP Trunks between SME and Leaf Clusters are not placed into Locations for CAC. These SIP
trunks are generally placed into Shadow Locations for Enhanced Locations based CAC which do not count
calls/bandwidth. Using this method Call Admission Control takes place in the Leaf Cluster/ UC system.
SME SIP Trunks to centralized applications and gateways can be placed into locations if required
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
A B C D D E
2017 Cisco and/or its affiliates. All rights reserved. Cisco Public F G
Dial Plans
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
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 (442-4000) dials 8-559-5000

Leaf Cluster 1 Leaf Cluster 2
Internal Directory Numbers (XXX-YYYY) Internal Directory Numbers (XXX-YYYY)
Abbreviated Dialing (8-XXX-YYYY) Abbreviated Dialing
2017 Cisco and/or its affiliates. (8-XXX-YYYY)
All rights reserved. Cisco Public 137
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 (442-4000) dials 8-559-5000

PBX 1 PBX 2
Internal Directory Numbers (XXX-YYYY) Internal Directory Numbers (XXX-YYYY)
Abbreviated Dialing (8-XXX-YYYY) Abbreviated Dialing
2017 Cisco and/or its affiliates. All(8-XXX-YYYY)
rights reserved. Cisco Public 138
+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
E.164 Dialing E.164
2017 Cisco and/or its affiliates. All rights Dialing
reserved. Cisco Public 139
Inter Cluster look Up Service (ILS)
- URI dialing
Global Dial Plan Replication (GDPR)
- Numeric dialing
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
Bob@cisco.com MSFT Lync 1 Fran@cisco.com

London Rowan@cisco.com
Jane@cisco.com
San Jose
Helen@cisco.com Bryan@cisco.com Diane@cisco.com
Greg@cisco.com Alicia@cisco.com Chris@cisco.com
Fran@cisco.com Bob@cisco.com
Anne@cisco.com Eric@cisco.com Anne@cisco.com Eric@cisco.com
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
San Jose London
Diane@cisco.com Helen@cisco.com
Is Helen@cisco.com a Chris@cisco.com Greg@cisco.com
Diane@cisco.com locally registered URI Bob@cisco.com Fran@cisco.com Helen@cisco.com
Anne@cisco.com Eric@cisco.com
?
San Jose London
Bob@cisco.com Fran@cisco.com
London San Jose
Helen@cisco.com Diane@cisco.com
Greg@cisco.com Chris@cisco.com
Eric@cisco.com Anne@cisco.com
ILS scales to 100 of 1000s of entries (1,000,000 tested) 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 142
URI Dialing
Diane calls
Helen@cisco.com SME
San Jose London
Is Helen@cisco.com a Chris@cisco.com Greg@cisco.com
No URI
locally registered Bob@cisco.com
Anne@cisco.com
Fran@cisco.com
Eric@cisco.com
?
San Jose London
Chris@cisco.com Can Helen@cisco.com Greg@cisco.com
Yes
be found in ILS ?
London San Jose
URI Dialing
Diane calls
Helen@cisco.com SME
San Jose London
Diane@cisco.com Bob@cisco.com Fran@cisco.com Helen@cisco.com
San Jose London

Return Route String
london.uk.eu for URI
Helen@cisco.com
London San Jose
URI Dialing
Diane calls
Helen@cisco.com SME
Yes
Does Route String San Jose London
london.uk.eu match Chris@cisco.com Greg@cisco.com
Diane@cisco.com an existing SIP Route Bob@cisco.com Fran@cisco.com Helen@cisco.com
Pattern
San Jose Route the URI call to London

Chris@cisco.com london.uk.eu over the Greg@cisco.com
Route Patterns SIP
Trunk
London San Jose
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
+14089024567 +442088244567 +33467678921
Diane@cisco.com +33467678921
+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
Fran@cisco.com +33453567619 +33453567619 Bob@cisco.com
+442088241234 +33677687297 +33677687297 +14089021234
+14089021234 +442088241XXX
2017 Cisco and/or its+1408902XXXX +442088241234
affiliates. All rights reserved. Cisco Public
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
Advertise Globally in ILS 9728131XXXXX
Directory URI can be imported from

LDAP
PSTN failover Number (EAN or E.164
number) supported for EAN, E.164
AN and URI calls
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
3
3
Note Numbers, URIs and Patterns for
3rd Party systems can be imported
into ILS GDPR
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
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 Global Backbone
San Jose.CA.US
New York.NY.US
US SME EU SME Asia CUBE

SBC
San Jose New York London Frankfurt Seoul Singapore

Default Route to
US SME
GDPR vs SME
or
GDPR and SME
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
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
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
Seattle Chicago
Deploying Applications in
Large Scale UC networks
Large Scale SIP Trunk Design Recommendations Applications
Unity Cisco
Connection Meetings
Voicemail Server
System (CMS)
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
Other applications such as voicemail and conferencing can be centralized BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 156
Centralized Applications - Conferencing
Cisco Meetings Server
SIP Trunk (CMS)
HTTPS
Rendezvous and Ad Hoc

Conferences
Session
Management
HTTPS connection Edition HTTPS connection
for Ad Hoc Cluster for Ad Hoc
Conferences Conferences
SIP Trunks for Ad Hoc and

Rendezvous Conferences

Cisco Meetings Server can be centralized with SME :

Rendezvous and Ad Hoc Conference calls can be routed over SIP Trunks via SME to CMS
Ad Hoc Conferences Also need a HTTPS connection to CMS from the leaf CUCM cluster
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
For Mobile Remote Access MRA clients establish a direct line side connection to their home cluster
BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
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)
Agenda
Complete Your Online Session Evaluation
Please complete your Online
Session Evaluations after each
session
Complete 4 Session Evaluations &
the Overall Conference Evaluation
(available from Thursday) to receive
your Cisco Live T-shirt
All surveys can be completed via
the Cisco Live Mobile App or the
Dont forget: Cisco Live sessions will be available
Communication Stations for viewing on-demand after the event at
CiscoLive.com/Online
Continue Your Education
Demos in the Cisco campus
Walk-in Self-Paced Labs
Lunch & Learn
Meet the Engineer 1:1 meetings
Related sessions
Q&A
Thank You
Appendix
Lots of detailed information

Deep down into SIP
SIP INVITE Request and

Associated Message Headers
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
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
Content-Length: 0
SIP Headers Categorized :
Identity, Timers, Supported Methods
and Events, Cisco related and other
headers
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
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 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 172
Date: Wed, 18 Feb 2015 18:37:57 GMT Other
Max-Forwards: 70 headers
event;Duration=500"
Content-Length 0
SIP Request Line :
INVITE
Request Request URI Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
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
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
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
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
Transaction 102 BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 178
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
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
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>
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
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
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
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.
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
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
which handles Authentication. BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 187
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
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
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>
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
UC 10.0 allows this order to be changed BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 191
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
Name and Number
Presentation and Restriction
Privacy: None
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
Search Space on the Device or Line Device/Line settings 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 194
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
SIP Trunk - Calling Line ID and Calling Name
Presentation/Restriction Outbound Calls

2002
Bob Jones
Trunk settings :
Default
Allowed
Restricted
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

1001
2002 or Remote-Party-ID: Jim Brown"sip:1001@10.10.199.250; privacy=Full
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
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
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 overwritten
CUCM Phone and Trunk SIP Profile Features
Centralized Trunk Overwriting the Caller DN and Name (1)
Edinburgh Office From: Cisco Systems<sip:+441315613613@10.10.199.251>
Directory Number = 5001 P-Asserted-Identity: Peter Black" <sip:5001@10.10.199.251>
Name = Peter Black Remote-Party-ID: Peter Black <sip:5001@10.10.199.251>;
Contact: <sip:+441315613613@10.10.199.251:5060>

London Office
Directory Number = 2002
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
Centralized Trunk Overwriting the Caller DN and Name (2)
From: Cisco Systems<sip:+441315613613@10.10.199.251>
Edinburgh Office
P-Asserted-Identity: Peter Black" <sip:5001@10.10.199.251>
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 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
Device Caller Information 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
Timer related headers
Request Header Request Header Content
Min-SE: 1800
Expires: 180
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
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
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
indicate who (UAS or UAC) is doing the refreshing. BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 206
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)
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
Cluster

Media
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

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
Maximum value = 300000 milliseconds = 3000 seconds = 5 minutes BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 210
Methods and Events supported

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
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
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
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
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
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
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
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
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
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
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
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.
Deep down into SIP
SIP 180 Ringing Response and

Associated Message Headers
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
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.
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
SIP 180 Ringing Response
Route and Transaction related
headers
Response Header Response/ Message Header Content
CSeq: 101 INVITE
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 Via
Headers can be used to record the route through several SIP switches 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 228
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
Identity and Dialog related headers
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
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
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
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
Methods and Events supported
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
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
Cisco and other headers
Date: Wed, 18 Feb 2015 18:37:57 GMT
Content-Length: 0
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
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
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
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
Deep down into SDP

Voice calls
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=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=fmtp:101 0-15
Some SDP lines are REQUIRED some are OPTIONAL, but all MUST appear in exactly theand/or
2017 Cisco order described
its affiliates. All rights reserved. in RFC
Cisco Public 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
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
<Format> RTP Payload Type numbers - Codec PTs in preference order 2017 Cisco and/or its affiliates. 0 8 18
All rights 101Cisco Public
reserved. 246
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)
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

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
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
a=fmtp:101 0-15 a=fmtp:1010-15
Deep down into SDP

Video calls
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
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
Far End Camera Control 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 253
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
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
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
b= <AS> Application Specific bandwidth : <value> in kbps 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 256
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
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
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
SDP Offer H.264 and H.263 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
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
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
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
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 )
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
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.
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)
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
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
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

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.
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)
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
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
Binary Floor Control 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 273
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
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 BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 275
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
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
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
Conference 1 User 8 Conference 1 User 6
Binary Floor Control 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 278
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
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
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
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
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
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
a=rtpmap:102 MP4A-LATM/90000
a=fmtp:102 bitrate=64000;profile-level-id=24;object=23
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:105 G7221/16000
a=fmtp:105 bitrate=32000
a=rtpmap:106 G7221/16000
a=fmtp:106 bitrate=24000
a=ptime:20
a=rtpmap:8 PCMA/8000
SIP Trunk Signaling Video Call
Complete SDP Answer : Voice, Video, BFCP and FECC
v=0
s=SIP Call
b=TIAS:6000000
b=AS:6000
t=0 0
c=IN IP4 10.58.9.222
b=TIAS:64000
a=fmtp:101 0-15
c=IN IP4 10.58.9.222
b=TIAS:5936000
a=label:11
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-
size=1382400;max-smbps=108000;max-fps=6000
a=content:main
c=IN IP4 10.58.9.222
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
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
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
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 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
SIP Trunk with Early Offer
subsequently be initiated by the called device)
MGCP Trunk
MGCP Gateway BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 288
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
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

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)
With Delayed Offer Calls - Media choices (e.g. codec decision/ DTMF transport decision)
made by the Leaf cluster originating the call
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)

With Early Offer Calls - Media choices (e.g. codec decision/ DTMF transport decision) made
by the Leaf cluster receiving the call
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
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
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
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
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
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 BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 298
SME cluster with no Media Resources
Why H323 Inter Cluster Trunks cannot be used.
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
and determination of which cluster is Master and Slave is random 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 300
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
Therefore - H323 Trunks cannot be used in SME deployments without media resources
Global SME Deployments
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
affects call set up rather than overall voice quality 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 303
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
concern enable PRACK on SIP Trunks. BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 304
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
SME MTP-less EO SIP Trunks - Recommended 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 305
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
Up to 500 mS between call processing nodes, Up to 500 mS between 2017
Publisher and Subscribers
Cisco and/or its affiliates. All rights reserved. Cisco Public 306
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
SIP trunks only with Run on all Nodes enabled - Mandatory 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 307
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
typically can be run as a background process during normal SME cluster operation. 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 308
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
Leaf Cluster Trunks placed into Route Lists and Route Groups for redundancy 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 309
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
processing node in the destination leaf cluster BRKUCC-2006 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 310
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
Route local operates in the SME cluster No inter node intra clustercall routing

Sip Trunk

Uploaded by

Copyright:

Available Formats

Sip Trunk

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sip Trunk

Uploaded by

Copyright:

Available Formats

SIP Trunk design and

UC 7.1 Support for IPv6

Legend: Yes Limited support No

Up to 16 destination addresses feature

Request Invitation to participate in a session

Response e.g. OK/ Busy/ Moved

Commonly Used Responses

100 Trying - CUCM has received the INVITE

Register 1001@10.1.1.1 Register 2002@10.2.2.2

UAS UAC UAS UAC

INVITE 2002 INVITE 2002

INVITE 2002 INVITE 2002

INVITE 2002 INVITE 2002

Why is CUCM a B2BUA ?

INVITE UAS UAS

Line Side SIP Trunk Side SIP

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

See Appendix for detailed descriptions and CUCM related configuration

Supported: X-cisco-srtp-fallback Cisco related

See Appendix for detailed descriptions and CUCM

Leaf Cluster Leaf Cluster

Leaf Cluster Leaf Cluster

See Appendix for detailed descriptions and CUCM related configuration

See Appendix for detailed descriptions and CUCM related configuration

SIP 180 Ringing

Two Way Media

Media Capabilities Endpoint IP Address, Codecs etc

Two Way Media

PRACK Two Way Media PRACK

Delayed Offer with Early Media

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

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

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