1.1 SIP Message Classification
SIP protocol is formed in the form of layer protocol, that is, its behavior is described in a set of relatively independent processing stages, the relationship between each phase is not very close.
The SIP protocol divides the messages between the server and the user agent into two categories: the request message and the response message.
Request message: A SIP message that the client sends to the server in order to activate a specific operation, including Invite, ACK, BYE, CANCEL, option, and update messages.
6 Ways to SIP requests:
1. Invitation (INVITE)--Invite users to join the call
2. Confirm (ACK)--Confirm that the client has received the final response to the invite
3. Optional (options)--request information about the capabilities of the server
4. Goodbye (BYE)--terminate calls between two users on a call
5. Cancellation (cancel)
6, registration (register)-Provide the mapping of address resolution, let the server know the location of other users
Response message: A SIP message that the server responds to the customer for the processing result of the request, including 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx responses
1.2 SIP message Structure
Both the request message and the response message include the SIP Message header field and the SIP Message body field;
SIP message header is mainly used to indicate the basic information that this message is initiated by WHO and by whom, after how many jumps;
SIP message body is mainly used to describe the specific implementation of this session;
1.3 Message Formats
1.3.1 Request Message Format
The format of the SIP request message, consisting of a SIP message header and a set of parameter rows, as shown in Figure 3-1. The command line and each parameter line are differentiated by line breaks.
Figure 1-1 SIP Request message structure
Note: The order of the parameter rows is not fixed. The corresponding parameter explanation is shown in 6.3.
Message body Definition:
Call-id: The header field is the unique identifier used to group messages
The From: Header field is the logical identity that indicates the initiator of the request, which may be the user's registered address. The From header field contains a URI and an optional display name
CSeq: The header field is used to identify transactions and sort transactions. It consists of a request method and a sequence number, and the request method must match the corresponding request message type
Max-fowords: The header field limits the maximum number of hops that a request message is allowed to pass before it reaches its destination. It contains an integer value, which is reduced by one per hop. If the value becomes 0 before the request message arrives at the destination, the request is rejected and a 483 (too many Hops) error response message is returned.
The Via: Header field defines the underlying (Transport Layer) transport protocol for the SIP transaction and identifies where the response message will be sent. The Via header field value can be added to the request message only if the transport protocol used to reach the next hop is selected.
Expires: The parameter indicates the validity period of the URI address contained in the value. The value of this parameter is measured in seconds. If this argument is not provided, the validity period of the URI address is determined by the Expires header field value.
The invite message is one of the SIP request messages.
The first line consists of the URI of the message header and peer SIP entity (Common resource Identifier) and the SIP version number.
A SIP URI is a telephone URI, attached to an IP address, that represents the domain of the port on which to send and receive SIP messages to the end and endpoint.
The three SIP message headers "from", "to" and "contact" belong to the phone URI.
When a back-to-back user agent makes a call, the URI in the "from" message header is filled out in the "Via" message head.
The request message type is filled in in the CSeq header, and when the SIP endpoint sends a request, the number is incremented accordingly.
The SIP protocol version is sip/2.0. Where SDP is added to the invite message content, content-length in the message header illustrates the length of the SDP content.
The INVITE request message is detailed:
INVITE sip:marconi@radio.org sip/2.0
<= request method, request address (Request-uri), SIP version number (currently sip/2.0)
<= request address is usually called party address, and MSN Friend email address similar
VIA:SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hg4bkfw19b
<=sip version number (2.0), Transport type (UDP), call address,
<=branch is a random code, which is considered a transmission identifier
The address in the <=via field is the message sender or proxy forwarding device address, which is typically composed of a host address and a port number
The <= transport type can be UDP, TCP, TLS, SCTP
Max-forwards:70
<= maximum number of hops, is the number of hops through the SIP server, mainly to prevent cyclic jumping
<= each proxy server, the integer is reduced by one
To:g. Marconi <sip:Marconi@radio.org>
From:nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
<= indicates the sender and destination of the request message
<= If there is a user name tag in it, the address needs to be wrapped in angle brackets.
<= for invite messages, you can include tag in the From field, which is also a random code
call-id:123456789@lab.high-voltage.org
The <= call ID is a globally unique value generated by the local device. The value is the same for each call
<= The invite message is sent to the user agent, the from tag and Call-id global unique codes are generated locally, and the called party Agent generates the to tag global unique code. These three random codes are used for the entire conversation of the dialogue Identifier (dialog indentifier) on both sides of the call.
Cseq:1 INVITE
<=CSEQ, also called command seqence, each time a new request is sent, the number is automatically added 1
* The above fields are required for all SIP message bodies, some of the other header fields are optional, and some are required for specific requests
Subject:about that Power Outage ...
Contact: <sip:n.tesla@lab.high-voltage.org>
<=contact is required for invite messages, it is routed to the called device address, also known as the user agent (UA)
Content-type:application/sdp
content-length:158
<= the last two-bit subordinate field describes the message body type and the field length
V=0 <=SDP version number, which is now 0.
O=tesla 28908445262890844526 INIP4 lab.high-voltage.org <= Calling Source address, type, etc.
S=phone Call
1.3.2 Response Message Format
The format of the SIP response message, consisting of a SIP response message header and a set of parameter rows, as shown in Figure 3-2. The command line and each line of arguments are differentiated by line breaks.
SIP Response Message Structure
Note: The order of the parameter rows is not fixed. The corresponding parameter explanation is shown in 6.3.
SIP Response Message instance:
sip/2.0 OK
Content-type:application/sdp
VIA:SIP/2.0/UDP 127.0.0.1:5061
call-id:01ef351f8140000000000@127.0.0.1
Cseq:1 INVITE
from:<sip:010203@127.0.0.1:5061; user=phone>;tag=29005358336b534f610a000
to:<sip:0109@127.0.0.1:5060; user=phone>;tag=5358336b534f2900cd1b0000
Contact:<sip:0109@127.0.0.1:55061>
content-length:156
The OK message is one of the SIP response messages.
The first line consists of a SIP version number and a 200 response message.
A SIP URI is a telephone URI, attached to an IP address, that represents the domain of the port on which to send and receive SIP messages to the end and endpoint.
The three SIP message headers "from", "to" and "contact" belong to the phone URI.
When a back-to-back user agent makes a call, the URI in the "from" message header is filled out in the "Via" message head.
The request message type is filled in in the CSeq header, and when the SIP endpoint sends a request, the number is incremented accordingly.
The SIP protocol version is sip/2.0. Add the SDP to the invite message content, explaining the length of the content in the message header.
Chapter Two main response codes of SIP protocol
2.1 Response Code Classification
SIP response messages are used to respond to a request message indicating the success or failure status of the call. Response messages of different classes are distinguished by status codes, which contain three-bit integers, the first bit of the status code is used to define the response type, and the other two bits are used to further explain the response in more detail. The classification of the response message is as follows.
1) 1XX: A temporary response indicating that the request message is being processed.
2) 2XX: Successful response, indicating that the request has been successfully received, fully understood and accepted.
3) 3XX: Redirect response, indicating that further steps need to be taken to complete the request.
4) 4XX: Client error indicates that the request message contains a syntax error message or the server cannot complete the client request.
5) 5XX: Server error, indicating that the server could not complete a legitimate request.
6) 6XX: Global failure, indicating that any server could not complete the request.
In the above message, the temporary response is used to indicate that the call is in progress, and the remaining final response is used to end the request message.
2.2 1XX Class Message (ad hoc response)
A 1XX message indicates that the server or agent is processing and has not received a definite response. The customer should continue to wait for the server to respond. When the server predicts that a final response cannot be received within 200 milliseconds, it should send a 1xx response. The server can send multiple 1xx responses. The following is a list of common 1xx class messages.
Table 1-1 Common 1XX class message lists
100 Call (Trying) is making calls-related operations (for example, accessing the database), but the called user has not yet been targeted.
180 called ringing (ringing) called the user agent has gotten the called position, which is being reminded of the called user. The response can also initiate a local return ring
181 Call forward (called is Being forwarded) the proxy server can use this status code to indicate that the current call is being transferred to another destination. (Call is forwarding)
182 Call Queuing (Queued) is called temporarily inaccessible, and the current call is queued instead of being rejected. When the server is active, you can continue to respond to the call. The response's "reason phrase" can further give information about the queued call, for example: "There are 5 calls in the queue and the expected wait time is 15 minutes." The server can issue multiple 182 responses to update information for the currently queued call.
The 183 session Progress answer is used to prompt the progress information for the dialog. Reason-phrase (the sentence that expresses the reason), the Head field, or the message body can be used to prompt for information about the update message of the call progress.
2.3 2xx Class Message (successful response)
2XX message indicates that the request has been received, processed and successfully accepted;
200:ok---request succeeded.
2.4 3xx Class Message (redirected response)
A 3xx message indicates that the response gives information about the user's new location or other optional service. Table 4-3 Below is a list of common 3xx class messages.
Table 1-2 Common 3XX class message lists
More than 300 select (multiple Choice) addresses in the request are resolved to multiple locations, and the user can redirect the request to an appropriate address. The response should contain a list of locations and resources that can be selected by the user or user agent, and in the Contact header field, list the addresses that are available for selection. (Network protocol is incompatible: one or more network protocols in the session description are not available.) ）
301 Permanent Departure (Moved permanently) in the request Request-uri the address that is not found by the user, the customer should try the Contact header field to give the new address. When the caller receives the response, it should update all local directories, address books, user location caches, and redirect future requests to the new address. (Network address format is incompatible: one or more address formats in the session description are not available.) ）
302 Leave temporarily (Moved temporarily) the customer should try the call with a new address given in the Contact header field. The Expire header field in the response indicates the validity period of the redirect, and if the validity period is not given, the redirect is valid only for the current call. (Transport protocol is incompatible: one or more delivery protocols in the session description are not available.) ）
303 bandwidth units are incompatible: one or more of the bandwidth units in the session description are not understood.
304 Media type is not available: one or more media types in the dialog description are not available.
305 The resource requested by the client using the proxy must be accessed through a proxy given in the contact header domain. The Contact header field gives the URI of the proxy. The response can only be issued by the user proxy server. (Incompatible Media Format: one or more media formats in the dialog description are not available.) ）
306 Media features are not understood: one or more media features in the dialog description are not supported.
307 dialog Description Parameters are not understood: parameters other than the above parameters are not understood.
330 Multicast is not available: The user site does not support multicast.
331 unicast is not available: Unicast traffic is not supported at the user site (usually due to the presence of a firewall)
370 Insufficient bandwidth: the bandwidth defined in the dialog description, or the media defined, exceeds the available bandwidth.
380 calls using other services (Alternate service) are unsuccessful, but other services (e.g. email, voicemail) are optional. The message body of the response gives a description of the optional service.
399 Mixed alarm: This alarm indicates any error of the user, the system receiving the alarm can not take any automatic action
2.5 4xx Class Message (client error)
The 4XX message indicates that the request message contains a syntax error or that the SIP server cannot complete the processing of the request message. Table 4-4 Below is a list of common 4xx class messages.
Table 1-3 Common 4xx class message lists
400 invalid requests (Bad Request) Request syntax is incorrect and cannot be understood by the server.
401 Unauthorized (unauthorized) requests require user authentication.
402 fee required (Payment Required) The response is reserved for future use.
403 (Forbidden) The server understands the request but refuses to complete it. The customer should not send a request again.
404 no User (not Found) is found in the request Request-rul the address given in does not have to be called. When the address given by Request-rul does not match the server-managed domain, the server also sends the response.
The 405 method does not allow the method specified in the request line to be disallowed (method not allowed). The response must contain an Allow header field that lists the methods supported by the server.
406 unacceptable (not acceptable) depending on the ACCPE header domain in the request, the content characters inside the response entity generated by the requested resource are unacceptable.
407 Agent Authentication Required (proxy authentication Required) The response is similar to 401 (unauthorized), but it indicates that the user must first authenticate themselves to the agent.
408 Request Timeout (requests timeout) The server cannot generate a response within the time specified by the requested expire header domain. Customers can re-send requests over a period of time.
409 conflict (CONFLICT) the client's request is in conflict with the current state of the resource and cannot complete the request. The response is returned when the register request's action parameter conflicts with an existing registration.
410 No available resources (Gone) The requested resource is not on the server, and no further contact addresses are known. This situation is considered to be permanent. If the server cannot determine whether the condition is permanent, it should send a 404 (called Not found) response.
411 requires a message body length (length Required) The server refuses to accept a request that does not contain a content-length header domain. Why did the customer re-send the request after joining a Cotent-length header field that represents the length of the message body?
413 The requested entity is too long (Request entities Too Large) the server refuses to process too long message entities. If this situation is temporary, the server should include the Retry-after header field in the response to indicate when the customer will re-send the request.
414 Request-uri too long (Request-uri Too long) The server cannot parse too long request-uri.
415 Media types not supported (unsupported media type) The format of the request message body is not supported by the server. The server should list the formats it supports in the response with the Accept,accept-encoding and Accept-language header fields.
416 The unsupported URI scheme (unsupported URL scheme) server terminates processing this request because it does not support URI schemes in Request-uri.
The 420 error extension (bad Extension) server does not understand the protocol extension specified in the Require header domain in the request.
421 require extended support (extension required) UAS require specific extensions to handle this request, but this extension is not listed in the requested supported header domain. An answer with this answer code must contain an require header field that lists the required extensions.
UAS should not use this response unless it really does not provide a valid service to the client. Conversely, if the required extensions are not listed in the support header domain, the server should be processed based on the baseline SIP-compliant methods and the extensions supported by the client.
The 423 interval is too short (interval too brief) The server rejects the request because the resource refresh time (or validity time) set in the request is too short. This response can be used to register the server to reject registration requests that have a short validity period for the contact header domain.
480 temporarily inaccessible (temporarily unavailable) the called Terminal system has been successfully connected, but the user is temporarily inaccessible (for example: the user is not logged in, or is logged on as a non-intrusive). The server can specify an additional access time in the Retry-after header domain.
481 Call Slip/transaction does not exist (called Leg/transaction Does not Exist) in two cases the server returns the response: the server received a bye request but could not find a matching call slip, or received a cancel request but could not find a matching transaction; is to receive a invite request that is not the same as the original tag flag. (For an ACK request that does not match, the server discards it directly and does not respond).
482 the VIA header domain that detects a circular call (loop detected) Request message contains the address of the receiving server itself.
483 hops Too many (Too many hop) requests that the VIA header field contain more entries (hops) than the value specified by the Max-forwards header field.
484 addresses not fully addressed by address incomplete request to or Request-rul.
485 address ambiguous (ambiguous) the called address provided in the request is ambiguous. The response can list ambiguous addresses in the Contact header field.
486 called busy (Busy here) the called Terminal system has been successfully connected, but the user is temporarily unwilling or not able to receive more calls. The server can specify an additional access time in the Retry-after header domain of the response. The customer may also be accessed through other means, such as a voice mailbox, so the response does not terminate a query. If we know that no other terminal system can answer this call, then we should return a status code of (Busy Everywhere).
487 Request Cancelled The original request message was canceled by a cancel request.
488 This request does not accept (not acceptable here) the answer and 606 (not acceptable) have the same meaning, but only the specific resources that are applied to Request-uri are unacceptable, and requests from elsewhere may be acceptable. The body of the message containing the media compatibility description can appear in the answer and be normalized according to the Accept header field in the Invite request (if there is no Accept header field, then APPLICATION/SDP). This response is like the message body that answers the options request (OK).
491 pending requests (Request pending) in the same conversation, the request received by UAS has a dependent request being processed.
493 Unable to decrypt (undecipherable) is not identifiable, the UAS receives a request that contains an encrypted mime, and does not know or provide the appropriate decryption key. This response can contain a single package containing the appropriate public key, which is used to encrypt the packet in the UAS communication.
2.6 5xx Class message (server error)
A 5xx message indicates that a SIP server failure cannot complete processing of the correct message. Table 4-5 Below is a list of common 5xx class messages.
Table 1-4 Common 5XX class message lists
500 Server Internal error (server Internal error) The server has an exception and cannot process the request.
501 The function is not implemented (not implemented) the server does not support the functionality necessary to complete the request.
502 Gateway Error (bad Gateway) a server that is a gateway or proxy receives an invalid response from another server when it processes a request.
503 Service Unavailable (Sevice unavailable) The server is currently unable to process the request due to temporary overloading or maintenance.
504 Gateway Time-outs (gateways Timeout/service time-out server timeouts) as the gateway's server does not receive a response from other servers (for example, the location server) in time to process the call.
Version 505 does not support versions that are used by the server to not or deny support for Request messages (version not supported).
513 Messages too large (message too large)
2.7 6XX Class message (Global error)
A 6XX message indicates that the request cannot be implemented on any SIP server. Table 4-6 Below is a list of common 5xx class messages.
Table 1-5 Common 5XX class message lists
600 full-busy (Busy Everywhere) The called Terminal system has been successfully connected, but the user is busy and unwilling to accept the current call. The server can specify an additional access time in the Retry-after header domain of the response. The response is only for situations where the customer cannot access it in another way, such as a voice mailbox. If the user is accessible by other means, the 486 (Busy here) response should be returned.
603 Deny (decline) the called Terminal system has been successfully connected, but the user is explicitly unwilling to accept the current call. The server can specify an additional access time in the Retry-after header domain of the response.
604 called does not exist (Does not Exist Anywhere) the requested to header domain does not exist for the specified user.
606 unacceptable (not acceptable) user agents have successfully connected, but some session descriptions such as media type, bandwidth, or address style are unacceptable. The response indicates that the user wants to establish communication, but does not fully support the session described by the request.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
