SIP Response Messages
Informational
100 Trying
This special case response is only a hop-by-hop request. It is never forwarded and may not contain a message body. A forking proxy must send a 100 Trying response, since the extended search being performed may take a significant amount of time. 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. A 100 Trying response typically does not contain a To tag.
180 Ringing
This reponse is used to indicate that the INVITE has been received by the user agent and that alerting is taken place. This response is important in interworking with telephony protocols, and it is typically mapped to messages such as an ISDN Progress or ISUP Address Complete Message (ACM). When the user agent answers immediately, a 200 OK is sent without a 180 Ringing; this scenario is called the "fast answer" case in telephony.
A message body in this response could be used to carry QoS or security information, or to convey ring tone or animations from the UAS to the UAC.
A UA normally generates its own ringback tone or remote ringing indication unless a Alert-Info header field is present.
181 Call Is Being Forwarded
This response is used to indicate that the call has been handed off to another end-point. This reponse is sent when this information may be of use to the caller. Also, because a forwarding operation may take longer for the call to be answered this response gives a status for the caller.
182 Call Queued
This response is used to indicate that the INVITE has been received, and will be processed in a queue. The reason phrase can be used to indicate the estimated wait time or the number of caller in line. A message body in this response can be used to carry musc on hold or other media.
183 Session Progress
The 183 Sessioin Progress response indicates that information about the progress of the session (call state) may be present in a message body or media stream. Unlike a 100 Trying reponse, a 183 is an end-to-end response and does establish a dialog (must contain a To tag and Contact). Unlike a 180, 181, or 182 reponse, however, it does not convey any specific information about the status of the INVITE. 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 calliing party's telephone switch to the called party's telephone switch in the PSTN prior to the call being answered. In SIP, the media session is established after the call is answered - after a 200 OK and ACK have been exchanged between the UAC and UAS. If a gateway used a 180 Ringing response instead, no media path would be established between the UAC and the gateway, and the caller would never hear ring tone, busy tone, or a recorded announcement (e.g., "The number you have dialed has changed, the new number is ...") since these are all heard in the media path prior to the call being answered.
Success
Success class responses indicate that the request has succeeded or has been accepted.
200 OK
The 200 OK response has two uses in SIP. When used to accept a session invitation, it will contain a message body containing the media properties of the UAS (calling party). When used in response to other requests, it indicates successful completion or receipt of the request. The response stops further retransmissions of the request. In response to an OPTIONS, the message body may contain the capabilities of the server. A message body may also be present in a response to a REGISTER request. For 200 OK responses to CANCEL, INFO, MESSAGE, SUBSCRIBE, NOTIFY, and PRACK, a message body is not permited.
202 Accepted
The 202 Accepted response indicates that the UAS has received and understood the request, but that the request may not have been authorized or processed by the server. It is commonly used in responses to SUBSCRIBE and REFER, and sometimes MESSAGE methods.
Redirection
Redirection class responses are generally sent by a SIP server acting as a redirect server in response to an INVITE. A UAS, however, can also send a redirection class response to implement certain types of call forwarding features. There is no requirement that a UAC receiving a redirection response must retry the request to the specified address. The UAC can be configured to automatically generate a new INVITE upon receipt of a redirection class response without requiring user intervention. In addition, proxies may also automatically send an ACK to a redirect and proxy the INVITE to the new location provided in the Contact URI of the redirection. To prevent looping, the server must not return any addresses contained in the request Via header field, and the client must check the address returned in the Contact header field against all other address tried in an earlier call attempt.
300 Multiple Choices
This redirection response contains multiple Contact header fields, which indicate that the locatioin service has returned multiple possible location for the sip or sips URI in the Request-URI. The order of the Contact header fields is assumed to be singificant. That is, they should be tried in the order in which they were listed in the response.
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. As a result, the Contact header field should not be cached across calls unless an Expires header field is present, in which case the location is valid for the duration of the time specified.
305 Usd Proxy
This redirection response contains a URI that points to a proxy server who has authoritative information about the calling party. The caller should resend the request to the proxy for forwarding. This response could be sent by a UAS that is using a proxy for incoming call screening. Because the proxy makes the decisions for the UAS on acceptance of the call, the UAS will only respond to INVITE requests that come from the screening proxy. Any INVITE request received directly would automatically receive this response without user intervention.
380 Alternative Service
This response returns a URI that indicates the type of service that the called party would like. An example might be a redirect to a voicemail server.
Client Error
This class of response is used by a server or UAS to indicate that the request cannot be fulfilled as it was submitted. The specific client error response or the presence of certain header fields should indicate to the UAC the nature of the error and how the request can be reformulated. The UAC should not resubmit the request without modifying the request based on the response. The same request, however, can be tried in other locations. A forking proxy receipt of a 4xx response does not terminate the search. Typically, client error reponses 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. An example might be a request that is missing required header fields such as To, From, Call-ID, or CSeq. This response is also used if a UAS receives multiple INVITE requests (not retransmissions) for the same Call-ID.
401 Unauthorized
This response indicates that the request requires the user to perform authentication. This resopnse is generally send by a user agent, since the 407 Proxy Authnentication Required is sent by a proxy that requires authentication. The exceptioin is a registrar server, which sends a 401 Unauthorized response to a REGISTER message that does not contain the proper credentials. An example of this response is:
SIP/2.0 401 Unathorized
Via: SIP/2.0/UDP proxy.globe.org:5060; branch=z9hG4bK2311ff5d.1; received=192.0.2.1
From: ; tag=341323
To: ; tag=19424103
From: Copernicus ; tag=34kdilsp3
Call-ID: [email protected]
CSeq: 1 INVITE
WWW-Authenticate: Digest realm="globe.org", nonce="8eff88df84f1cec4341ae6e5a359", gop="auth", opaque=" ", stale=FALSE, algorithm=MD5
Content-Length: 0
The presence of the required WWW-Authenticate header field is required to give the calling user agent a chance to response with the correct credentials. A typical authentication exchange using SIP digest. Note that the follow-up INVITE request should use the same Call-ID as the original request as the authentication may fail in some cases if the Call-ID is changed from the initial request to the retried request with the proper credentials.
402 Payment Required
This response is a placeholder for future definition in the SIP protocol. It could be used to negotiate call completion changes.
403 Forbidden
This response is 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. This response is not used when authorization is required.
404 Not Found
This response indicates that the user identified by the sip or sips URI in the Require-URI cannot be located by the server, or that the user is not currently signed on with the user agent.
405 Method Not Allowed
This response indicates that the server or user agent has received and understood a request but is not willing to fulfill the request. An example might be a REGISTER request sent to a user agent. An Allow header field must be present to inform the UAC what method are acceptable. This is different from the case of an unknown method, in which a 501 Not Implemented response is returned. Note that a proxy will forward request types it does not understand unless the request is targeted to the proxy server (i.e., the Request-URI is the URI of the proxy server).
406 Not Accpetable
This response indicates that the request cannot be processed due to a requirement in the request message. The Accept header field in the request did not contain any options supported by the UAS.
407 Proxy Authentication Required
This request sent by a proxy indicates that the UAC must first authenticate itself with the proxy before the request can be processed. The response should contain information about the type of credentials required by the proxy in a Proxy-Authenticate header field. The request can be resubmitted with the proper credentials in a Proxy-Authorization header field. Unlike in HTTP, this response may not be used by a proxy to authenticate another proxy.
SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/UDP discrete.sampling.org:5060;branch=z9hG4bK6563;received=65.61.140.198
From: Shannon ;tag=59204
To: Schockley ;tag=142334
Call-ID: [email protected]
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="sampling.org", qop="auth", nonce=9c8e88df84df1cec4341ae6cbe5a359",opaque=" ", stale=FALSE, algorithm=MD5
Content-Length: 0
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. This response could be sent by a forking proxy or a user agent. The request can be retried at any time by the UAC, perhaps with a longer time period in the Expires header field or no Expires header field at all. Alternatively, a stateful proxy can send this response after the request transaction times out without receiving a final response.
409 Conflict
This response code has been removed from RFC 3261 but is defined in RFC 2543. It indicates that the request cannot be processed due to a conflict in the request. This response is used by registrars to reject a registration with a conflicting action parameter.
410 Gone
This response is similar to the 404 Not Found response but contains the hint that the required user will not be available at this location in the futuren. This response could be used by a service provider when a user cancels their service.
411 Length Required
This response code has been removed from RFC 3261 but is defined in RFC 2543. This response can be used by a proxy to reject a request containing a message body but no Content-Length header field. A proxy that takes a UDP request and forwards it as a TCP request could generate this response since the use of Content-Lenght is more critical in TCP requests. However, the response code in not very useful since a proxy can easily calculate the length of message body in a UDP request (it is until the end of the UDP packet) but cannot with a stream-oriented transport such as TCP. In this case, a missing Content-Length header field would cause the message body to go on indenfinitely, which would generate a 513 Message Too Large response instead of a 411 Length Required.
413 Request Entity Too Large
This response can be used by a proxy to reject a request that has a message body that si too large. A proxy suffering congestioni could temporarily generate this responde to save processing long requests.
414 Request-URI Too Long
This response indicates that the Request-URI in the request was too long and cannot be processed correctly. There is no maximum length defined for a Request-URI in the SIP standard document.
415 Unsupported Media Type
This response sent by a user agent indicates that the media type contained in the INVITE request is not supported. For example, a request for a video conference to a PSTN gateway that only handles telephone calls will result in this response. The response should contain header fields to help the UAC reformulate the request.
416 Unsupported URI Scheme
The 416 Unsupported URI Scheme response is new to RFC 3261 and is used when a UAC uses a URI scheme in a Reqeust-URI that the UAS does not understand. For example, if a request URI contains a secure SIP (sips) scheme that a proxy does not understand, it would return a 416 response. Since all SIP elements must understand the sip scheme, the request should be retried using a sip uri in the request-uri.
420 Bad Extensioin
This response indicates that the extension specified in the Require header field is not supported header field listing the extensions that are supported. The UAC could resubmit the same request without the extension in the Requrie header field or submit the request to another proxy or user agent.
421 Extension Required
The 421 Extension Required response indicates that a server requires an extension to process the request that was not present in a Supported header field in the request. The required extension should be listed in a Required header field in the response. The client should retry the request adding the extension to a Supported header field, or try the request at a different server that may not require the extension.
422 Session Timer Interval Too Small
The 422 Session Timer Interval Too Small response is used to reject a request containing a Session-Expires header field with too short an interval. The ability to reject short durations is important to prevent excessive re-INVITE or UPDATE traffic. The minimun allowed interval is indicated in the required Min-SE header field. The requestor may retry the request without the Session-Expires header field or with a value less than or equal to the specified minimum.
423 Interval Too Brief
The 423 Interval Too Brief response is returned by a registrar that is rejecting a registration request because the requested expiration time on one or more Contacts is too brief. The response must contain a Min-Expires header field listing the minimum expiration interval that the registrar server with registratioin refresh requests - this response allows a registrar to protect against this.
428 Use Authentication Token
The 428 Use Authentication Token response is used by a UAS that is requiring the use of an Authentication Information Body (AIB). The AIB is a S/MIME body that is an encrypted message/sip or message/sipfrag body. At a minimum, an AIB must contain the From, Date, and Call-ID header fields as well. (The selection of these header fields is to prevent cut-and-paste attacks and hijacking.) The SIP request should contain a Content-Type: message/sipfrag header field and a Content-Disposition: aib; handing=optional header field.
429 Provide Referror Identity
The 429 Provide Referror Identity response is used to request that a Referred-By header field be re-sent with a valid Referred-By security token. The security token is carried as an S/MIME message body. The recipient of this error message (the UA that received and accepted the REFER) should relay this request back to the originator of the REFER by including it a NOTIFY. The send of the REFER can then generate the Referred-By security token and include it in the REFER, which would then be copied into the triggered request.
480 Temporarily Unavailable
This response indicates that the request has reached the correct destination, but the called party is not available for some reason. The reason phrase should be modified for this response to give the caller a better understanding of the situation. The response should contain a Retry-After header indicating when the request may be able to be fulfilled. For example, this response could be sent when a telephone has its ringer turned off, or a "do not disturb" button has been pressed. This response can also be sent by a redirect server.
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 previdously forwarded the request. Each server that forwards a request adds a Via header with its address to the top of the request. A branch parameter is added to the Via header, which is a hash function of the Request-URI, and the To, From, Call-ID, and CSeq number. A second part is added to the branch parameter if the request is being forked. The reason the branch parameter must be checked is to allow a request to be routed back to a proxy, provided that the Request-URI has changed. This could happen with a call forwarding feature. In this case, the Via headers would differ by having different branch parameters.
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. This is indicated by the receipt of a Max-Forwards: 0 header in a request. In the following example, the UAC include a Max-Forwards: 4 header in the REGISTER request. A proxy receiving this request five hops later generates a 483 response:
REGISTER sip:registrar.timbuktu.tu SIP/2.0
Via: SIP/2.0/UDP 201.202.203.204:5060; branch=z9hG4bK45347.1
Via: SIP/2.0/UDP 198.20.2.4:6128; branch=z9hG4bK917a4d4.1
Via: SIP/2.0/UDP 18.56.3.1:5060; branch=z9hG4bK7154.1
Via: SIP/2.0/TCP 101.102.103.104:5060; branch=z9hG4bKa5ff4d3.1
Via: SIP/2.0/UDP 168.4.3.1:5060; branch=z9hG4bK676746
To: sip:[email protected]
From: ; tag=341323
Call-ID: [email protected]
CSeq: 1 REGISTER
Max-Forwards: 0
Contact: sip:[email protected]
Content-Length: 0
SIP/2.0 483 Too Many Hops
Via: SIP/2.0/UDP 201.202.203.204:5060; branch=z9hG4bK45347.1
Via: SIP/2.0/UDP 198.20.2.4:6128; branch=z9hG4bK917a4d4.1
Via: SIP/2.0/UDP 18.56.3.1:5060; branch=z9hG4bK7154.1
Via: SIP/2.0/TCP 101.102.103.104:5060; branch=z9hG4bKa5ff4d3.1
Via: SIP/2.0/UDP 168.4.3.1:5060; branch=z9hG4bK676746
To: ; tag=a5642
From: ; tag=341323
Call-ID: [email protected]
CSeq: 1 REGISTER
Content-Length: 0
484 Address Incomplete
This response indicates that the Request-URI address is not complete. This could be used in an overlap dialing scenario in PSTN interworking where digits are collected and sent until the complete telephone number is assembled by a gateway and routed. Note that the follow-up INVITE requests may use the same Call-ID as the original request.
485 Ambiguous
This request indicates that the Request-URI was ambiguous and must be clarified in order to be processed. This occurs if the username matches a number of registrations. This occurs if the username matches a number of registratioins. If the possible matching choices are returned in Contact header fields, then this response is similar to the 300 Multiple Choices response. They are slightly different, however, since the 3xx response returns equivalent choices for the same user, but the 4xx response returns alternatives that can be different users. The 3xx response can be processed without human intervention, but this 4xx response requires a choice by the caller, which is why it is classifed as a client error class response. A server configuration; otherwise a vague or general Request-URI could be used by a rogue user agent to try to discover sip or sips URIs of registered users.
486 Busy Here
This response is used to indicate that the user agent cannot accept the call at this location. This is different, however, from the 600 Busy Everywhere response, which indicates that the request should not be tried elsewhere. In general, a 486 Busy Here is sent by a UAS unless it knows definitively that the user cannot be contacted. 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.
488 Not Acceptable Here
This response indicates that some aspect of the proposed session is not acceptable and may contain a Warning header field indicating the exact reason. This response has a similar meaning to 606 Not Acceptable, but only applies to one location and may not be true globally as the 606 response indicates.
489 Bad Event
The 489 Bad Event response is used to reject a subscription request or notification containing an Event package that is unknown or not supported by the UAS. The response code is also used to reject a subscriptioin request that does not specify an Event package, assuming that the server does not support the PINT protocol.
491 Request Pending
The 491 Request Pending response is used to resolve accidental simultaneous re-INVITEs by both parties in a dialog. Since both INVITEs seek to change the session, they cannot be processed at the same time. While a user agent is awaiting a final response to a re-INVITE, any re-INVITE request received must be replied to with this response code. This is analogous to the "glare" condition in telephony in which both ends seize a trunk at the same time. The reconsideration algorithm in SIP is for the user agent to generate a delay (randomly selected within a range determined by if the user agent send the initial INVITE or not) then retry the re-INVITE, assuming that another re-INVITE has not been received in the meantime. In this way, one side or the other will "win" the race conditioin and have the re-INVITE proecessed.
493 Request Undecipherable
The 493 Request Undecipheralbe repsonse is used when an S/MIME UAS odes not supported S/MIME, no message body will be present in the respnse. If the UAS does supported S/MIME, the response will contain in a message body containing a public key suitable for the UAC to use for S/MIME encryption.