Research on SIP SAP and SDP Protocol
Default 字 9 9pt10pt11pt12pt13pt14pt15pt16pt17pt18pt20pt25pt30pt35pt40pt45pt50pt
Sumproof SIP, SAP, SDP is an important protocol involved in NGN and 3TNET. Based on the introduction and analysis of SIP, SAP, SDP protocol, this article gives an example of multimedia conference applications implemented based on three protocol portfolios. Keywords SIP SAP SDP 1 Introduction SIP (Session Initiation Protocol, Session Initiation), SAP (Session Announcement Protocol, Session Agreement), SDP (Session Description Protocol, Session Description Protocol) is both related to session There is a connection and difference RFC protocol. In this article, we will make a simple analysis of these three protocols and give a multimedia application with the three protocols implemented. 2 Protocol Analysis 2.1 SIP Protocol Introduction and Analysis Session Initial Protocol (SIP) is a signaling protocol for initial, managing, and terminating voice and video sessions in the network, specifically, is used to generate, modify, and end one or more Session between a participant. SIP is an integral part of the Internet Engineering Task Force (IETF) multimedia data and control architecture, so it is associated with many other protocols of IETF, such as RTP (real-time transport protocol) and SAP, SDP protocol mentioned herein. SIP mainly provides five aspects related to session establishment and ending, which are: (1) User positioning: Decision of terminal system for communication; (2) User availability: Decision of the willingness to participate in communication by caller; (3) User capability: Decision of media and media parameters; (4) Conference establishment: "Ring", call, and caller session parameters; (5) Session management: including transfer and end session, modify session Parameters, and calling business, etc. The SIP network consists of four types of logical SIP entities. Each entity has a specific function, as a client (initial request), or as a server (response request), or as a combination of the two, participates in SIP communication. A "physical device" can have more functionality than one logical SIP entity. For example, a network server as a proxy server can have a function of registering a server at the same time. Here are four functional entities: (1) User agent (UA) is an endpoint entity in SIP. The user agent is initially and terminating sessions by switching requests and responding. UA as an application, which contains the user agent client and user proxy server, as follows: · User Agent Client (UAC): Client Application, It initially SIP request. · User Agent Server (UAS): Server Applications, when it receives the SIP request, it contacts the user and returns a response on behalf of the user. The device with UA function in the SIP network is: workstation, IP phone, telephone gateway, call agent, and automatic answer service. (2) The proxy server proxy server is the intermediate entity of the server and client, and its purpose is to represent other clients to generate requests. The request is handled internally or may pass it to other servers after the translation. If necessary, the agent can interpret and rewrite the request message before forwarding.
(3) Redirect the server redirection server to accept the SIP request, and map the SIP address of the caller into zero (if you do not know the address) or more new addresses and return them to the client. Unlike proxy servers, redirect the server does not pass the request to other servers. (4) The registration server registration server is a server that accepts the Register request, and its purpose is to update the location database based on the contact information specified in the request. SIP indicates the user address via an address in the form of e-mail. Each user is identified by a first-class URL that is constructed by elements such as a user phone number or host name (for example: SIP: user@company.com). Because it is similar to the E-mail address, SIP URLS is easy to associate with the user's E-mail address. SIP has two types of messages, which are: (1) request: from the client to the server message. (2) Response: Send the message from the server to the client. The request message includes: • Invite: initial call, change the parameter (Re-invite). · ACK: Confirm the end response of the INVITE. · BYE: Terminate the call. · Cancel: Undo Search and Zhen Ling. · Options: Query the other capability. · Register: Register the location service. · INFO: Send information in the session without changing the session state. • PRACK: The same is the same as the ACK, but it is used for temporary responses. Subscribe: This method is used to book a notification of its status change to the remote endpoint. · Notify: This method sends a message to notify the subscriber's change in the state it is. • Update: Allows customers to update the parameters of a session without affecting the current state of the session. · Message: Instant messages are implemented by carrying instant messaging content in its requestor. · REFER: The function is to contact a third party by using the contact address information provided in the request. The response message contains a digital response code. The SIP response code set part is based on HTTP response code. There are two types of responses, they are: • Temporary Response (1xx): Temporary response is used by the server to indicate the process, but does not end the SIP. · Final response (2xx, 3xx, 4xx, 5xx, 6xx): Final response to termination of SIP. Each SIP message consists of three parts: (1) Start line: Each SIP message starts by the starting line. The starting line conveys the message type (the method type in the request is a response code) and the protocol version. The starting line can be a request line (request) or a status line (response). (2) SIP header: Used to deliver message attributes and modify the message meaning. They are the same as the HTTP header field in syntax and semantics (in fact, some heads are borrowed from HTTP), and always keep formats:
Possible body types include the SDP session description protocol that will be described herein. 2.2 SAP Protocol Introduction and Analysis SAP's full name is a session notification protocol, which is to inform a multicast multi-media conference or other multicast session to send relevant session establishment information to the expected meeting participants. The SAP protocol itself does not establish a session, which only will establish the information necessary for the session, such as the video or audio coding method notified to other participants in a multicast group, when the participant receives the notification packet You can start the corresponding tool and set the correct parameter to establish a session to the initiator of the meeting (establish a session using the SIP protocol). The initiator of the notification did not know if the participants received a session notification, that is to say that each participant did not reply to the notification initiator to confirm the "I received the notice"; therefore, the notification initiator can only be periodically Send this session notification to maximize the participants to receive notifications. SAP is not sent to each participant one by one, which sends a notification packet with a known multicast address and port by multicast mechanism (Multicast), member within the multicast group If you work properly, you will receive the notification packet. Therefore, in order to enable the participants of the meeting to receive notifications, be sure to participate in the multicast group. A notification dataset can notify a session to initiate, and you can notify the session to cancel or some of the communication parameters of the session have been modified. Of course, this requires the corresponding mechanism to make these notifications for the same session. So how SAP describes the information about the session, which requires the SDP protocol. In general, the SDP data is typically filled in the PayLoad field of the SAP packet, which describes the basic information necessary to establish a session. SDP will be introduced in Section 1.3. 2.3 SDP Protocol Introduction and Analysis The two protocols described above are used to use SDP. In fact, SDP is used to describe protocols for multimedia session announcements, multimedia session invitations, and other forms of multimedia session initialization. The SDP package typically includes the following information: (1) Session information, session name and purpose. · Session activity time. Since the resources involved in the session are restricted, it is very useful to include the following additional information. · Bandwidth information used by sessions. · The contact information of the session leader. (2) Media information · Media type, such as video and audio. · Transfer protocol, such as RTP / UDP / IP and H.320. · Media format, such as H.261 video and MPEG video. · Multicast addresses and media transport ports (IP multicast sessions). · The remote address (IP unicast session) for the media and transmission ports of the contact address. SDP description consists of many text lines, the format of the text line is
