From Wikipedia, the free encyclopedia
The Session Initiation Protocol (SIP) is a signalling protocol used for controlling communication sessions such as Voice over IP telephone calls. SIP is based on request/response transactions, in a similar manner to the Hypertext Transfer Protocol (HTTP). Each transaction consists of a SIP request (which will be one of several request methods), and at least one response.[1]: p11
SIP requests and responses may be generated by any SIP user agent; user agents are divided into clients (UACs), which initiate requests, and servers (UASes), which respond to them.[1]: §8 A single user agent may act as both UAC and UAS for different transactions:[1]: p26 for example, a SIP phone is a user agent that will be a UAC when making a call, and a UAS when receiving one. Additionally, some devices will act as both UAC and UAS for a single transaction; these are called Back-to-Back User Agents (B2BUAs).[1]: p20
SIP responses specify a three-digit integer response code, which is one of a number of defined codes that detail the status of the request. These codes are grouped according to their first digit as «provisional», «success», «redirection», «client error», «server error» or «global failure» codes, corresponding to a first digit of 1–6; these are expressed as, for example, «1xx» for provisional responses with a code of 100–199.[1]: §7.2 The SIP response codes are consistent with the HTTP response codes, although not all HTTP response codes are valid in SIP.[1]: §21
SIP responses also specify a «reason phrase», and a default reason phrase is defined with each response code.[1]: §7.2 These reason phrases can be varied, however, such as to provide additional information[1]: §21.4.18 or to provide the text in a different language.[1]: §20.3
The SIP response codes and corresponding reason phrases were initially defined in RFC 3261.[1] That RFC also defines a SIP Parameters Internet Assigned Numbers Authority (IANA) registry to allow other RFC to provide more response codes.[1]: §27 [2]
This list includes all the SIP response codes defined in IETF RFCs and registered in the SIP Parameters IANA registry as of 27 January 2023. This list also includes SIP response codes defined in obsolete SIP RFCs (specifically, RFC 2543), which are therefore not registered with the IANA; these are explicitly noted as such.
SIP responses may also include an optional Warning header, containing additional details about the response. The Warning contains a separate three-digit code followed by text with more details about the warning.[1]: §20.43 The current list of official warnings is registered in the SIP Parameters IANA registry.
1xx—Provisional Responses[edit]
- 100 Trying
- Extended search being performed may take a significant time so a forking proxy must send a 100 Trying response.[1]: §21.1.1
- 180 Ringing
- Destination user agent received INVITE, and is alerting user of call.[1]: §21.1.2
- 181 Call is Being Forwarded
- Servers can optionally send this response to indicate a call is being forwarded.[1]: §21.1.3
- 182 Queued
- Indicates that the destination was temporarily unavailable, so the server has queued the call until the destination is available. A server may send multiple 182 responses to update progress of the queue.[1]: §21.1.4
- 183 Session Progress
- This response may be used to send extra information for a call which is still being set up.[1]: §21.1.5
- 199 Early Dialog Terminated
- Can be used by User Agent Server to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated.[3]
2xx—Successful Responses[edit]
- 200 OK
- Indicates that the request was successful.[1]: §21.2.1
- 202 Accepted
- Indicates that the request has been accepted for processing, but the processing has not been completed.[4]: §7.3.1 [5] Deprecated.[6]: §8.3.1 [2]
- 204 No Notification
- Indicates the request was successful, but the corresponding response will not be received.[7]
3xx—Redirection Responses[edit]
- 300 Multiple Choices
- The address resolved to one of several options for the user or client to choose between, which are listed in the message body or the message’s Contact fields.[1]: §21.3.1
- 301 Moved Permanently
- The original Request-URI is no longer valid, the new address is given in the Contact header field, and the client should update any records of the original Request-URI with the new value.[1]: §21.3.2
- 302 Moved Temporarily
- The client should try at the address in the Contact field. If an Expires field is present, the client may cache the result for that period of time.[1]: §21.3.3
- 305 Use Proxy
- The Contact field details a proxy that must be used to access the requested destination.[1]: §21.3.4
- 380 Alternative Service
- The call failed, but alternatives are detailed in the message body.[1]: §21.3.5
4xx—Client Failure Responses[edit]
- 400 Bad Request
- The request could not be understood due to malformed syntax.[1]: §21.4.1
- 401 Unauthorized
- The request requires user authentication. This response is issued by UASs and registrars.[1]: §21.4.2
- 402 Payment Required
- Reserved for future use.[1]: §21.4.3
- 403 Forbidden
- The server understood the request, but is refusing to fulfill it.[1]: §21.4.4 Sometimes (but not always) this means the call has been rejected by the receiver.
- 404 Not Found
- The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.[1]: §21.4.5
- 405 Method Not Allowed
- The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI.[1]: §21.4.6
- 406 Not Acceptable
- The resource identified by the request is only capable of generating response entities that have content characteristics but not acceptable according to the Accept header field sent in the request.[1]: §21.4.7
- 407 Proxy Authentication Required
- The request requires user authentication. This response is issued by proxies.[1]: §21.4.8
- 408 Request Timeout
- Couldn’t find the user in time. The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time.[1]: §21.4.9
- 409 Conflict
- User already registered.[8]: §7.4.10 Deprecated by omission from later RFCs[1] and by non-registration with the IANA.[2]
- 410 Gone
- The user existed once, but is not available here any more.[1]: §21.4.10
- 411 Length Required
- The server will not accept the request without a valid Content-Length.[8]: §7.4.12 Deprecated by omission from later RFCs[1] and by non-registration with the IANA.[2]
- 412 Conditional Request Failed
- The given precondition has not been met.[9]
- 413 Request Entity Too Large
- Request body too large.[1]: §21.4.11
- 414 Request-URI Too Long
- The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.[1]: §21.4.12
- 415 Unsupported Media Type
- Request body in a format not supported.[1]: §21.4.13
- 416 Unsupported URI Scheme
- Request-URI is unknown to the server.[1]: §21.4.14
- 417 Unknown Resource-Priority
- There was a resource-priority option tag, but no Resource-Priority header.[10]
- 420 Bad Extension
- Bad SIP Protocol Extension used, not understood by the server.[1]: §21.4.15
- 421 Extension Required
- The server needs a specific extension not listed in the Supported header.[1]: §21.4.16
- 422 Session Interval Too Small
- The received request contains a Session-Expires header field with a duration below the minimum timer.[11]
- 423 Interval Too Brief
- Expiration time of the resource is too short.[1]: §21.4.17
- 424 Bad Location Information
- The request’s location content was malformed or otherwise unsatisfactory.[12]
- 425 Bad Alert Message
- The server rejected a non-interactive emergency call, indicating that the request was malformed enough that no reasonable emergency response to the alert can be determined.[13]
- 428 Use Identity Header
- The server policy requires an Identity header, and one has not been provided.[14]: p11
- 429 Provide Referrer Identity
- The server did not receive a valid Referred-By token on the request.[15]
- 430 Flow Failed
- A specific flow to a user agent has failed, although other flows may succeed. This response is intended for use between proxy devices, and should not be seen by an endpoint (and if it is seen by one, should be treated as a 400 Bad Request response).[16]: §11.5
- 433 Anonymity Disallowed
- The request has been rejected because it was anonymous.[17]
- 436 Bad Identity-Info
- The request has an Identity-Info header, and the URI scheme in that header cannot be dereferenced.[14]: p11
- 437 Unsupported Certificate
- The server was unable to validate a certificate for the domain that signed the request.[14]: p11
- 438 Invalid Identity Header
- The server obtained a valid certificate that the request claimed was used to sign the request, but was unable to verify that signature.[14]: p12
- 439 First Hop Lacks Outbound Support
- The first outbound proxy the user is attempting to register through does not support the «outbound» feature of RFC 5626, although the registrar does.[16]: §11.6
- 440 Max-Breadth Exceeded
- If a SIP proxy determines a response context has insufficient Incoming Max-Breadth to carry out a desired parallel fork, and the proxy is unwilling/unable to compensate by forking serially or sending a redirect, that proxy MUST return a 440 response. A client receiving a 440 response can infer that its request did not reach all possible destinations.[18]
- 469 Bad Info Package
- If a SIP UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 response, which contains a Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests.[19]
- 470 Consent Needed
- The source of the request did not have the permission of the recipient to make such a request.[20]
- 480 Temporarily Unavailable
- Callee currently unavailable.[1]: §21.4.18
- 481 Call/Transaction Does Not Exist
- Server received a request that does not match any dialog or transaction.[1]: §21.4.19
- 482 Loop Detected
- Server has detected a loop.[1]: §21.4.20
- 483 Too Many Hops
- Max-Forwards header has reached the value ‘0’.[1]: §21.4.21
- 484 Address Incomplete
- Request-URI incomplete.[1]: §21.4.22
- 485 Ambiguous
- Request-URI is ambiguous.[1]: §21.4.23
- 486 Busy Here
- Callee is busy.[1]: §21.4.24
- 487 Request Terminated
- Request has terminated by bye or cancel.[1]: §21.4.25
- 488 Not Acceptable Here
- Some aspect of the session description or the Request-URI is not acceptable.[1]: §21.4.26
- 489 Bad Event
- The server did not understand an event package specified in an Event header field.[4]: §7.3.2 [6]: §8.3.2
- 491 Request Pending
- Server has some pending request from the same dialog.[1]: §21.4.27
- 493 Undecipherable
- Request contains an encrypted MIME body, which recipient can not decrypt.[1]: §21.4.28
- 494 Security Agreement Required
- The server has received a request that requires a negotiated security mechanism, and the response contains a list of suitable security mechanisms for the requester to choose between,[21]: §§2.3.1–2.3.2 or a digest authentication challenge.[21]: §2.4
5xx—Server Failure Responses[edit]
- 500 Internal Server Error
- The server could not fulfill the request due to some unexpected condition.[1]: §21.5.1
- 501 Not Implemented
- The server does not have the ability to fulfill the request, such as because it does not recognize the request method. (Compare with 405 Method Not Allowed, where the server recognizes the method but does not allow or support it.)[1]: §21.5.2
- 502 Bad Gateway
- The server is acting as a gateway or proxy, and received an invalid response from a downstream server while attempting to fulfill the request.[1]: §21.5.3
- 503 Service Unavailable
- The server is undergoing maintenance or is temporarily overloaded and so cannot process the request. A «Retry-After» header field may specify when the client may reattempt its request.[1]: §21.5.4
- 504 Server Time-out
- The server attempted to access another server in attempting to process the request, and did not receive a prompt response.[1]: §21.5.5
- 505 Version Not Supported
- The SIP protocol version in the request is not supported by the server.[1]: §21.5.6
- 513 Message Too Large
- The request message length is longer than the server can process.[1]: §21.5.7
- 555 Push Notification Service Not Supported
- The server does not support the push notification service identified in a ‘pn-provider’ SIP URI parameter[22]: §14.2.1
- 580 Precondition Failure
- The server is unable or unwilling to meet some constraints specified in the offer.[23]
6xx—Global Failure Responses[edit]
- 600 Busy Everywhere
- All possible destinations are busy. Unlike the 486 response, this response indicates the destination knows there are no alternative destinations (such as a voicemail server) able to accept the call.[1]: §21.6.1
- 603 Decline
- The destination does not wish to participate in the call, or cannot do so, and additionally the destination knows there are no alternative destinations (such as a voicemail server) willing to accept the call.[1]: §21.6.2 The response may indicate a better time to call in the Retry-After header field.
- 604 Does Not Exist Anywhere
- The server has authoritative information that the requested user does not exist anywhere.[1]: §21.6.3
- 606 Not Acceptable
- The user’s agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.[1]: §21.6.4
- 607 Unwanted
- The called party did not want this call from the calling party. Future attempts from the calling party are likely to be similarly rejected.[24]
- 608 Rejected
- An intermediary machine or process rejected the call attempt.[25] This contrasts with the 607 (Unwanted) SIP response code in which a human, the called party, rejected the call. The intermediary rejecting the call should include a Call-Info header with «purpose» value «jwscard», with the jCard[26] with contact details. The calling party can use this jCard if they want to dispute the rejection.
References[edit]
- ^ a b c d e f g h i j k l m n o p q r s t u v w x y z aa ab ac ad ae af ag ah ai aj ak al am an ao ap aq ar as at au av aw ax ay az ba bb bc bd be bf bg bh bi bj bk bl Rosenberg, Jonathan; Schulzrinne, Henning; Camarillo, Gonzalo; Johnston, Alan; Peterson, Jon; Sparks, Robert; Handley, Mark; Schooler, Eve (June 2002). SIP: Session Initiation Protocol. IETF. doi:10.17487/RFC3261. RFC 3261.
- ^ a b c d Roach, Adam; Jennings, Cullen; Peterson, Jon; Barnes, Mary (17 April 2013) [Created January 2002]. «Response Codes». Session Initiation Protocol (SIP) Parameters. IANA.
- ^ Holmberg, Christer (May 2011). Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. IETF. p. 1. Abstract. doi:10.17487/RFC6228. RFC 6228.
- ^ a b Roach, Adam B. (June 2002). Session Initiation Protocol (SIP)-Specific Event Notification. IETF. doi:10.17487/RFC3265. RFC 3265.
- ^ Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (June 1999). «202 Accepted». Hypertext Transfer Protocol — HTTP/1.1. IETF. sec. 10.2.3. doi:10.17487/RFC2616. RFC 2616.
- ^ a b Roach, Adam (July 2012). SIP-Specific Event Notification. IETF. doi:10.17487/RFC6665. RFC 6665.
- ^ Niemi, Aki (May 2010). «204 (No Notification) Response Code». In Willis, Dean (ed.). An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification. IETF. sec. 7.1. doi:10.17487/RFC5839. RFC 5839.
- ^ a b Handley, Mark; Schulzrinne, Henning; Schooler, Eve; Rosenberg, Jonathan (March 1999). SIP: Session Initiation Protocol. IETF. doi:10.17487/RFC2543. RFC 2543.
- ^ Niemi, Aki, ed. (2004). ««412 Conditional Requset Failed» Response Code». Session Initiation Protocol (SIP) Extension for Event State Publication. IETF. sec. 11.2.1. doi:10.17487/RFC3903. RFC 3903.
- ^ Schulzrinne, Henning; Polk, James (February 2006). «No Known Namespace or Priority Value». Communications Resource Priority for the Session Initiation Protocol (SIP). IETF. sec. 4.6.2. doi:10.17487/RFC4412. RFC 4412.
- ^ Donovan, Steve; Rosenberg, Jonathan (April 2005). «422 Response Code Definition». Session Timers in the Session Initiation Protocol (SIP). IETF. sec. 6. doi:10.17487/RFC4028. RFC 4028.
- ^ Polk, James; Rosen, Brian; Peterson, Jon (December 2011). «424 (Bad Location Information) Response Code». Location Conveyance for the Session Initiation Protocol. IETF. sec. 4.3. doi:10.17487/RFC6442. RFC 6442.
- ^ Rosen, Brian; Schulzrinne, Henning; Tschofenig, Hannes; Gellens, Randall (September 2020). «425 (Bad Alert Message) Response Code». Non-interactive Emergency Calls. IETF. sec. 5.1. doi:10.17487/RFC8876. RFC 8876.
- ^ a b c d Peterson, Jon; Jennings, Cullen (August 2006). Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC4474. RFC 4474.
- ^ Sparks, Robert J. (September 2004). «The 429 Provide Referrer Identity Error Response». The Session Initiation Protocol (SIP) Referred-By Mechanism. IETF. sec. 5. doi:10.17487/RFC3892. RFC 3892.
- ^ a b Jennings, Cullen; Mahy, Rohan; Audet, Francois, eds. (October 2009). Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC5626. RFC 5626.
- ^ Rosenberg, Jonathan (December 2007). «433 (Anonymity Disallowed) Definition». Rejecting Anonymous Requests in the Session Initiation Protocol (SIP). IETF. sec. 5. doi:10.17487/RFC5079. RFC 5079.
- ^ Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. IETF. December 2008. doi:10.17487/RFC5393. RFC 5393.
- ^ Session Initiation Protocol (SIP) INFO Method and Package Framework. IETF. January 2011. doi:10.17487/RFC6086. RFC 6086.
- ^ Rosenberg, Jonathan; Willis, Dean (October 2008). «Definition of the 470 Response Code». In Camarillo, Gonzalo (ed.). A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP). IETF. sec. 5.9.2. doi:10.17487/RFC5360. RFC 5360.
- ^ a b Arkko, Jari; Torvinen, Vesa; Camarillo, Gonzalo; Niemi, Aki; Haukka, Tao (January 2003). Security Mechanism Agreement for the Session Initiation Protocol (SIP). IETF. doi:10.17487/RFC3329. RFC 3329.
- ^ Push Notification with the Session Initiation Protocol (SIP). IETF. May 2019. doi:10.17487/RFC8599. RFC 8599.
- ^ Rosenberg, Jonathan (October 2002). «Refusing an offer». In Camarillo, Gonzalo; Marshall, Bill (eds.). Integration of Resource Management and Session Initiation Protocol (SIP). IETF. sec. 8. doi:10.17487/RFC3312. RFC 3312.
- ^ A SIP Response Code for Unwanted Calls. IETF. July 2017. doi:10.17487/RFC8197. RFC 8197.
- ^ A Session Initiation Protocol (SIP) Response Code for Rejected Calls. IETF. December 2019. doi:10.17487/RFC8688. RFC 8688.
- ^ RFC 7095
External links[edit]
- Mapping SIP Error Messages to DSS1 codes at the Wayback Machine (archived 2021-04-12)
- Session Initiation Protocol (SIP) Parameters Contains a registry of different SIP parameters, including response codes
1xx – информационные ответы
SIP/2.0 100 Trying
Запрос обрабатывается.
SIP/2.0 180 Ringing
Местоположение вызываемого пользователя определено. Выдан сигнал о входящем вызове.
SIP/2.0 181 Call is Being Forwarded
Прокси-сервер переадресует вызов к другому пользователю.
SIP/2.0 182 Call is Queued
Вызываемый абонент временно недоступен. Вызов поставлен в очередь.
SIP/2.0 183 Session Progress
Используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому пользователю.
2xx – ответы о завершении запроса
SIP/2.0 200 OK
Успешное завершение.
SIP/2.0 202 Accepted
Запрос принят для обработки. Используется для справки о состоянии обработки.
3xx – сообщения о переадресации
SIP/2.0 300 Multiple Choices
Указывает несколько SIP-адресов, по которым можно найти вызываемого пользователя.
SIP/2.0 301 Moved Permanently
Вызываемый пользователь больше не находится по адресу, указанному в запросе.
SIP/2.0 302 Moved Temporarily
Пользователь временно сменил местоположение (настроена переадресация по SIPUA в т.ч. с VOIP-телефона).
SIP/2.0 305 Use Proxy
Вызываемый пользователь недоступен непосредственно. Входящий вызов должен пройти через прокси-сервер.
SIP/2.0 380 Alternative Service
Запрошенная услуга недоступна, но доступны альтернативные услуги.
4xx – невозможность обработать запрос
SIP/2.0 400 Bad Request
Запрос не распознан из-за синтаксических ошибок или ошибок в сигнализации.
SIP/2.0 401 Unauthorized
Нормальный ответ сервера о том, что пользователь еще не авторизовался. Обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль.
SIP/2.0 401 AUTH Error: Stall nonce
1.Разные данные в поле NONCE (шифр пароля), проверить дату/время или проблема с протоколом шифрования
2. Проверить на клиентской стороне не заблокирован ли sipnet.ru (212.53.40.40)
3. Проверить в ВАТС статус присутствия. Должен быть «нет».
SIP/2.0 401 Expired Authorization
Время регистрации истекло.
SIP/2.0 402 Payment Required
Требуется оплата (зарезервирован для использования в будущем).
SIP/2.0 403 No Such User
Нет такого пользователя. Ошибка в номере, логине или пароле.
SIP/2.0 403 No license available
Кончились лицензия на SIP
SIP/2.0 403 You
Нет такого пользователя. Ошибка в номере, логине или пароле.
SIP/2.0 403 User Disabled
Пользователь отключен.
SIP/2.0 403 You do not have the required right
Неверный логин в поле «From»
SIP/2.0 403 Wrong Guess
Ошибка в пароле.
SIP/2.0 403 Conflict
Такой SIP-номер уже используется.
SIP/2.0 403 Forbidden
Абонент не зарегистрирован.
SIP/2.0 403 Empty Route Set
Нет ни одного шлюза в роутинге.
SIP/2.0 403 Caller Not Registered
Нет такого пользователя.
SIP/2.0 403 Out of Look-Ahead Retries
Перебор узлов закончен.
SIP/2.0 403 Invalid Phone Number
Нет такого направления.
SIP/2.0 403 No Money Left on RFC Account
На счету недостаточно денежных средств для совершения вызова.
SIP/2.0 404 Not found
Вызываемый абонент не найден, нет такого SIP-номера.
SIP/2.0 404 Undefined Reason
Неопределенное направление.
SIP/2.0 404 Unknown user account
Логин и пароль не найдены.
SIP/2.0 404 Out of Order
В заявке на маршрутизацию по этому направлению нет принимающих шлюзов.
SIP/2.0 405 Method Not Allowed
Метод не поддерживается. Может возникать если пользователь пытается отправлять голосовую почту и т.п.
SIP/2.0 406 No codecs match
Неправильная конфигурация кодеков.
SIP/2.0 406 Not Acceptable
Пользователь недоступен.
SIP/2.0 407 Proxy Authentication Required
Необходима аутентификация на прокси-сервере.
SIP/2.0 407 User not found
Проверить ID на CGP
SIP/2.0 408 Request Timeout
Время обработки запроса истекло. Абонента не удалось найти за отведенное время. (Проблема с firewall, нет ответа на Invite от сервера)
SIP/2.0 408 Login timed out
За отведенное время не получен ответ от сервера на запрос авторизации.
SIP/2.0 410 No Route
Вариант «SIP/2.0 403 Empty Route Set». Нет доступа к ресурсу или ресурс по указанному адресу больше не существует.
SIP/2.0 413 Request Entity Too Large
Размер запроса слишком велик для обработки на сервере.
SIP/2.0 415 No Media
Звонок совершается неподдерживаемым кодеком.
SIP/2.0 416 Unsupported Scheme
Сервер не может обработать запрос из-за того, что схема адреса не распознана.
SIP/2.0 420 Bad extension
Неизвестное расширение. Сервер не распознал расширение протокола SIP.
SIP/2.0 421 Extension Required
В заголовке запроса не указано, какое расширение сервер должен применить для его обработки.
SIP/2.0 423 Interval Too Brief
Сервер отклоняет запрос, так как время действия ресурса короткое.
SIP/2.0 480 Invalid Phone Number
Неправильный номер телефона, не соответствует количеству цифр или неправильный код страны или города.
SIP/2.0 480 Destination Not Found In Client Plan
Нет направления в тарифном плане абонента.
SIP/2.0 480 Wrong DB Response
Проблемы с центральной базой данных.
SIP/2.0 480 DB Timeout
Проблемы с центральной базой данных.
SIP/2.0 480 Database Error
Проблемы с центральной базой данных.
SIP/2.0 480 Codec Mismatch
Несоответствие кодеков.
SIP/2.0 480 No Money Left on RFC Account
Недостаточно денежных средств на счету.
SIP/2.0 480 Empty Route Set
Пустое направление. Нет принимающих шлюзов.
SIP/2.0 480 No money left
Недостаточно денежных средств на счету.
SIP/2.0 480 Temporarily Unavailable
Временно недоступное направление. (Возможно статус DND)
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Действие не выполнено. Нормальный ответ при поступлении дублирующего пакета.
SIP/2.0 482 Loop Detected
Обнаружен замкнутый маршрут передачи запроса.
SIP/2.0 483 Too Many Hops
Запрос на своем пути прошел через большее число прокси-серверов, чем разрешено.
SIP/2.0 484 Address Incomplete
Принят запрос с неполным адресом.
SIP/2.0 485 Ambiguous
Адрес вызываемого пользователя неоднозначен.
SIP/2.0 486 Busy Here
Абонент занят.
SIP/2.0 487 Request Terminated
Запрос отменен. Обычно приходит при отмене вызова.
SIP/2.0 488 Codec Mismatch
Нет шлюзов с поддержкой заказанного кодека.
SIP/2.0 488 Private IP Address
Адрес RTP media из сетей RFC1918.
SIP/2.0 488 Not acceptable here
Не совпадают кодеки
SIP/2.0 491 Request Pending
Запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу.
SIP/2.0 493 Undeciperable
Сервер не в состоянии подобрать ключ дешифрования. Невозможно декодировать тело S/MIME сообщения.
SIP/2.0 499 Codec Mismatch
Отсутствует кодек.
5xx – ошибки сервера
SIP/2.0 500 Internal Server Error
Внутренняя ошибка сервера.
SIP/2.0 500 DB Timeout
Нет ответа от базы данных.
SIP/2.0 500 Database Error
То же самое, но в другой момент.
SIP/2.0 500 Wrong DB Response
Неправильный ответ базы данных.
SIP/2.0 500 Undefined Reason
Неопределенная причина.
SIP/2.0 500 account has been moved to a remote system
Аккаунт перенесен в удаленную систему (дословно).
SIP/2.0 500 Call placing quota exceeded
Превышен CPS.
SIP/2.0 501 Method Not Supported Here
В сервере не реализованы какие-либо функции, необходимые для обслуживания запроса. Метод запроса SIP не поддерживается.
SIP/2.0 502 Bad Gateway
Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос.
SIP/2.0 503 Service Unavailable
Сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.
SIP/2.0 504 Server time-out
Сервер не получил ответа в течение установленного промежутка времени от сервера, к которому он обратился для завершения вызова.
SIP/2.0 505 SIP Version not supported
Версия не поддерживается. Сервер не поддерживает эту версию протокола SIP.
SIP/2.0 513 Message too big
Сервер не в состоянии обработать запрос из-за большой длины сообщения.
6xx – глобальная ошибка
SIP/2.0 600 Busy everywhere
Вызываемый пользователь занят и не желает принимать вызов в данный момент.
SIP/2.0 603 Decline
Вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа.
SIP/2.0 604 Does Not Exist Anywhere
Вызываемого пользователя не существует.
SIP/2.0 606 Not Acceptable
Соединение с сервером было установлено. Отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации не доступны.
Introduction[]
This article displays SIP error codes and a definition of such codes
Categories of SIP messages[]
- 1xx is ‘Informational’
- 2xx is ‘Success’
- 3xx is a ‘Redirection’
- 4xx is a ‘Client Error’
- 5xx is a ‘Server Error’
- 6xx is a ‘Global Failure’
1xx—Provisional Responses[]
- As mentioned earlier, a 1xx SIP response code can be sent at anytime while a connection is being established. Some of the regularly received codes are
Message Id | Description | ||
---|---|---|---|
100 Trying | This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy. | ||
180 Ringing | Destination user agent received INVITE, and is alerting user of call. | ||
181 Call is being forwarded | Servers can optionally send this response to indicate a call is being forwarded. | ||
182 QUeued | The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, «5 calls queued; expected waiting time is 15 minutes». The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call. | ||
183 Session Progress | The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. | ||
199 Early Dialog Terminated | Can be used by User Agent Server to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated. |
2xx—Successful Responses[]
The 2xx response codes are used to indicate that a SIP request has been successfully processed. You’ll typically see the following versions:
Message Id | Description | ||
---|---|---|---|
200 OK | Indicates the request was successful. | ||
202 Accepted | Indicates that the request has been accepted for processing, but the processing has not been completed. | ||
204 No Notification | Indicates the request was successful, but the corresponding response will not be received. |
3xx—Redirection Responses[]
3xx responses give information about the user’s new location, or about alternative services that might be able to satisfy the call.
Message Id | Description | ||
---|---|---|---|
300 Multiple Choices | The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location.
The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body. |
||
301 Moved Permanently | The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field. The requester SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed. | ||
302 Moved Temporarily | The requesting client SHOULD retry the request at the new address(es) given by the Contact header field. The Request-URI of the new request uses the value of the Contact header field in the response.
The duration of the validity of the Contact URI can be indicated through an Expires header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions. |
||
305 Use Proxy | The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. | ||
380 Alternative Service | The call was not successful, but alternative services are possible.
The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization. |
4xx—Client Failure Responses[]
4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.
Message Id | Description | ||
---|---|---|---|
400 Bad Request | The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, «Missing Call-ID header field». | ||
401 Unauthorized | The request requires user authentication. This response is issued by UASs and registrars. | ||
402 Payment Required | Reserved for future use. | ||
403 Forbidden | The server understood the request, but is refusing to fulfill it. Sometimes (but not always) this means the call has been rejected by the receiver. | ||
404 Not Found | The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. | ||
405 Method Not Allowed | The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. | ||
406 Not Acceptable | The resource identified by the request is only capable of generating response entities that have content characteristics but not acceptable according to the Accept header field sent in the request. | ||
407 Proxy Authentication Required | The request requires user authentication. This response is issued by proxys. | ||
408 Request Timeout | Couldn’t find the user in time. The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time. | ||
409 Conflict | User already registered. | ||
410 Gone | The user existed once, but is not available here any more. | ||
411 Length Required | The server will not accept the request without a valid Content-Length. | ||
412 Conditional Request Failed | The given precondition has not been met. | ||
413 Request Entity Too Large | The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after what time the client MAY try again. |
||
414 Request-URI Too Long | The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. | ||
415 Unsupported Media Type | The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. | ||
416 Unsupported URI Scheme | The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. | ||
417 Unknown Resource-Priority | There was a resource-priority option tag, but no Resource-Priority header. | ||
420 Bad Extension | The server did not understand the protocol extension specified in a Proxy-Require or Require header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. | ||
421 Extension Required | The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions.
A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client. |
||
422 Session Interval Too Small | The received request contains a Session-Expires header field with a duration below the minimum timer. | ||
423 Interval Too Brief | The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small. | ||
424 Bad Location Information | The request’s location content was malformed or otherwise unsatisfactory. | ||
428 Use Identity Header | The server policy requires an Identity header, and one has not been provided. | ||
429 Provide Referrer Identity | The server did not receive a valid Referred-By token on the request.
A specific flow to a user agent has failed, although other flows may succeed. This response is intended for use between proxy devices, and should not be seen by an endpoint (and if it is seen by one, should be treated as a 400 Bad Request response). |
||
433 Anonymity Disallowed | The request has been rejected because it was anonymous. | ||
436 Bad Identity-Info | The request has an Identity-Info header, and the URI scheme in that header cannot be dereferenced. | ||
437 Unsupported Certificate | The server was unable to validate a certificate for the domain that signed the request. | ||
438 Invalid Identity Header | The server obtained a valid certificate that the request claimed was used to sign the request, but was unable to verify that signature. | ||
439 First Hop Lacks Outbound Support | The first outbound proxy the user is attempting to register through does not support the «outbound» feature of RFC 5626, although the registrar does. | ||
440 Max-Breadth Exceeded | If a SIP proxy determines a response context has insufficient Incoming Max-Breadth to carry out a desired parallel fork, and the proxy is unwilling/unable to compensate by forking serially or sending a redirect, that proxy MUST return a 440 response. A client receiving a 440 response can infer that its request did not reach all possible destinations. | ||
469 Bad Info Package | If a SIP UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 response, which contains a Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests. | ||
470 Consent Needed | The source of the request did not have the permission of the recipient to make such a request. | ||
480 Temporarily Unavailable | The callee’s end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the «do not disturb» feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure.
This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user. |
||
481 Call/Transaction Does Not Exist | Server received a request that does not match any dialog or transaction. | ||
482 Loop Detected | Server has detected a loop. | ||
483 Too Many Hops | Max-Forwards header has reached the value ‘0’. | ||
484 Address Incomplete | The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase.
This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response. |
||
485 Ambiguous | The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs.
Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response. |
||
486 Busy Here | The callee’s end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call. | ||
487 Request Terminated | The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself. | ||
488 Not Acceptable Here | The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. |
||
489 Bad Event | The server did not understand an event package specified in an Event header field. | ||
491 Request Pending | Server has some pending request from the same dialog. | ||
493 Undecipherable | The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. | ||
494 Security Agreement Required | The server has received a request that requires a negotiated security mechanism, and the response contains a list of suitable security mechanisms for the requester to choose between, or a digest authentication challenge. |
5xx—Server Failure Responses[]
5xx responses relate to server error issues and are mostly generated by the likes of proxy servers, location servers, and redirect servers. You’ll be familiar with some of these: — 500 Server Internal Error — 501 Not Implemented — 502 Bad Gateway — 503 Service Unavailable — 504 Server Time-Out
Message Id | Description | ||
---|---|---|---|
500 Server Internal Error | The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds.
If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field. |
||
501 Not Implemented | The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.)
Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported. |
||
502 Bad Gateway | The server is acting as a gateway or proxy, and received an invalid response from a downstream server while attempting to fulfill the request. | ||
503 Service Unavailable | The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. |
||
504 Server Time-out | The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server. | ||
505 Version Not Supported | The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. | ||
513 Message Too Large | The server was unable to process the request since the message length exceeded its capabilities. | ||
580 Precondition Failure | The server is unable or unwilling to meet some constraints specified in the offer. |
6xx—Global Failure Responses[]
Finally, the 6xx response codes relate to Global Error issues. They include: — 600 Busy Everywhere — 603 Decline — 604 Does Not Exist Anywhere — 606 Not Acceptable
Message Id | Description | ||
---|---|---|---|
600 Busy Everywhere | The callee’s end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field.
If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned. |
||
603 Decline | The callee’s machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request. | ||
604 Does Not Exist Anywhere | The server has authoritative information that the requested user does not exist anywhere. | ||
606 Not Acceptable | The user’s agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.
A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. |
||
607 Unwanted | The called party did not want this call from the calling party. Future attempts from the calling party are likely to be similarly rejected. |
SIP ошибки и их значение
SIP/2.0 400 Bad Request — ошибка в сигнализации, скорее всего что-то с настройками оборудования
SIP/2.0 401 Unauthorized — нормальный ответ сервера о том, что пользователь еще неавторизировался, обычно после этого на абонентское оборудование отправляет на сервер логин и пароль
SIP/2.0 401 Expired Authorization — время регистрации истекло
SIP/2.0 403 No Such User — нет такого пользователя, ошибка в номере, логине или пароле
SIP/2.0 403 User Disabled — пользователь отключен
SIP/2.0 403 Wrong Guess — ошибка в пароле
SIP/2.0 403 Forbidden — абонент не зарегистрирован
SIP/2.0 403 Empty Route Set — нет ни одного шлюза в роутинге
SIP/2.0 403 Caller Not Registered — нет такого пользователя
SIP/2.0 403 Out of Look-Ahead Retries — перебор узлов закончен
SIP/2.0 403 Invalid Phone Number — нет такого направления
SIP/2.0 404 Not found — вызываемый абонент не найден, нет такого SIP-номера
SIP/2.0 404 Undefined Reason — неопределенное направление
SIP/2.0 404 Unknown user account — логин и пароль не найдены
SIP/2.0 405 Method Not Allowed — метод не поддерживается, может возникать если пользователь пытается отправлять голосовую почту и т.п.
SIP/2.0 406 No codecs match — неправильная конфигурация кодеков
SIP/2.0 406 Not Acceptable
SIP/2.0 407 Proxy Authentication Required — что-то с регистрацией
SIP/2.0 408 Request Timeout — превышение ожижание ответа на запрос
SIP/2.0 408 Login timed out — за отведенное время не получен ответ от сервера на запрос авторизации
SIP/2.0 410 No Route — вариант SIP/2.0 403 Empty Route Set
SIP/2.0 415 No Media — несоответствие кодеков
SIP/2.0 480 Invalid Phone Number — неправильный номер телефона
SIP/2.0 480 Destination Not Found In Client Plan — направления не существует
SIP/2.0 480 Codec Mismatch — несоответствие кодеков
SIP/2.0 480 Empty Route Set — что-то с маршрутизацией
SIP/2.0 480 No money left — недостаточно денег на счете
SIP/2.0 480 Temporarily Unavailable — временно недоступное направление — попробуйте позвонить позже
SIP/2.0 481 Call Leg/Transaction Does Not Exist — действие не выполнено, нормальный ответ при поступлении дублирующего пакета
SIP/2.0 487 Request Terminated — запрос отменен, обычно приходит при отмене вызова
SIP/2.0 486 Busy Here — абонент занят
SIP/2.0 488 Codec Mismatch — нет шлюзов с поддержкой заказанного кодека
SIP/2.0 488 Private IP Address — адрес RTP media из сетей RFC1918
SIP/2.0 499 Codec Mismatch — отсутствует кодек
SIP/2.0 500 Internal Server Error — внутренняя ошибка сервера
SIP/2.0 500 DB Timeout — нет ответа от базы данных
SIP/2.0 500 Database Error — то же самое, но в другой момент
SIP/2.0 500 Wrong DB Response — неправильный ответ базы данных
SIP/2.0 500 Undefined Reason — неопределенная причина
SIP/2.0 500 account has been moved to a remote system — аккаунт перенесен в удаленную систему (дословно)
SIP/2.0 5хх — проблемы с SoftSwitch-ом
SIP/2.0 603 Decline — отказ в обслуживании звонка
Читайте другие страницы сайта.
The SIP response codes are consistent with, and extend to, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT be used. Also, SIP defines a new class, 6xx.
Provisional 1xx
Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses MAY contain message bodies, including session descriptions.
100 Trying
This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy.
180 Ringing
The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback.
181 Call Is Being Forwarded
A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations.
182 Queued
The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, «5 calls queued; expected waiting time is 15 minutes». The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call.
183 Session Progress
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress.
Successful 2xx
The request was successful.
200 OK
The request has succeeded. The information returned with the response depends on the method used in the request.
Redirection 3xx
3xx responses give information about the user’s new location, or about alternative services that might be able to satisfy the call.
300 Multiple Choices
The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location.
The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body.
The choices SHOULD also be listed as Contact fields. Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. UAs MAY use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection.
This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request.
301 Moved Permanently
The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field. The requester SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed.
302 Moved Temporarily
The requesting client SHOULD retry the request at the new address(es) given by the Contact header field. The Request-URI of the new request uses the value of the Contact header field in the response.
The duration of the validity of the Contact URI can be indicated through an Expires header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions.
If the URI cached from the Contact header field fails, the Request-URI from the redirected request MAY be tried again a single time.
The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available.
305 Use Proxy
The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs.
380 Alternative Service
The call was not successful, but alternative services are possible.
The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization.
Request Failure 4xx
4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful.
400 Bad Request
The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, «Missing Call-ID header field».
401 Unauthorized
The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers.
402 Payment Required
Reserved for future use.
403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated.
404 Not Found
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request.
405 Method Not Allowed
The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI.
The response MUST include an Allow header field containing a list of valid methods for the indicated address.
406 Not Acceptable
The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request.
407 Proxy Authentication Required
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy.
This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication.
408 Request Timeout
The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time.
410 Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead.
413 Request Entity Too Large
The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD include a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
414 Request-URI Too Long
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret.
415 Unsupported Media Type
The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content.
416 Unsupported URI Scheme
The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server.
420 Bad Extension
The server did not understand the protocol extension specified in a Proxy-Require or Require header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response.
421 Extension Required
The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions.
A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client.
423 Interval Too Brief
The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small.
480 Temporarily Unavailable
The callee’s end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the «do not disturb» feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure.
This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user.
481 Call/Transaction Does Not Exist
This status indicates that the UAS received a request that does not match any existing dialog or transaction.
482 Loop Detected
The server has detected a loop.
483 Too Many Hops
The server received a request that contains a Max-Forwards header field with the value zero.
484 Address Incomplete
The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase.
This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response.
485 Ambiguous
The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs.
Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response.
486 Busy Here
The callee’s end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call.
487 Request Terminated
The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself.
488 Not Acceptable Here
The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere.
A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request.
491 Request Pending
The request was received by a UAS that had a pending request within the same dialog.
493 Undecipherable
The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA.
Server Failure 5xx
5xx responses are failure responses given when a server itself has erred.
500 Server Internal Error
The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds.
If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field.
501 Not Implemented
The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.)
Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported.
502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request.
503 Service Unavailable
The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response.
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.
Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable).
504 Server Time-out
The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server.
505 Version Not Supported
The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message.
513 Message Too Large
The server was unable to process the request since the message length exceeded its capabilities.
Global Failures 6xx
6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI.
600 Busy Everywhere
The callee’s end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field.
If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned.
603 Decline
The callee’s machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request.
604 Does Not Exist Anywhere
The server has authoritative information that the user indicated in the Request-URI does not exist anywhere.
606 Not Acceptable
The user’s agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable.
A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported.
This status response is returned only if the client knows that no other end point will answer the request.
Similar topics
Usage tips
- Using Firefox browser? Take the Current Status with you.
- Current Status for your Google page
- Where is the Current Status
Knowledge base
- HTTP Status Codes — 1xx
- HTTP Status Codes — 2xx
- HTTP Status Codes — 5xx
- HTTP Status Codes — 3xx
- FTP Basic Target Type
Howtos
- Check WHOIS records for status changes
- Configure Alert Dependencies
- Safely Monitor Backend Databases
Glossary
- RTSP Status Codes
- HTTP status codes
- Numeric Pagers Contacts
- HTTP Response
- URL Contacts
Frequently asked questions
- Does WebSitePulse offer DNS monitoring?
- What is WSDL / Web Service Definition Language?
- Do you provide WAP monitoring?
- Does your service support Secure Socket Layer for ecommerce transactions?
- What is a Ping?
The Session Initiation Protocol (SIP) is a signalling protocol used for controlling communication sessions such as Voice over IP telephone calls. SIP is based around request/response transactions, in a similar manner to the Hypertext Transfer Protocol (HTTP). Each transaction consists of a SIP request (which will be one of several request methods), and at least one response.
SIP requests and responses may be generated by any SIP user agent; user agents are divided into clients (UACs), which initiate requests, and servers (UASes), which respond to them. A single user agent may act as both UAC and UAS for different transactions: for example, a SIP phone is a user agent that will be a UAC when making a call, and a UAS when receiving one. Additionally, some devices will act as both UAC and UAS for a single transaction; these are called Back-to-Back User Agents (B2BUAs) .
SIP responses specify a three-digit integer response code, which is one of a number of defined codes that detail the status of the request. These codes are grouped according to their first digit as «provisional», «success», «redirection», «client error», «server error» or «global failure» codes, corresponding to a first digit of 1–6; these are expressed as, for example, «1xx» for provisional responses with a code of 100–199.The SIP response codes are consistent with the HTTP response codes, although not all HTTP response codes are valid in SIP .
SIP responses also specify a «reason phrase», and a default reason phrase is defined with each response code. These reason phrases can be varied, however, such as to provide additional information [1] :§21.4.18 or to provide the text in a different language.
The SIP response codes and corresponding reason phrases were initially defined in RFC 3261. That RFC also defines a SIP Parameters Internet Assigned Numbers Authority (IANA) registry to allow other RFC to provide more response codes.
This list includes all the SIP response codes defined in IETF RFCs and registered in the SIP Parameters IANA registry as of 14 July 2017. This list also includes SIP response codes defined in obsolete SIP RFCs (specifically, RFC 2543), which are therefore not registered with the IANA; these are explicitly noted as such.
List of SIP status codes
1xx – Provisional
-
Preliminary information that the server is still performing further actions and therefore cannot yet send a final response.
2xx – Successful
-
The request was successful.
3xx – Redirection
-
These messages inform about a new contact address of the called party or about other services that enable the connection to be established successfully.
4xx – Request Failures
-
Request failures are negative confirmations. The previous message could not be processed.
5xx – Server Failures
-
A server involved in the transmission could not process a message.
6xx – Global Failures
General errors: The server has been contacted successfully, but the transaction does not take place.
7xx – Fehlercodes des SIP-Stacks
Code | Nachricht | Bedeutung |
---|---|---|
100 | Trying | An attempt is made to transfer the call. |
180 | Ringing | An attempt is made to ring from the called party. |
181 | Call Is Being Forwarded | The call is forwarded. |
182 | Queued |
The call is on hold. |
183 | Session Progress | The connection is established. |
199 | Early Dialog Terminated | The dialog was closed during connection setup. |
Code | Nachricht | Bedeutung |
200 | OK | The request has been processed successfully and the result of the request is transferred in the response. |
202 | Accepted | The request has been accepted, but will be executed at a later time. |
204 | No Notification | The request was executed successfully, but the corresponding response is deliberately not sent. |
Code | Nachricht | Bedeutung |
300 | Multiple Choices | There is no unique destination address for the remote terminal. |
301 | Moved Permanently | The called party is permanently reachable somewhere else. |
302 | Moved Temporarily | The called party is temporarily reachable somewhere else. |
305 | Use Proxy | The specified proxy must be used. |
380 | Alternative Service | The call was not successful, but alternative services are available. |
Code | Nachricht | Bedeutung |
---|---|---|
400 | Bad Request | The SIP request is incorrect. |
401 | Unauthorized | The authorization is incorrect. |
402 | Payment Required | Not yet defined; intended for «not enough credit available». |
403 | Forbidden | The request was invalid. |
404 | Not Found | The remote terminal was not found or does not exist. |
405 | Method Not Allowed | The method of the request (for example, SUBSCRIBE or NOTIFY) is not allowed. |
406 | Not Acceptable | The call options are not allowed. |
407 | Proxy Authentication Required | The proxy needs authorization. |
408 | Request Timeout | Timeout — The remote peer does not respond within a reasonable time. |
410 | Gone | The desired subscriber can no longer be reached at the specified address. |
412 | Conditional Request Failed | The prerequisites for processing the request could not be met because a request required for this failed. |
413 | Request Entity Too Large | The message content is too large. |
414 | Request URI Too Long | The SIP address (URI) of the request is too long. |
415 | Unsupported Media Type | The codec is not supported. |
416 | Unsupported URI Scheme | The SIP address is incorrect. |
417 | Unknown Resource-Priority | The request should be treated with a certain priority, but the server does not understand the details. |
420 | Bad Extension | The server does not understand a protocol extension. |
421 | Extension Required | The server needs a protocol extension. |
422 | Session Interval Too Small | The Session Expires value is too low for the server. |
423 | Interval Too Brief | The value of the desired machining time is too short. |
428 | Use Identity Header | The identity header is missing. |
429 | Provide Referrer Identity | No valid referred by token is specified. |
430 | Flow Failed | The particular routing failed (proxy internal, endpoints should treat the response like code 400). |
433 | Anonymity Disallowed | The server refuses to process anonymous requests. |
436 | Bad Identity-Info | The SIP address contained in the identity header is invalid, unavailable, or not supported. |
437 | Unsupported Certificate | The verifier cannot verify the certificate in the identity header. |
438 | Invalid Identity Header | The certificate in the identity header is invalid. |
439 | First Hop Lacks Outbound Support | The registrar supports outbound feature, but the proxy used does not. |
440 | Max-Breadth Exceeded | It is no longer possible to derive concurrent forks from the query. |
469 | Bad Info Package | Unsuitable Info-Package — Transmission error, resend. |
470 | Consent Needed | The server has no access rights to at least one of the specified SIP addresses. |
480 | Temporarily Unavailable | The called party is currently not reachable. |
481 | Call/Transaction Does Not Exist | This connection does not exist (anymore). |
482 | Loop Detected | A forwarding loop has been detected. |
483 | Too Many Hops | Too many forwarding steps were identified. |
484 | Address Incomplete | The SIP address is incomplete. |
485 | Ambiguous | The SIP address cannot be uniquely resolved. |
486 | Busy Here | The called party is busy. |
487 | Request Terminated | The call attempt was aborted. |
488 | Not Acceptable Here | Illegal call attempt. |
489 | Bad Event | The server does not know the specified event. |
491 | Request Pending | A request from the same dialog is still being processed. |
493 | Undecipherable | The request contains an encrypted MIME body that the recipient cannot decrypt. |
494 | Security Agreement Required | The request requires a security agreement, but does not include a security mechanism supported by the server. |
Code | Nachricht | Bedeutung |
---|---|---|
500 | Server Internal Error | Internal server error. |
501 | Not Implemented | The server does not support the SIP request. |
502 | Bad Gateway | The gateway in the SIP request is corrupted. |
503 | Service Unavailable | The server’s SIP service is temporarily unavailable. |
504 | Server Time-out | The server cannot reach another server in a reasonable time. |
505 | Version Not Supported | The SIP protocol version is not supported by the server. |
513 | Message Too Large | The SIP message is too large for UDP; TCP must be used. |
580 | Precondition Failure | The server cannot or does not want to meet the requirements for processing the request. |
Code | Nachricht | Bedeutung |
600 | Busy Everywhere | All terminal devices of the called subscriber are occupied. |
603 | Declined | The called party has rejected the call attempt. |
604 | Does Not Exist Anywhere | The called party no longer exists. |
606 | Not Acceptable | The terminal device of the called party rejects the SIP request as invalid. |
Code | Nachricht | Bedeutung |
701 | Party Hangs Up | The called party has hung up. |
SIP is a widely adopted application layer protocol used in VoIP calls and confernecing applciations and in IMS architeture or pure packet switched networks .
More on SIP , its packet structure , transaction and dialogs , loose and strict record routing , location service , near and far end nating , and commonly used SIP Call flows like Redirection , forking , click to Dial – https://telecom.altanai.com/2013/07/13/sip-session-initiaion-protocol/(opens in a new tab)
SIP Request and Repsosnes
Traditional SIP headers for Call setup are INVITE, ACK and teardown are CANCEL or BYE , however with more adoption newer methods specific to services were added such as :
MESSAGE Methods for Instant Message based services
SUBSCRIBE, NOTIFY standardised by Event notification extension RFC 3856
PUBLISH to push presence information to the network
Outlining the SIP Requests and Responses in tables below,
Request Message
Request Message |
Description |
REGISTER | A Client use this message to register an address with a SIP server |
INVITE | A User or Service use this message to let another user/service participate in a session. The body of this message would include a description of the session to which the callee is being invited. |
ACK | This is used only for INVITE indicating that the client has received a final response to an INVITE request |
CANCEL | This is used to cancel a pending request |
BYE | A User Agent Client use this message to terminate the call |
OPTIONS | This is used to query a server about its capabilities |
Response Message
Code |
Category |
Description |
1xx | Provisional | The request has been received and processing is continuing |
2xx | Success | An ACK, to indicate that the action was successfully received, understood, and accepted. |
3xx | Redirection | Further action is required to process this request |
4xx | Client Error | The request contains bad syntax and cannot be fulfilled at this server |
5xx | Server Error | The server failed to fulfill an apparently valid request |
6xx | Global Failure | The request cannot be fulfilled at any server |
Display names
From originators sipuri
CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number.
Contact – SIP URI that represents a direct route to the originator usually composed of a username at a fully qualified domain name (FQDN) , also IP addresses are permitted. The Contact header field tells other elements where to send future requests.
Max-Forwards -to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop.
Content
Content-Type – description of the message body.
Content-Type: application/h.323 Content-Type: message/sip Content-Type: application/sdp Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s
Content Encoding
Content-Encoding: text/plain
Content Language
Content-Language: en
Content-Length – an octet (byte) count of the message body.
Content-Disposition
describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. It extends the MIME Content-Type
Disposition Types :
- “session” – body part describes a session, for either calls or early (pre-call) media
- “render” – body part should be displayed or otherwise rendered to the user.
- “icon” – body part contains an image suitable as an iconic representation of the caller or callee
- “alert” – body part contains information, such as an audio clip
Accept
Accept – acceptable formats like application/sdp or currency/dollars
Header field where proxy ACK BYE CAN INV OPT REG
Accept R - o - o m* o
Accept 2xx - - - o m* o
Accept 415 - c - c c c
An empty Accept header field means that no formats are acceptable.
Accept-Encoding
Accept-Encoding R - o - o o o
Accept-Encoding 2xx - - - o m* o
Accept-Encoding 415 - c - c c c
Accept-Language : languages for reason phrases, session descriptions, or status responses carried as message bodies in the response.
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c
Tag globally unique and cryptographically random with at least 32 bits of randomness. identify a dialog, which is the combination of the Call-ID along with two tags ( from To and FROM headers )
Call-Id uniquely identify a session
contact – sip url alternative for direct routing
Encryption
Expires – when msg content is no longer valid
Mandatory SIP headers
INVITE sip:altanai@domain.comSIP/2.0 Via: SIP/2.0/UDP host.domain.com:5060 From: Bob To: Altanai Call-ID: 163784@host.domain.com CSeq: 1 INVITE
Informational headers
Call-Info additional information for example, through a web page. The “card” parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA
Call-Info: http://wwww.example.com/alice/photo.jpg ;purpose=icon,http://www.example.com/alice/ ;purpose=info
Contact
Contact: “Mr. Watson” ;q=0.7; expires=3600,
“Mr. Watson” watson@bell-telephone.com ;q=0.1 m: ;expires=60
Priority indicates the urgency of the request as perceived by the client.
can have the values “non-urgent”, “normal”, “urgent”, and “emergency”, but additional values can be defined elsewhere
Subject: A tornado is heading our way!
Priority: emergency
or
Subject: Weekend plans
Priority: non-urgent
Subject summary or indicates the nature of call
Subject: Need more boxes
s: Tech Support
Supported enumerates all the extensions supported. can contain list of option tags, described
Supported: 100rel
k: 100rel
Unsupported features not supported
Unsupported: foo
User-Agent information about the UAC originating the request.
User-Agent: Softphone Beta1.5
Organization conveys the name of the organization to which the SIP element issuing the request or response belongs.
Organization: AltanaiTelecom Co.
Warning additional information about the status of a response.
List of warn-code
- 300 Incompatible network protocol:
- 301 Incompatible network address formats:
- 302 Incompatible transport protocol:
- 303 Incompatible bandwidth units:
- 304 Media type not available:
- 305 Incompatible media format:
- 306 Attribute not understood:
- 307 Session description parameter not understood:
- 330 Multicast not available:
- 331 Unicast not available:
- 370 Insufficient bandwidth:
- 399 Miscellaneous warning:
- 1xx and 2xx have been taken by HTTP/1.1.
Warning: 307 isi.edu “Session parameter ‘foo’ not understood”
Warning: 301 isi.edu “Incompatible network address type ‘E.164′”
Authetication and Authorization related headers
Authentication-Info mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field.
Authentication-Info: nextnonce=”47364c23432d2e131a5fb210812c”
Authorization authentication credentials of a UA
Authorization: Digest username=”Alice”, realm=”atlanta.com”, nonce=”84a4cc6f3082121f32b42a2187831a9e”, response=”7587245234b3434cc3412213e5f113a5432″
Proxy-Authenticate contains an authentication challenge.
Proxy-Authenticate: Digest realm=”atlanta.com”,domain=”sip:ss1.carrier.com”, qop=”auth”,
nonce=”f84f1cec41e6cbe5aea9c8e88d359″,opaque=””, stale=FALSE, algorithm=MD5
Timers
exponential back-off on re-transmissions
limit the time period over which a stateful proxy must maintain state information.
options
- User agents must tear down the call after the expiration of the timer , or
- aller can send re-INVITEs to refresh the timer, enabling a “keep alive” mechanism for SIP.
SDP (Session Description Protocol)
SIP can bear many kinds of MIME attachments , one such is SDP. It is a standard for protocol definition for exchange of media , metadata and other transport realted attributes between the particpants before establishing a VoIP call.
SDP session description is entirely textual using the ISO 10646 character set in UTF-8 encoding and described by application/SDP media type.
It should be noted that SDP itself does not incorporate a transport protocol and can be used with difference protocls like Session announcement proctols (SAP) , SIP , HTTP , Electronic MAIl MIME extension, RTSP etc.
In case of SIP SDP is encapsulated inside of SIP packet and use offer/answer model to convey information about media stream in multimedia session.
SDP body contains 2 parts : session based section starting with v= line and media bsesction starting with m= line
Media and Transport Information can contain type of media like video, audio , transport protocol like RTP/UDP/IP, H.320 and format of the media such as H.261 video, MPEG video, etc.
Session Description in SDP
protocol version ( v= ) protocol version mostly version 0
originator and session identifier ( o= )
o= < username > <session-id> <session-version> <net-type> <addr-type> <unicast address> o=- 6476888576284874344 2 IN IP4 127.0.0.1
session name ( s=) and session information ( i= ) session name is textual and can contain empty space or even s=- but must not be empty. Session infomration is optional textual information about the session
URI of description ( u = )
Email Address and Phone Number (“e=” and “p=”)
Both are optional free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding
Nothe that if given the Phone numbers SHOULD follow international public telecommunication number specification ( ITU-T Recommendation E.164) and be preceded by a “+”. Spaces and hyphens may be used to split up a phone field to aid readability if desired.
e=Jane Doe j.doe@example.com
p=+1 617 555-6011
Connection Data ( c= ) connection information — not required if included in all media in which media specific connecion data override overall session connection data
c= <net-type> <addr-type> <connection-address>
c=IN IP4 172.31.90.251
If the session is multicast, the connection address will be an IP multicast group address . TTL shoudl be present in IPv4 multicast address .
If connection is unicast the address contains the unicast IP address of the expected data source or data relay or data sink .
Bandwidth ( b= ) interpreted as kilobits per second by default
b= <bwtype> : <bandwidth>
Encryption Keys ( k= ) Only is SDP is exchanged in secure and trusted channel, keys va be excahnged on this SDP field . Although this process is not recomended,
k= clear:< encryption key >
k= base64:< encoded encryption key >
k= uri:< URI to obtain key >
k= prompt
Attributes ( a= )
extends the SDP with values like flags
a=inactive , a=sendonly , a=sendrecv , a=recvonly
Mapping the Encoder Spec from
a=rtpmap: < payload type > < encoding name >/ < clock rate > [/ ]
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/48000
a=rtpmap:97 telephone-event/8000
Conferenec Type like “broadcast”, “meeting”, “moderated”, “test”,
a=type: < conf type>
Orientation portrait or landscape for whiteboard session
a=orient: <orientation>
ICE candidates
a=ice-pwd:86701d63e2d96ec42268679a a=ice-ufrag:948a1316 a=rtcp-12133xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
Frame per second for video
a=framerate:
Quality between 0 – 10 ( 10 best still image , 5 default , 0 wrst )
a= quality: < quality >
Format specific Parameters
a=fmtp: <format> <parameters>
a=rtpmap:114 AMR-WB/16000/1 a=fmtp:114 mode-change-capability=2;max-red=220 a=rtpmap:113 AMR-WB/16000/1 a=fmtp:113 octet-align=1;mode-change-capability=2;max-red=220 a=rtpmap:102 AMR/8000/1 a=fmtp:102 mode-change-capability=2;max-red=220 a=rtpmap:115 AMR/8000/1 a=fmtp:115 octet-align=1;mode-change-capability=2;max-red=220 a=rtpmap:105 telephone-event/16000 a=fmtp:105 0-15 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
Time Description in SDP
Timing (t =)
time the session is active)
t=<start-time> <stop-time>
If the <stop-time> is set to zero, then the session is not bounded, though it will not become active until after the < start -time>.
If the <start-time> is also zero, the session is regarded as permanent.
t=0 0
Repeat Times ( r= )
zero or more repeat times for scheduling a session
r= <repeat interval> <active duration> <offsets from start-time>
time zone adjustments ( z = )
z= <adjustment time> <offset> <adjustment time> <offset> ….
useful for scejduling session during transation to daylightv saving to standard time and vice versa
Media Description in SDP
For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session
m= <media> <port> <proto> <fmt> …
m=audio 20098 RTP/AVP 0 101
will stream RTP on 20098 and RTCP on 20099
For multiple transport ports pairs of RTP , RTCP stream are specified
m= <media> <port>/ <number of ports> <proto> <fmt> …
m=audio 20098/2 RTP/AVP 0 101
will stream one pair on RTP 20098 , RTCP 20099 and RTP 20100 , RTCP 20101
If non-contiguous ports are required, they must be signalled using a separate attribute like example, “a=rtcp:”
Additioan SDP features : In addition to normal unicast sessions , SDP can also convery multicast group address for media on IP multicast session. Private (encryption of SDP ) or public session are not treated differently by SDP and they are entorely a function of implementing mechanism like SIP or SAP. Optiopnal SDP params include URI , Categorisation “a=cat:” , Internationalisation etc
Example 1 : Typical Audio call SIP INVITE showing SIP headers in blue and SDP in green below
INVITEnbspsip:01150259917040@x.x.x.x SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5060branch=z9hG4bK400fc6e6 From: "123456789" ltsip:123456789@x.x.x.xgttag=as42e2ecf6 To: ltsip:01150259917040@x.x.x.x.4gt Contact: ltsip:123456789@x.x.x.x4gt Call-ID: 2485823e63b290b47c042f20764d990a@x.x.x.x.x CSeq: 102 INVITE User-Agent:nbspMatrixSwitch Date: Thu, 22 Dec 2005 18:38:28 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER Content-Type: application/sdp Content-Length: 268 v=0 o=root 14040 14040 IN IP4 x.x.x.x s=session c=IN IP4 x.x.x.x t=0 0 m=audio 26784 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=fmtp:18nbspannexb=no - - - - c=* (connection information - optional if included at session-level) b=* (bandwidth information) a=* (zero or more media attribute lines)
The above SDP shows 4 supported media codecs on audio stream which are 0 PCMU , 8 PCMA , 18 G729 and finally 101 used for telephone events . It also shows RTP/AVP as RTP profile and does not contain any m=cideo line which shows that this endpoint does not want a video call , only an audio one.
Example 2 : Video Vall SIP invite from Linphone
SIP URI Params
Internet Assigned Number Authority (IANA) Universal Resource Identifier (URI) Parameter Registry defines URI params that can be sued along with SIP scheme
sip:user:password@host:port;uri-parameters?headers
comp param
signalling compression of SIP messages
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
The aobve exmaple indicates that the request has to be compressed using SigComp
transport-param
SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768), TCP (RFC 761), and SCTP (RFC 2960).
For a SIPS URI, the transport parameter MUST indicate a reliable transport.
“transport=” ( “udp” / “tcp” / “sctp” / “tls” / “ws” / other-transport )
sip:alice:secretword@atlanta.com;transport=tcp
maddr paarm
The server address ( detsiantion address , port , transport ) to be contacted for this user, overriding any address derived from the host field.
Although discouraged , maddr URI param has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination.
user-param
“user=” ( “phone” “ip” “dialstring” other-user )
sip:1-212-555-1212:1234@gateway.com;user=phone
sip:123;phone-context=atlanta.example.com@example.com;user=dialstring
method-param
“method=” Method
sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
annc-parameters (announcement)
ANNC-URL
sip‑ind annc‑ind “@” hostport annc‑parameters uri‑parameters
sip:annc@ms.example.net;
; play=file://fs.example.net//clips/my-intro.dvi;
; content-type=video/mpeg%3bencode%d3314M-25/625-50
sip-ind - “sip:” / “sips:”
annc-ind - “annc”
annc-parameters
“;” play‑param
[ “;” delay‑param ]
[ “;” duration‑param ]
[ “;” repeat‑param ]
[ “;” locale‑param ]
[ “;” variable‑params ]
[ “;” extension‑params ]
play-param – “play=” prompt‑url
prompt-url – “/provisioned/” announcement‑id
announcement-id = 1*( ALPHA / DIGIT )
content-param “content‑type=” MIME‑type
VoiceXML Media Services
dialog-param
“voicexml=” vxml-url ; vxml-url follows the URI syntax
method-param – “method=” ( “get” / “post” )
postbody-param- “postbody=” token
ccxml-param – “ccxml=” json‑value
aai-param- “aai=” json‑value
json-value – false / null / true / object / array / number / string
sip:dialog@mediaserver.example.com;
voicexml=http://appserver.example.com/promptcollect.vxml;
maxage=3600;maxstale=0
dialog-params (prompt and collect)
DIALOG-URL = sip-ind dialog-ind “@” hostport dialog‑parameters
ttl-param (time-to-live)
ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP.
sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15
cause param
“cause” EQUAL Status-Code
; 404 Unknown/Not available
; 486 User busy
; 408 No reply
; 302 Unconditional
; 487 Deflection during alerting
; 480 Deflection immediate response
; 503 Mobile subscriber not reachable
; 380 Service number translation RFC 8119 – Section 2
sip:voicemail@example.com;target=bob%40example.com;cause=486
SIP Responses
1xx—Provisional Responses
response that tells to its recipient that the associated request was received but result of the processing is not known yet which could be if the processing hasnt finished immediately. The sender must stop retransmitting the request upon reception of a provisional response.
100 Trying
180 Ringing : Triigers a local ringing at callers device
181 Call is Being Forwarded : Used before tranefering to another UA such as during forking or tranfer to voice mail Server
182 Queued
183 Session in Progress : conveys information . Headers field or SDP body has mor details about the call. Used in announcements and IVR + DTMF too by being followed by “Early media”.
199 Early Dialog Terminated
2xx—Successful Responses
final responses express result of the processing of the associated request and they terminate the transactions.
200 OK
202 Accepted
204 No Notification
3xx—Redirection Responses
Redirection response gives information about the user’s new location or an alternative service that the caller should try for the call. Used for cases when the server cant satisfy the call and wants the caller to try elsewhere . After this the caller is suppose to resend the request to the new location.
300 Multiple Choices
301 Moved Permanently
302 Moved Temporarily
305 Use Proxy
380 Alternative Service
4xx—Client Failure Responses
negative final responses indicating that the request couldn’t be processed due to callers fault , for reasons such as t contains bad syntax or cannot be fulfilled at that server.
400 Bad Request
401 Unauthorized
402 Payment Required
403 Forbidden
404 Not Found
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
410 Gone
411 Length Required
412 Conditional Request Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Unsupported URI Scheme
417 Unknown Resource-Priority
420 Bad Extension
421 Extension Required
422 Session Interval Too Small
423 Interval Too Brief
424 Bad Location Information
428 Use Identity Header
429 Provide Referrer Identity
430 Flow Failed
433 Anonymity Disallowed
436 Bad Identity-Info
437 Unsupported Certificate
438 Invalid Identity Header
439 First Hop Lacks Outbound Support
470 Consent Needed
480 Temporarily Unavailable
481 Call/Transaction Does Not Exist
482 Loop Detected.
483 Too Many Hops
484 Address Incomplete
485 Ambiguous
486 Busy Here
487 Request Terminated
488 Not Acceptable Here
489 Bad Event
491 Request Pending
493 Undecipherable
494 Security Agreement Required
5xx—Server Failure Responses
negative responses but indicating that fault is at server’s side for cases such as server cant or doesnt want to respond the the request.
500 Server Internal Error
501 Not Implemented
502 Bad Gateway
503 Service Unavailable
504 Server Time-out
505 Version Not Supported
513 Message Too Large
580 Precondition Failure
6xx—Global Failure Responses
request cannot be fulfilled at any server with definitive information
600 Busy Everywhere
603 Decline
604 Does Not Exist Anywhere
606 Not Acceptable
Mandatory SIP headers in SIP respone
SIP/2.0 200 OK Via: SIP/2.0/UDP host.domain.com:5060 From: Bob<sip:bob@domain.com> To: Altanai<sip:altanai@domain.com> Call-ID: 163784@host.domain.com CSeq: 1 INVITE
Via, From, To, Call-ID , and CSeq are copied exactly from request
Re-INVITE and Target-Refresh Request Handling
An INVITE request sent within an existing dialog is known as a re-INVITE. A re-Invite has an offer-answer exchange and can be used to do the following
- change the session and/or dialog params
- change the port to which media should be sent.
- change the connection address or media type.
- Hold/Release and SUSPEND/RESUME rtp streams (connection address is zero).
- FAX (T.38 and Bypass).
Re-INVITE with SDP useCases
1.UAS rejects all changes in params in re-INVITE
Situtaion where UAC establishes audio only call
SDP1: m=audio 30000 RTP/AVP 0
but later wants to upgrade to video as well SDP:
m=audio 30000 RTP/AVP 0 m=video 30002 RTP/AVP 31
UAS configured to reject video streams, can reject this with a 4XX error and get ACK .
No changes to session are made
2. UAS receives re-INVITE for param but wants to accept few and reject others, it sends back SDP with acceptable changes with 200 OK
For instance UAC moves to high bandwidth access point and wants to update IP of media stream . It also wanst to add video stream
initial SDP
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
new SDP in reINVITE
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
UAS returns a 200 (OK) response to accept IP but sets the port of the video stream to zero in its SDP to show rejected of video stream.
m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5 m=video 0 RTP/AVP 31
another example is when UAC wwants to add another audio codec and also add video stream to session
orignal SDP
m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1
re-invite SDP
m=audio 30000 RTP/AVP 0 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
again the UAS will optionally accept the some param canges like audio code but set video to null IP address
m=audio 31000 RTP/AVP 0 3 c=IN IP4 192.0.2.5 m=video 31002 RTP/AVP 31 c=IN IP4 0.0.0.0
3. UAS receives re-INVITE but waits for user intervention
UAS receives re-INVITE to add video , but instead of rejecting , it prompts user to permit.
So UAS provides a null IPaddress instead of setting the stream to ‘inactive’ because inactive streams still need to exchange RTP Control Protocol (RTCP) traffic
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
Later if user rejects the addition of the video stream. Consequently, the UAS sends an UPDATE request (6) setting the port of the video stream to zero in its offer.
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
References:
- RFC 3261 SIP
- RFC 4566 SDP https://tools.ietf.org/html/rfc4566
- RFC 6141 Updates the RFC 3261 with respect to re-INVITE and UAS behaviour https://tools.ietf.org/html/rfc6141
- Techinvote : https://www.tech-invite.com/fo-abnf/tinv-fo-abnf-sipuriup.html