VoIP uses only a few SIP methods today, but more methods are being released while the technology and market evolve.
SIP is also a key element in transmitting other forms of non-verbal communication, such as Instant Messaging. This topic covers only the SIP methods for VoIP transmissions, not the other SIP offerings.
Sending an INVITE
The SIP method to initiate a phone call is the INVITE, and it’s defined in the international guidelines for SIP put forth by the Internet Engineering Task Force (IETF) in its memo RFC 2543. The INVITE method identifies the host, the intended recipient, and the other accepted SIP methods that are accepted for use by the originating SIP device during the call.
A snapshot of a standard SIP INVITE looks like this:
Investigating the Request-Line
The code in the preceding section shows a very straightforward INVITE method. The Request-Line of the header starts with the word INVITE, and if you missed it, the second line reiterates the method by telling you Method: INVITE. SIP always tells it like it is.
A traditional VoIP call from one SIP softphone or device to another SIP end-point has a different-looking Request-Line than the one in the preceding section. Rather than a phone number and an IP address, the INVITE is directed toward a destination that’s named more like an e-mail address.
A SIP address referred to as a SIP URI or Uniform Resource Identifier. It identifies both the user and the server (wiley.com). That server knows the location of user and is responsible for connecting SIP calls to him. (The proxy server knows the users by using another SIP method called REGISTER, which I cover in the section “Logging in with REGISTER,” later in this topic.)
In this respect, the SIP URI functions like the final routing point for a local phone provider. If the Public Switched Telephone Network (PSTN) had to find a direct path all the way to the home or office of everyone called, it would take more than a minute to make the connection. Instead, the PSTN terminates your call to the central office of your local carrier, which provides connectivity to not only you, but to all the other homes and businesses in
your area. This reduces the amount of routing options available to the PSTN to find your phone and ring it, so the entire process can be done in milliseconds instead of minutes.
If you’re not functioning in a public network and instead are working within a secure network, the SIP URI would change to sips:, like this:
sips:wiley.com
A SIP URI functions a bit like a standard Web site’s Universal Resource Locator (URL), such as www.ebay.com or www.google.com. These URLs don’t identify the specific servers or hardware that support the eBay and Google Web sites — but it references to the IP address does that. But you can remember a URL much more easily than an IP address.
The Domain Name System (DNS) references URLs to their public IP addresses. In the server, the DNS client (sometimes called the DNS resolver) is the application that matches the URL with the IP address. In the same way that URLs are linked to the servers’ IP addresses, the URIs must also be resolved to their constituent IP addresses.
You may not need to worry about this added DNS resolving step if you’re sending only one call every few minutes. The challenge comes when you’re sending a high volume of calls that require DNS resolution to the Edge Proxy Server (EPS) or Session Boarder Controller (SBC) of a long-distance carrier. They function as your gateway between you and the non-VoIP world of the PSTN that’s used to provide connectivity between every analog phone line and digital circuit in the world. The quantity of calls that these EPSs and SBCs receive prevents them from taking the time to resolve every URI to an IP address, so most carriers now require you to use Fully Qualified Domain Names (FQDNs) that are mapped to a specific IP address. In the preceding example, the Request-Line includes both a phone number and an IP address:
The constituent parts of that address are still the same as in the preceding Request-Line example — but in this instance, the user is +14145551212, and the server providing connectivity to that user is identified by the IP address of 100.100.100.100. If this INVITE (say, for a call to your grandmother in Milwaukee, Wisconsin) was sent to your long-distance carrier to complete, the IP address listed probably isn’t actually a server on which Grammy’s SIP hardphone is registered. The address represents the phone number you want to contact, and the SIP EPS or SBC of your carrier acts as a gateway between your VoIP connection and the PSTN. This type of addressing allows you to convey a call and reach any phone number in the world through your long-distance carrier’s IP address.
SIP ignores dashes in a phone number, so the address could also be written as
The structure of a phone number with a preceding +1 is an industry standard called E.164. It lays out the parameters for domestic and international phone numbers, as described by the international organization of telecom professionals called the ITU-T (International Telecommunications Union Telecommunications Standardization Sector). E.164 numbers establish the quantity of digits available for both the international country code and domestic phone number. Currently, the international country code and the domestic phone number (including the area code, sometimes called the city code in international dialing, and local number) can’t exceed 15 digits. The Internet Engineering Task Force (IETF) took the E.164 standard and enhanced it to work with VoIP endpoints. The IETF developed a procedure called ENUM, that brings together VoIP-originated calls from URIs and allows them to connect to traditional phone numbers anywhere in the world.
Getting into the Message Header
The SIP Message Header contains the basic contact information and rules of engagement for the call:
The key elements of the Message Header portion of the INVITE establish the origination and termination points for the SIP signaling. The Via line of the INVITE identifies the destination server the IP address and port (in this case, IP 200.200.200.200 and port 50 60) to which it should send all SIP messaging. This IP address is frequently the same as the one listed in the From line. It also identifies the version of SIP used (in this case, version 2.0) and that the preceding INVITE example is using UDP to transmit the SIP messaging.
TCP/IP (Transmission Control Protocol/Internet Protocol) is the most common protocol to transmit data across the Internet. It transmits typical computer data reliably because it resends lost packets or transmissions if they fail to arrive at the final destination. (You need to receive a complete computer file, even if
the pieces arrive out of sequence and you have to reassemble them in the correct order.) VoIP uses the User Datagram Protocol (UDP), which is much better suited to the real-time application. UDP is a leaner protocol that doesn’t resend lost packets. If a packet is lost or arrives out of sequence, it’s less disruptive to discard the packet than to attempt to input it into the media stream out of sequence and play a delayed audio packet in a normal sounding conversation.
Branding the transmission with a Call ID
Every SIP call is branded with a call ID located in the Call-ID line of the code. In the example in the preceding section, the call ID looks like this:
The ID isn’t the entire string of data, only the letters and numbers before the symbol and the IP address. The call ID is unique for each call. The call ID performs its task by is reiterating the call ID in every message of the SIP banter between the end points that allow the SIP methods and responses to be linked to the specific call over which they manage.
Limiting the forwarding
Limiting the number of times a call can be forwarded may seem counterintuitive. But all VoIP transmissions are very sensitive to delay. Each time a call is forwarded, that call experiences a few milliseconds of delay. The initial INVITE message in our example places a limit of 70 on the number of times this call can be forwarded.
This isn’t an industry standard. Your SIP software can be modified for any number you want in the Max Forwards field.
Each time the call is forwarded, the number sent in this section of the SIP header is reduced by one to ensure the call does not exceed the Max Forwards number presented in the initial INVITE message for the call.
topic 5 covers latency in detail.
Allowing methods
Not every server accepts every SIP method. SIP is also used for Instant Message and video transmissions. Many of the SIP methods used in those mediums don’t work in voice transmissions, so the initial INVITE message outlines the methods that the originating server accepts. In the example in the section “Getting into the Message Header,” earlier in this topic, the server responds to all the standard SIP methods for VoIP:
These methods are described in the following sections.
Sending another INVITE
Just because the INVITE message is the first SIP method sent, that doesn’t mean it isn’t ever used again in the call. VoIP calls frequently include an additional INVITE message from either the originating or terminating server as a means to negotiate new features (such as special compression software for faxing) or redirect a call to a new server for a conference call, voicemail, or auto-attendant feature.
The use, look, and feel of the Re-INVITE (as it’s commonly known) is covered in detail in topic 10.
Moving a call with REFER
SIP calls are extremely dynamic, and can be rescinded and redirected quite easily. The SIP method REFER (defined in IETF memo number RFC 3261) provides an alternative URI or address in case a third party needs to receive the call in lieu of the current recipient. On the surface, this method looks like a simple Re-INVITE, but it differs in the fact that all the SIP messaging is transferred to the new SIP endpoint in a REFER method, instead of simply redirecting the audio portion of the call. Figure 2-2 compares the REFER and
Re-INVITE methods.
Figure 2-2:
REFER and Re-INVITE comparison.
In this example, the REFER-ed call no longer passes any messaging between the initial SIP Phone A and SIP Phone B. This type of redirect sends not only the media portion of the call carrying the voice portion away from SIP Phone A, but also the overhead. A simple Re-INVITE keeps the SIP overhead processing through SIP Phone A, which acts as an intermediary on the new call. The voice path is the only portion of the call that’s completely separated from SIP Phone A.
The REFER method both looks similar to and requires the same SIP response as a SIP BYE method and can be used at any time during a call. It includes a Refer-To header field that contains the URI of the SIP device to which the call is being referred. Here’s a simple Refer-To header:
Some long-distance carriers don’t like you REFER-ing calls to your friends. The challenge with the REFER method is more logistical than structural. If every end point you’re dealing with is accessed through the Internet, then a REFER works without causing any legal or financial concerns to your VoIP carrier. If SIP Phone B is actually a business line in Boston that uses a VoIP carrier to reach the PSTN, then using the REFER method becomes more complex. This extreme example shows the pitfalls of REFER when handling end points that must be reached through a long-distance carrier. If you call from your office in Boston to a remote employee in London, your long-distance carrier charges you a standard per-minute rate for that call from Boston to London. If you then REFER that call so that your London affiliate can speak to your external sales director on a SIP phone in Nairobi, you just eliminated Boston as any kind of reference point that your long-distance carrier can use for billing. You’re left with a call from London to Nairobi and a long-distance carrier trying to figure out how to accurately rate this new call between England and Kenya. Since the first established point of the call was England, that is seen as the point of origin. That requires that your long-distance carrier be an authorized outbound carrier with the proper British accreditation on file to do business in England. If your carrier isn’t registered as a long-distance carrier in England, it now has a legal/jurisdictional problem, as well as trying to determine the correct per minute rate for a domestic U.S. call that only exists between London and Nairobi.
Confirming a call with an ACK
The SIP method ACK that’s described in the IETF memo number RFC 2543 is essentially used as an acknowledgement (ACK) to a SIP response. ACK is most commonly employed as an acknowledgement to a 200 OK SIP response received after the media portion of a call is established. It can also function to acknowledge other, Non-2XX SIP responses.
This very simple method is designed with detailed information on the call negotiating elements of the message body covered in topic 3. The use of ACK is not confined to use with the 200 OK response, but also confirms aspects of the call offered in other SIP responses. A basic ACK response is
An ACK transmission usually doesn’t contain any additional data or media because its sole purpose is to simply acknowledge a response.
Logging in with REGISTER
A traditional SIP or SIPS URI requires that the server listed in the URI know the user’s location. This is a simple SIP URI:
For the URI to function, the wiley.com server must know where is to send his VoIP calls. To notify the server about the location of the SIP phone, that phone periodically sends a REGISTER method to the server. The server that receives the method is called a registrar, and it maintains a database of users and their locations, so calls can be routed appropriately.
One of the great features of SIP is that it permits more than one end point to log in to the registrar for the same user. So, both a SIP hardphone at work and a SIP softphone on a PC at home can send a REGISTER method to wiley.com, allowing calls to be sent to both locations so you never miss that important call.
A registration doesn’t last forever. The response to a REGISTER should list the time at which the registration period ends in the Expires header. You can request that your REGISTER be valid for a specific duration when your phone sends the REGISTER method to the registrar, but the registrar doesn’t necessarily award you the entire duration that your phone requests. If the response to the REGISTER method doesn’t include an Expires time, your SIP node is most likely registered for the default time of one hour.
The REGISTER method is used only to establish routing for incoming SIP calls. The enrollment of a user on a SIP registrar doesn’t prevent that user from making outbound calls. SIP can qualify outbound calls through a standard challenge-and-password security mechanism, but these validation systems aren’t SIP. They’re based on HTTP authentication.
Signing off
Two SIP methods can end a SIP call. Which method your phone uses depends on whether you’re terminating a call that had the bi-directional voice portion of the call established. A SIP call that processes a normal INVITE message that is responded to with a 200 OK and an ACK indicates the call has full, bi-directional audio that must be torn down, instead of simply cancelling an INVITE. The audio may have been formed before anyone even speaks a word on the call. This is common when calling from, or to a large phone system that prompts you to dial an extension or places you on hold until someone can pick up the line. Even though you can’t speak to another person, you can still hear the recorded messages of the destination phone system, and they can hear the touch tones you press. You not only use a different method to end a call, depending on the situation, the SIP method also functions differently.
There are two SIP methods to end a call:
BYE: The SIP method that ends a call after the voice portion has been established through the normal SIP banter of sending out an INVITE, and receiving a 200 OK replied to with an ACK.
It’s just like any normal call — you dial a number, someone answers, you have a conversation, and one person hangs up the phone. In this case, the VoIP hardware associated with the first person hanging up the call sends a BYE, and the recipient VoIP hardware responds with a 200 OK.
CANCEL: The SIP method that ends a call if the bi-directional audio portion of the call hasn’t been established.
If you hang up a call before the person (or phone system of the person) you dialed picks up the line, you reach a number that has been disconnected, you get a busy signal, or your call attempt leads to anything other than a solid connection, you must use a CANCEL method, which the VoIP hardware receiving it responds to with a SIP response of 487 request terminated.
Determining your OPTIONS
SIP allows you to gather information about a destination server or node without sending it a traditional INVITE message. The OPTIONS method solicits information about the capabilities of the remote device without engaging it in a call. The SIP messaging for an OPTIONS method looks very similar to an
INVITE:
The key difference between the OPTIONS method and any other SIP method request is the addition of an Accept line in the header. This line identifies the desired media capabilities. The preceding example of an OPTIONS method indicates that the originating SIP device accepts SDP (Secession Description Protocol) for its media. SDP and the associated signaling components are reviewed in topic 3.
The SIP device receiving the OPTIONS method replies to it by using a similar SIP response as to an INVITE. The standard response is a 200 OK that lists the capabilities of the node that’s queried. Here’s a typical response to an OPTIONS method:
Updating your call
After you send an INVITE, you may need to renegotiate some aspect of the call. If you haven’t yet received a 100 TRYING or 200 OK from your initial INVITE, you can’t send another INVITE to change the parameters of the call. You can, however, send an UPDATE to negotiate the modification before the initial INVITE is confirmed.
Either end of the VoIP call can send the UPDATE. The response to the UPDATE is delivered in the 200 OK associated with the initial INVITE message. This method updates any aspect of the SIP or media negotiation in the initial INVITE, from the IP address you’re using to receive the SIP information to a modification in the type of compression you want to use for the media portion of the call. The response to the UPDATE establishes a clean slate for the SIP banter when the destination SIP node sends the 200 OK, for the initial INVITE, all of the changes offered and accepted in the UPDATE method are listed.
After the destination end SIP node answers an INVITE with a 200 OK, the VoIP hardware on either end should send a re-INVITE to update the information on any aspect of the call instead of using the UPDATE method. SIP treats the UPDATE method as an urgent transmission and responds immediately, without the need for user approval. Use UPDATE only when you really need it — in all other cases, just re-INVITE.
If the call fails and the destination end SIP node sends a standard SIP reject response to the initial INVITE, such as a 404 Not Found, SIP node receiving it ignores the UPDATE, and the call simply fails.
Making provisional information final
PRACK acts as an ACK for provisional responses (I explain provisional responses in the section “Responding to Methods,” later in this topic). If a normal INVITE receives a response of 180 Trying, it can reply to it with a PRACK.
The PRACK method maintains the integrity of a SIP call when the response from the far end is either delayed or not expected in less than three minutes. Most PRACKs are sent in 2 172 -minute increments to reinforce the provisional responses received and keep the call alive until the final responses arrive.
Spanning technologies with PINT
Gone are the days when VoIP was used almost entirely to span calls from one IP device on the Internet to another. VoIP has integrated itself into the very fabric of the traditional, non-VoIP PSTN. That negotiation of VoIP and PSTN required some help along the way. The challenge is that some cool telephony services are available only in the dusty, traditional world of telecom. PSTN/ Internet Interworking (PINT) service tries to bridge the gap between the neat features on the old technology and the flexibility of VoIP. The PINT protocol uses SIP, and it enables the standard SIP servers and clients as PINT servers and clients.
Figure 2-3 shows how the PINT client, which is also a SIP client, uses the existing SIP proxy to travel the Internet and reach the PINT gateway that sits on the edge of the PSTN. The PINT gateway negotiates requests from PINT clients over the Internet using SIP with the delivery of their requested services or sessions from the PSTN.
PINT is important not only because of what it does, but also because it has three unique SIP methods associated with it:
SUBSCRIBE: A PINT client uses this method to let a PINT server know
that it’s interested in a specific PSTN feature. Maybe you want your daily horoscope or the status of a phone call, or you need specific information on the disposition of a fax to see if it is ringing, negotiating, complete and transmitted successfully. If the information you require is the disposition of a call originated by an INVITE from the PINT client or SIP proxy, the details of the media portion of the call are listed in the SIP response to the INVITE message.
UNSUBSCRIBE: A PINT client uses this method to let a PINT server know
that it’s no longer interested in the PSTN feature for which it initially logged in. This method is the standard way to signify that the PINT client no longer expects a requested PSTN feature to be delivered.
NOTIFY: This method keeps the PINT client updated on the disposition of the PSTN feature for which the PINT client is SUBSCRIBE-d. A NOTIFY update is sent to the PINT client whenever the status of the request for PSTN service changes, including the successful delivery of the PSTN service or notification of a delay incurred in the request.
A PINT gateway can send an UNSUBSCRIBE, regardless of whether the PINT
client requested it. The PINT gateway may time out the request, even if the PINT client has no desire to terminate the request.
Figure 2-3:
PINT network configuration.
SUBSCRIBE methods have an Expires header that specifies when the information you’re requesting (if you’re asking for the disposition of a transmitted fax, for instance) will be purged. If you SUBSCRIBE to pull information but don’t receive that information before the deadline specified in the Expires header that the PINT gateway sends, the information you’ve requested won’t be sent. The PSTN features requested are only available to you during the life of the SUBSCRIBE request. The expiration for the PSTN service requested by the PINT client is either listed in the SIP response to the initial INVITE message or as a response to a SUBSCRIBE or UNSUBSCRIBE method.
