sip trunk design and deployment in enterprise · pdf filesip trunk design and deployment in...
TRANSCRIPT
SIP Trunk design and deployment in Enterprise
UC networks
BRKUCC-2006
Tony Mulchrone
Technical Marketing Engineer
Cisco Collaboration Technology Group
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 don’t forget to visit Cisco Live Virtual:www.ciscolivevirtual.com
Objectives of this break out session
a) Provide a quick overview of SIP basics
b) To analyse real SIP traces and to explain how the various headers
and SDP information relate to CUCM SIP Trunk configuration
We will look at how Voice, Video, Desktop Sharing and Far End
Camera Control are set up over a SIP Trunk
We will describe the differences between voice and video media
negotiation
c) To explain how CUCM SIP Trunk features operate and how and
when these features can be used
d) To leave this audience with a good understanding of CUCM SIP
Trunk operation
Agenda
• Why choose SIP for UC Trunking ?
• SIP Basics
• Deep down into SIP
• Deep down into SDP
• CUCM SIP Trunk features and functions
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 issues, Sip to SIP
interop is easier than SIP to H.323, SIP to MGCP
Cisco UC Protocol Feature Set Comparison
From UC 8.5 onwards, SIP Trunks are more feature rich than
H.323 and MGCP Trunks
Legend: Yes Limited support
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
No
Unified CM Inter Cluster TrunksSIP Trunks vs H.323 Trunks – Feature Comparison
Unified CM SIP Trunk — Gateway IntegrationTechnology Basics
• Types of Gateways• MGCP, H.323, and SIP
• Gateway Deployment• Central site
• Distributed at branch locations
• Gateway Selection• Route Patterns point to a Gateway
• Route Patterns route calls to Gateways via a Route List and Route Groups
Framing
PRI Layer 3
Layer 2Q.931 Backhaul over TCP
MGCP over UDP
TDM IP
Cisco
Unified CM
SIP over UDP/TCP/TLS
MGCP
Gateway
SIP
Gateway
H.323
Gateway
H.245
H.225
Cisco
Unified CM
Cisco
Unified CM
Framing
PRI Layer 3
Layer 2
Framing
PRI Layer 3
Layer 2
PS
TN
PS
TN
PS
TN
CUCM SIP Trunks vs H323 and MGCP Trunks to Gateways
• SIP Trunks support the “Run On All Unified CM Nodes” and “Up to 16 destination IP addresses” features
• H323 and MGCP Trunks to gateways and 3rd party UC systems support standard Call Manager Groups and a single destination IP address
• Using standard Call Manager Groups (rather than Run on All Nodes) increases call set up traffic between nodes within a cluster
• Multiple Trunks may be required with the single destination IP address limitation
• Note – MGCP Trunks are only active on one node in the Call Manager Group (as the signaling channel is back hauled to CUCM)
H323
ICT Trunk H323 Trunk A
H323 Trunk B
Selected outbound Trunk
Route List
SIP
ICT Trunk MGCP Trunk A
MGCP Trunk B
Selected outbound Trunk
Route List
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 Call Manager Group
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
Legend: Yes Limited support No
CUCM Trunks to IOS Gateways
SIP Trunks, H.323 and MGCP Gateways – Feature Comparison
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
SIP Basics
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
UAS UAC UAS UAC
Request – Invitation to participate in a session
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 ACK’ed)
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
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.
UAS UAC UAS UAC
INVITE 2002
200 OK
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……
Register [email protected] Register [email protected]
Registrar
RTP Media
BYEBYE BYEProxy
INVITE 2002
200 OK Record
Route
Proxy
SIP Basics – 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
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.
UAS
UAC
UAS
UAC
CUCM - B2BUA
Deep down into SIP
SIP INVITE Request and Associated Message Headers
SIP Basics – Typical Call Set Up SIP Message exchange
Two Way Media
INVITE
200 OK
ACK
180 Ringing
100 Trying
SIP Trunk
10.10.199.251 10.10.199.250
2002 1001
SIP Messages – INVITE Request with SIP Headers
INVITE sip:[email protected]:5060 SIP/2.0Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:[email protected]>
Date: Wed, 18 Feb 2015 18:37:57 GMT
Call-ID: [email protected]
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.0
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER…..
CSeq: 101 INVITE
Contact: <sip:[email protected]:5060;transport=tcp>
Expires: 180
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
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:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
Max-Forwards: 70
Content-Length: 0
------------------------------------ Request INVITE to 1001
SIP Message
Headers
Some Mandatory
Some Optional
SIP Header Categories : Identity, Timers, Supported
Methods and Events, Cisco related headers
Request /Header Request Header Content Category
INVITE sip:[email protected]:5060 SIP/2.0 Route and Transaction relatedheaders
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
CSeq: 101 INVITE
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
Identity and Dialog related headersTo: <sip:[email protected]>
Call-ID: [email protected]
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
Contact: <sip:[email protected]:5060;transport=tcp>
SIP Messages – INVITE with Headers re-grouped (1 of 3)
Request Header Request Header Content Category
Supported: timer,resource-priority,replaces Timer related headersSession-Expires: 1800
Min-SE: 1800
Expires: 180
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Methods and Events
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback Cisco related headersSupported: Geolocation
User-Agent: Cisco-CUCM8.0
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
SIP Messages – INVITE with Headers re-grouped (2 of 3)
Request Header Request Header Content Category
Date: Wed, 18 Feb 2015 18:37:57 GMT Other headers
Max-Forwards: 70
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Content-Length 0
SIP Messages – INVITE with Headers re-grouped (3 of 3)
SIP INVITE – Request Line
Request Request Header Content
INVITE sip:[email protected]:5060 SIP/2.0
SIP URI content sip:user@host:port-number Comments
User 1001 Number /NameThe Called User
Host 10.10.199.250 IP Address/ Hostname/ Domain NameConfigured SIP Trunk Destination
Port 5060 TCP/UDP Port NumberIncoming and Outgoing Transport Type Configurable via SIP Trunk Security Profile
SIP Protocol Version 2.0
How CUCM configuration affects the contents of the INVITE Request :
SIP Trunk destination configured using an IP address - Host portion = IP addressSIP Trunk destination configured using FQDN or DNS SRV - Host portion = NameSIP 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 Destination
Request Line/SIP Message Header
SIP URI/ SIP Message Header content
IP Address Used INVITE Request Line sip:[email protected]:5060 SIP/2.0
IP Address Used To : Header <sip:[email protected]>
FQDN/DNS SRV Used INVITE Request Line sip:[email protected]:5060 SIP/2.0
FQDN/DNS SRV Used To : Header <sip:[email protected]>
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:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
CSeq: 101 INVITE
SIP Sessions : Transactions and DialogsA 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
UAS UAC UAS UAC
Request – INVITE
Response – 200 OK
Request – INVITE (Hold)
Response – 200 OK
RTP Media
Transaction 101
Transaction 102
Dialog UA1 - UA2
SIP INVITE - Route and Transaction related Headers :Via HeaderA Mandatory Header in Requests and ResponsesThe 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 switchesExactly 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/TLSIncoming and Outgoing Transport Type Configurable via SIP Trunk Security Profile
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 NumberConfigurable via SIP Trunk Security Profile
Branch z9hG4bK3395a5cdb Unique Identifier for this transaction
SIP INVITE – Command Sequence Header
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
Request /Header Request Header Content
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
CSeq: 101 INVITE
SIP Header Categories : Identity and Dialog related headers
SIP Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:[email protected]>
Call-ID: [email protected]
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
Contact: <sip:[email protected]:5060;transport=tcp>
SIP INVITE – From and To Headers
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 Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:[email protected]>
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
SIP INVITE – Call-ID Header
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
SIP Message Header Message Header Content
Call-ID: 8fe4f600-b7c13785-3-fbc712ac @10.10.199.251
P-Asserted-ID and Remote-Party-ID Headers
SIP Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
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
SIP INVITE : P-Asserted-Identity - Related Headers
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.
SIP Message Header Message Header Content /values
From: “Bob Jones” <sip:[email protected]>
P-Asserted-Identity: “Bob Jones” <sip:[email protected]>
P-Preferred-Identity: “Bob Jones” <sip:[email protected]>
Privacy: None/ ID/ ID Critical
CUCM Config : P-Asserted-Identity – Asserted Type
2002Bob Jones Default = P-Asserted-Identity: “Bob Jones” <sip:[email protected]>
PPI = P-Preferred-Identity: “Bob Jones” <sip:[email protected]>
PAI = P-Asserted-Identity: “Bob Jones” <sip:[email protected]>
SIP Trunk configuration :Asserted Identity Type Value
Used When….
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
P-Asserted Identity
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.
Trusted SIP Realm B
P-Preferred Identity
Digest Auth Challenge from SIP Realm B
Digest Authentication Response
CUCM Configuration : PAID/PPID – SIP Privacy header
From: "Anonymous" <sip:localhost>
P-Asserted-Identity: “Bob Jones” sip:[email protected]
Privacy : ID
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
2002Bob Jones
From: “Bob Jones" <sip:[email protected]>
P-Asserted-Identity: “Bob Jones” sip:[email protected]
Privacy :None
SIP INVITE : Remote-Party-ID Header
Remote-Party-ID differs from PAI in that it has no authentication challenge mechanismRemote-Party-ID has largely been superseded by P-Asserted-Identity today
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
SIP Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
Message Header Fields Values
User Identity “Name” <Number@Host Address> e.g. “Bob Jones” <[email protected]>
Party Called/ Calling
Screen Yes = Identity Trusted by CUCM/ No – If “Screen=No” received over Q.931/SIP
Privacy Name/URI/Full/OffPrivacy values taken from Device/ Trunk settings for Identity Presentation and Restriction
Related CUCM Config – From Header and Identity HeadersSIP 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:[email protected]> <sip:[email protected]>
P-Asserted-Identity: <sip:[email protected]> <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]> <sip:[email protected]>
Contact: <sip:[email protected]:5060> <sip:[email protected]>
Number and Name Presentation informationHeader Priority : From/ RPID/ PAI
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……
2002Bob Jones
P-Asserted-Identity: “Bob Jones” <sip:[email protected]>
From: “Jim Smith” <sip:[email protected]>
Remote-Party-ID: “May Brown” <sip:[email protected]>
Displayed
Caller
Identity
?
CUCM SIP Trunk FeaturesSIP 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
SIP Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
P-Asserted-Identity: <sip:[email protected]>
Privacy: None
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
Presentation/Restriction of Calling Line ID & Calling Name
2002Bob Jones
Applied using Line ID and Name Presentation settings in a Translation
Pattern associated with the Calling Search Space on the Device or Line
Applied at the Trunk Level using Line ID and Name Presentation settings
If Non-Default - Overrides Device/Line settings
Applied at the Trunk Level using P-Asserted-Identity – Privacy Header
settings
If Non-Default - Overrides Device/Line and Trunk settings
From: “Bob Jones" <sip:[email protected]> or From: “Bob Jones" <sip:localhost> or From: "Anonymous" <sip:[email protected]>or From: "Anonymous" <sip:localhost>
Line/Device - Presentation/Restriction of Calling Line ID and Calling Name
Phone Caller ID Values :
Default = Do not change ID/Name
Allowed
Restricted
Applied via Translation Pattern/ Transformation Pattern
Applied Translation Pattern
2002Bob Jones
From: “Bob Jones" <sip:[email protected]> or From: “Bob Jones" <sip:localhost> or From: "Anonymous" <sip:[email protected]>or From: "Anonymous" <sip:localhost>
SIP Trunk - Calling Line ID and Calling NamePresentation/Restriction – Outbound Calls
Trunk settings :
DefaultUse calling device valuesAllowedRPID privacy value = OffRestrictedRPID privacy value = Name/URI/Full
2002Bob Jones
From: “Bob Jones" <sip:[email protected]> or From: “Bob Jones" <sip:localhost>
or From: "Anonymous" <sip:[email protected]>or From: "Anonymous" <sip:localhost>
SIP Trunk - Connected Line ID and Connected Name Presentation/Restriction – Inbound Calls
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 :DefaultUse calling device valuesAllowedRPID privacy value = OffRestrictedRPID privacy value = Name/ URI/ Full
2002Bob Jones
Remote-Party-ID: “Jim Brown"sip:[email protected]; privacy=Off or Remote-Party-ID: “Jim Brown"sip:[email protected]; privacy=Name
or Remote-Party-ID: “Jim Brown"sip:[email protected]; privacy=URIor Remote-Party-ID: “Jim Brown"sip:[email protected]; privacy=Full
1001 Jim Brown
180/ 183/ 200/Responses
CUCM SIP Trunk FeaturesSIP Profile settings – Reject Anonymous Calls
INVITE sip:[email protected]:5060 SIP/2.0From: "Anonymous" <sip:localhost>P-Asserted-Identity: “Jim Brown” <sip:[email protected]>Privacy : IDRemote-Party-ID: “Brown” sip:[email protected] ; privacy=full
x
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
433 Anonymity Disallowed
2002Bob Jones
1001 Jim Brown
Cisco Systems UK
+442088241000
X
CUCM SIP Trunk FeaturesOutbound Calls – Overwriting the Caller DN and Name
INVITE sip:[email protected]:5060 SIP/2.0From: “Cisco Systems UK”<sip:[email protected]>P-Asserted-Identity: “Bob Jones" <sip:[email protected]>Remote-Party-ID: "Bob Jones“ <sip:[email protected]> Contact: <sip:[email protected]:5060>
The Trunk configuration for Caller Information allows the From header to be overwritten for outbound SIP Trunk calls
If “Maintain Original Caller ID DN and Name” is not checked the P-Asserted-Identity and Remote-Party-ID fields are also overwritten
2002Bob Jones
2002Bob Jones
CUCM SIP Trunk FeaturesCentralized Trunk – Overwriting the Caller DN and Name (1)
From: “Cisco Systems UK”<sip:[email protected]>
P-Asserted-Identity: “Bob Jones" <sip:[email protected]>
Remote-Party-ID: "Bob Jones“ <sip:[email protected]>;
Contact: <sip:[email protected]:5060>
X
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
From: “Cisco Systems”<sip:[email protected]>
P-Asserted-Identity: “Peter Black" <sip:[email protected]>
Remote-Party-ID: “Peter Black“ <sip:[email protected]>;
Contact: <sip:[email protected]:5060>
This setting can still be used
London OfficeDirectory Number = 2002Name = Bob Jones
Edinburgh OfficeDirectory Number = 5001Name = Peter Black
For each remote site :
Create a SIP Profile and configure the Caller ID DN and Caller Name. Associate this profile with the phones at this site
On the Outbound SIP Trunk SIP Profile - Check the box to “Allow Passthrough of configured Line Device Caller Information”
CUCM SIP Trunk FeaturesCentralized Trunk – Overwriting the Caller DN and Name (2)
From: “Cisco Systems”<sip:[email protected]>
P-Asserted-Identity: “Peter Black" <sip:[email protected]>
Remote-Party-ID: “Peter Black“ <sip:[email protected]>;
Contact: <sip:[email protected]:5060>
London OfficeDirectory Number = 2002Name = Bob Jones
Edinburgh OfficeDirectory Number = 5001Name = Peter Black
X
+441315613613
Cisco Systems
For Phones in Edinburgh
For Outbound Trunk
SIP INVITE – Contact Header
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 Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
SIP Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
Contact: sip:[email protected]:5060;transport=tcp
SIP Header Categories : Timer related headers
Request Header Request Header Content
Supported: timer,resource-priority,replaces
Session-Expires: 1800
Min-SE: 1800
Expires: 180
SIP INVITE – Supported Header
Should be sent in an INVITE
Indicates new SIP options supported by this UA
Options Supported : timer, resource-priority, replaces
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
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
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
Supported: timer, resource-priority, replaces
SIP INVITE – Session Expires and Min-SE Headers
Optional Headers - Support indicated via the Supported: “timer” header optionSession-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 requestAllows 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 ProxiesMin-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.
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Session-Expires 1800
Min-SE 1800
Related CUCM configuration Min-SE Header, Session Expires HeaderSIP 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
Leaf Cluster
North America
Leaf Cluster
Europe
SME
Cluster
Media
SME
Node
crash
SIP INVITE – Expires Header
Optional Header in INVITE RequestsThe 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.
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Expires: 180
Service Parameter value in milliseconds – Header value in secondsDefault value = 180000 milliseconds = 180 seconds = 3 minutesMinimum value = 60000 milliseconds = 60 seconds = 1 minuteMaximum value = 300000 milliseconds = 3000 seconds = 5 minutes
SIP Header Categories : Methods and Events supported
Request Header Request Header Content
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence, kpml
SIP INVITE – Allow Header
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
SIP INVITE Allow-Events Header
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)
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Allow-Events presence, kpml
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
SIP Header Categories : Cisco and other headers
Request Header Request Header Content
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
User-Agent: Cisco-CUCM8.0
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
Date: Wed, 18 Feb 2015 18:37:57 GMT
Max-Forwards: 70
Content-Length: 0
SIP INVITE – Supported Header
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Supported: X-cisco-srtp-fallback
SIP INVITE – Supported Header
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Supported: Geolocation
SIP INVITE – Call-Info Header
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
SIP INVITE – User Agent Header
Optional Header - Contains information about the client User Agent originating the request
CUCM configurable : SIP Profile “User-Agent and Server header information”
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
User-Agent: Cisco-CUCM8.0
SIP INVITECisco GUID Header – Globally Unique Identifier
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Cisco-Guid: 2414147072-3082893189-0000000002-4224127660
SIP INVITE – Date Header
An Optional Header
Date and time the Request or Response sent
Greenwich Mean Time (GMT) only
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Date: Wed, 18 Feb 2015 18:37:57 GMT
SIP INVITE : Max-Forwards Header
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
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Max-Forwards: 70
SIP INVITE : Content-Length Header
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.
Request Request URI Content
INVITE sip:[email protected]:5060 SIP/2.0
Request Header Request Header Content
Content-Length: 0
Deep down into SIP
SIP 180 Ringing Response and Associated Message Headers
SIP Basics – Typical call set-up SIP Message exchange
Two Way Media
INVITE
200 OK
ACK
180 Ringing
100 Trying
SIP Trunk
10.10.199.251 10.10.199.250
2002 1001
CUCM SIP Trunk Signaling180 Ringing Response - Ringback
Two Way Media
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
Caller hears locally
generated ringback
tone
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
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:[email protected]>;tag=abee6e2b-75b0-4537-80f3-7a3a37d0fa55-32557664
Date: Wed, 18 Feb 2015 18:37:57 GMT
Call-ID: [email protected]
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
Contact: <sip:[email protected]:5060;transport=tcp>
Call-Info: <sip:10.10.199.250:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Supported: X-cisco-srtp-fallback
Supported: Geolocation
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;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
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
CSeq: 101 INVITE
SIP 180 Ringing ResponseVia Header
A Mandatory Header in Requests and ResponsesSIP/2.0 – SIP Protocol Version / TCP – Transport Protocol10.10.199.251 – IP Address of CUCM generating the Request5060 – TCP Port number for SIP signallingBranch – Unique Identifier for this transactionThis 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
Response/Header Response Header Content
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
SIP 180 Ringing Response –Command Sequence Header
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
Response /Header Response Header Content
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 10.10.199.251:5060;branch=z9hG4bK3395a5cdb
CSeq: 101 INVITE
SIP 180 Ringing Response Identity and Dialog related headers
SIP Message Header Message Header Content
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:[email protected]>;tag=abee6e2b-75b0-4537-80f3-7a3a37d0fa55-32557664
Call-ID: [email protected]
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
Contact: <sip:[email protected]:5060;transport=tcp>
180 Ringing Response: From Header and To Header
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
Response/Header Response Header Content
SIP/2.0 180 Ringing
From: <sip:[email protected]>;tag=1b1993ff-121d-4616-8dc5-353990242dfe-32552697
To: <sip:[email protected]>;tag=abee6e2b-75b0-4537-80f3-7a3a37d0fa55-32557664
SIP 180 Ringing Response: Call-ID Header
Mandatory Header in 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 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
Response/Header Response Header Content
SIP/2.0 180 Ringing
Call-ID: [email protected]
SIP 180 Ringing Response: Identity 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 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
Response /Header Response Header Content
SIP/2.0 180 Ringing
P-Asserted-Identity: <sip:[email protected]>
Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=off
SIP 180 Ringing Response: Contact Header
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
Response/Header Response Header Content
SIP/2.0 180 Ringing
Contact: <sip:[email protected]:5060;transport=tcp>
SIP 180 Ringing Response Methods and Events supported
Request Header Request Header Content
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
Allow-Events: presence
SIP 180 Ringing Response: Allow Header
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
Response/Header Response Header Content
SIP/2.0 180 Ringing
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
SIP 180 Ringing Response: Allow-Events Header
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
Note:
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
Response/Header Response Header Content
SIP/2.0 180 Ringing
Allow-Events: presence
SIP 180 Ringing ResponseCisco and other headers
Request Header Request Header Content
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Date: Wed, 18 Feb 2015 18:37:57 GMT
Content-Length: 0
SIP 180 Ringing Response: Supported Headers
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
Response /Header Response Header Content
SIP/2.0 180 Ringing
Supported: X-cisco-srtp-fallback
Supported: Geolocation
SIP 180 Ringing Response: Call-Info Header
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
Response/Header Response Header Content
SIP/2.0 180 Ringing
Call-Info: <sip:10.10.199.251:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
SIP 180 Ringing Response: Date Header
An Optional Header
Date and time the Request or Response sent
Greenwich Mean Time (GMT) only
Response/Header Response Header Content
SIP/2.0 180 Ringing
Date: Wed, 18 Feb 2015 18:37:57 GMT
SIP 180 Ringing Response: Content Header
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. SDP
is not usually sent in unreliable 1XX messages. The message body is appended after the
Content-Length header.
Response/Header Response Header Content
SIP/2.0 180 Ringing
Content-Length: 0
Deep down into Session Description Protocol
(SDP)
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
A 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 Basic Operation The Offer/Answer model - SIP Early Offer
Information about the calling device’s 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…….)
Two Way Media
INVITE with SDP (Offer)
200 OK with SDP (Answer)
ACK
180 Ringing
100 Trying
INVITE with SDP (Offer)
200 OK with SDP (Answer)
ACK
180 Ringing
100 TryingOne Way
Media
SIP Trunk Signaling and Basic Operation The Offer/Answer model - SIP Delayed Offer
No information about the calling device’s 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 device’s “Offer” contains its IP Address, UDP Port number, list of codecs etc.
The calling device selects which of the offered codecs it wishes to use for the call and returns its “Answer” in the SDP body of a reliable SIP response (ACK) – The Answer also contains the IP address and UDP port number etc of the calling device
Delayed Offer is a mandatory part of the SIP standard (but not supported by all vendors)
Ordinarily, the Offer or Answer cannot be sent reliably in 100 Trying or 180 Ringing as 1XX messages are unacknowledged… This can be resolved using PRACK ….. discussed later…..
Two Way Media
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
Deep down into SDP
Media negotiation for Voice calls
SIP Trunk Signaling - Media negotiation for Voice calls : The SDP Offer
…..Content-Type: application/sdpContent-Length: 337
v=0o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250s=SIP Callc=IN IP4 10.10.199.130t=0 0m=audio 16444 RTP/AVP 0 8 18 101a=rtpmap:0 PCMU/8000a=ptime:20a=rtpmap:8 PCMA/8000a=ptime:20a=rtpmap:18 G729/8000a=ptime:20a=sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15
SIP Message Headers
Content-Type : application/SDP
Content-Length : 337 Bytes
SDP Message Body
Describes the media characteristics of the endpoint offering the SDP
Includes :
Endpoint IP address
Codecs supported
UDP Port number for RTP
In Band DTMF support details
Some SDP lines are REQUIRED some are OPTIONAL, but all MUST appear in exactly the order described in RFC 4566
Media negotiation for Voice calls The SDP Offer - SDP Session Attributes
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 addressTiming = <start-time><stop-time> 0 0 = permanent session
Attribute Description Attribute Content Required/Optional
v= Version 0 Required
o= Origin CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250
Required10.10.199.250 = CUCM IP Address
s= Session Name SIP Call Required
c= Connection Data IN IP4 10.10.199.130 Optional10.10.199.130 = Phone’s IP Address
t= Timing 0 0 Required
Media negotiation for Voice calls – The SDP OfferSDP Media Attributes – Voice Codecs Offered
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 0 8 18 101
Attribute Description Attribute Content Comments
c= Connection Data IN IP4 10.10.199.130 Phone’s IP Address
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 ptime:20 RTP packet sampling time (mS)
a= Attribute rtpmap:8 PCMA/8000 G.711 a-law codec
a= Attribute ptime:20 RTP packet sampling time (mS)
a= Attribute rtpmap:18 G729/8000 G.729 codec
a= Attribute ptime:20 RTP packet sampling time (mS)
Media negotiation for Voice calls – The SDP OfferSDP Media Attributes – Voice Codecs Offered
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)
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
Media negotiation for Voice calls – The SDP OfferSDP Media Attributes - Audio Direction and DTMF
Audio Directiona=sendrecv Media can be sent by this endpoint, media can be received on this endpointa=recvonly Media can only be received on this endpoint, it will not send mediaa=sendonly Media can only be sent by this endpoint, it will not receive mediaa=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
Attribute Description Attribute Content Comments
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)
SIP Trunk Signaling - Media negotiation Voice calls : The SDP AnswerAttribute Description Attribute Content Comments
v= Version 0 Phone’s IP Address
o= Origin CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.251
10.10.199.251 = CUCM IP Address
s= Session Name SIP Call
c= Connection Data IN IP4 10.10.199.179 Phone’s IP Address
t= Timing 0 0 Permanent Session
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 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 )
SIP Trunk SignalingMedia negotiation Voice calls – The Negotiated Session
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.251c=IN IP4 10.10.199.179m=audio 28668 RTP/AVP 18 101a=rtpmap:18 G729/8000a=ptime:20a=sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.10.199.250c=IN IP4 10.10.199.130m=audio 16444 RTP/AVP 18 101a=rtpmap:18 G729/8000a=ptime:20a=sendrecva=rtpmap:101 telephone-event/8000a=fmtp:101 0-15
10.10.199.25110.10.199.250
10.10.199.179RTP UDP Port 28668
G.729 codecTwo way AudioRFC 2833 DTMF
10.10.199.130RTP UDP Port 16444 G.729 codecTwo way AudioRFC 2833 DTMF
Deep down into SDP
Media negotiation for Video calls
Summarized slides - See Appendix for Detailed slides
SIP Trunk SignalingVideo 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 SignalingVoice and Video call with BFCP and FECC
Audio
Main Video
Slide Video
Binary Floor Control
Far End Camera Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk Signaling - Video calls SDP Offer – Abridged – Showing Video detailsv=0o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6s=SIP Callb=TIAS:6000000t=0 0
m=video 16446 RTP/AVP 98 99c=IN IP4 10.58.9.86b=TIAS:6000000
a=rtpmap:98 H264/90000a=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/90000a=fmtp:99 QCIF=1;CIF=1;CIF4=1;CUSTOM=352,240,1
a=rtcp-fb:* nack plia=rtcp-fb:* ccm tmmbr
SDP Session attributes
SDP Media Attributes
Only Video related lines are shown here (See Appendix for full SDP Offer)
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 receive capabilities
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= Attribute rtpmap:99 H263-1998/90000 H.263 Video Codec
a= H.263 Video Codec receive capabilities
fmtp:99 QCIF=1; CIF=1; CIF4=1; CUSTOM=352,240,1
a= Attribute rtcp-fb:* nack pli RTCP Feedback – Packet Loss
a= Attribute rtcp-fb:* ccm tmmbr RTCP Feedback – Max Bit Rate
SIP Trunk Signaling - Video calls SDP Offer – Media Attributes for Video
SIP Trunk Signaling - SDP OfferH.264 and H.263 Video Codec details
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 in video quality and bandwidth utilisation when compared with H.263 video.
The Codecs (formats) in the Offer must be listed in preference order. H.264 preferred over H.263
Attribute Description Attribute Content Comments
m= Media Descriptions video 16446 RTP/AVP 98 99 Media/Port#/Protocol/ RTP Payload Types Codec Preference order : H.264, H.263
a= Attribute rtpmap:98 H264/90000 H.264 Video Codec
a= H.264 Video Codec receive capabilities
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= Attribute rtpmap:99 H263-1998/90000 H.263 Video Codec
a= H.263 Video Codec receive capabilities
fmtp:99 QCIF=1; CIF=1; CIF4=1; CUSTOM=352,240,1
SIP Trunk Signaling - SDP Offer H.264 Video Codec Receive Capabilities - Detail
H.624 Codec Parameter Description/ Comments
profile-level-id=428016 The Profile-Level-ID describes the minimum set of features/ capabilities that are supported by this endpoint :
Profile ID : 4280XX = Baseline Video Profile
Level ID : XXXX16 = Level 2.2 = Resolution = 352 x 480 pixels, Frame Rate = 30 fps
The following parameters describe the capabilities beyond those of the profile-level-id supported by this endpoint
packetization-mode=1 1 = Multiple video samples (in decoding order) per RTP packet, Fragments allowed
max-mbps=245000 Max Decoding speed = Max Macroblocks/sec = 245000 (Level 2.2 value = 20250)
max-fs=9000 Max Frame Size = 9000 Macroblocks (Baseline profile level 2.2 value = 1620)
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/Second in 1/100s of a frame/second = 60 fps (Level 2.2 value = 30 fps)
SIP Trunk Signaling – SDP Offer H.264 Video Codec – RTP Control Protocol (RTCP)
RTCP can be used for video rate adaption when congestion/ packet loss encountered
RTCP Attribute Description/ Comments
a=rtcp-fb:* nack pli rtcp-fb - RTP Control Protocol (RTCP) - Feedback* - RTCP-Feedback for any of the offered video codecsNACK - Negative Acknowledgement - indicates the loss of one or more RTP packetsPLI - Picture Loss Indication
a=rtcp-fb:* ccm tmmbr rtcp-fb - RTP Control Protocol (RTCP) - Feedback* - RTCP-Feedback for any of the offered video codecsccm - Indicates support of codec control using RTCP feedback messagestmmbr - Temporary Maximum Media Stream Bit Rate - Request/Notification
SIP Trunk Signaling - Video callsSDP Answer – Abridged – Showing Video detailsv=0o=CiscoSystemsCCM-SIP 112480 1 IN IP4 10.58.9.44s=SIP Callb=TIAS:6000000t=0 0
m=video 2348 RTP/AVP 98c=IN IP4 10.58.9.222b=TIAS:5936000
a=rtpmap:98 H264/90000a=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 plia=rtcp-fb:* ccm tmmbra=sendrecv
SDP Session attributes
SDP Media Attributes
H.264 video codec selected
H.264 video attributes and capabilities do not have to be symmetric
Only Video related lines are shown here - See Appendix for full SDP Answer
SIP Trunk Signaling - H.264 Video Codec Offer/Answer H.264 Codec Capabilities Compared
H.624 Codec Parameter values in SDP Offer H.624 Codec Parameter values in SDP Answer
profile-level-id=428016 profile-level-id=428016
packetization-mode=1 packetization-mode=1
The Profile-Level-ID and Packetization-Mode values used by each device must be the same.Other values need not be the same as they reflect the receive capabilities of each device
max-mbps=245000 max-mbps=108000
max-fs=9000 max-fs=3600
max-cpb=200 max-cpb=200
max-br=5000 max-br=5000
max-rcmd-nalu-size=3456000 max-rcmd-nalu-size=1382400
max-smbps=245000 max-smbps=10800
max-fps=6000 max-fps=6000
SIP Trunk Signaling – Negotiated MediaVoice and Video call
Audio RTP UDP Port 2346 MP4A-LATM Audio codec
Bandwidth 64kbpsRFC 2833 DTMF
Audio RTP UDP Port 16444 MP4A-LATM Audio codec
Bandwidth 64kbpsRFC 2833 DTMF
Video RTP UDP Port 2348H.264 Video codec
Asymmetric Receive valuesBandwidth (6Mbps - 64kbps)
Video RTP UDP Port 16446H.264 Video codec
Asymmetric Receive valuesBandwidth 6Mbps
Audio
Video
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk Signaling – Negotiated MediaVoice and Video call with BFCP
Audio RTP UDP Port 2346 MP4A-LATM Audio codec
RFC 2833 DTMF
Audio RTP UDP Port 16444 MP4A-LATM Audio codec
RFC 2833 DTMF Audio
Video RTP UDP Port 2348H.264 Video codec
Asymmetric Receive values
Video RTP UDP Port 16446H.264 Video codec
Asymmetric Receive values Main Video
Video RTP UDP Port 2350 H.264 Video codec
Asymmetric Receive values
Video RTP UDP Port 16448 H.264 Video codec
Asymmetric Receive values Slide Video
BFCP UDP Port 5070 Conference 1 User 6
BFCP UDP Port 5070 Conference 1 User 8 Binary Floor Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk Signaling – Negotiated MediaVoice and Video call with BFCP & FECC
Audio RTP UDP Port 2346 MP4A-LATM Audio codec
RFC 2833 DTMF
Audio RTP UDP Port 16444 MP4A-LATM Audio codec
RFC 2833 DTMF Audio
Video RTP UDP Port 2348H.264 Video codec
Video RTP UDP Port 16446H.264 Video codec Main Video
Video RTP UDP Port 2350 H.264 Video codec
Video RTP UDP Port 16448 H.264 Video codec Slide Video
BFCP UDP Port 5070 BFCP UDP Port 5070 Binary Floor Control
FECC UDP Port 2352RTP Payload Type 107
FECC UDP Port 16450RTP Payload Type 107 Far End Camera Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
CUCM SIP Trunk features and SIP Trunk Call functions
SIP Messaging – Delayed and Early Offer - Recap
SIP Early Offer
SIP Delayed Offer
You can send SDP in 1XX messages, but without PRACK these messages are not acknowledged and SDP must be sent in the next reliable message/response
Two Way Media
INVITE with SDP (Offer)
200 OK with SDP (Answer)
ACK
180 Ringing
100 Trying
INVITE with SDP (Offer)
200 OK with SDP (Answer)
ACK
180 Ringing
100 TryingOne Way
Media
Two Way Media
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
CUCM SIP Trunk Signaling – SIP Early MediaUsing Provisional Acknowledgement (PRACK) - 1SIP defines two types of Responses: Final and Provisional. Final Responses convey the result of the processed request, and are sent reliably :- The receipt of the Response is acknowledged by the receiving UAProvisional Responses provide information on the progress of the request, but are not sent reliably -So the sender of a provisional response does know that it has been received.
To send an Offer or Answer in a provisional 1XX Response – The 1XX Response must be sent reliably PRACK – Provisional Reliable Acknowledgement is used to provide 1XX Responses with reliability.
Two Way Media
INVITE w/ SDP Supported:100rel
PRACK
200 OK (PRACK)
183 Progress w/ SDP Require:100rel
100 Trying
INVITE w/ SDP Supported:100rel
PRACK
200 OK (PRACK)
183 Progress w/ SDP Require:100rel
100 Trying
Early Offer == Early MediaEarly Offer with Early Media
CUCM SIP Trunk Signaling – SIP Early MediaUsing Provisional Acknowledgement (PRACK) - 2 Like Final Responses, by using PRACK - 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”
Two Way Media
INVITE Supported:100rel
PRACK w/ SDP
200 OK (PRACK)
183 Progress w/ SDP Require:100rel
100 Trying
INVITE Supported:100rel
PRACK w/ SDP
200 OK (PRACK)
183 Progress w/ SDP Require:100rel
100 Trying
Delayed Offer with Early Media
CUCM SIP Trunk SignalingInbound Delayed Offer to Outbound Early Offer calls
So what happens when Unified CM receives an inbound Delayed Offer call on a SIP Trunk and needs to onward route the call over a Early Offer SIP Trunk ?
The outbound SIP Trunk does not have the calling device’s media characteristics and it needs to send an Offer in SDP with the outbound INVITE…
Solution – Insert a Media Termination Point (MTP) and use its media characteristics to create the Offer in SDP with the outbound INVITE
Two Way Media
INVITE
200 OK w/ SDP (Offer)
ACK w/ SDP (Answer)
180 Ringing
100 Trying
INVITE w/ SDP (MTP)
200 OK w/ SDP (Answer)
ACK
180 Ringing
100 Trying
SIP Delayed Offer SIP Early Offer
MTP
CUCM SIP Trunk SignalingEnabling SIP Early Offer – “MTP Required” – Pre UC 8.5
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.
Using the “MTP Required” option :
MTP Recommendation – Always use IOS MTPs
CUCM based MTPs do not have feature parity with software and hardware based IOS MTPs
SIP Trunk with Early OfferSIP LineMTP
MTPSCCP Line SIP Trunk with Early Offer
SIP Trunk SIP Trunk with Early OfferMTP
H323 Trunk SIP Trunk with Early OfferMTP
MGCP Trunk SIP Trunk with Early OfferMTP
For Calls from trunks and devices that canprovide their IP Address, UDP port number and supported codecs - This information is sent in the SDP body of the initial SIP Invite on the outbound Early Offer Trunk. No MTP is used for the Early Offer
For Calls from trunks and devices that cannotprovide Early Offer information – use the calling device’s MTP resources (first) or the outbound trunk’s MTPs (second) to create a SIP Offer for an unencrypted voice call. (SRTP and video can subsequently be initiated by the called device)
CUCM SIP Trunk SignalingEnabling SIP Early Offer – Method 2 – UC 8.5+SIP Profile “Early Offer support for voice and video calls (insert MTP if needed)”
SIP Trunk with Early OfferSIP Line
Cisco SIP Phones
SIP Trunk SIP Trunk with Early Offer
SIP Delayed Offer
MTP
H323 Trunk SIP Trunk with Early Offer
H323 Slow Start
MTP
H323 Trunk SIP Trunk with Early Offer
H323 Fast Start
MGCP Trunk SIP Trunk with Early Offer
MGCP Gateway
SIP Trunk SIP Trunk with Early Offer
SIP Early Offer
SCCP Line SIP Trunk with Early Offer
Newer SCCP Phones
SCCP Line SIP Trunk with Early Offer
Older SCCP Phones
MTP
Benefits of “Early Offer support for voice and video calls (insert MTP if needed)” • Reduced MTP usage• Single voice codec MTP limitation removed (by using the pass through codec (IOS MTPs only)• Voice codecs sent in SIP Offer based on calling device capabilities & region settings• Use the Calling device’s MTP rather than Trunk’s MTP - Media does not hairpin through the Trunk’s MTP
CUCM SIP Trunk SignalingEnabling SIP Early Offer – Method 2 – Benefits
SIP Trunk with Early OfferSIP Line
Cisco SIP Phones
SIP Trunk SIP Trunk with Early Offer
SIP Early Offer
SCCP Line SIP Trunk with Early Offer
Newer SCCP Phones
SCCP Line SIP Trunk with Early Offer
Older SCCP Phones
MTP
SIP Trunk SIP Trunk with Early Offer
SIP Delayed Offer
MTP
H323 Trunk SIP Trunk with Early Offer
H323 Slow Start
MTP
H323 Trunk SIP Trunk with Early Offer
H323 Fast Start
MGCP Trunk SIP Trunk with Early Offer
MGCP Gateway
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
SCCP Line
SCCP Line
SIP Trunk
H323 Trunk
MGCP Trunk
SIP Line Best Effort Early Offer SIP Trunk
H323 Trunk
SIP Trunk
Cisco SIP Phones
Newer SCCP Phones
Older SCCP Phones
SIP Delayed Offer
H323 Slow Start
MGCP Gateway
H323 Fast Start
SIP Early Offer
Best Effort Early Offer SIP Trunk
Best Effort Early Offer SIP Trunk
Best Effort Early Offer SIP Trunk
Best Effort Early Offer SIP Trunk
Best Effort Early Offer SIP Trunk
Best Effort Early Offer SIP Trunk
Best Effort Early Offer SIP Trunk
Early Offer sent
Early Offer sent
Delayed Offer sent
Delayed Offer sent
Delayed Offer sent
Early Offer sent
Early Offer sent
Early Offer sent
Best Effort Early Offer
SME clusters with no Media Resources
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 clusterThis 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 BRKUCC-2450)
Leaf Cluster
New York
SME
Cluster
Leaf Cluster
Los Angeles
Leaf Cluster
Europe
Media Resources
Media Resources
Media Resources
Media Resources
Leaf Cluster SIP ICT Trunks - Voice, Video and Encryption supportedSIP Delayed Offer/Early Offer (insert MTP if Needed), Run on All Nodes, Multiple Destination Addresses, OPTIONS PingSME Cluster SIP ICT Trunks - Voice, Video and Encryption supportedSIP MTP-less Early Offer, Run on All Nodes, Multiple Destination Addresses, OPTIONS Ping, No Media resources can be assigned to TrunksCUBE/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, Early Offer usually required by Service Providers (Use CUBE SIP DO to EO)
SIP Trunk Design Recommendations – UC versions pre 10.5
IP PSTN
CUCM 8.5+ SME
CUCM 8.5+
CUCM 8.5+
SIP TrunkCUBE SIP DO to EOSIP Delayed/Early Offer
SIP Early Offer
SIP MTP-less Early Offer
Leaf Cluster SIP ICT Trunks - Voice, Video and Encryption supportedSIP Best Effort Early Offer, Run on All Nodes, Multiple Destination Addresses, OPTIONS PingSME Cluster SIP ICT Trunks - Voice, Video and Encryption supportedSIP Best Effort Early Offer, Run on All Nodes, Multiple Destination Addresses, OPTIONS Ping, Media resources not requiredCUBE/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, Early Offer usually required by Service Providers (Use CUBE SIP DO to EO)
SIP Trunk Design Recommendations – UC versions 10.5+
IP PSTN
CUCM 10.5+ SME
CUCM 10.5+
CUCM 10.5+
SIP TrunkCUBE SIP DO to EOSIP Delayed/Early Offer
SIP Early Offer
SIP Best Effort Early Offer
CUCM SIP Trunk Call functions Hold/Resume
“HOLD”
CUCM SIP Trunk Signaling and Operation Hold/Resume Signaling - Hold
Call In Progress - Two Way Media
SIP Trunk
INVITE with SDP
(a=sendonly)
200 OK with SDP
(a=recvonly)
ACK
INVITE with SDP
(a=inactive)
200 OK with SDP
(a=inactive)
ACK
INVITE with SDP
(a=inactive)
200 OK with SDP
(a=inactive)
ACK
Note – CUCM SIP Trunks also send c= IN IP4 0.0.0.0 in SDP
(Older RFC 2543 Hold method)
“RESUME”
CUCM SIP Trunk Signaling and Operation Hold/Resume Signaling - Resume
Call Resumes - Two Way Media
SIP Trunk
INVITE with SDP
(a=sendrecv)
200 OK w/ SDP
(a=sendrecv)
ACK
INVITE without SDP
200 OK with SDP
(a=sendrecv)
ACK with SDP
(a=sendrecv)
INVITE without SDP
200 OK with SDP
(a=sendrecv)
ACKwith SDP
(a=sendrecv)
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 functionsSend “Send Receive” in mid call
INVITE
“HOLD”
CUCM SIP Trunk Interop Feature – The issue (1)“Send send-receive SDP in mid-call INVITE”
Call In Progress - Two Way Media
SIP Trunk
INVITE with SDP
(a=sendonly)
200 OK with SDP
(a=recvonly)
ACK
INVITE with SDP
(a=inactive)
200 OK with SDP
(a=inactive)
ACK
INVITE with SDP
(a=inactive)
200 OK with SDP
(a=inactive)
ACK
Used to address a=inactive issues with 3rd Party systems
( Issue not widely found - typically with some Service Providers)
“RESUME”
CUCM SIP Trunk Interop Feature – The issue (2)“Send send-receive SDP in mid-call INVITE”
3rd Party UC system returns last known value “a=inactive” – Media not resumed
SIP Trunk
INVITE with SDP
(a=sendrecv)
200 OK w/ SDP
(a=INACTIVE)
ACK
INVITE without SDP
200 OK with SDP
(a=INACTIVE)
ACK with SDP
(a=inactive)
INVITE without SDP
200 OK with SDP
(a=INACTIVE)
ACKwith SDP
(a=inactive)
Some 3rd Party UC systems return a=inactive in response to a mid call INVITE without SDP
Effect - Media cannot be re-established on Resume
“HOLD”
CUCM SIP Trunk Interop Feature – The Fix (1)“Send send-receive SDP in mid-call INVITE” – Enabled
Call In Progress - Two Way Media
SIP Trunk
INVITE with SDP
(a=sendonly)
200 OK with SDP
(a=recvonly)
ACK
INVITE with SDP
(a=sendrecv)
200 OK with SDP
(a=sendrecv)
ACK
INVITE with SDP
(a=sendrecv)
200 OK with SDP
(a=sendrecv)
ACK
When the mid-call INVITE is sent – CUCM inserts an MTP which anchors the media to the held device and allows the holding device to disconnect its media (and optionally insert MOH)
MTP
“RESUME”
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)
ACK
INVITE without SDP
200 OK with SDP
(a=sendrecv)
ACK with SDP
(a=sendrecv)
INVITE without SDP
200 OK with SDP
(a=sendrecv)
ACKwith SDP
(a=sendrecv)
MTP
CUCM SIP Trunk Call functions Transfer
CUCM SIP Trunk Signaling and Operation Transfer – Call in Progress – Hold Initiated
“Transfer”
Initiate HOLD
HOLD Complete
SIP TrunkInitiate HOLD
HOLD Complete
RTP
CUCM SIP Trunk Signaling and Operation Transfer – Call Transfer Target
Initiate HOLD
HOLD Complete
SIP TrunkInitiate HOLD
HOLD Complete
Initiate 2nd Call
Call Complete
Initiate 2nd Call
Call Complete
Initiate 2nd Call
Call Complete
Dial 2nd Number
CUCM SIP Trunk Signaling and Operation Transfer – Completing the Transfer
Initiate HOLD
HOLD Complete
SIP TrunkInitiate HOLD
HOLD Complete
Initiate 2nd Call
Call Complete
Initiate 2nd Call
Call Complete
Initiate 2nd Call
Call CompleteTransfer
INVITE
REFER
RTP
Note – CUCM consumes REFER from Phone and sends Re-INVITEsto maintain control of call signalling
INVITE
200 OK with SDP
ACK with SDP
100 Trying
INVITE
200 OK with SDP
ACK with SDP
100 Trying
INVITE/100INVITE/100/200INVITE/100/200/ACK
202 ACCEPTED
NOTIFY (REFER active)
BYE
NOTIFY (REFER Term.)
CUCM SIP Trunk Signaling Operation SIP Messaging – Transfer – REFER Transparency
SIP Trunk
REFER
Refer To 2000Referred By CVP
REFER Transparency supported for SIP Trunk to SIP Trunk calls only – REFER Passthrough LUA Script
CUCM/SME relinquishes control of call, dropping out of the signalling path
1000
2000
RTP
REFER
Refer To 2000Referred By CVP
202 ACCEPTED202 ACCEPTED
NOTIFY (REFER active)NOTIFY (REFER active)
BYEBYE
INVITE
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
INVITE
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
CVP
SIP Trunk
NOTIFY (REFER Term.)NOTIFY (REFER Term.)
CUCM SIP Trunk Call Features explained
CUCM SIP Trunk FeaturesRequire SDP Inactive Exchange for Mid-Call Media Change
Not related to mid call/hold resume…..
SIP allows media changes to be made to an existing session without breaking the media stream e.g. codec changes, IP address, UDP port number changes
Some SIP devices are not capable of reacting to media changes without disconnecting the established media channel first.
Unchecked by default – If checked, CUCM Trunk sends a=inactive in the SDP body of mid-call INVITES to break the media channel, before making media changes.
Note - For Early Offer enabled SIP trunks, this parameter will be overridden by the “Send send-receive SDP in mid-call INVITE” parameter
CUCM SIP Trunk Signaling and Operation The Offer/Answer model - Ringback
Two Way Media
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
INVITE
200 OK with SDP (Offer)
ACK with SDP (Answer)
180 Ringing
100 Trying
INVITE Supported:100rel
200 OK with SDP (Answer)
200 OK (PRACK)
183 Progress w/ SDP Require:100rel
100 Trying
PRACK w/ SDP(Answer)
200 OK (PRACK)
183 Progress w/ SDP Require:100rel
100 Trying
SIP allows SDP to be optionally sent in 18X messages (MUST BE WITH PRACK)
Media Established - Ringback
Caller hears locally
generated ringback
tone
Caller hears ringbacktone from called UC
system
INVITE Supported:100rel
CUCM SIP Trunk FeaturesSIP Profile settings - Disable Early Media on 180
By default, Cisco Unified Communications Manager signals the calling phone to play local ringback if SDP is not received in the 180 or 183 response.
If SDP is included in the 180 or 183 response, instead of playing ringback locally, Cisco Unified Communications Manager connects media, and the calling phone plays whatever the called device is sending (such as ringback or busy signal).
If ringback is not received, the device to which you are connecting may be including SDP in the 180 response, but it is not sending any media before the 200 OK response. In this case, check this check box to play local ringback on the calling phone and connect the media upon receipt of the 200 OK response
CUCM SIP Trunk FeaturesSIP Profile settings - Redirect by Application
Redirect by Application – Default setting = unchecked
When checked allows CUCM to apply digit analysis to the redirected contact number to :
a) Make sure that the call gets routed correctly
b) Apply a specific Calling Search Space for Calls of Service/ Call Restriction
c) Prevent DOS attack by limiting the number of redirections
d) Allow other features to be invoked while the redirection is taking place
When unchecked (default) the redirection gets handled at the SIP stack level and the
above features cannot be invoked
CUCM SIP Trunk FeaturesRedirect by Application – Disabled (Default setting)
SIP Trunk
INVITE (1000)1000
+15551230000
INVITE (1000)
302 Temporarily Moved
(+15551230000)
INVITE (+15551230000)
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
SIP
INVITE (+15551230000)
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
Call Forward
All
RTP
CUCM SIP Trunk FeaturesRedirect by Application – Enabled – Call Allowed
SIP Trunk
INVITE (1000)
2000
INVITE (1000)
302 Temporarily Moved
2000
INVITE (2000)
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
SIP
INVITE (2000)
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
200 OK with SDP
ACK with SDP
180 Ringing
100 Trying
RTP
1000
Call Forward
AllApply
CCS
CUCM SIP Trunk FeaturesRedirect by Application – Enabled – Call Blocked
SIP Trunk
INVITE (1000) INVITE (1000)
302 Temporarily Moved
(+15551230000)
CANCEL
SIP
CANCELCANCEL
1000
Call Forward
All
Apply
CCS
+15551230000
SIP Trunk 2SIP Trunk 1
Cluster 1 Cluster 2 Cluster 1 Cluster 2
Matching inbound SIP calls to configured SIP Trunks
A
B
C
D
E
F
G
H
A
B
C
D
E
F
G
H
Cluster 1 – SIP Trunk 1 Configuration
SIP Trunk 1 has an active SIP
daemon on servers A, B, C, D and E
Cluster 2 servers F, G and H are
defined as Trunk destinations
Cluster 2 – SIP Trunk 2 Configuration
SIP Trunk 2 has an active SIP
daemon on servers F, G and H
Cluster 1 servers A, B, C, D and E are
defined as Trunk destinations
CUCM 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
CUCM SIP Trunk FeaturesSIP Profile settings – Reroute request based on
Reroute Incoming Request to New Trunk based on :
Never (Default) - Match inbound call to SIP Trunk based on IP address and port number
Contact header - Match inbound call based on IP address and port number – but re-route the call to another SIP Trunk based on the IP address and port number received in the contact header
- Can be used to reroute calls from a SIP Proxy to an end user/system specific CUCM SIP Trunk
Call-Info Header with purpose=x-cisco-origIP
- Used to match inbound calls from CVP to a specific Trunk based on the IP address and port number contained in the Call-Info header – parameter “purpose=x-cisco-origIP” (Used for CAC)
Complete Your Online Session Evaluation
Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online
• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.
• Complete your session surveys though the Cisco Live mobile app or your computer on Cisco Live Connect.
Continue Your Education
• Demos in the Cisco campus
• Walk-in Self-Paced Labs
• Table Topics
• Meet the Engineer 1:1 meetings
• Related sessions
Collaboration Cisco Education OfferingsCourse Description Cisco Certification
CCIE Collaboration Advanced Workshop (CIEC) Gain expert-level skills to integrate, configure, and troubleshoot complex
collaboration networks
CCIE® Collaboration
Implementing Cisco Collaboration Applications
(CAPPS)
Understand how to implement the full suite of Cisco collaboration
applications including Jabber, Cisco Unified IM and Presence, and Cisco
Unity Connection.
CCNP® Collaboration
Implementing Cisco IP Telephony and Video
Part 1 (CIPTV1)
Implementing Cisco IP Telephony and Video
Part 2 (CIPTV2)
Troubleshooting Cisco IP Telephony and Video
(CTCOLLAB)
Learn how to implement Cisco Unified Communications Manager, CUBE,
and audio and videoconferences in a single-site voice and video network.
Obtain the skills to implement Cisco Unified Communications Manager in a
modern, multisite collaboration environment.
Troubleshoot complex integrated voice and video infrastructures
CCNP® Collaboration
Implementing Cisco Collaboration Devices
(CICD)
Implementing Cisco Video Network Devices
(CIVND)
Acquire a basic understanding of collaboration technologies like Cisco Call
Manager and Cisco Unified Communications Manager.
Learn how to evaluate requirements for video deployments, and implement
Cisco Collaboration endpoints in converged Cisco infrastructures.
CCNA® Collaboration
For more details, please visit: http://learningnetwork.cisco.com
Questions? Visit the Learning@Cisco Booth or contact [email protected]
Thank you
Appendix
Deep down into SDP
Media negotiation for Video calls
SIP Trunk SignalingVideo 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 SignalingVoice and Video call with BFCP and FECC
Audio
Main Video
Slide Video
Binary Floor Control
Far End Camera Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk SignalingVoice and Video call - Main video channel negotiation
Audio
Video
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk SignalingVideo calls – SDP Offer – Detail - Videov=0
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
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 SignalingVideo calls – SDP Offer – Bandwidth attribute
Session Level
Media Level
v=0
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
s=SIP Call
b=TIAS:6000000
b=AS:6000t=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
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
SIP Trunk SignalingBandwidth 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 SignalingBandwidth attribute - CUCM Related Configuration
Session Level Bandwidth value (kbps)
Region Configuration - Maximum Session Bite Rate for Video Calls
The Maximum Session Bit Rate for video calls limits media bandwidth for the call – If the endpoint sends a lower value this will be used in SDP
SIP Trunk SignalingVideo calls – SDP Offer – Bandwidth in this Offero=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
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
….attributes of multiple audio codecs in the offer
…
m=video 16446 RTP/AVP 98 99
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
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
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
The Codecs (formats) in the Offer must be listed in preference order. H.264 preferred over H.263
SIP Trunk SignalingVideo calls – SDP Offer – Detail - Video Codecs…
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 (= 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.
The Codecs (formats) in the Offer must be listed in preference order. H.264 preferred over H.263
SIP Trunk SignalingVideo 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
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 Profile-Level-ID describes the minimum set of features/ capabilities that are supported by this endpoint
These parameters describe the features and capabilities beyond those of the profile-level-id that are supported by this endpoint
SIP Trunk Signaling – H.264 Video calls The 1st four digits of the Profile level ID – The Profile
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 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
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 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 SignalingVideo 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-
cpb=200;max-br=5000;max-rcmd-nalu-size=3456000;max-smbps=245000;max-fps=6000
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 SignalingVideo calls – SDP Offer – H.264 Video Codec – Detail 2a=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 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 SignalingVideo calls – SDP Offer – H.264 Video Codec - RTCP…
m=video 16446 RTP/AVP 98 99
…
…
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 SignalingVideo calls – SDP Answer – Detail = Video Onlyv=0
o=CiscoSystemsCCM-SIP 112480 1 IN IP4 10.58.9.44
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=rtcp-fb:* ccm tmmbr
a=sendrecv
SIP Trunk Signaling H.264 Video Codec - Offer/Answer Compared
Offer H.264 and H.263 Offereda=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
Answer H.264 selected – Symmetric Attributes - Asymmetric attributesa=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 MediaVoice and Video call
Audio RTP UDP Port 2346 MP4A-LATM Audio codec
Bandwidth 64kbpsRFC 2833 DTMF
Audio RTP UDP Port 16444 MP4A-LATM Audio codec
Bandwidth 64kbpsRFC 2833 DTMF
Video RTP UDP Port 2348H.264 Video codec
Asymmetric Receive valuesBandwidth (6Mbps - 64kbps)
Video RTP UDP Port 16446H.264 Video codec
Asymmetric Receive valuesBandwidth 6Mbps
Audio
Video
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk SignalingVideo 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 NegotiationVoice and Video call with BFCP
Audio
Main Video
Slide Video
Binary Floor Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk SignalingVideo calls – SDP Offer part 1: Detail = BFCP onlyv=0
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
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
….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
….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 SignalingVideo calls – SDP Offer part 2: Detail = BFCPm=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=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=label:12 Label 12 used to identify Slides Video Stream
a=content:slides Content :Slides (desktop presentation) Video Stream
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr
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 SignalingVideo calls – SDP Answer part 1: Detail = BFCP Onlyv=0
o=CiscoSystemsCCM-SIP 112480 1 IN IP4 10.58.9.44
s=SIP Call
b=TIAS:6000000
b=AS:6000 Note - Session Bandwidth value = 6 Mbps total
t=0 0
m=audio 2346 RTP/AVP 102 101
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 SignalingVideo calls – SDP Answer part 2 : Detail = BFCP Onlym=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=fmtp:98 profile-level-id=428016;packetization-mode=1;max-mbps=108000;max-fs=3840;max-cpb=200;
max-br=5000;max-rcmd-nalu-size=1474560;max-smbps=108000;max-fps=6000
a=content:slides Content :Slides (desktop presentation) Video Stream
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr
m=application 5070 UDP/BFCP *
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
SIP Trunk Signaling – Negotiated MediaVoice and Video call with BFCP
Audio RTP UDP Port 2346 MP4A-LATM Audio codec
RFC 2833 DTMF
Audio RTP UDP Port 16444 MP4A-LATM Audio codec
RFC 2833 DTMF Audio
Video RTP UDP Port 2348H.264 Video codec
Asymmetric Receive values
Video RTP UDP Port 16446H.264 Video codec
Asymmetric Receive values Main Video
Video RTP UDP Port 2350 H.264 Video codec
Asymmetric Receive values
Video RTP UDP Port 16448 H.264 Video codec
Asymmetric Receive values Slide Video
BFCP UDP Port 5070 Conference 1 User 6
BFCP UDP Port 5070 Conference 1 User 8 Binary Floor Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk SignalingVideo 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 SignalingVideo calls – SDP Offer : Detail = FECC onlyv=0
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
….
m=audio 16444 RTP/AVP 102 103 104 9 105 106 0 8 101
….attributes of multiple audio codecs in the offer
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
m=application 5070 UDP/BFCP *
…..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 SignalingVideo calls – SDP Answer : Detail = FECC Onlyv=0
o=CiscoSystemsCCM-SIP 112480 1 IN IP4 10.58.9.44
….
m=audio 2346 RTP/AVP 102 101
…. Attributes of selected audio codec and DTMF RFC2388
m=video 2348 RTP/AVP 98
…. Attributes of selected main video codec and RTCP functions
m=video 2350 RTP/AVP 98
…. Attributes of selected BFCP slides video codec and RTCP functions
m=application 5070 UDP/BFCP *
…. 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
SIP Trunk Signaling – Negotiated MediaVoice and Video call with BFCP & FECC
Audio RTP UDP Port 2346 MP4A-LATM Audio codec
RFC 2833 DTMF
Audio RTP UDP Port 16444 MP4A-LATM Audio codec
RFC 2833 DTMF Audio
Video RTP UDP Port 2348H.264 Video codec
Video RTP UDP Port 16446H.264 Video codec Main Video
Video RTP UDP Port 2350 H.264 Video codec
Video RTP UDP Port 16448 H.264 Video codec Slide Video
BFCP UDP Port 5070 BFCP UDP Port 5070 Binary Floor Control
FECC UDP Port 2352RTP Payload Type 107
FECC UDP Port 16450RTP Payload Type 107 Far End Camera Control
10.58.9.86 10.58.9.222
10.10.199.25110.10.199.250
SIP Trunk Signaling – Video CallComplete SDP Offer : Voice, Video, BFCP and FECC
v=0
o=CiscoSystemsCCM-SIP 161095 1 IN IP4 10.58.9.6
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:103 MP4A-LATM/90000
a=fmtp:103 bitrate=56000;profile-level-id=24;object=23
a=rtpmap:104 MP4A-LATM/90000
a=fmtp:104 bitrate=48000;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
a=ptime:20
SIP Trunk Signaling – Video CallComplete SDP Answer : Voice, Video, BFCP and FECCv=0
o=CiscoSystemsCCM-SIP 112480 1 IN IP4 10.58.9.44
s=SIP Call
b=TIAS:6000000
b=AS:6000
t=0 0
m=audio 2346 RTP/AVP 102 101
c=IN IP4 10.58.9.222
b=TIAS:64000
a=rtpmap:102 MP4A-LATM/90000
a=fmtp:102 bitrate=64000;profile-level-id=24;object=23
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
m=video 2348 RTP/AVP 98
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
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm tmmbr
m=video 2350 RTP/AVP 98
c=IN IP4 10.58.9.222
b=TIAS:5936000
a=label:12