Brkucc 2006

Tony Mulchrone
Technical Marketing Engineer

Cisco Collaboration Technology
•
•
•
•
•
•
•
BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
•
•
•
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
cs.co/ciscolivebot#BRKUCC-2006
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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
© 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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 1 Active Node in a

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
•
•
•
•
•
•
•
INVITE sip:1001@10.10.199.250:5060 SIP/2.0 --------------------------------
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
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>
Request Request URI Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
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
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
Request /Header Request/ Message Header Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
CSeq: 101 INVITE
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
Request /Header Request Header Content
INVITE sip:1001@10.10.199.250:5060 SIP/2.0
CSeq: 101 INVITE
Request Header Content Category
<sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5- Identity and
SIP Message Header Message Header Content
353990242dfe-32552697
Dialog
From: <sip:2002@10.10.199.251>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-
<sip:1001@10.10.199.250>
32552697
related
8fe4f600-b7c13785-3-fbc712ac@10.10.199.251 headers
To: <sip:1001@10.10.199.250>
<sip:2002@10.10.199.251>
<sip:2002@10.10.199.251>;party=calling;screen=yes;privacy=off
<sip:2002@10.10.199.251:5060;transport=tcp>
INVITE sip:1001@10.10.199.250:5060 SIP/2.0

32552697
To: <sip:1001@10.10.199.250>
INVITE sip:1001@10.10.199.250:5060 SIP/2.0

Call-ID: 8fe4f600-b7c13785-3-fbc712ac @10.10.199.251
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 user’s 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
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>
Request Header Request Header Content Category
Supported: timer,resource-priority,replaces Timer related
Session-Expires: 1800 headers
Min-SE: 1800
Expires: 180
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

Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
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
•
•
•
•
•
•
•
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 Phone’s 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 )
Attribute Description Attribute Content Comments
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
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
b= Bandwidth (bps) TIAS:6000000 Transport Independent
Application Specific bandwidth
m= Media Descriptions video 16446 RTP/AVP 98 99 Media/Port#/Protocol/ RTP
Payload Types (H.264, H.263)
c= Connection Data IN IP4 10.58.9.86 Video Phone IP Address
a= Attribute rtpmap:98 H264/90000 H.264 Video Codec
a= H.264 Video Codec fmtp:98 profile-level-id=428016; packetization-mode=1; max-mbps=245000;
receive capabilities max-fs=9000;max-cpb=200; max-br=5000; max-rcmd-nalu-size=3456000; max-
smbps=245000; max-fps=6000
a= Attribute rtpmap:99 H263-1998/90000 H.263 Video Codec
a= H.263 Video Codec fmtp:99 QCIF=1; CIF=1; CIF4=1; CUSTOM=352,240,1
receive capabilities
a= Attribute rtcp-fb:* nack pli RTCP Feedback – Packet Loss
a= Attribute rtcp-fb:* ccm tmmbr RTCP Feedback – Max Bit Rate
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
•
•
•
•
•
•
•
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)
•
•
•
•
•
•
•
•
Privacy: None
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
•
•
•
•
•
•
•
•
•
•
•
•
•
•
9.X End of Support December 2018
Large Scale UC Designs
Call Admission Control
(CAC)

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•

• 

•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
 »
»
»
Cisco Webex Teams
Questions?
Use Cisco Webex Teams (formerly Cisco Spark)
to chat with the speaker after the session
How
1 Find this session in the Cisco Events Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
cs.co/ciscolivebot#BRKUCC-2006
Complete your online
session survey
• Please complete your Online Session
Survey after each session
• Complete 4 Session Surveys & the Overall
Conference Survey (available from
Thursday) to receive your Cisco Live T-
shirt
• All surveys can be completed via the Cisco
Events Mobile App or the Communication
Stations
Don’t forget: Cisco Live sessions will be available for viewing

on demand after the event at ciscolive.cisco.com
Continue Your Education
Demos in Meet the Related

Walk-in
the Cisco engineer sessions
self-paced
Showcase labs 1:1
meetings
Thank you
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
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 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
Min-SE: 1800
Expires: 180

Cisco-Guid: 2414147072-3082893189-0000000002-4224127660

Date: Wed, 18 Feb 2015 18:37:57 GMT Other
Max-Forwards: 70 headers
event;Duration=500"
Content-Length 0
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
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
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 188
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
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

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. BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 192
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


1) Delivery of user identity for call trace purposes, when a user’s identity is anonymized in the content
of the From Header
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. 197
BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
From: “Bob Jones" <sip:2002@10.10.199.250>
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 201
CUCM SIP Trunk Features
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
Privacy: None
Presentation/Restriction of Calling Line ID & Calling Name
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
Line/Device - Presentation/Restriction of Calling Line ID
and Calling Name
or From: "Anonymous" <sip:localhost>
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 - Connected Line ID and Connected Name
Presentation/Restriction – Inbound Calls
Remote-Party-ID: “Jim Brown"sip:1001@10.10.199.250; privacy=Off
or Remote-Party-ID: “Jim Brown"sip:1001@10.10.199.250; privacy=Name
or Remote-Party-ID: “Jim Brown"sip:1001@10.10.199.250; privacy=URI

or Remote-Party-ID: “Jim Brown"sip:1001@10.10.199.250; privacy=Full 1001
2002 Jim Brown
Bob Jones
180/ 183/ 200/Responses
Connected Line ID and Connected Name

Presentation/ Restriction affect the
privacy value in the RPID header sent in :
180, 183 Responses and 200 Responses
Trunk settings :
Default
Use calling device values
Allowed
RPID privacy value = Off
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 User’s 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
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 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” is
X 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)
From: “Cisco Systems”<sip:+441315613613@10.10.199.251>
Edinburgh Office
P-Asserted-Identity: “Peter Black" <sip:5001@10.10.199.251>
Directory Number = 5001
Name = Peter Black Remote-Party-ID: “Peter Black“ <sip:5001@10.10.199.251>;
Contact: <sip:+441315613613@10.10.199.251:5060>
From: “Cisco Systems UK”<sip:+442088241000@10.10.199.251>

London Office
P-Asserted-Identity: “Bob Jones" <sip:2002@10.10.199.251>
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” © 2019 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
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 216
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)
SIP Session Expires and Min-SE Headers - Operation
During call set up - Session timers and Session Refresh methods are negotiated and
agreed on each SIP Trunk. Once the call is established – the session on each Trunk
periodically refreshed. If no session refresh request or response is received the UA
sends a BYE to terminate the session
SME Node
crash
SME
Cluster
Leaf Cluster Leaf Cluster

North America Europe
Media
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
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.
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
100 Trying 100 Trying
180 Ringing 180 Ringing
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
Response Header Response/ Message Header Content

CSeq: 101 INVITE
SIP 180 Ringing Response
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© 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
SIP 180 Ringing Response –
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
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


1) Delivery of user identity for call trace purposes, when a user’s identity is anonymized in the
content of the From Header
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
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
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
SIP Trunk Signaling - Media negotiation for Voice calls :
The SDP Offer
….. SIP Message Headers
Content-Type: application/sdp Content-Type : application/SDP
Content-Length: 337 Content-Length : 337 Bytes
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250
s=SIP Call SDP Message Body
c=IN IP4 10.10.199.130
Describes the media characteristics of the
t=0 0 endpoint offering the SDP
m=audio 16444 RTP/AVP 0 8 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20 Includes :
a=rtpmap:8 PCMA/8000 Endpoint IP address
a=ptime:20 Codecs supported
a=rtpmap:18 G729/8000
a=ptime:20 UDP Port number for RTP
a=sendrecv In Band DTMF support details
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Some SDP lines are REQUIRED some are OPTIONAL, but all MUST appear in exactly the
© 2019 Cisco and/ororder
its affiliates.described in RFC
All rights reserved. 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 = Phone’s 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
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© 2019 Cisco and/or its affiliates. All0rights8 reserved.
18 101 Cisco Public
SDP Media Attributes – Voice Codecs Offered
m= Media Descriptions audio 16444 RTP/AVP 0 8 18 101 Media/Port#/Protocol/ RTP Payload Types
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
SIP Trunk Signaling - Media negotiation Voice calls : The
SDP Answer
v= Version 0 Phone’s 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
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:101 0-15
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
Binary Floor Control
Far End Camera Control © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
m=video 16446 RTP/AVP 98 99

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

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

b= bandwidth – Can be applied at the session level (all media streams) or media level
b= <modifier>:<value>
b= <TIAS> Transport Independent Application Specific : <value> bit/sec
b= <AS> Application Specific bandwidth : <value> in kbps © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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 the
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
SIP Trunk Signaling - Video calls
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=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
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
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 beyond
max-cpb=200 those of the profile-level-id that are supported by this endpoint
max-br=5000
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-

cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
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
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-
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
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
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
MP4A-LATM Audio codec MP4A-LATM Audio codec
Bandwidth 64kbps Bandwidth 64kbps
RFC 2833 DTMF RFC 2833 DTMF
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
SIP Trunk Signaling
v=0
Video calls – SDP Offer part 1: Detail = BFCP only
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
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
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
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
Audio RTP UDP Port 16444 Audio RTP UDP Port 2346
RFC 2833 DTMF Audio RFC 2833 DTMF
Video RTP UDP Port 16446 Video RTP UDP Port 2348
Asymmetric Receive values Main Video Asymmetric Receive values
Asymmetric Receive values Slide Video Asymmetric Receive values
BFCP UDP Port 5070 BFCP UDP Port 5070
Conference 1 User 8 Conference 1 User 6
Binary Floor Control © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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
Audio RTP UDP Port 16444 Audio RTP UDP Port 2346
RFC 2833 DTMF Audio RFC 2833 DTMF
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
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=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:8 PCMA/8000
SIP Trunk Signaling – Video Call
v=0
Complete SDP Answer : Voice, Video, BFCP and FECC
s=SIP Call
b=TIAS:6000000
b=AS:6000
t=0 0
c=IN IP4 10.58.9.222
b=TIAS:64000
a=rtpmap:101 telephone-event/8000
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-
a=content:main
c=IN IP4 10.58.9.222
b=TIAS:5936000
Reasons to use SIP Trunks on SME
SME clusters with no Media Resources
Media Resources Media Resources
Leaf Cluster
New York
Media Resources
SME
Cluster
Media Resources
Leaf Cluster
Leaf Cluster Europe
Los Angeles
Ideally, Media Resources such as MTPs, Transcoders, Music on Hold, Conferencing Resources should
never be utilized in the SME cluster – as this entails hair-pinning media via the media resource
associated with the SME cluster
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” BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 295
Enabling SIP Early Offer – “MTP Required” – Pre UC 8.5
SIP Line SIP Trunk with Early Offer
MTP
SCCP Line SIP Trunk with Early Offer

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

SIP Early Offer Trunks use the Trunk’s Media Termination Point (MTP) resources, inserting an MTP
into the media path for every outbound (and inbound) call – sending the MTP’s 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 Trunk’s 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)”
SIP Line SIP Trunk with Early Offer
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
SIP Trunk SIP Trunk with Early Offer
MTP
For Calls from trunks and devices that cannot
SIP Delayed Offer provide Early Offer information – use the calling
MTP
device’s MTP resources (first) or the outbound
H323 Slow Start trunk’s 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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 297
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
Delayed Offer Delayed 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)” No media
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 BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 299
SME MTP less Early Offer – Delayed Offer Call
Media Resources
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
This EO/DO pass-through feature also affects media negotiation……
With Delayed Offer Calls - Media choices (e.g. codec decision/ DTMF transport decision) made by the
Leaf cluster originating the call
Media resources (if needed) are inserted by the originating Leaf cluster © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
SME MTP less Early Offer – Early Offer Call
Early Offer Early Offer
Media Resources
INVITE with SDP (Offer)
200 OK with SDP (Answer)

This EO/DO pass-through feature also affects media negotiation……
With Early Offer Calls - Media choices (e.g. codec decision/ DTMF transport decision) made by the Leaf
cluster receiving the call
Media resources (if needed) are inserted by the Leaf cluster receiving the call © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
SME SIP Trunks – MTP less Early Offer - Summary
SME
Cluster

North America Early Offer Early Offer Europe
Leaf systems can use SIP Early Offer or Delayed Offer

Use Codec Preference Lists to avoid transcoding
If a Transcoder is required – Inserted by Leaf cluster
If MOH, Announcement service 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
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

North America Early Offer Early Offer Europe
Leaf systems can use SIP Early Offer/Delayed Offer/Best Effort Early Offer (recommended )
Use Codec Preference Lists to avoid transcoding
If a Transcoder is required – Inserted by Leaf cluster
If MOH, Announcement service 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
SME with no Media Resources
Possible with SIP Delayed Offer Trunks Everywhere ?
Leaf Cluster Early Offer Media Delayed Offer Leaf Cluster

North America Decision Europe
made here
All SME Trunks configured as Delayed Offer

No media resources (MTPs, Transcoders etc) associated to the SME Trunks
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

No media resources (MTPs, Transcoders etc) associated to the SME Trunks
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 307
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 BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 309
Reasons to use SIP Trunks only
H323 Slow Start Trunks – Media Negotiation
MSD MSD = Master/ Slave Determination
Slave
Media
SME
Decision
Cluster
made 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
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
Impact of Signaling Delay on Call Set Up
Messages exchanged before the caller
hears ringback tone
One way signalling Delay
INVITE INVITE
100 Trying 100 Trying
180 Ringing 180 Ringing
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 called Messages exchanged before called user hears the
user after ringback stops 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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 313
Reducing Signaling Delay
Pre UC 9.1 - Multiple regional SME clusters
SME SME
Signalling Path
SME SME
Latin America Asia Pac
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
UC 9.1 - One Global SME cluster – UC 9.1
SME CoW up
Clustered over the WAN with extended RTT (1) 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 Publisher and Subscribers
UC 9.1 - One Global SME cluster – UC 9.1
SME CoW up
Clustered over the WAN with extended RTT (2) 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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
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 up SME
CPU threads (using a CLI
to 500mS CoW+ command) prior to upgrade to
RTT reduce DB Replication time –
this does not impact call
< 500 mS
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. BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 317
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 up Route List
Route List
to 500mS Leaf Cluster Leaf Cluster
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 318
BRKUCC-2006 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public
Trunk config from SME cluster to Leaf clusters
DC1 SME Nodes
North America
UC 9.1
SME CoW up
to 500mS Europe
North America
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 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 319
Call Routing – Route Local for SME
DC1 SME Nodes
North America
1st choice Trunk
UC 9.1
SME CoW up Route List
to 500mS Europe
North America
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 C all
st
Distribution – priority order – nearest data centre 1 , second nearest data centre 2 etcnd
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 cluster call routing

Brkucc 2006

Uploaded by

Copyright:

Available Formats

Brkucc 2006

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

Brkucc 2006

Uploaded by

Copyright:

Available Formats

Tony Mulchrone

Technical Marketing Engineer

“Run On All Nodes” feature 1 Active Node in a

“Up to 16 destination addresses” feature

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

SIP Message Header Message Header Content

SIP Message Header Message Header Content

P-Asserted Identity and Remote-Party-ID are optional SIP message headers -

P-Asserted Identity and Remote-Party-ID perform the same functions :

Supported: X-cisco-srtp-fallback Cisco related

Supported: X-cisco-srtp-fallback Cisco related

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

Don’t forget: Cisco Live sessions will be available for viewing

Demos in Meet the Related

Two Way Media

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

Supported: X-cisco-srtp-fallback Cisco related

Request Header Request Header Content Category

SIP Trunk destination configured using an IP address - Host portion = IP address

Transaction 101 Dialog between UA1 and UA2

UAS UAC Request – INVITE (Hold) UAS UAC

Mandatory Header in Requests and Responses

Sequence number - An arbitrary integer = 101

SIP Message Header Message Header Content

SIP Message Header Message Header Content

Mandatory Header in all Requests and Responses

Transactions are tracked by the branch value in the VIA Header

P-Asserted Identity and Remote-Party-ID are optional SIP message headers -

P-Asserted Identity and Remote-Party-ID perform the same functions :

P-Asserted-Identity header – Where interconnected SIP systems trust one another

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….

P-Asserted Identity is sent within a Trusted Realm

2002 From: "Anonymous" <sip:localhost>

SIP Message Header Message Header Content

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

Message Header Fields Values

Calling Line Identification Presentation applies to inbound Requests and Responses

Applied via Translation Pattern/ Transformation Pattern Phone Caller ID Values :

or From: "Anonymous" <sip:2002@10.10.199.251>

or Remote-Party-ID: “Jim Brown"sip:1001@10.10.199.250; privacy=URI

Connected Line ID and Connected Name

433 Anonymity Disallowed

The Trunk configuration for Caller Information

From: “Cisco Systems UK”<sip:+442088241000@10.10.199.251>

With multiple Remote Branches sharing a

Caller ID DN and Name can be configured per site

For each remote site :

phones at this site

SIP Message Header Message Header Content

Mandatory in INVITE Requests and 2XX Responses

Should be sent in an INVITE

Options Supported : timer, resource-priority, replaces

Supported Option Description

Sessions can be refreshed with a Re-INVITE or UPDATE request

Service Parameter for Session Timers – Affects all SIP Trunks

Leaf Cluster Leaf Cluster

Service Parameter value in milliseconds – Header value in seconds