Session Initiation Protocol (SIP) is an IETF standards-based signaling protocol widely used for multimedia (voice and video) communications. SIP is an application layer
ptg13358382 protocol and can leverage TCP or UDP for transmission. It is a text-based protocol and
has many elements of HTTP. SIP can also operate in its secure form with TLS for signal-ing, known as Secure SIP (SIPS). SIP uses TCP/UDP port 5060 and SIPS uses TCP port 5061.
Analogous to MGCP, SIP uses SDP for negotiating media type and format such as audio and video codecs, transport protocol parameters, ports, and so on. SDP operates in an offer-answer approach such that the session-initiating endpoint (UA) specifies desired session parameters (such as supported codecs), and the receiving endpoint (UA) replies with matching session parameters. Each resource in a SIP network is identified by a Uniform Resource Identifier (URI). A typical SIP URI is in the following format:
sip: username : password @ host : port .
SIP sends DTMF digits in-band. However, it can use out-of-band DTMF as well. In a SIP session, DTMF can be transported as KeyPad Markup Language (KPML), Unsolicited Notify (UN), or Network Termination Equipment (NTE) (RFC 2833). KPML and UN are out-of-band DTMF transportation mechanisms, whereas NTE is an in-band mechanism for DTMF delivery. KPML and NTE are standards based, whereas UN is a non-standard protocol.
SIP phones can leverage either KPML or SIP dial rules for dialing a number to a destina-tion phone/route pattern. SIP (Type-A) phones leverage SIP dial rules and use a different method compared to SIP KPML (Type-B) phones.
KPML is similar to SCCP in terms of the process used to collect each digit. The caller enters digits on the keypad of the phone, and digit analysis occurs in real time, after which CUCM routes the call to the destination device or translation/route pattern. SIP KPML uses SIP NOTIFY messages to carry the dialed digits from the phone to CUCM.
As indicated, devices that use KPML are known as Type-B SIP phones. The phones that support KPML are automatically enabled for KPML. No configuration on CUCM is necessary for these devices to support KPML. KPML is configured under the SIP Profile applied to the IP Phone.
SIP dial rules on CUCM can be configured to allow the SIP phone to download a dial plan file (dialplan.xml) from the CUCM TFTP server when the phone boots. When a caller enters digits on the phone keypad, the phone analyzes the dialed digits and compares them with the strings contained within the dialplan.xml file stored locally on the phone.
When there is a match to the dialed number and the timeout is set to 0, the phone sends to CUCM a SIP INVITE message that contains the entire called number. If the dialed number does not match any of the strings contained within the diaplan.xml file, the call will only be routed when the inter-digit timeout expires (or the caller presses “#” or “Dial”).
If a dialplan.xml file is downloaded to a phone that supports KPML, KPML is disabled and the phone behaves in the same way as a Type-A SIP phone. A hybrid of using KPML and dial rules is not supported, and SIP dial rules/dial plan always take priority over KPML. The exception to this statement is when CUCME is used and the last statement within the dial plan contains a dial pattern with a single wildcard character (.) as the last pattern in the dial plan.
ptg13358382 VoIP Signaling Protocols 67
A SIP network includes many elements for establishing, terminating, and managing SIP sessions, as listed and described in Table 3-3 .
Table 3-3 SIP Network Elements Network Element Description
SIP user agent (UA) Manages send and receive SIP messages and manages a session. A SIP endpoint can act as both a user agent client (UAC) and a user agent server (UAS).
SIP user agent client (UAC)
Initiates and sends requests and gets a response from a SIP UAS or SIP proxy server. UAC, however, is a logical role and lasts only for the duration of a SIP transaction.
SIP user agent server (UAS)
Responds to SIP requests by accepting, rejecting, or redirecting the request. Analogous to UAC, UAS is also a logical role that lasts only for the duration of a SIP transaction.
SIP proxy server Provides routing, enforces policies, provides features, and authenti-cates and authorizes users.
SIP redirect server UAS server that provides address translation and that generates 3XX (Redirection) responses to requests it receives, thereby directing the client to contact an alternate set of URIs. It allows SIP proxy servers to redirect invites to external domains as well.
SIP registrar server A SIP endpoint that accepts REGISTER requests from SIP UAs and places the information received in those requests into a location ser-vice for the domain it handles. This allows users to register their cur-rent locations.
SIP back-to-back user agent (B2BUA)
Receives requests from UAs. However, it generates a new request on their path to the destination.
There are two SIP message types: request and response. A request message is sent by a client to a server and is used to invoke certain methods (functions). A response message is sent by a server to a client in answer to the request and indicates the status of the request received.
Table 3-4 lists the methods available for SIP requests.
Table 3-4 SIP Request Methods Method Description
INVITE Used by a UA to initiate a session with a UAC. When this arrives at a UAS, the UAS processes it and sends a suitable type of response message.
ptg13358382 Method Description
REGISTER Method used by a UA to indicate its current IP address and the URLs for which it would like to receive calls to register its contact information. Cisco SIP phones send their MAC addresses and regis-ter their lines with the primary CUCM using REGISTER messages.
ACK Confirms reliable message exchange and is sent in reply to a final response message from a server.
BYE Terminates a session between users.
CANCEL Terminates a pending request (a request for which a final response has not yet been received).
OPTIONS Requests information about the capabilities of a caller, without set-ting up a call.
Provisional Response Acknowledgement (PRACK)
Adds an acknowledgement system to the Provisional response (1XX).
PRACK is sent in response to a Provisional response.
Table 3-5 lists the types of SIP responses.
Table 3-5 SIP Responses
SIP Response Description
Provisional (1XX) Indicates that a request has been received and is being processed. It is informational in nature.
Success (2XX) Indicates success (the action was successfully received, understood, and accepted).
Redirection (3XX) Indicates that further action needs to be taken by the sender to complete the request, perhaps in case of a redirection in response to a UA by SIP proxy.
Server Error (5XX) Indicates a server’s failure to fulfill a valid request by client.
Global Failure (6XX) Indicates a global failure and that the request cannot be fulfilled at any server.
Figure 3-4 depicts a SIP call flow between UAs (Cisco Unified IP Phones) and a UAS/
B2BUA (CUCM).
ptg13358382 VoIP Signaling Protocols 69
REGISTER
IP Phone A CUCM IP Phone B
REGISTER 200 OK
INVITE (SDP)
100 Trying 180 Ringing
200 OK ACK
RTP BYE
200 OK 200 OK
BYE RTP ACK 200 OK 180 Ringing
100 Trying INVITE (SDP)
200 OK
Figure 3-4 SIP Call Flow Between Two Endpoints Registered to Same CUCM The following events occur during the SIP call flow illustrated in Figure 3-4 :
1. Cisco Unified IP Phones (SIP UAs) send REGISTER requests to CUCM (SIP UAS).
CUCM sends the response 200 OK after authenticating the UAs.
2. IP Phone A goes off-hook and sends an INVITE to CUCM. In response, CUCM sends a TRYING 100. At the same time, using the digits dialed by the user, CUCM reroutes the request to IP Phone B. The INVITE contains SDP information for capa-bilities negotiation.
3. IP Phone B sends a Ringing 180 response to CUCM when the phone begins to ring.
CUCM sends 180 ringing (alerting) to IP Phone A.
4. The response 200 OK message corresponds to the user at IP Phone B answering the call, at which time IP Phone A gets 200 OK from CUCM as well.
5. IP Phone A sends an ACK to CUCM, and CUCM sends an ACK to IP Phone B in reply to 200 OK messages followed by opening the media channel. RTP starts with the parameters (ports, addresses, codecs, etc.) of the SDP protocol (negotiated dur-ing INVITE).
6. The user at IP Phone A decides to terminate the call, and the phone sends BYE to CUCM. Consecutively CUCM sends BYE to IP Phone B.
From the Library of Juan Arcaya
ptg13358382 7. Both phones reply with an OK 200 message to confirm that the final message has
been received correctly.
SIP supports Early Offer (EO) and Delayed Offer (DO) for capability negotiation. In case of an Early Offer, the SDP message is sent from the calling party to the called party in the initial INVITE message. The called party responds with the negotiated capability in the 200 OK to the calling party. In case of Delayed Offer, the called party sends the SDP message in the 200 OK message to the calling party. The calling party responds with the negotiated parameter in the ACK message to the called party.
SIP also supports Early Media and Delayed Media for media channel negotiation. In the case of Early Media, the media between the called and calling party is established before the session establishment. The called party sends 183 instead of 180 and allows the call-ing party to establish a bearer channel between the two. With Delayed Media, the media is established once the SIP session negotiation is complete.
On Cisco IOS, voice gateway SIP configuration/options such as transport type (TCP/
UDP), registrar server configuration, binding all traffic to a certain interface, and so on can be configured under voice services voip . Example 3-2 shows a configuration of the SIP voice service where the session transport protocol is set to TCP (default is UDP) and SIP EO is forced for all SIP sessions.
Example 3-2 SIP Global Parameter Configuration
SIPRouter(config)# voice service voip SIPRouter(conf-voi-serv)# sip
SIPRouter(conf-serv-sip)# session transport tcp
SIPRouter(conf-serv-sip)# bind all source-interface loopback 0 SIPRouter(conf-serv-sip)# early-offer forced
Example 3-3 illustrates the SIP UA configuration for defining a remote registrar server (a local registrar server can be defined in voice service voip).
Example 3-3 SIP UA Configuration
SIPRouter(config)# sip-ua
SIPRouter(config-sip-ua)# registrar ipv4: 10.76.108.146 tcp
SIPRouter(config-sip-ua)# registrar ipv4: 10.76.108.147 tcp secondary
SIPRouter(config-sip-ua)# authentication username registrar password C1sc0123
Consecutively at least one VoIP dial peer is required on the gateway so it can send calls to and receive calls from CUCM. Example 3-4 illustrates the configuration of a SIP dial peer.
ptg13358382