SIP (Session Initiation Protocol) Conversation Initiation Protocol

SIP (Session Initiation Protocol) Conversation Initiation Protocol is an application layer control (signaling) protocol for network telephony and conferencing. It is mainly a multimedia communication protocol based on IP network. It can realize the signaling functions are also using RTP as a media transmission protocol. Originally presented by the IETF Mmusic (multiparty multimedia session control) workgroup.

SIP can achieve the main functions are: 1, network Office, 2, instant messaging, 3, real-time state management, 4, network IP Phone, 5, network conferencing. is composed of the following parts,
Bottom: UA Toolkit API (tool pack)
Interface layer: Call control (API), User state management (API), instant Messaging (API)
Application layer:
UAC (client) process
Call Control-〉 initialization (including registration)-〉 session call establishing-〉 media and data channel negotiation-〉SDP packet parsing
User Status-〉 status information subscription and notification-〉 state information Settings-〉 state information query
Instant Message Send Instant message: Receive instant message
UAS (server side)
Conference Management: Set up meetings, join meetings, revise meetings, leave meetings, close meetings, inquire about the relevant information of the meeting, and publish the status of the meeting;
User management: Location information query, user authentication, increase users, delete users;
Media management: Initializing (negotiating media channels, specifying ports and properties), sending media streams, receiving media streams, and adding or removing media streams from users.
The RTP/RTCP protocol stack is provided to complete the Send/receive and transmit of the media stream.

In the connection of the address of the use of the URL, more convenient, mainly in the format: User name @ host address, called Number @pstn gateway address and such as tel:010-62281234, such as ordinary phone number description. The most powerful thing about SIP is the user positioning function. Messages and signaling are encoded using text. SIP is used to initiate a session that controls the management of multimedia sessions involving multiple participants and dynamically adjusts the properties of the session. SIP is independent of low-level protocol, generally uses UDP and other connectionless protocols, and uses its own application layer reliability mechanism to ensure the reliable transmission of messages.

Important Concepts:
UA: The user agent describes a common user terminal and user agent, with the client and server points in the SIP. A client is an application that establishes a connection to a server in order to send a request to the server. The user agent and the agent (proxy) contain clients. A server is an application that is used to send a request to a client to provide a service and echo the answer. There are 4 basic types of servers:
· User Proxy Server: Contact the user when the SIP request is received and return the response on behalf of the user.
· Proxy server: Initiates a request on behalf of another client that acts as a media program for both the server and the client. It may overwrite the contents of the original request message before forwarding the request.
· REDIRECT server: Receives SIP requests, maps the original address in the request to 0 or more new addresses, and returns it to the client.
· Registration server: Receives the client's registration request, completes the user address registration.

SIP is simpler for lexical and grammatical analysis of messages expressed in text form. has a distributed multicast function.
Features available: 1 name translation and user positioning: 2 feature negotiation: 3 Call Participant Management 4 call feature change
SIP has two elements: SIP user agent and SIP network server.
The user agent is the terminal system element of the call, and the SIP server is the network device that handles the associated signaling of multiple calls. The user agent itself has a client element (User Agent client UAC) and a server element (user Proxy server UAS). The client element initiates the call and the server element answers the call. This allows point-to-point calls to be done through the client-server protocol.
The main function of the SIP server is to provide name resolution and user positioning. What you can get is an email address or a phone number associated with the caller. With this information, the caller's user agent can identify a particular server to resolve the address information-which may involve many servers in the network. The SIP proxy server receives the request, decides where to send the requests, and routes them to the next server (using the next hop routing principle). There can be multiple jumps in the network.

The structure of the SIP protocol stack:
The bottom layer of the SIP is syntax and coding.
The second layer is the transport layer: it defines how a client on the network sends requests and receive responses and how a server receives requests and sends responses.
The third layer is the transaction layer: Transaction layer processing application layer retransmission, matching response to request, and application tier timeout.
Tasks performed by any user agent client (UAC) are generated using a set of transactions. SIP addresses the user's address by email. Each user is identified by a hierarchical URL, which is constructed by elements such as a user phone number or a host name (for example, sip:user@company.com). Because of its similarity to the email address, SIP URLs are easy to associate with the user's email address. The caller uses invite to request an initial call when a user wants to call another user, the caller uses invite to request an initial call, and the request contains enough information to be used by the caller to participate in the session. If the client knows the location of the other party, it can send the request directly to the other side's IP address. If not known, the client sends the request to a locally configured SIP network server. If the server is a proxy server, it resolves the location of the called user and sends the request to them. There are a number of ways to do this, such as searching DNS or accessing the database. The server can also be a redirected server, which can return the location of the called user to the calling client for direct contact with the user. In the process of locating a user, the SIP network server can, of course, be able to proxy or redirect calls to other servers until it arrives at a server that clearly knows the IP address of the user being called. Once the user's address is found, the request is sent to the user, and several options are produced. In the simplest case, the user's telephone client receives the request-that is, the user's telephone ringing. If the user accepts the call, the client responds to the request with the specified ability of the client software and establishes the connection. If a user rejects a call, the session is redirected to a voice mailbox server or another user. Specify capabilities to refer to features that the user wants to enable. For example, the client software can support video conferencing, but the user only wants to use audio conferencing, which only enables audio features.
SIP also has two other important features. The first is a stateful SIP proxy has the ability to split into or copy into a call, allowing several extended branches to run at the same time. The first answering branch accepts the call. This feature is very handy when the user is working between two locations (for example, laboratories and offices) or at the same time ringing the manager and his secretary. The second feature is SIP's unique ability to return different media types. Give an example of a user contact company. When a SIP server receives a client's connection request, it is able to return to the customer's client via the Web Interactive Voice Response page, which has branch branches available to it or users who provide it on the list. Clicking on the appropriate link will send a request to the clicked selected user to establish the call.

There are two types of SIP messages:
Request: Send from client to server
Response: Send from server to client
SIP Request message contains three elements: Request line, header, message body. SIP response messages contain three elements: status row, header, message body. The request line and header domains define the nature of the call based on business, address, and protocol characteristics, which are independent of the SIP protocol and can contain anything.

SIP defines the following methods:
invite--invite users to join the call.
bye--terminates a call between two users on a call.
options--requests information about the server's capabilities.
ack--confirms that the client has received a final response to the invite.
register--provides address resolution mapping to let the server know where other users are located.
info--for the session Citic Order.

2.1 The overall description of SIP messages
There are two types of SIP messages: Requests from the client to the server (request), and the response of the server to the client (Response). SIP messages consist of a starting line (Start-line), one or more fields (field) headers, a blank line (CRLF) that flags the end of a message header, and a message body (the message Boby) as an option, which describes the body The head of the body is called the entity header (entity header). Generic-message = Start-line *message-header CRLF [message-body] Start Row-Request line (Request-line) and status line (Status-line) Where the request line is the starting line for the request message, and the status row is the starting line for the response message. The message header is divided into Universal headers (General-header), request headers (Request-header), Response Headers (Response-header), and entity headers (Entity-header) four.

The format of the 2.2 SIP request message Request message is as follows.
Request = Request-line * (General-header | request-header | Entity-header CRLF [message-body] The request line (Request-line) begins with the method tag, followed by the Request-uri and protocol version (Sip-version), and ends with the return key, which is separated by a space-bar character interval between the elements. Request-line = Method sp Request-uri sp sip-version CRLF SIP uses the term "method" to describe the description section, and the method identifier is case-sensitive. SIP defines the following methods (methods). method = "INVITE" | "ACK" | "Options" | "BYE" | "Cancel" | "REGISTER" | The "INFO"-invite INVITE method is used to invite users and services to participate in a session. In the message body of the invite request, the session to which the callee is invited can be described. such as the type of media that the caller can receive, the type of media emitted, and some of its parameters: a successful response to a invite request must indicate in the message body of the response that the called party is willing to receive the media, or the media sent by the called party. The server can automatically respond to meeting invitations by using the (OK). The-ack ACK request is used by the client to confirm to the server that it has received the final response to the invite request. The ACK is only used with the invite request. The confirmation of the 2XX final response is issued by the client user agent, and the confirmation of the other final response is issued by the first agent or the first client user agent receiving the response. The value of the To, from, call-id,cseq fields of an ACK request is copied from the value of the corresponding field of the corresponding Inivite request. -options is used to query the server for its capabilities. If the server thinks it can contact the user, a capability set is available to respond to the options request, and the agent and redirect server simply forwards the request without displaying its ability. The From and to options contain the address information of the master being called, and the value of from, to (possibly plus the tag parameter) in the response to the options request is copied from the value of the field in the response in the options request bye the Call-id field. The user Agent client uses the bye request to indicate to the server that it wants to release the call. Bye requests can be forwarded as invite requests and can be issued by the caller or by the called Party. The caller must issue a bye request before releasing (hangs) the call, receive BThis side of ye request must stop sending the media stream to the party that issued the bye request. The-cancel cancel request is used to cancel an ongoing request that has the same value for a call-id,to,from and CSEQ (only serial number) field, but does not cancel a completed request (if the server returns a final state response, the request is considered complete). The number portion of the CALL-ID,TO,CSEQ in the cancel request and the corresponding field value of the From field and the original request match the cancel request to the request it is canceling. The-register register method is used by the client to register address information in the To field to the SIP server. The meanings of each field in the Register request message header are defined as follows: to: The address record that contains the registration to create or update. From: The address record of the person who submitted the registration. Request-uri: The destination address of the registration request, the value of the domain portion of the address is the domain where the responsible registrant resides, and the host part must be empty. Generally, the value of the domain portion of the address in Request-uri is the same as the value of the domain portion of the address in to. Call-id: A request to identify a specific client. Registration requests from the same client are expected to have the same Call-id field values for at least the same restart cycle; The user can register different addresses with different call-id values, and subsequent registration requests replace the previous request. The CSeq field value of the registration request with the same Cseq:call-id field value must be incremented, but the order is not related and the server does not reject the unordered request. Contact: This field is optional: The non-registration request to be sent to the URI in the To field is forwarded to the location given by the contact field. If the contact field is not in the request, the registration remains unchanged. Expires: Indicates the deadline for registration. The-info INFO method is an extension of the SIP protocol, which is used to pass the session-related control information, such as ISUP and ISDN signaling messages, for use in this method, which is still to be standardized, see IETF RFC 2976 for details.

The format of the 2.3 SIP response Information Response information is as follows.
Response = Status-line * (General-header | response-header | Entity-header CRLF [message-body] status line (Status-line) begins with the protocol version, The following is a digital state code (STATUS-CODE) and related text descriptions, with the end of the ENTER key and the empty characters (SP) interval between the elements, except in the final CRLF sequence, where carriage returns or newline characters are not allowed. Status-line = the sip-version sp status-code SP reason-phrase CRLF SIP Protocol represents a response to the request with a three-bit integer status code (status code) and a Reason value (Reason code). The status code is used for machine recognition operations, and the reason phrase (reason-phrase) is a simple text description of the status code, which is used for human recognition. Status-code = 1xx (information) | 2XX (Success) | 3xx (redirection) | 4xx (Client-error) | 5xx (Service-error) | 6XX (global-failure) | The first number in the Extension-code status code defines the category of the response, with 6 values in the first number in sip/2.0, defined as follows: 1xx:informational-The request has been received and the request continues to be processed. 2xx:success-Action has been successfully received, understood and introduced. 3xx:redirection-In order to complete the call request, further action must be taken. 4xx:client ERROR-The request has syntax errors or cannot be executed by the server. The client needs to modify the request and then send the request again. 5xx:server Error-Server error, cannot execute legitimate request. 6xx:global failure-No server can execute the request. Where the 1xx response is a temporary response (provisional response), and the other response is final response.

2.4 Sip Message Header field
The message definition of the SIP protocol is similar to that of HTTP in terms of syntax rules and definitions. Each header field follows the following format: First, field name, field name, case-insensitive, followed by a colon, followed by a field value, with multiple leading spaces (LWS) between the field value and the colon. Message-header = field-name ":" [Field-value] CRLF field-name = Token field-value = * (Field-content | LWS) (1) Common message header (General-header) Common header fields are available for request messages and response messages, including the following fields: General-header = Accept | accept-encoding | Accept-language | Call-id | Contact Us | CSeq | Data | Encryption | Expires | from | Organization | Record-route | Timestamp | to | user-agent | Via which, the Accept,accept-encoding,accept-language field is used for the media type in which the client gives an acceptable response in the request message, encoding, and description Language: Media type, encoding method, and description language for the server to indicate its understandable request message in the 415 response. The Call-id field is used to uniquely identify a registration request for a particular invitation or a client, and a multimedia meeting can produce multiple Call-id different calls. The contact field gives a URL where the user can establish further communication with this URL. The CSeq field identifies the different requests made by the server, and if the Call-id value is the same, then the CSEQ value must vary. The date field reflects the first time a request or response message was made, and the message has the same data field value as the original message. The encryption field indicates that the content has been encrypted, and this encryption is end-to-end encryption. The Expire field gives the date and time the message content is due. The From field must be in all messages, and this field gives the initiator of the request. The Organization field gives the name of the organization to which the entity that issued the request or response message belongs. The Record-route field gives a globally reachable Request-uri to identify the proxy server. The Time-stamp field gives the time that a client makes a request to the server. The To field must be in all messages, and this field gives the purpose of the request deceptions. UserThe-agent field contains information about the user Agent client that initiated the request. The Via field gives the path to the request message to date. (2) The Entity-header Entity header field is used to define information related to the body of the message. Entity-header = content-encoding | Content-length | The Content-type content-encoding field indicates how the content encoding of the application is added to the message body. The Content-length field indicates the size of the message body. The Content-type field indicates the media type of the message body. (3) The Request-header Request header field is used for the client to upload additional information to the server, which includes information about the request and the client itself. Request-header = Authorization | Contact; | Hide; | Max-forwards; | Priority; | Proxy-authorization; | Proxy-require; | Route; | Require; | Response-key; | Subject; The authorization field is used by the user agent to authenticate itself to the server. The Hide field is used by the client to indicate that it wants to hide the path made by the Via field to a subsequent proxy server or user agent. The Max-forwords field indicates the number of times the request message was allowed to be forwarded. The Priority field is used by the client to indicate the urgency of the request. The Priority-authorization field is used by the client to indicate its identity to the proxy server that the requesting province authenticates. The Proxy-require field identifies the proxy-sensitive features that the agent must support. The Route field determines the route of the request message. The Require field is used by the client to tell the proxy server the option that the client wants the server to support in order for the server to handle the request correctly. The Require-key field is used to provide the required key to be met by the calling user agent to encrypt the response message. The Subject field provides an overview of the call or indicates the nature of the call, which can be used for call filtering. (4) The Response-header response header field is used to send additional information about the response to the address specified by the server to Request-uri. Response-header = Allow | Proxy-authenticate | Retry-after | Server | Unsupported | Warning | WThe Ww-authenticate proxy-authenticate field must be part of a 407 response, and the value in the field gives the authentication scheme and parameters for the agent that is applicable to the Request-uri. The Retry-after field can be used in 503 responses to indicate to the requesting client how long the service is expected to be enabled, and for the 404,600,603 response to indicate when the call will be available again. The server field contains the software information used by the user proxy to process the request. The unsupported field lists features that are not supported by the server. The warning field is used to pass additional information about the state of the response. The Www-authenticate field is included in the 401 response, indicating the authentication system and parameters applicable to the Request-uri.