Call Us Today! 877.742.2583




Page tree
Skip to end of metadata
Go to start of metadata

About

The SIP protocol specifies messages that communicate status between endpoints. Each standardized message is indexed by a number as listed below.

RFC 3261


 Click here to expand ToC

Requests

  • INVITE Indicates that a user is being invited to join a session.
  • ACK Confirms that client has received a response to the invite message.
  • BYE Terminates a call.
  • CANCEL Cancels any Pending Searches.
  • OPTIONS Queries for Capabilities.
  • REGISTER Registers the Address listed in the header field with a SIP Server.

Responses

1xx Informational Messages

  • 100 Trying: Indicates that a request has been initiated by the caller and the called party has yet not been located.

  • 180 Ringing: Indicates that the called party has been located and is being notified of the call.

  • 181 Call is being forwarded: Indicates that the called party has rerouted the call to another.

  • 182 Queued: Indicates that the called party is currently not available, and have put the call in queue.

  • 183 Session in Progress

2xx Successful Responses

  • 200 OK: Indicates that the request has been successfully processed.

3xx Redirection Responses

  • 300 Multiple Choices: Indicates that the address resolved to more than one location.

  • 301 Moved permanently: Indicates user is no longer available at this location, an alternate location should be included in the header.

  • 302 Moved Temporarily: Indicates that the user in temporarily unavailable, an alternate location should be included in the header.

  • 305 Use Proxy: This response indicates that the caller must use a proxy to contact the called party.

  • 380 Call is not successful but alternate services are available.

4xx Request Failure Responses

  • 400 Bad Request: Indicates the request sent could not be understood.

  • 401 Unauthorized Request: Indicates the request requires authorization.

  • 402 Payment Required: Indicates payment is required to complete the call.

  • 403 Forbidden: Indicates Server has received the request but will not provide the service.

  • 404 Not Found: Indicates the server was not found.

  • 405 Method Not Allowed: Indicates that the request contains a list of methods that are not allowed.

  • 406 Not acceptable: Indicates that the request can not be processed by the client.

  • 407 Proxy Authentication Required: Client must first authenticate itself with a proxy.

  • 408 Request Timeout: The server could not produce a response before a given time out.

  • 409 Conflict: Indicates a conflict with the current state of the resource.

  • 410 Gone: Resource is no longer available at the server and no forwarding address was found.

  • 411 Length Required: User refuses request without a specified length.

  • 412 Request Entity Too Large: Server refuses to process request because URI is too long.

  • 415 Unsupported Media: Indicates the format of the body is not supported by the destination endpoint.

  • 420 Bad Extension: The server could not understand the protocol extension indicated in the required header.

  • 480 Temporarily Unavailable: Indicates that the called party was contacted but was temporarily unavailable.

  • 481 Call Leg Transaction Does Not Exist: Indicates that the server was ignoring the request of bye or cancel since there is no matching Invite transaction.

  • 482 Loop Detected: (Also, Request Merged) Server received a request which has it self in the path.

  • 483 Too Many Hops: The server received a request that required more hops than allowed.

  • 484 Incomplete Address: The server received a request with an incomplete address.

  • 485 Ambiguous: Server received a request in which the called address is ambiguous.

  • 486 Busy Here: The called party was contacted but the system was not able to receive any more calls.

  • 487 Request Terminated: The calling party canceled the request before the dialog was established with a 200 OK.

  • 488 Not Acceptable Here

  • 489 Bad Event: See RFC3265

  • 491 Request Pending

  • 493 Undecipherable

  • 494 Security Agreement Required: See RFC3329

5xx Server Failure Responses

  • 500 Server Internal Error: Server encountered an unexpected error and could not process the request

  • 501 Not Implemented: Server does not support the functions required to complete the request.

  • 502 Bad Gateway: Server received an invalid request upstream.

  • 503 Service Unavailable: Server has an overload or maintenance problem.

  • 504 Gateway Timeout: Server did not receive a timely response from another server.

  • 505 Version Not Supported: Server does not support the SIP protocol used in the request.

6xx Global Failure Responses

  • 600 Busy Everywhere: Called party is busy and cannot take the call at this time.
  • 603 Decline: Called party was contacted but does not want to take part in the call.
  • 604 Does Not Exist Anywhere: Called Party does not exist anywhere in the network.
  • 606 Not Acceptable: Called party has rejected some part of the call session description as unacceptable.

Example: Playback custom error message

 

Dialplan example
<action application="set" data="hangup_on_bridge=true"/>
<action application="set" data="continue_on_fail=true"/>
<action application="bridge" data="..."/>
<action application="lua" data="playerror.lua"/>

That'll run the lua script after the bridge, but only if the bridge fails.

In the lua script:

Lua script
cause = session:getVariable("originate_disposition")
if (cause == "USER_BUSY") then
    session:streamFile("ivr/ivr-user_busy.wav");
elseif (cause == "UNALLOCATED_NUMBER") then
    session:streamFile("ivr/ivr-unallocated_number.wav");
elseif (cause == "NO_USER_RESPONSE" or cause=="NO_ANSWER") then
    session:streamFile("ivr/ivr-no_user_response.wav");
else
    session:streamFile("ivr/ivr-please_check_number_try_again.wav");
end

See Hangup_Causes for the full list of causes.


Alternatively you can now use transfer_on_fail like this

Dialplan Example transfer_on_fail
<action application="set" data="hangup_on_bridge=true"/>
<action application="set" data="continue_on_fail=true"/>
<action application="set" data="transfer_on_fail=UNALLOCATED_NUMBER auto_cause xml error"/>
<action application="bridge" data="A..."/>

<action application="bridge" data="B..."/>

 

then have the an "Error" context in your dialplan.
Dialplan Context error
<context name="error">
    <extension name="UNALLOCATED_NUMBER" continue="true">
      <condition field="${originate_disposition}" expression="UNALLOCATED_NUMBER" continue="false" break="on-true">
        <action application="playback" data="/usr/local/freeswitch/sounds/NotInService.wav"/>
        <action application="hangup" data="NORMAL_CLEARING"/>
      </condition>
    </extension>
</context>

See Also