SIP for the standard protocol of peer communication

For multi-user communications, there are also common protocols for standardized management, such as the previously mentioned SDP and SIP (Session initiation Protocol), which is a control protocol belonging to the application layer, primarily used to create, modify, and abort sessions between one or more participants ( Sessions). The types of sessions include IP telephony, multimedia streaming, and multimedia conferencing.

SIP Introduction

SIP invitations (invitations) are used to create sessions that carry session descriptions (such as SDP information), allowing participants to use a range of compatible media types.
SIP uses an element called a proxy server to help forward the user's current location, authenticate and authorize the user, and provide the user with the appropriate functionality.
SIP also provides a registration function to allow users to upload their current address for use by the proxy server. The SIP protocol runs on multiple different transport protocols.

SIP supports 5 ways to establish and abort multimedia sessions:

• User address: Determines the terminal system used for communication.
• User availability: Determines whether the callee is willing to join the communication.
• User capabilities: Determines the multimedia type and the parameters used by the media.
• Session setup: "Ringing", which establishes a session on the caller and on the called side.
• Session management: includes transferring and aborting sessions, modifying session parameters, and invoking services.

SIP is not a vertically integrated communication system, but works as a component with other protocols, such as RTP and other real-time transport protocols. In addition, SIP does not provide services,
Only primitives that can be used to implement various services are provided. For example, SIP can locate a user and transfer an opaque object to its current address. If the primitive is used to
Transmission of the SDP, the terminal will be able to know some of the parameters of the session; If the same primitive is used to transmit a photo, it can also implement a "show caller's avatar" service.
Thus, a primitive is often used to implement many different services.

SIP working Process

Describes the basic functions of SIP: Locating a terminal, generating a communication request, establishing a session, and ending a session.

Atlanta.com. biloxi.com.           Proxy Proxy.                                       . .Alice ' s ....................Bob ' s SoftphoneSipPhone |                |                |     | |INVITEF1 | | | |--------------->| INVITE F2 | | |100TryingF3 |--------------->| INVITE F4 | |<---------------| Trying F5 |--------------->| | |<-------------- | Ringing F6 | | |180RingingF7 |<---------------| |180RingingF8 |<---------------| $ OK F9 | |<---------------| $ OK F10 |<---------------| |200 ok f11 |<- --------------| | |<---------------| | | | ack f12 | | ------------------------------------------------->| | media session | |<============================================ ====>| | bye f13 | |<----------------------- --------------------------| | 200 ok f14 | | ------------------------------------------------->| | | Figure  1: SIP session established        

The figure depicts the process of exchanging sip information between Alice and Bob, two users. (information is represented as FN.) First, Alice uses a sip terminal on her PC (assuming it's a software phone),
and call Bob over the Internet. Where we see two proxy servers Atlanta and Biloxi to help both parties to establish sessions. This typical arrangement is often
is called SIP之梯(SIP trapezoid) .

When Alice calls Bob, she uses the SIP identity information of Bob, a specific type of URI called the SIP URI, similar in form to an e-mail address, containing the user name and host name.
In this example, Bob's address is sip:[email protected] , Biloxi is Bob's SIP service provider, and Bob also contacts Alice through its SIP addresssip:[email protected]
to communicate. SIP also provides a secure link sips, similar to HTTPS, primarily through TLS for content encryption, encrypted address formatsips:[email protected]

SIP is based on the request/response transport model of a kind of HTTP. Each transfer contains a request that invokes a particular method or function, and at least one response. In this example,
At the beginning of the transfer, Alice sends a invite request to Bob's SIP URI. The invite request contains a series of header fields. The header field is called a property,
Provides additional information about the message. The terminal that generated the INVITE request contains a unique call identifier, destination address, Alice's address, and Alice
Type information for the session that you want to establish with Bob. An example of a invite request is as follows, where Alice's SDP information is not displayed:

INVITESip:bob@biloxi. com sip/2.0Via:sip/2.0/UDP Pc33.atlanta.com;branch=z9hg4bk776asdhds max-forwards: 70 To:bob <sip:bob @biloxi. Com> From:alice <sip:alice @atlanta. Com>;tag=1928301774 Call- id:a84b4c76e66710 @pc33. Atlanta.com CSEQ: 314159 invite contact: <sip : Alice @pc33 .atlanta.com> content-TYPE:APPLICATION/SDP Content-length: 142 (Alice's SDP information, slightly) figure 2:alice send request message            

The first line contains the name of the method (INVITE). Some of the following lines are a series of head sections, and the meanings of each header field are described in the next section.

Because Alice does not know the exact address of Bob, the message is sent first to Alice's SIP service provider, atlanta.com. This address is available at Alice
The terminal (software phone) configured above, of course, can also be found through a protocol such as DHCP. The SIP server receives the SIP request and, as its purpose
To forward. In this case, after receiving the invite request, the proxy server returns a Trying response to Alice, indicating that the request is being forwarded.
The SIP response uses a three-digit number to represent the state, including the same to, from, Call-id, CSeq, and branch (via) parameters in the invite request,
This allows Alice's terminal to associate it with the request. Proxy server atlanta.com to get Bob's service provider address through DNS.
and the Via field in the forwarded message adds its own address information. The biloxi.com proxy receives a invite request and returns a 100 response to the
atlanta.com. Proxy servers look for their databases (often referred to as location services), which contain Bob's current IP address. At the same time the agent before forwarding the request
Also add your own address to the Via field in the header.

After Bob's terminal (SIP phone) receives a invite request, Bob is prompted for a call from Alice. Meanwhile Bob's terminal returns 180 responses,
Indicates that a call is being made and the response is forwarded back to Alice's terminal so Alice can also know that the other phone is ringing. Each agent passes through the head
field to determine the direction in which the response is sent, and to remove its own address information from the top of Via. So while sending the request to DNS and location services,
However, when sending a response, it is not required.

In this example, Bob decides to pick up the phone. At this point, Bob's SIP phone sends a 200 response indicating that the call was answered. 200 response contains the information body (SDP)
Indicates the type of session that Bob wants to establish. Therefore, this formed two times the SDP information exchange process: Alice sent to Bob, and Bob sent it to Alice.
This two exchange provides the basic bargaining power, and is based on a simple offer/answer model. If Bob
If you don't want to answer the phone or are talking to someone, an error response is returned, so that no multimedia session is established. The 200 response structure that Bob sends is broadly as follows:

sip/2.0OKVia:sip/2.0/UDP server10.biloxi.com; branch=z9hg4bknashds8;received=192.0.2.3Via:sip/2.0/UDP bigbox3.site3.atlanta.com; branch=z9hg4bk77ef4c2312983.1;received=192.0.2.2Via:sip/2.0/UDP pc33.atlanta.com; branch=z9hg4bk776asdhds; received=192.0.2.1 To:bob <sip:bob @biloxi. Com>;tag=a6c85cf From:alice <SIP: Alice @atlanta. Com>;tag=1928301774 call- id:a84b4c76e66710 @pc33. Atlanta.com CSEQ: 314159 invite contact: <sip : [Email protected]192.0.2.4 > Content-TYPE:APPLICATION/SDP content-Length: 131 (Bob's SDP information, slightly) Figure 3:bob sent response message      

Bob's SIP phone adds a tag parameter to the header of the packet, which is merged into the conversation by two endpoints and is included in all subsequent requests and responses (for this call).
The contact header contains a uri,content-type and content-length that Bob can directly connect to to represent the message body (not posted) in the format information.
In this case, the proxy server can also expand its capabilities, for example, when receiving a 486 (Busy here) response from Bob, you can go to Bob's voicemail, etc.
Send a invite request; A proxy server can send requests to multiple addresses at the same time, and this feature of parallel lookups is often called forking (forking).

After the response is returned to Alice's software phone, the phone stops ringing and notifies Alice that the caller has answered and sends an ACK message to Bob
The terminal, indicating that the response has been received. In this example, the ACK is sent directly to Bob, not through two proxy servers, because two endpoints know the other's address.
Therefore, you do not need to go through the proxy to find.

After the ACK is received, Alice and Bob can communicate with each other. After the communication is complete, suppose Bob hangs up the phone and generates a bye message that is sent directly to Alice,
Alice ends the session by receiving a confirmation request and returning a (OK) response. Note that there is no ACK sent because the ACK is sent only when confirming the response of the invite request.

Registration (registration) is another common operation of SIP. The user registers to enable the proxy server to know its current address information. such as Bob
You can send a registration request () to biloxi.com at initialization time REGISTER , which is also known as a Registrar (registrar).
Registrars associate Bob's SIP URI with its current address (often called a binding) and store this mapping information in a server-side database.
That is, the location services mentioned above. Usually the proxy server that registers the server and the corresponding domain name is the same address, so you know the type of SIP server
The difference is logical rather than physical.

SIP Protocol Architecture

SIP is a layered protocol, which means that its behavior is described by a series of sibling but separate segments (stage). The lowest layer of SIP is syntax and encoding, where the encoding is encoded by the
BNF syntax (Backus-naur Form grammar) designation; The SIP second layer is the Transport Layer (transport layer), which defines how the client and server are sent and received
Request and response; The third layer is the transaction layer (transaction layer), the transaction layer is the underlying component of the SIP, and a transaction consists of the sent request and the corresponding response.
The transaction layer handles the retransmission of the application layer, request/response matching and timeout, etc., above the transaction layer called the transaction user (TU, transaction user), each SIP
Entities (except stateless proxies) are a tu.

All SIP elements, including User Client (UAC), Server (UAS), stateless (stateless) or full-state (stateful) agents,
And registrars, all contain a core that differentiates each other. In addition to the stateless agent, the kernel of the other elements is the transactional user.
The kernel behavior of UAC and UAS relies on methods, and there are general rules for all methods, which are not elaborate here. For UAC, these rules dictate
The construction of the request message.

SIP Message Format

SIP is a text-based (text-based) protocol and uses the UTF-8 character set. A SIP message is either a request from the client to the server,
Either the server-to-client response; Both types of messages contain a starting line, one or more header areas, a blank line representing the end of the head,
and (optional) body part (message body), each part separated by CRLF:

     generic-message  =  start-line                         *message-header                         CRLF                         [ message-body ]     start-line       =  Request-Line / Status-Line

In addition to the character set, most SIP packets and header syntax are the same as http/1.1, although this is not an extension of the HTTP protocol.

SIP Request

The first line of a SIP request contains one, and the 请求行(Request-Line) request line includes the method name, the request URI, and the protocol version.
and separated by SP (space) except at the end of the line, no carriage return (CR) and newline (LF) are allowed in the request lines, nor are the existing empty characters in the element (LWS, linear whitespace).

  Request-Line  =  Method SP Request-URI SP SIP-Version CRLF

which

• Method: Means, RFC3261 defines six methods, namely:
  • Register: Used to register contact information.
  • INVITE, ACK, CANCEL, BYE: These four methods are used for the establishment of a session.
  • OPTIONS: Used to discover the performance of the server (capabilities).
• Request-uri: A sip or sips URI that represents the service or user information requested to be sent, which cannot include control characters,
  Nor can it be included in "<>".
• The version number of the Sip-version:sip, which corresponds to the RFC3261, is "sip/2.0". Similar to http/1.1, but with different points for SIP processing
  The version number is formatted as a string, although this does not matter much in practice.

SIP Response

The SIP response differs from the request, its starting behavior 状态行(Status-Line) , the status line includes the protocol version, the status code, and the corresponding status text description,
Like the request line, elements are separated by a space, and no newline and carriage return can occur in the middle.

Status-Line  =  SIP-Version SP Status-Code SP Reason-Phrase CRLF

The status code (STATUS-CODE) is a 3-digit number that represents the result of the request. The first bit of the status code indicates the kind of response:

• 1XX (100-199, same as): Interim response (provisional), indicating that the request has been received but is still being processed.
• 2XX: Success (Success), the request is successfully received, understood and accepted.
• 3XX: Redirect (redirection), you may need to re-select the sending address to complete the request.
• 4XX: Client error, request contains incorrect syntax, or cannot be completed by the server.
• 5XX: Service side error (server error), the server has failed to process a legitimate request.
• 6XX: Failure (Global Failure),

Header fields

The header of the SIP packet is similar to the head of the HTTP, and also has the same properties, such as the ability to combine the values of the same attribute in multiple head areas into a single head,
and make field-value separated by commas, etc., the header is in the following format:

  field-name: field-value

You can add any space on either side of the colon, but it is not recommended to do so, but instead of leaving a space between the filed-name and the colon, a colon and a field-value are left blank.
For example, in Figure 2, Alice's request message, some of the common header field-name are outlined:

• Via: Contains the address that the sender wants to accept the response for this request, this is pc33.atlanta.com,
  It also contains the branch parameters (branch parameter) that identify this transport transaction.
• Max-forwards: Used to limit the maximum number of hops requested (Max hops), which is reduced after each hop.
• To: The display name and the Sip/sips URI (sip:[email protected]) for the user that contains the purpose of the request.
• From: Contains the display name of the sender of this request Alice and the URI, in addition to a tag parameter, contains the immediately string,
  will be used to add in URIs, primarily for validation and differentiation.
• Call-id: Contains a globally different identity for this call, combined by a random string and the host name or IP address of the sending side. To,from and Call-id
  The field completely defines an end-to-end SIP relationship for Alice and Bob, and is represented as the current Conversation (dialog).
• CSEQ: Or command Sequence, contains an integer (CSEQ) and method name, and the CSEQ number is incremented for each new request in this conversation.
• Contact: Contains the Sip/sips URI that represents the direct connection to Alice. Unlike the Via segment, via tells other units to send a response,
  The contact tells the other unit where to send the (later) request.
• Content-length: The length of the message body.
• Content-type: The message body format, such as the SDP information is "APPLICATION/SDP", about the SDP can refer to the previous blog Peer Communication Standard Protocol (iii) ice.

Postscript

This paper briefly introduces the structure and message format of the SIP protocol, in which many details are not in depth, so the length is only one-tenth of the original/rfc3261,
If you want to design the actual application according to the agreement, still need to look over the original of the agreement carefully. At this point, the introduction of the peer Communication series will be over.
It has always been a very exciting topic to focus on, both in information technology and in finance and politics, with limitless potential.
A recent series of articles focused on getting started and implementing simple VoIP applications, the next phase should look at content distribution protocols (such as BitTorrent),
But judging by my procrastination, it must have been a long time.

SIP for the standard protocol of peer communication