SIP Tutorial
Pablo Leiva
Cisco Unified Communications Manager
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
1
• SIP Overview
• CUCM SIP Architecture
• SIP Clients & Servers
• SIP Dial Rules
• SIP Requests & Responses
• SIP URI Dialing
• SIP Headers Fields
• SIP normalization
• SDP
• CUBE
• Basic SIP Call
• SIP Troubleshooting
• Media Negotiation
• DTMF relay over SIP
• SIP Call Flows
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
2
SIP Overview
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
3
• SIP
(Session Initiation Protocol) is a generic session
establishment protocol (signaling protocol used to establish,
manage and terminate sessions over an IP network)
• IETF standard
• ASCII-based messages (human readable)
• SIP is extensible (unrecognized headers are ignored)
• Peer to peer architecture
• Intelligent network elements - endpoints or User Agents
• UA Clients send requests to UA Servers
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
4
• SIP uses port 5060 (UDP or TCP)
• CUCM default settings on SIP Trunk Security Profile:
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
5
SIP-URI (Uniform Resource Identifier)
sip: user-info @ host ; uri-parameters
• User-info: SIP Endpoint identification (number or name)
• Host part: Hostname/IPv4 address/IPv6 address
• URI parameters:


transport = udp/tcp/tls
user=phone
Example:
alice@mydomain.com;user=phone
|
|
|
User
Host
Parameters
alice@1.1.1.1;user=phone; transport=tcp
 9193926009@1.1.1.2; transport=udp
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
6
• Dialog (formerly called ‘call leg’) - A peer-to-peer SIP relationship
between two UAs that persists for some time. It is identified by a
common Call-ID, From-Tag, and To-Tag. The From-Tag is added
in the first request and the To-Tag added in the first response
• Transaction - A SIP request (also called method message) and its
response(s). Most transactions have only a final response.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
7
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
8
• Cseq: The CSeq header field is an identifier which serves to
match the request and responses of an active transaction. It is
formed of a method name which must match that of the request,
and a sequence number which can start at an arbitrary value. The
responses to a request are required to have a CSeq header
identical to the CSeq header of the request.
• Each client is required to increase the CSeq number by one for
each request they send during a dialog (except for ACK and
CANCEL requests, where the sequence number is used to
identify the target of the action requested).
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
9
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
10
SIP Clients & Servers
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
11
• SIP Clients
 SIP User Agents (UAC & UAS)
 SIP Back-to-Back User Agents (B2BUA)
 SIP Gateways
• SIP Servers
 Proxy Servers
 Redirect Servers
 Registration (Registrar) Servers
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
12
SIP User Agents
• A SIP-enabled end-device is called a SIP user agent
 Endpoints – IP phones, Soft phones…
• A SIP user agent contains both a client application and a server
application.
• User Agent Client (UAC) – originates SIP requests
• User Agent Server (UAS) – terminate SIP requests
• The UAC initiates requests while the UAS generates responses.
During a session, a user agent will usually operate as both a UAC
and a UAS.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
13
SIP B2BUA
• A back-to-back user agent (B2BUA) is a type of SIP device that
receives a SIP request, then reformulates the request and sends
it out as a new request.
• Responses to the request are also reformulated and sent back in
the opposite direction.
• The relayed media suffers from increased latency and increased
probability of packet loss, which can reduce the quality of the
media session.
• UCM, CUBE and CVP are B2BUA
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
14
SIP B2BUA
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
15
SIP gateways
• A SIP gateway is an application that interfaces a SIP network to a
network utilizing another signaling protocol.
• In terms of the SIP protocol, a gateway is just a special type of
user agent, where the user agent acts on behalf of another
protocol rather than a human
• From the UCM perspective, a SIP trunk is used to reach both a
B2BUA or a SIP gateway.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
16
SIP gateways
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
17
SIP proxy
• An optional SIP component
• A SIP proxy server receives a SIP request from a user agent or
another proxy and acts on behalf of the user agent in forwarding
or responding to the request.
• A proxy is not a B2BUA since it is only allowed to modify requests
and responses according to strict rules. These rules preserve the
end-to-end transparency of the SIP signaling while still allowing a
proxy server to perform valuable services and functions for user
agents.
• A proxy does not need to understand a SIP request in order to
forward it.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
18
SIP proxy
• A proxy server does not issue requests; it only responds to
requests from a user agent. (CANCEL request is an exception)
• A proxy server has no media capabilities.
• A proxy server does not parse message bodies; it relies
exclusively on header fields.
• SIP Proxy can use a database, Registrar Server, DNS SRV
queries or static routes to determine the location of the next-hop
of the message.
• SIP Proxies can insert a Record-Route header into an INVITE
message. This will ensure that the signaling for a CANCEL or
BYE will flow through the Proxy. This might be required for billing
or features to be activated.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
19
SIP proxy
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
20
SIP proxy
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
21
SIP proxy
• Cisco has two SIP proxy products:
 CUSP (Cisco Unified SIP Proxy)
 CUPS (Cisco Unified Presence Server)
For example: NME-CUSP-522
CUPS Admin >
Cisco Unified
Presence >
Proxy Server >
Static Routes
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
22
SIP redirect
• An optional SIP component
• A Redirect Server is a modified proxy server (both functionality
can reside on the same physical box) that responds to, but does
not forward requests.
• Like a proxy sever, a redirect server uses a database or location
service to look up a user. The location information, however, is
sent back to the caller in a redirection class response (3xx),
which, after the ACK, concludes the transaction.
• A Redirect Server expects the UAC that receives the 3xx Redirect
to handle the routing of the call on it’s own. The UAC can then
route the subsequent request directly to an end-point or through a
Proxy Server.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
23
SIP redirect
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
24
SIP registration (registrar)
• An optional SIP component
• Can be a separate box, or a process that resides on a Proxy or
Redirect server.
• A SIP registration server, also known as a registrar, accepts SIP
REGISTER requests; all other requests receive a 501 Not
Implemented response.
• The contact information from the request is then made available
to other SIP servers within the same administrative domain, such
as proxies and redirect servers.
• UCM functions as SIP registrar for SIP phones
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
25
SIP registration (registrar)
• Cisco SIP phone will receive configuration file from TFTP:
 CallManager group
 Device pool
 Softkeys
 Dialplan
 Line Configuration
 IP address of primary and secondary CUCM
 Each SIP phone is associated with a user ID
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
26
SIP registration (registrar)
• Cisco IP phones send a SIP Register message per DN configured
on the phone.
• SIP phones send the following information in its Register
message:
 DN=<number>
 AuthID=“name”
 MAC=<MACaddress>
• SIP phones need a line or DN configured to be able to register
with CUCM and also requires associated user.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
27
SIP registration (registrar)
• SIP phone sends Register message as keepalive to their primary
and secondary CCM’s
• Both primary and Secondary UCMs send back a 200 OK in
response to their message.
• Keepalive timer is configurable via service parameter (default is 2
minutes):
• Keepalives are not seen by default in CCM traces:
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
28
SIP registration (registrar)
• Third-party SIP phones will get 401 Unauthorized SIP message
with authorization challenge
Registrar server
Third-party SIP phones require digest challenge. From the thirdparty software or phone side, need to configure user ID same as
the extension. Or add digest to the user in CUCM and associate
user to phone. SIP phones need to have an extension to register.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
29
SIP Requests & Responses
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
30
• INVITE: request from a UAC to initiate a session
• ACK: confirms receipt of a final response
• BYE: sent by either side to end a session
• CANCEL: sent to end a call not yet connected
• UPDATE: Updates offer for not-yet-established sessions.
• REGISTER: UA registers with Registrar Server
• SUBSCRIBE: Used to request specific event notifications
• NOTIFY: notifies that an event has occurred
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
31
• REFER: the mechanism to initiate a session transfer
• INFO: a means of carrying “data” in a message body
• MESSAGE: the means of carrying “data” for instant messages.
• OPTIONS: sent to query capabilities outside of SDP
• PRACK: confirms receipt of a provisional response (1xx)
 Messages contain SIP Headers and Body.
 Body might be SDP, attachment, XML or other application type
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
32
• The INVITE method is used to establish media sessions between
user agents (similar to a Setup message in ISDN).
• A successful INVITE request establishes a dialog between the
two user agents, which continues until a BYE is sent by either
party to end the session
• A media session is considered established when the INVITE, 200
OK, and ACK messages have been exchanged between the UAC
and the UAS.
• A UAC that originates an INVITE to establish a dialog creates a
globally unique Call-ID that is used for the duration of the call.
• A CSeq count is initialized (which need not be set to 1) and
incremented for each new request for the same Call-ID.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
33
• A From tag is included in the INVITE, and the UAS includes a To
tag in any responses. The combination of the To tag, From tag,
and Call-ID is the unique identifier for the dialog.
• For any re-INVITE (or mid-call INVITE) used to change the
session characteristics or refresh the state of the dialog, the Cseq
is incremented so that a UAS can distinguish the re-INVITE from
a retransmission of the original INVITE.
• Mandatory Headers in an INVITE Request
∙ Call-ID
∙ Cseq
∙ From
∙ Max-Forwards
∙ Via
∙ Contact
© 2010 Cisco and/or its affiliates. All rights reserved.
∙ To
Cisco Confidential
34
SIP
Header
body
|AppInfo |//SIP/SIPUdp/: Incoming SIP UDP message size 1143 from 172.16.165.5:[55223]:
INVITE sip:23198@172.17.207.91:5060 SIP/2.0
Via: SIP/2.0/UDP 10.80.17.134:5060
Via: SIP/2.0/UDP 172.18.192.232:5060;branch=1FV1xhfvxGJOK9rWcKdAKOA
To: <sip:23198@172.18.192.232>
From: <sip:15691@10.80.17.134>;tag=a73kszlfl
Call-ID: c2943000-50405d-6af10a-382e3031@10.80.17.134
Min-SE: 1800
Shows
Minimum
Proxy
SDPtransport
body
Server
allowed
provides
that
protocol
value
wishes
media
(UDP
fortothe
or
CSeq: 100 INVITE
The
Sequence
Incoming
Calling
From-Tag
party
ornumber
outgoing
and
is included
originator
doesn’t
shows
by
need
URI
the
Every
remain
Method,
Indicates
TCP),
session
capabilities
SIP
size
on
SIP
method
expiration.
device
the
ofURI
ofthe
signaling
the
that
(Called
includes
packet,
endpoint
The
touches
path
number,
duration
remote
a body
after
(IP
this
Contact: sip:15691@10.80.17.134:5060
UAC;
address.
Call
direction
to
start
identifier
the
Any
To-Tag
with
of
the
new
for
value
will
message
this
requests
be
1.
SIP
Do
added
dialog
from
not
from
by
Expires: 180
the
address
packet
of
(application
IPthe
IP
INVITE
address/domain
address
session
adds
to terminate
Transaction
itself
type
and
is negotiated
SDP
toephemeral
the
&media,
SIP
and
must
Viaport)
size)
field.
using
RTP
add
confuse
the
UAS
UAS
UCM
inwith
the
will
perspective
first
response
go to
response
this code
URI
Content-Type: application/sdp
port
the
(dynamic)
itself
Session-Expires
and
to
supported
Record-Route
port
selected
codecs)
header
Content-Length: 219
User-Agent: Cisco IP Phone/ Rev. 1/ SIP enabled
Record-Route: <sip:23198@172.18.192.232:5060;maddr=172.18.192.232>
o=CiscoSystemsSIP-IPPhone-UserAgent 17045 11864 IN IP4 10.80.17.134
s=SIP Call
c=IN IP4 10.80.17.134
t=0 0
m=audio 29118 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
35
• CUCM 8.5 includes SIP OPTIONS as a keep-alive mechanism on
the SIP trunk.
• SIP OPTIONS method allows a SIP trunk to track the status of
remote destinations. CUCM does not attempt to set up new calls
to unreachable remote peers, which allows for quick failovers.
• Remote side needs to support OPTIONS (CUBE does). On
CUCM side, enable on SIP profile:
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
36
• The PRACK method is used to acknowledge receipt of reliably
transported provisional responses (1xx). The reliability of 2xx,
3xx, 4xx, 5xx, and 6xx responses to INVITEs is achieved using
the ACK method. However, in cases where a provisional
response, such as 180 Ringing or 183 Session Progress, is
critical in determining the call state, it may be necessary for the
receipt of a provisional response to be confirmed.
• The PRACK method applies to all provisional responses except
the 100 Trying response, which is never reliably transported.
SIP Profile
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
37
• CANCEL is used to terminate a pending session.
• BYE is used to terminate an established session.
• UPDATE is used to update information about a pending
session.
• Re-INVITE is used to update information for an established
session
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
38
• 1xx Provisional/Informational Responses – Indicates status of call
prior to completion
100 Trying – This special case response is only a hop-by-hop
request. It is never forwarded and may not contain a message
body. This response can be generated by either a proxy server or
a user agent. It only indicates that some kind of action is being
taken to process the call – it does not indicate that the user has
been located (similar to ISDN Proceeding)
180 Ringing – This response is used to indicate that the INVITE
has been received by the user agent and that alerting is taken
place (similar to ISDN Alerting)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
39
• 1xx Provisional/Informational Responses
183 Session Progress – indicates that information about the
progress of the session (call state) may be present in a message
body or media stream.
A typical use of this response is to allow a UAC to hear ring tone,
busy tone, or a recorded announcement in calls through a
gateway into the PSTN. This is because call progress information
is carried in the media stream in the PSTN. A one-way media
connection or trunk is established from the calling party’s
telephone switch to the called party’s telephone switch in the
PSTN prior to the call being answered (similar to ISDN Progress).
183 Session Progress allow an early media session to be
established prior to the call being answered.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
40
• 2xx Final Successful Responses – Request has succeeded. If for
an INVITE, ACK should be sent; otherwise, stop retransmissions
of request
200 OK – this response has two uses in SIP. When used to
accept a session invitation (INVITE), it will contain a
message body containing the media properties of the UAS
(called party). When used in response to other requests, it
indicates successful completion or receipt of the request.
202 Accepted – UAS has received and understood the request,
but may not have been authorized or processed by the server
(presence or IM).
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
41
• 3xx Redirect Responses – generally sent by a redirect server,
returning possible locations. The client should retry request at that
location
300 Multiple Choices – The address resolved to one of several
options for the client to choose between, which are listed in the
message body or the message's Contact fields
301 Moved Permanently – This redirection response contains a
Contact header field with the new permanent URI of the called
party. The address can be saved and used in future INVITE
requests.
302 Moved Temporarily – This redirection response contains a
URI that is currently valid but that is not permanent
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
42
• 4xx Responses – Client error
Indicates that the request cannot be fulfilled as it was submitted.
The request might need to be modified or tried in other locations.
Typically, client error responses will require user intervention
before a new request can be generated
400 Bad Request – This response indicates that the request was
not understood by the server (syntax error or malformed request).
An example might be a request that is missing required header
fields such as To, From, Call-ID, or Cseq, or has a field not known
by the server
401 Unauthorized – Indicates that the request requires the user to
perform authentication. For example, a response to a REGISTER
message that does not contain the proper credentials.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
43
• 4xx Responses – Client error
403 Forbidden – Endpoint is not allowed to place the request/call.
Used to deny a request without giving the caller any recourse. It is
sent when the server has understood the request, found the
request to be correctly formulated, but will not service the request
404 Not found – Server does not know about this end point. This
response indicates that the user identified by the sip URI cannot
be located by the server, or that the user is not currently signed
on with the user agent. Generally CSS/PT or dial-peer issue.
406 Not Acceptable – This response indicates that the request
cannot be processed due to a requirement in the request
message
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
44
• 4xx Responses – Client error
408 Request Timeout – This response is sent when an Expires
header field is present in an INVITE request, and the specified
time period has passed.
420 Bad Extension – This response indicates that the extension
specified in the Require header field is not supported by the proxy
or user agent. The response should contain a Supported header
field listing the extensions that are supported.
480 Temporarily Unavailable – Called party is not available to
take the call. The response should contain a Retry-After header
indicating when the request may be able to be fulfilled. Could be
sent when the DND feature is enabled or user is logged out.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
45
• 4xx Responses – Client error
481 Dialog/Transaction Does Not Exist – This response indicates
that a response referencing an existing call or transaction has
been received for which the server has no records or state
information.
482 Loop Detected – This response indicates that the request has
been looped and has been routed back to a proxy that previously
forwarded the request, by finding it’s own address in the Via
header
483 Too Many Hops – This response indicates that the request
has been forwarded the maximum number of times as set by the
Max-Forwards header in the request.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
46
• 4xx Responses – Client error
486 Busy Here – User agent is busy and cannot accept the call.
This response is equivalent to the busy tone in the PSTN.
487 Request Terminated – This response can be sent by a user
agent that has received a CANCEL request for a pending INVITE
request. A 200 OK is sent to acknowledge the CANCEL, and a
487 is sent in response to the INVITE.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
47
• 5xx Responses – Server Failure
Indicate that the request cannot be processed because of an
error with the server. The response may contain a Retry-After
header field if the server anticipates being available within a
specific time period. The request can be tried at other locations
because there are no errors indicated in the request.
500 Internal Server Error – Some error is preventing the server
from processing the request. For example a Re-Invite is received
before the initial Invite is processed.
501 Not Implemented – Indicates that the server is unable to
process the request because it is not supported. A proxy,
however, will forward a request containing an unknown request
method.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
48
• 5xx Responses – Server Failure
502 Bad Gateway – This response is sent by a proxy that is
acting as a gateway to another network, and indicates that some
problem in the other network is preventing the request from being
processed.
503 Service Unavailable – The requested service is temporarily
unavailable. For example, T1/E1 line down or FXS/FXO ports are
in “down” state
505 Version Not Supported – Incompatible SIP Clients (only SIP
version 2.0 is currently implemented)
513 Message Too Large – Endpoint is not capable of processing
large SIP messages
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
49
• 6xx Responses – Global Failure
This response class indicates that the server knows that the
request will fail wherever it is tried. As a result, the request should
not be sent to other locations.
600 Busy Everywhere – Sent when all instances of the logical SIP
user are busy. For example, not even the VM can take the call.
603 Decline – The called party declined to answer the call
604 Does not exist anywhere – All instances of the logical SIP
user are not available (logged out, un-registered etc.)
606 Not Acceptable – The UA was contacted successfully but
some aspects of the session description such as the requested
media, bandwidth, or addressing style were not acceptable.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
50
• SIP responses have a human readable text associated with every
response code.
• This Reason Phrase is never processed by a SIP stack. It’s
simply there for you to read. SIP stacks deal only with the threedigit number.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
51
SIP Headers Fields
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
52
• Allow-Events – The Allow-Events header field is used to list the
event packages that are supported.
Allow-Events: presence, kpml
u: telephone-event
• Authorization – Used to carry the credentials of a user agent in a
request to a server.
Authorization: Digest username="Cust1", realm="company.com",
nonce="9c8e88df84f1cec4341ae6e5a359“,
uri="sip:user2@company.com",
response="e56131d19580cd833064787ecc"
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
53
• Call-ID – Mandatory header field in all SIP requests and
responses. It is part of the dialog used to uniquely identify a call
between two user agents. A Call-ID must be unique across calls,
except in the case of a Call-ID in registration requests. All
registrations for a user agent should use the same Call-ID. A CallID is always created by a user agent and is never modified by a
server. The Call-ID is made up of a local-id, the @ symbol, and a
host name or IP address (globally unique).
Call-ID: 34a5d553192cc35@15.34.3.1
i: 35866383092031257@port34.carrier.com
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
54
• Contact – All new requests in this SIP dialog need to go to this
URI. For example, a Contact header field in a 200 OK response
to an INVITE can allow the ACK message and all future requests
during this call to bypass proxies and go directly to the called
party.
• Cseq – The command sequence CSeq header field is a required
header field in every request. The CSeq header field contains an
integer number that increases for each request. Usually, it
increases by 1 for each new request, with the exception of
CANCEL and ACK requests, which use the CSeq number of the
INVITE request to which it refers. The CSeq count is used by
UASs to determine out-of-sequence requests or to differentiate
between a new request (different CSeq) or a retransmission
(same CSeq).
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
55
• From – Is a required header field that indicates the originator of
the request. It is one of two addresses used to identify the dialog.
From: <sip:armstrong@hetrodyne.com>;tag=3342436
From: Thomas Edison <sips:edison@electric.com>;tag=532
• Min-SE – Determines the minimum allowed duration for the
session expiration. The duration of the session is negotiated
using the Session-Expires header.
Min-SE: 1800
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
56
• Record-Route – Used to force routing through a proxy for all
subsequent requests in a session between two user agents.
Normally, the presence of a Contact header field allows user
agents to send messages directly bypassing the proxy chain used
in the initial request. A proxy inserting its address into a RecordRoute header field overrides this and forces future requests to
include a Route header field containing the address of the proxy
that forces this proxy to be included.
• Supported – Used to list one or more options implemented by a
user agent or server. It is typically included in responses to
OPTIONS requests.
Supported: 100rel,timer,resource-priority,replaces
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
57
• To - Required header field in every SIP message used to indicate
the recipient of the request. A tag added to the header field in a
200 OK response is used throughout the call and incorporated
into the dialog. The To header field is never used for routing —
the Request-URI is used for this purpose.
• User-Agent - Used to convey information about the user agent
originating the request (it can contain manufacturer information,
software version, or comments).
User-Agent: Cisco-SIPGateway/IOS-15.2.4.M3
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
58
• Via – Required header field used to record the SIP route taken by
a request and is used to route a response back to the originator.
A user agent generating a request records its own address in a
Via header field in the request. While the ordering of most SIP
header fields is not significant, the Via header fields order is
significant because it is used to route responses. A proxy also
adds its own address to the top of the list of Via header fields
when forwarding the request.
A proxy receiving a response checks the top Via header field to
ensure that it matches its own address. If it does not, the
response has been misrouted and should be discarded. The top
Via header field is then removed, and the response forwarded to
the address specified in the next Via header field.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
59
– Works with Min-SE header value to
periodically refresh SIP sessions by sending repeated INVITE
requests. UAC or UAS can set the refresher parameter in the
Session-Expires header indicates who performs the re-INVITES
• Session-Expires
• Diversion – Support for redirecting services (Call Forwarding).
The INVITE Diversion header carries information about the
redirecting party
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
60
• Max-Forwards – Used to indicate the maximum number of hops
that a SIP request may take. The value of the header field is
decremented by each proxy that forwards the request. A proxy
receiving the header field with a value of zero discards the
message and sends a 483 Too Many Hops response back to the
originator.
Max-Forwards: 70 (default/suggested initial value)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
61
• Reason – Can be used in BYE and CANCEL messages to
indicate the reason why the session or call attempt is being
terminated.
Reason: Q.850 ;cause=1
http://www.cisco.com/c/en/us/td/docs/ios/voice/monitor/configuratio
n/guide/12_4t/vt_12_4t_book/vt_ccodes_debug.pdf
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
62
• Replaces – A user agent in an established dialog receiving an
INVITE or REFER with a Replaces header field that matches the
existing dialog must accept the request, terminate the existing
dialog with a BYE, and transfer all resources and state from the
existing dialog to the newly established dialog.
Replaces:
tag=2343
3232904875945@server.org;
to-tag=34314;
from-
• Require – Used to list features and extensions that a UAC
requires a UAS to support in order to process the request. If
support or use of a feature is desirable but not required, the
Supported header field is used instead.
Require: rel100
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
63
• Content-Length – Used to indicate the number of octets in the
message body.
Content-Length: 507
Content-Length: 0 (indicates no message body).
• Content-Type – Used to specify the Internet media type in the
message body. Media types have the familiar form type/sub-type
(application/sdp, application/xml, text/plain, text/html). If this
header field is not present, application/sdp is assumed.
Content-Type: application/sdp
Content-Type: application/dialog-info+xml
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
64
SDP
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
65
• SDP
(Session Description Protocol) is used to describe
multimedia sessions established using SIP.
• The default message body type in SIP is application/sdp.
• The calling and called party lists the media capabilities that they
are willing to receive or supported in SDP.
• SDP contains the following information about the media session:
 IP Address (IPv4/IPv6 address or host name)
 Port number (RTP port used for media transmission)
 Media type (audio, video, interactive whiteboard, ...)
 Media encoding scheme (PCM A-Law, MPEG II video, ...)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
66
• Field Name
v= Protocol version number
o= Owner/creator and session identifier
s= Session name
i= Session information
u= Uniform Resource Identifier
e= Email address
p= Phone number
c= Connection information
b= Bandwidth information
t= Time session starts and stops
r= Repeat times
z= Time zone corrections
k= Encryption key
m= Media information
a= Media attributes
© 2010 Cisco and/or its affiliates. All rights reserved.
Mandatory/Optional
m
m
m
o
o
o
o
m
o
m
o
o
o
o
o
Cisco Confidential
67
• The line begins with a single lower-case letter. There are never
any spaces between the letter and the =, and there is exactly one
space between each parameter.
v=0
o=johnston 2890844526 2890844526 IN IP4 43.32.1.5
s=SIP Tutorial
i=This broadcast will cover this new IETF protocol
u=http://www.digitalari.com/sip
e=Alan Johnston alan@mci.com
p=+1-314-555-3333 (Daytime Only)
c=IN IP4 225.45.3.56/236
b=CT:144
t=2877631875 2879633673
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 23422 RTP/AVP 31
a=rtpmap:31 H261/90000
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
68
• Protocol Version – Current (valid) version of SDP is 0
• Owner – Contains information about the originator of the session and
session identifiers. This field is used to uniquely identify the session. The
field contains:
o=username session-id version network-type address-type address
• Connection Data – Contains information about the media connection.
c=network-type address-type connection-address
 network-type - parameter is defined as IN for the Internet.
 address type - defined as IP4 or IP6
 connection-address - IP address that will send the media packets
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
69
• Media Announcements – Contains information about the type of media
session.
m=media port transport format-list
 media - parameter is either audio, video, application, data, telephone-
event, or control
 port - parameter contains the port number.
 transport - parameter contains the transport protocol, which is either
RTP/AVP (Real-time Transport/ Audio Video Profiles) or udp
 format-list - contains more information about the media. Usually, it
contains media payload types
• Attributes – Contains attributes of the preceding media session.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
70
v=0
o=CiscoSystemsSIP-GW-UserAgent 3223 8097 IN IP4 172.16.165.5
s=SIP Call
connection information
c=IN IP4 172.16.165.5
t=0 0
supported audio media
m=audio 16742 RTP/AVP 9 0 18 101
c=IN IP4 172.16.165.5
attribute
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
media format
a=rtpmap:0 PCMU/8000
parameter capability
a=rtpmap:18 G729/8000
Payload type:
a=fmtp:18 annexb=no
0 - 95 → static
a=rtpmap:101 telephone-event/8000
95 and above → dynamic
a=fmtp:101 0-15
pt: 101 for DTMF
relay (RTP-NTE)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
71
Basic SIP Call
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
72
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
73
INVITE sip:marconi@radio.org SIP/2.0
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b
Max-Forwards: 70
To: G. Marconi <sip:Marconi@radio.org>
From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
From-tag is added by
Call-ID: 123456789@lab.high-voltage.org
the request originator
CSeq: 1 INVITE
Subject: About That Power Outage...
Contact: <sip:n.tesla@lab.high-voltage.org>
CSeq set to initial value
Content-Type: application/sdp
Content-Length: 158
in the first INVITE
v=0
o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org
s=Phone Call
c=IN IP4 100.101.102.103
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
© 2010 Cisco and/or its affiliates. All rights reserved.
SDP included in this
INVITE message
Cisco Confidential
74
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP lab.high-voltage.org:5060; branch=z9hG4bKfw19b
To: G. Marconi <sip:marconi@radio.org>;tag=a53e42
From: Nikola Tesla <sip:n.tesla@high-voltage.org>>;tag=76341
Call-ID: 123456789@lab.high-voltage.org
To-tag is added on the
CSeq: 1 INVITE
first response
Contact: <sip:marconi@tower.radio.org>
Content-Length: 0
Note that the To and From header fields are not
reversed in the response message as one might
expect them to be. This is because the To and
From header fields in SIP are defined to indicate
the direction of the request, not the direction of
the message.
© 2010 Cisco and/or its affiliates. All rights reserved.
CSeq indicates this is a
response to the INVITE
with this CSeq value
SDP is not included in
this message
Cisco Confidential
75
SIP/2.0 200 OK
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b
;received=100.101.102.103
To: G. Marconi <sip:marconi@radio.org>;tag=a53e42
From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
Call-ID: 123456789@lab.high-voltage.org
CSeq: 1 INVITE
Contact: <sip:marconi@tower.radio.org>
Content-Type: application/sdp
CSeq indicates this is a
Content-Length: 155
v=0
o=Marconi 2890844528 2890844528 IN IP4 tower.radio.org
s=Phone Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 60000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
© 2010 Cisco and/or its affiliates. All rights reserved.
response to the INVITE
with this CSeq value
SDP is included in this
message
Cisco Confidential
76
ACK sip:marconi@tower.radio.org SIP/2.0
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bK321g
Max-Forwards: 70
To: G. Marconi <sip:marconi@radio.org>;tag=a53e42
From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
Call-ID: 123456789@lab.high-voltage.org
CSeq: 1 ACK
Content-Length: 0
The command sequence, CSeq, has the same number as the INVITE,
but the method is set to ACK.
The branch parameter in the Via header field contains a new
transaction identifier than the INVITE, since an ACK sent to
acknowledge a 200 OK is considered a separate transaction.
The SIP session is considered to be established when the INVITE, 200
OK and ACK has been exchanged.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
77
BYE sip:n.tesla@lab.high-voltage.org SIP/2.0
Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf
Max-Forwards: 70
To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
From: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID: 123456789@lab.high-voltage.org
CSeq: 2 BYE
Content-Length: 0
The Via header field contains a new transaction
identifier since the BYE is considered a
separate transaction from the INVITE or ACK
transactions shown previously.
CSeq is increased to 2 BYE
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
78
SIP/2.0 200 OK
Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf
;received=200.201.202.203
To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
From: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID: 123456789@lab.high-voltage.org
CSeq: 2 BYE
Content-Length: 0
200 OK is used to acknowledged the BYE message (CSeq is 2 BYE).
The SIP session is completely torn down after the BYE and respective
200 OK have been exchange.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
79
Media negotiation
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
80
• SIP use SDP to communicate media information. SDP body
contain the IP address, UDP port number, supported media, list of
codecs, media attributes… SDP uses offer/answer model
• One endpoint sends an offer SDP with capabilities supported or
the capabilities he wishes to negotiate:
 m (media) line for each media stream being negotiated (audio, video,
content)
 a (attribute) lines describing media
• Other endpoint sends answer SDP with the same or subset of
capabilities
 for each m line in the offer, there must be a corresponding m line in the
answer
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
81
• INVITE is sent without SDP
• 200 OK response provides SDP offer
• ACK provides SDP answer
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
82
• INVITE is sent with SDP offer
• 200 OK response provides SDP answer
• ACK is sent without SDP
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
83
1. MTP required
2. Insert MTP if needed – introduced in CUCM 8.5
3. Best Effort Early Offer (BEEO) – introduced in CUCM 10.5
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
84
1. MTP required
•
Inserts MTP resource into the media path for every call
•
CUCM sends MTP's IP address, port and codec in SDP
•
MTP support a single audio codec only
•
If command: “codec pass-through” is not supported by MTP,
inserting MTP will break SRTP, video and T38 faxing
•
CUCM will look into SIP trunk MRGL to allocate an MTP, so the
media path is forced (regardless of the calling device)
SIP trunk
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
85
2. Insert MTP if needed – introduced in CUCM 8.5
•
If calling device can provide media information, SDP with
information is sent – therefore no MTP is used for EO
•
If calling device cannot provide EO information, MTP is
required. However, calling MRGL is used first to allocate MTP. If
allocation fails, trunk MGRL is used.
•
This causes a reduction on the MTP usage
•
The calling device capabilities and regions settings used, not
the MTP. Even if MTP is used, the media path is not changed.
SIP Profile
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
86
3. Best Effort Early Offer (BEEO) – introduced in CUCM 10.5
•
BEEO feature prohibits the user of MTP just to provide early
offer. CUCM provides EO or DO based on incoming SDP
availability.
•
Early Offer support for voice and video calls is now a drop-down
menu:
SIP Profile
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
87
• Early Media is the ability of two user agents to communicate
before the session is actually established.
• The SIP 183 Session Progress message can be used instead of
the SIP 180 Ringing, to provide announcements or messages
about the state of the call
• Support for early media is important both for interoperability with
the PSTN and billing purposes.
Note: Do not confuse Early Media with Early Offer
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
88
• INVITE is sent with SDP offer
• 183 Session Progress provides SDP answer and media can be
established before the call actually connects
• If the call finally connects, 200 OK should have exact SDP
answer as provided in 183 Session Progress
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
89
• INVITE is sent without SDP
• 183 Session Progress provides SDP offer
• PRACK needs to be used to reliably acknowledge the 183 and
provide SDP answer to established the media
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
90
• PRACK method is used to acknowledge a provisional response
(1xx); can be used to cut through audio before call is connected:
 Unallocated number announcement - call is not connected,
therefore not charged
 Toll free number - announcement before call is routed to an call
center
 Meeting bridges - enter the ID before call is connected
SIP Profile
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
91
• Either UA can re-INVITE (mid-call INVITE) to re-negotiate
parameters:
 change negotiated codec
 Fax
 Jabber enabling video
Note: You can differentiate the reINVITE from the first INVITE, because
it already has a To-tag included
 Placing call on hold
• If the call is still not connected (final response hasn’t been
received), an UPDATE can be used instead of the INVITE
 For example, when hitting transfer before the call is connected
(blind transfer)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
92
• For call hold, resume, transfer, conference or any other
requirement to stop the media, a re-INVITE can be sent setting
the audio attribute to inactive, the connection line to the null
address (0.0.0.0) or the media the direction attribute for the
endpoint so that it does not receive media from other endpoint:
v=0
o=CiscoSystemsSIP-GW-UserAgent 4415 6760 IN IP4 172.16.148.5
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 17300 RTP/AVP 0
c=IN IP4 0.0.0.0
a=inactive
or setting: a=sendonly
a=rtpmap:0 PCMU/8000
a=ptime:20
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
93
• Some SIP endpoints might be not capable of reacting to changes
in the codec or connection information without disconnecting the
media first.
• By default, CUCM passes the mid-call SDP to the peer leg
without sending a prior Inactive SDP to break the media
exchange.
SIP Profile
• If the box is checked, during mid-call codec or connection
updates CUCM sends an INVITE a=inactive SDP message to the
endpoint to break the media exchange.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
94
• When call is connected to MTP (early offer enabled SIP trunks),
breaking the media during a hold or supplementary service is not
necessary.
SIP Profile
• If the box is checked, CUCM will not send an INVITE a=inactive
SDP message during call hold or media break during
supplementary services (only applies to early offer enabled SIP
trunks)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
95
DTMF-relay over SIP networks
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
96
• In-Band (IB)
 RFC 2833 (RTP-NTE)
• Out-of-Band (OOB)
 SIP Notify
 KPML
 SIP Info
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
97
• In-Band
• Digits passed in the RTP stream with unique payload type
(generally pt = 101)
• Capability negotiated in SDP like any other codec
v=0
o=CiscoSystemsSIP-GW-UserAgent 8773 2764 IN IP4 10.100.0.74
s=SIP Call
c=IN IP4 10.100.0.74
RTP-NTE digits are not seen in the
t=0 0
traces as they are sent IB. You need to
m=audio 19264 RTP/AVP 0 8 101
run a sniffer capture or debug:
a=rtpmap:0 PCMU/8000
‘debug voip rtp session named-event’
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Support RTP payload type 101 and
digits 0 to 15 (0-9,*,#,ABCD)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
98
• Unsolicited Out-of-Band
• Capability negotiated in call-info header
INVITE sip:7071@14.48.46.2:5060 SIP/2.0
Via: SIP/2.0/UDP 14.48.20.15:5060;branch=z9hG4bK212336
From: <sip:2001@14.48.20.15>;tag=46709670-256F
To: <sip:7071@14.48.46.2>
Call-ID: E33AD68B-266211E1-885DE130-CC2C3FF8@14.48.20.15
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Contact: <sip:2001@14.48.20.15:5060>
Allow-Events: telephone-event
SIP trunk
security profile
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
99
• Digits sent in SIP NOTIFY (unsolicited telephony events)
NOTIFY sip:7071@14.48.46.2:5060 SIP/2.0
Via: SIP/2.0/UDP 14.48.20.15:5060;branch=z9hG4bK251965
From: <sip:2001@14.48.20.15>;tag=46709670-256F
To: <sip:7071@14.48.46.2>;tag=76443782-f2df-4954-81c7-811f18c00b73-25783179
Call-ID: E33AD68B-266211E1-885DE130-CC2C3FF8@14.48.20.15
CSeq: 104 NOTIFY
Event: telephone-event
Content-Type: audio/telephone-event
Content-Length: 4
12/15/2011 09:50:01.879 CCM|getUnsolNotifyContents: Unsol NOTIFY message
12/15/2011 09:50:01.879 CCM|getUnsolNotifyContents: Parsed digit=9
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
100
• Not Unsolicited Out-of-Band i.e. needs to subscribe
• Capability advertised in Allow-events header
SUBSCRIBE sip:7071@14.48.46.2:5060 SIP/2.0
Call-ID: 5FF97038-299511E1-8871E130-CC2C3FF8@14.48.20.15
CSeq: 102 SUBSCRIBE
Event: kpml
Content-Type: application/kpml-request+xml
Content-Length: 327
<?xml version="1.0" encoding="UTF-8"?>
<kpml-request><pattern persist="persist"><regex tag="dtmf">
[x*#ABCD]
</regex></pattern></kpml-request>
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
101
• Digit sent in SIP NOTIFY (KPML event)
NOTIFY sip:14.48.46.2:5060 SIP/2.0
Call-ID: 5FF97038-299511E1-8871E130-CC2C3FF8@14.48.20.15
CSeq: 104 NOTIFY
Event: kpml
Subscription-State: active
Content-Type: application/kpml-response+xml
Content-Length: 113
<?xml version="1.0" encoding="UTF-8"?>
<kpml-response version="1.0" code="200" text="OK" digits="1" tag="dtmf"/>
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
102
• SIP Info message, not supported by CUCM
INFO sip:2143302100@172.17.2.33 SIP/2.0
Via: SIP/2.0/UDP 172.80.2.100:5060
From: <sip:9724401003@172.80.2.100>;tag=43
To: <sip:2143302100@172.17.2.33>;tag=9753.0207
Call-ID: 984072_15401962@172.80.2.100
CSeq: 25634 INFO
Supported: 100rel
Supported: timer
Content-Length: 26
Content-Type: application/dtmf-relay
Signal= 1
Duration= 160
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
103
SIP Call Flows
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
104
Trace: SDL001_100_000001.txt
cn=“7001”
dd=“8001”
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
105
Trace: SDL001_100_000002.txt
cn=“8001”
dd=“7001“
CFwdNA
1007
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
106
Trace: SDL001_100_000003.txt
cn=“7001”
dd=“1007”
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
107
Trace: SDL001_100_000004.txt
cn=“7001"
dd=“8001“
conference
1007
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
108
Trace: SDL001_100_000005.txt
cn=“8001"
dd=“7001“
transfer
1007
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
109
Trace: SDL001_100_000006.txt
cn=“7001"
dd=“1001“
transfer
8001
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
110
CUCM SIP Architecture
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
111
|AppInfo |SIPTcp: Incoming SIP TCP message from 192.168.200.166 on port 52978
REGISTER sip:192.168.213.86 SIP/2.0
Via: SIP/2.0/TCP 192.168.200.166:52978;branch=z9hG4bK0542280e
From: <sip:1008@192.168.213.86>;tag=aca0166f7971000c497ea126-31834d8d
To: <sip:1008@192.168.213.86>
Call-ID: aca0166f-7971005a-71ff814c-37ebc2ea@192.168.200.166
Max-Forwards: 70
Date: Fri, 01 Jan 1982 00:11:20 GMT
CSeq: 107 REGISTER
User-Agent: Cisco-CP9951/9.4.1
Contact: <sip:4d74b62@192.168.200.166:52978;+u.sip!devicename="SEPACA0166F7971”
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo
Reason: SIP;cause=200;text="Name=SEPACA0166F7971 ActiveLoad=sip9951.9-4-1-9.loads"
Expires: 3600
Content-Type: multipart/mixed; boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 1249
Note: Call ID will remain same for every register
message sent by endpoint (CSEQ increases)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
112
SdlSig
SdlSig
|SIPSPISignal
|SIPRegisterInd
|SIPHandler(1,100,72,1)
|SIPStationInit(1,100,65,1)
|SIPTcp(1,100,64,1)
|SIPHandler(1,100,72,1)
Created
|
|SIPStationD(1,100,66,10)
|SIPStationInit(1,100,65,1)
SdlSig
SdlSig
|Start
|SIPRegisterInd
|SIPStationD(1,100,66,10)
|SIPStationD(1,100,66,10)
|SIPStationD(1,100,66,10)
|SIPStationInit(1,100,65,1)
SdlSig
SdlSig
SdlSig
|LineRegisterReq
|DmPidReq
|DmPidErr
|LineManager(1,100,166,1)
|DeviceManager(1,100,199,1)
|LineManager(1,100,166,1)
|SIPStationD(1,100,66,10)
|LineManager(1,100,166,1)
|DeviceManager(1,100,199,1)
Created
|
|LineControl(1,100,167,16)
|LineManager(1,100,166,1)
SdlSig
SdlSig
SdlSig
|Start
|LineControl(1,100,167,16)
|LineRegisterRes
|SIPStationD(1,100,66,10)
|DeviceLineRegister |LineControl(1,100,167,16)
|LineControl(1,100,167,16)
|LineManager(1,100,166,1)
|SIPStationD(1,100,66,10)
SdlSig
|SIPRegisterResp
|SIPStationD(1,100,66,10)
© 2010 Cisco and/or its affiliates. All rights reserved.
|SIPHandler(1,100,72,1)
Cisco Confidential
113
|AppInfo |SIPTcp: Outgoing SIP TCP message to 192.168.200.166 on port 52978
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.200.166:52978;branch=z9hG4bK0542280e
From: <sip:1008@192.168.213.86>;tag=aca0166f7971000c497ea126-31834d8d
To: <sip:1008@192.168.213.86>;tag=1571276938
Date: Tue, 24 Jun 2014 19:43:40 GMT
Call-ID: aca0166f-7971005a-71ff814c-37ebc2ea@192.168.200.166
CSeq: 107 REGISTER
Expires: 120
Contact: <sip:4d74b62@192.168.200.166:52978;+u.sip!devicename="SEPACA0166F7971”
Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0
Content-Type: application/x-cisco-remotecc-response+xml
Content-Length: 367
<x-cisco-remotecc-response><response><code>200</code><optionsind><combine
max="6"><remotecc><status/></remotecc><service-control/></combine><dialog usage="hook
status"><unot/></dialog><dialog usage="shared line"><unot/></dialog><presence usage="blf
speed dial"><unot/></presence><joinreq></joinreq></optionsind></response>
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
114
LineControl
Register lines associated to
the SIP phone
SipCdpc
Created per call to handle
call processing
SipStation
Cdfc
Created per call to handle
SIP line features
SipStationD
Created to handle this SIP
phone until it unregisters
SipStationInit
SipHandler
SIP phone
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
115
SipD process gets subscribed
to RouteListControl when the
trunk is associated to a RG/RL
Route List
Control
SipCdpc
Created per call to handle
call processing
SipD
Created when the SIP trunk
is provisioned in CUCM
SIPHandler
SIP trunk
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
116
• Media Termination Point Required
• SIP Trunk Security Profile
• SIP profile
• Destination Address is an SRV
• Run on all active UCM nodes
• SIP OPTIONS Ping
• QSIG over SIP
• REFER transparency
• Accept received codec preference
• Normalization Script
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
117
Trace: SDL001_100_000007.txt
cn=“7001”
dd=“8001”
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
118
SIP Dial Rules
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
119
• SIP dial rules allow configuration of dial plans for phones that are
running SIP
• Create SIP dial rules and associate them to the SIP phone
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
120
• KPML allows for the digits to be sent to Cisco Unified
Communications Manager digit by digit.
• SIP Dial Rules allow for a pattern of digits to be collected locally
on the phone prior to sending to CUCM.
Recommended to use SIP dial rules,
to increase CUCM performance
(less processing of SIP messages)
• If phones do not support KPML (and no SIP dial rules are
configured), the user must wait interdigit timeout before digits are
sent to CUCM for processing, or press the Dial softkey
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
121
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
122
SIP URI Dialing
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
123
• SIP URI dialing is really a pretty basic concept. Instead of using a
normal DN or number to designate a destination, you use a SIP
URI such as 1001@radio.org or even marconi@radio.org.
• In CUCM, URI dialing is case sensitive by default. Behavior can
be modified via enterprise parameter:
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
124
• We have two “flavors’ of URI dialing:
 URI dialing to SIP trunks (using SIP route patterns which has
been available since CUCM version 5.x)
 URI dialing to CUCM IP phones (feature has been added in
CUCM version 9.x – works for any SCCP or SIP IP phone)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
125
• Create a SIP route pattern and point to a SIP trunk (RL option
included in CUCM 9.x).
• Use a SIP device capable of URI dialing to place the call. CUCM
checks the host portion of the URI and matches against the
configured SIP route patterns. Call will hit the SIP route pattern
and get routed to the SIP trunk.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
126
• CUCM 9.x uses URI as an alias to a DN. A call to the URI
behaves as if the call was made directly to the DN. Up to 6 URIs
can be associated to a DN.
• Only a few phones support dialing a URI, but all phones support
receiving an URI call. Most phones support call back to URI
(missed or received call history).
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
127
• Add Directory URI to end user
• Associate the phone to the end user and select primary
extension.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
128
• The line would now display associated Directory URI
• You can associate additional Directory URIs directly to the DN
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
129
AppInfo |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from 192.168.200.166 on port 50290
INVITE sip:user1@test.cisco.com SIP/2.0
SdlSig |DaReq
|wait
|Da(1,100,204,1)
|Cdcc(1,100,212,39)
|
CI=30399177
Cgpn=tn=0npi=0ti=1nd=7001pi=1si1
DialedNum=tn=0npi=1ti=2nd=user1
User=user1Host=test.cisco.comPort=5060 DisplayName=RawUrl=sip:user1@test.cisco.com
AppInfo
AppInfo
AppInfo
AppInfo
AppInfo
|Digit Analysis: star_DaReq: Matching SIP URL, Alphaumeric User, uri=user1@test.cisco.com
|Digit Analysis: SetFQDNAfterURILookup FQDN-[1007]
|$URI getDaRes: Blended dn-1007 URI-user1@test.cisco.com
|Digit analysis: match(pi="2", fqcn="7001", cn="7001",plv="5", pss="Directory URI", dd="user1")
|Digit analysis: analysis results
|PretransformCallingPartyNumber=7001
|CallingPartyNumber=7001
|DialingPartition=Directory URI
|DialingPattern=([mM][oO][cC].[oO][cC][sS][iI][cC].[tT][sS][eE][tT]@1resu)
|FullyQualifiedCalledPartyNumber=moc.ocsic.tset@1resu
|DialingPatternRegularExpression=([Mm][Oo][Cc].[Oo][Cc][Ss][Ii][Cc].[Tt][Ss][Ee][Tt]@1resu)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
130
• If you don't want to call the full directory URI, you want to call
without the domain name, you can change the following
Enterprise parameters:
• End User Directory URIs are assigned to a special undeletable
Directory URI partition. An alias to that Directory URI partition can
be set up from the enterprise parameter:
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
131
• Intra-cluster routing – calls to URIs on the local cluster are routed
using partitions and CSS.
• What happens if URIs on multiple cluster can have the same
domain suffix?
• Inter-cluster routing – URIs are replicated between clusters using
ILS (Inter-cluster Lookup Service). CUCM looks up in ILS to figure
out the sub-domain, hit a SIP route pattern and find the SIP trunk
to route the call.
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
132
• Intercluster Directory URI
• ILS networking and URI sync is required:
CLI
utils ils lookup user@cisco.com
Routing string is lab.cisco.com
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
133
• CUCM supports addressing of directory URIs and directory
numbers (blended identity). Both directory URI and the directory
number of the sending party is included in outgoing SIP INVITE.
SIP trunk
• The destination endpoint has the option of using either the URI or
DN for its response – both will reach the same destination.
• Phone will register using the x-cisco-number tag in the SIP
identity headers to communicate blended address (Remote-PartyID, Diversion, P-Asserted-ID, P-Preferred-Identity).
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
134
SIP Normalization
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
135
• Normalization Script – This option was added in CUCM 8.0. This
feature allows more interoperability capability with 3rd part SIP
Vendors. A normalization script allows following transformations
on inbound and outbound SIP messages and content bodies:
 get and modify request/response line
 get, add, modify, and remove parameters
 get, add, modify, and remove headers
 get, add, and remove content bodies
 specific APIs for manipulating SDP
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
136
CUBE
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
137
• Special
type
connections.
of
voice
gateway that
provides
SIP-to-SIP
• Provides security border between trusted enterprise and un-
trusted public network
• Hides internal IP addresses
• Provides
tools to monitor the network
vulnerabilities, DoS attacks, IPS, Firewall
traffic,
prevent
• Signaling and media control point (media flow through)
• Provide CAC
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
138
SIP
SIP
CUBE
incoming dial-peer
voice service voip
allow-connections sip to sip
ip address trusted list
ipv4 192.168.1.0 255.255.255.0
sip
early-offer forced
rel1xx supported
dial-peer voice 1 voip
incoming called-number .T
session protocol sipv2
dtmf-relay rtp-nte sip-kmpl
codec g711ulaw
© 2010 Cisco and/or its affiliates. All rights reserved.
outgoing dial-peer
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g711alaw
codec preference 3 g729r8
dial-peer voice 2 voip
destination-pattern 2...
session protocol sipv2
session target ipv4:10.1.1.1
dtmf-relay rtp-nte
voice-class codec 1
voice-class sip early-offer forced
Cisco Confidential
139
SIP
SIP
CUBE
incoming dial-peer
outgoing dial-peer
B2BUA
• debug ccsip messages
• debug voice ccapi inout
• debug voip rtp session named-events
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
140
• By default, CUBE receives media packets from the inbound call
leg, terminates them, and then re-originates the media stream on
an outbound call leg (Media flow-through)
• Media flow-around enables media packets to be passed directly
between the endpoints, without the intervention of the CUBE.
voice service voip
allow-connections sip to sip
media flow-around
dial-peer voice number voip
media flow-around
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
141
• Passthrough Media Change – Passthrough media change
method optimizes or consumes mid-call media-related signaling
within the call. Mid-call signaling changes will be passed through
only when bidirectional media like T.38 or video is added.
• Block – Blocks all mid-call media-related signaling to the specific
SIP trunk (Video escalation and T.38 callflow are rejected when
the mid-call signaling block command is configured)
voice service voip
sip
mid-call signaling [passthru media-change | block]
dial-peer voice number voip
mid-call signaling [passthru media-change | block]
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
142
Troubleshooting SIP
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
143
Busy tone when calling SIP ICT
dd=“8001”
503 service unavailable
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
144
Reorder tone heard when calling PSTN
numbers (918002472020). It happened
after CUBE upgrade to IOS 15.0
IP address trusted list issue
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
145
Working
scenario
Calling: 8013545
Called: 918004266710
Result: IVR picks up right away
Failed
scenario
Calling: 8015024
Called: 918004266710
Result: No answer, just hear ringback
Need early media
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
146
Calls from 9951 to Lync client fails
when video is enabled
Interoperability issue
contactHeader, "video;audio;video"
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
147
Calls from Rintzler SX10 to 2200 fail
Video codec mismatch
(region BW limited)
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
148
Calls to Rightfax (6477770025) gets
dropped. If send directly from CUBE to
RF it works
Disable g711alaw in RF
© 2010 Cisco and/or its affiliates. All rights reserved.
Cisco Confidential
149
Thank you!