The SIP methods are often tied to, or limited by, the SIP response received. All SIP responses are presented in three-digit numeric codes and referred to in denominations of 100 that identify the permutations of success, failure, or disposition of action requested in the preceding SIP method. SIP numbered responses range from 100 to 699, as shown in the following sections.
SIP responses aren’t infallible. They’re generated in response to specific situations and events, and every SIP node sending a response has its own qualifications for when one response is required over another. If someone wrote his or her own SIP code, he or she could configure it to send a 604 response in a situation in which other devices might send a 503 or a 410. Most of the time, everyone plays by the same rules and you get expected and mundane SIP responses. You see more 100 Trying, 180 Ringing, and 200 OK responses than all the others combined. When you’re using the SIP response codes to trouble-shoot, don’t get hung up on the specifics of the code. Just use the response as an general indication about what the code most likely represents, and you’ll do fine.
Aside from the numerical breakdown of SIP responses into the 1XX, 2XX, 3XX, 4XX, 5XX, or 6XX group, they fit into two larger categories:
Final responses provide actionable intelligence. If you get a response telling you that the call connected and the audio portion is established, you can accept that information, act on it, and finish establishing your call. The final responses are sent by reliable means to the server that sent the INVITE, and they trigger the progression of call establishment, disconnect, and are acted on by VoIP phone systems to route calls.
Provisional responses aren’t sent by reliable means. If all VoIP was conducted only between two VoIP servers using a well managed private Internet connection between them, the issue of provisional responses wouldn’t be that important. A controlled environment like a private network almost eliminates the possibility of lost packets or failures due to connectivity. Every message is sent reliably, and so no provisional responses need to be sent while a server waits for a response from the far end. The challenge comes because most VoIP calls now enter the PSTN with every other non-VoIP call, so the gateway at your VoIP carrier needs to connect the high-speed VoIP phone at your house to the analog, rotary-dial phone at grandma’s house. A VoIP call needs to know what’s going on all the time. If it doesn’t receive a prompt response from the far end of the call, it thinks something bad has happened. Post-Dial-Delay (PDD), that 5- to 35-second delay before you hear the line start to ring, is a common condition when dialing someone internationally, and even domestically. PDD on a non-VoIP call doesn’t cause any problems, but a delay of as little as a second starts to make VoIP anxious.
100s: Receiving information
The SIP responses in the 1XX series are provisional responses that just keep you updated on the progress of a call. They’re sent mainly to let you know that the SIP server at the other end hasn’t forgotten about you, in spite of the fact that the line isn’t ringing yet. The provisional responses are sent if the server thinks that you’ll be waiting at least 200 milliseconds before it has a final response to send to you. The responses are SIP packets sent in the overhead of the call, and are only realized by a caller when they trigger your phone system to do something, like play ringing in your ear before the person you called answers. The three informational responses you see the most are
100 Trying: The most typical first response you receive back from a submitted INVITE. This response simply tells you that the INVITE method was received and is being processed, but that all the connections on the back end of the call aren’t done yet. The call may need to be converted from VoIP to pass through the PSTN, or it may simply need to be forwarded downstream through more servers.
180 Ringing: This response is usually sent after a 100 Trying and is used to trigger your SIP phone or VoIP phone system to play back a ringing sound in your ear. The traditional analog phone you called is ringing, but since bi-directional audio hasn’t been established on the VoIP portion of the call, the VoIP gateway sends you the 180 Ringing to alert your SIP device to play its internal ring-back recording.
183 Session Progress: This response is sometimes sent in lieu of the 180 Ringing when your call is immediately received into a VoIP phone system. The phone remains silent (no ring-back is played) while you wait for the call to connect to the number dialed.
200s: Achieving success
SIP responses in the 2XX series are final responses. The most common 2XX series SIP response is the 200 OK. This response code contains the negotiated response to all the information proposed in the INVITE message. If the INVITE message requests a specific type of compression for the media of the call, or any type of special handling or routing, the 200 OK response confirms what the receiving server can accept. A simple 200 OK response looks like this:
The preceding response to the INVITE message identifies the SIP methods the responding SIP node uses and validates all the IP and URI information required to engage in the SIP dialog.
The 200 OK response requires its own confirmation from the receiving server. SIP isn’t configured to reply to a SIP response with another SIP response, so the correct confirmation to a 200 OK SIP is the SIP ACK method.
300s: Being redirected
Not every SIP INVITE ends up receiving a neat little 200 OK with a bow on it. Sometimes, just like sending a letter to someone’s house, the recipient may have moved (temporarily or permanently) or may have more than one location at which you can try to reach him or her. The 3XX SIP responses handle all these situations in which your call must be redirected. They include the following responses:
‘ 300 Multiple Choices: This response lets the INVITE know that it needs to send INVITE-s to a few other endpoints and to the primary URI it initially contacted. The original SIP end point may have been too limiting. After losing too many calls while you’re in meetings, at home, or on the road, you might decide to receive your calls through every means possible. SIP has the ability to send a single call to multiple end points, and so you can have your calls sent to not only the SIP softphone on the computer at your desk, but also to the SIP hardphone in the conference room, the VoIP service you have at your home, and the VoIP phone system in the office, which forwards the call to your cell phone.
Despite all these options about where you can receive your call, you must let the server sending the INVITE know where the call is received. The initial INVITE specified a single URI and end point, so the SIP node or proxy sending the 300 response keeps the SIP nodes aware of the new end point options (which weren’t listed in the initial INVITE).
301 Moved Permanently: A normal response when a SIP URI has been moved, but the server receiving the initial INVITE message still knows where to find the intended extension. When you receive a 301 response, program your SIP proxy or phone system to keep the information and update your address topic or database to expedite connections to the same SIP URI in the future.
‘ 302 Moved Temporarily: This response is like holiday routing on your phone line. You aren’t at your house in the suburbs, but by having your mail redirected to your beach house, your friends can still reach you. The 302 Moved Temporarily response does the same thing. It alerts the server sending the INVITE that you’re not at the SIP URI listed in the contact header field. The server knows both where you are now and for how
long you’ll be there. Your new address is listed in the Contact Header field, and the Expires section of the SIP header alerts the INVITE-ing server about how long you’ll be available at the alternative location.
‘ 305 Use Proxy: A straightforward response telling the originating SIP node to refrain from sending VoIP calls directly to you, but instead to contact your SIP proxy. The originating SIP device should retain this information, just as if it had received a 301 Moved Permanently response. You can’t configure the SIP hardware of everyone that might send you a VoIP call to identify and hold this information from 301 responses, but you can ensure it is set up within your own hardware.
‘ 380 Alternative Service: This response is actually more of a failure with a silver lining. The 380 response tells you that the call attempt failed but that alternative services are available and defined within the message body of the response.
400s: Receiving a client error
4XX responses are some of the least desirable responses in the SIP world. This section of SIP responses has the largest variety of established codes, and they all indicate the many splendid ways that your call can fail.
Here’s a sampling of the many 4XX response codes:
400 Bad Request: Indicates that something in the syntax of the request was flawed.
This response generally alerts you to the source of the problem, and the Reason-Phrase section of the header may tell you how to fix it.
401 Unauthorized: This rejection is usually used only by SIP registrars and indicates that you need to authenticate your registration.
403 Forbidden: The server knows what you want but won’t connect you to the required extension or SIP device.
This response is the SIP equivalent of slamming the door in your face.
404 Not Found: The server has received your request, has checked its database of extensions and registered SIP devices, but can’t find the end point you’re trying to reach.
405 Method Not Allowed: Indicates that the SIP method submitted isn’t supported by the far-end server. The good news is that this response also includes a list of the SIP methods that are acceptable.
408 Request Timeout: SIP is a protocol that’s very aware of how much time it takes to do anything, and it likes to keep you informed. If it can’t find the final SIP endpoint requested in a timely manner (maybe if that endpoint is too many hops away), you receive a 408 response. It tells
you that the originating SIP proxy server really tried to find the final SIP node or execute the command — but it just took too long, so your SIP proxy server eventually gave up.
‘ 410 Gone: This response tells you that the SIP URI you’re looking for is gone and left no forwarding address. The server you contacted is aware that, at one point in time, the SIP URI was active.
If the server has more information about the destination URI, such as where it moved to or when it would be back, you receive a 3XX code with that information. If you get a 410 response, move on.
‘ 415 Unsupported Media Type: This rejection code is a popular one in the VoIP faxing arena. If you’re using any of the advanced compression techniques for fax (which are covered in detail in topic 6), one of the SIP devices at the far end (or any place in the middle) may not support that technique. The incompatible device kicks out a 415 rejection, and either lists the compression algorithms it can support or identifies the wayward configuration.
SIP is nothing if not a helpful protocol, and the 415 rejection is nice enough to list the acceptable media types in the Accept, Accept-Encoding, and Accept-Language fields in the SIP header.
‘ 480 Temporarily Unavailable: If your SIP phone has logged off because you left for the day, or if you’ve activated the Do Not Disturb feature on your phone, your SIP proxy sends a 480 response to anyone trying to reach you. This simple rejection means, “Try again later.” Some 480 responses also tell you when to try back.
‘ 487 Request Terminated: A pending SIP method waiting for a response can be stopped by either the origination or destination SIP node sending a BYE or CANCEL method. When this method is sent, the first SIP method receives a 487 response, indicating that the request associated with it was rejected because it received the BUY or CANCEL method.
500s: Receiving a server failure
The 5XX series responses pertain only to rejections or dispositions of the SIP servers that support the final SIP device.
The most common 5XX series responses you encounter are
500 Server Internal Error: Similar to the server error you receive when you can’t reach your favorite Web site. The server error may be temporary, and if you attempt the call again later, you may be able to connect.
503 Service Unavailable: If you dial a phone number that isn’t built into the dial plan of the destination SIP server, that server probably replies with a 503 Service Unavailable response. This problem may be temporary, as well, if the entire destination SIP server is down due to a power outage.
The most common reason for a SIP server returning a 503 response is because the routing for the specific SIP URI you’re trying to reach isn’t yet fully constructed and active.
504 Server Time-Out: Very similar to the 408 Request Time-out response, but instead of the origination SIP proxy being unable to respond to your VoIP phone in a timely manner, it’s the terminating SIP proxy that can’t get a response from the final SIP node and respond to your request.
505 Version Not Supported: The SIP protocol you’re using isn’t supported by the destination SIP server.
600s: Going nowhere with a Global Failure
The 6XX series responses are referred to as global failures. It sounds very daunting, but the failures aren’t really global. They’re specific to a final SIP node or the proxy server for the SIP node.
The 6XX response comes in only four varieties, which are similar to other responses in the 3XX, 4XX, and 5XX series:
600 Busy Everywhere: This response doesn’t mean that you can’t call anyone — it’s not as if the entire Internet is busy and you can’t send a single INVITE. It simply means that the server you’ve sent your INVITE to can’t reach the SIP phone or device you’re trying to reach.
603 Decline: the SIP phone or device you’re calling can decide whether it wants to decline all incoming calls to it. Like the 480 response, you might get a note about when to try the end device again — which you can find in the Retry-After header field of the SIP transmission.
604 Does Not Exist Anywhere: The SIP URI you’re trying to reach isn’t known anywhere in the universe of SIP URIs associated with the SIP server receiving your request.
606 Not Acceptable: SIP methods that request addressing syntax, bandwidth, or media types that aren’t accepted by the server receive this response. It may explain suitable addressing or media, or it may list the reasons the session can’t be supported in a Warning header.
