SIP协议详解：GB28181与Session Initiation Protocol

需积分: 13 76 浏览量更新于2024-07-18 1 收藏 815KB PDF 举报

"SIP最新协议文档GB28181，这是一个关于Session Initiation Protocol (SIP)的协议分析文档，包含报文实例分析，适用于代码实现和理解。" SIP（Session Initiation Protocol）是一种应用层控制协议，用于创建、修改和终止具有一个或多个参与者的会话。这些会话可以包括互联网电话通话、多媒体分发以及多媒体会议等多种形式。该协议由Internet工程任务组（IETF）定义，并在RFC 3261中标准化，该文档已更新并替代了早期的RFC 2543。 SIP协议的核心功能是通过邀请（Invitations）来建立会话。这些邀请消息携带了会话描述，这些描述信息通常使用SDP（Session Description Protocol）来编码，用于定义参与者的媒体类型、传输地址、端口号以及编码参数等。SIP邀请不仅用于初始会话的建立，还可以用于在会话进行中添加、删除或修改参与者，以及调整会话的媒体特性。 SIP架构基于客户端-服务器模型，但与HTTP不同，SIP中的请求和响应可以在多个实体之间转发，这使得SIP网络可以灵活地处理路由和代理服务器。SIP代理服务器可以用于会话路由、认证、授权、计费以及其他中间服务。SIP还支持重定向服务器，它们可以将呼叫引导到不同的目的地。 SIP消息主要包括两种类型：请求消息和响应消息。请求消息如INVITE、ACK、CANCEL、BYE和OPTIONS等，用于发起某种操作；响应消息则提供对请求的确认或拒绝，例如200 OK表示请求成功，404 Not Found表示目标无法找到。SIP消息结构包含起始行、消息头和可选的消息体，其中消息头包含了许多重要的元数据，如From、To、Call-ID、CSeq等，用于标识和管理会话。在GB28181中，SIP被应用于中国的国家公共安全视频监控系统，它规定了如何使用SIP进行设备注册、呼叫控制、媒体流传输等操作。这个标准文档不仅包含了SIP的基本概念和流程，还可能包括针对中国国情的特定扩展和规定。 SIP协议文档GB28181是理解并实现SIP通信系统的关键资源，它提供了详细的协议规则、报文格式和实例，对于开发者和网络管理员来说，这份文档可以帮助他们构建和维护高效的多媒体通信系统。在实际应用中，需要结合具体的场景和需求，正确理解和应用SIP的各种机制，以确保会话的顺利进行。

RFC 3261

SIP: Session Initiation Protocol June 2002

requests and responses in this call. The Contact header field

contains a URI at which Bob can be directly reached at his SIP phone.

The Content-Type and Content-Length refer to the message body (not

shown) that contains Bob’s SDP media information.

In addition to DNS and location service lookups shown in this

example, proxy servers can make flexible "routing decisions" to

decide where to send a request. For example, if Bob’s SIP phone

returned a 486 (Busy Here) response, the biloxi.com proxy server

could proxy the INVITE to Bob’s voicemail server. A proxy server can

also send an INVITE to a number of locations at the same time. This

type of parallel search is known as forking.

In this case, the 200 (OK) is routed back through the two proxies and

is received by Alice’s softphone, which then stops the ringback tone

and indicates that the call has been answered. Finally, Alice’s

softphone sends an acknowledgement message, ACK, to Bob’s SIP phone

to confirm the reception of the final response (200 (OK)). In this

example, the ACK is sent directly from Alice’s softphone to Bob’s SIP

phone, bypassing the two proxies. This occurs because the endpoints

have learned each other’s address from the Contact header fields

through the INVITE/200 (OK) exchange, which was not known when the

initial INVITE was sent. The lookups performed by the two proxies

are no longer needed, so the proxies drop out of the call flow. This

completes the INVITE/200/ACK three-way handshake used to establish

SIP sessions. Full details on session setup are in

Section 13.

Alice and Bob’s media session has now begun, and they send media

packets using the format to which they agreed in the exchange of SDP.

In general, the end-to-end media packets take a different path from

the SIP signaling messages.

During the session, either Alice or Bob may decide to change the

characteristics of the media session. This is accomplished by

sending a re-INVITE containing a new media description. This re-

INVITE references the existing dialog so that the other party knows

that it is to modify an existing session instead of establishing a

new session. The other party sends a 200 (OK) to accept the change.

The requestor responds to the 200 (OK) with an ACK. If the other

party does not accept the change, he sends an error response such as

488 (Not Acceptable Here), which also receives an ACK. However, the

failure of the re-INVITE does not cause the existing call to fail -

the session continues using the previously negotiated

characteristics. Full details on session modification are in

Section

14.

Rosenberg, et. al. Standards Track [Page 16]

RFC 3261

SIP: Session Initiation Protocol June 2002

At the end of the call, Bob disconnects (hangs up) first and

generates a BYE message. This BYE is routed directly to Alice’s

softphone, again bypassing the proxies. Alice confirms receipt of

the BYE with a 200 (OK) response, which terminates the session and

the BYE transaction. No ACK is sent - an ACK is only sent in

response to a response to an INVITE request. The reasons for this

special handling for INVITE will be discussed later, but relate to

the reliability mechanisms in SIP, the length of time it can take for

a ringing phone to be answered, and forking. For this reason,

request handling in SIP is often classified as either INVITE or non-

INVITE, referring to all other methods besides INVITE. Full details

on session termination are in

Section 15.

Section 24.2 describes the messages shown in Figure 1 in full.

In some cases, it may be useful for proxies in the SIP signaling path

to see all the messaging between the endpoints for the duration of

the session. For example, if the biloxi.com proxy server wished to

remain in the SIP messaging path beyond the initial INVITE, it would

add to the INVITE a required routing header field known as Record-

Route that contained a URI resolving to the hostname or IP address of

the proxy. This information would be received by both Bob’s SIP

phone and (due to the Record-Route header field being passed back in

the 200 (OK)) Alice’s softphone and stored for the duration of the

dialog. The biloxi.com proxy server would then receive and proxy the

ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently

decide to receive subsequent messages, and those messages will pass

through all proxies that elect to receive it. This capability is

frequently used for proxies that are providing mid-call features.

Registration is another common operation in SIP. Registration is one

way that the biloxi.com server can learn the current location of Bob.

Upon initialization, and at periodic intervals, Bob’s SIP phone sends

registrar. The REGISTER messages associate Bob’s SIP or SIPS URI

(sip:bob@biloxi.com) with the machine into which he is currently

logged (conveyed as a SIP or SIPS URI in the Contact header field).

The registrar writes this association, also called a binding, to a

database, called the location service, where it can be used by the

proxy in the biloxi.com domain. Often, a registrar server for a

domain is co-located with the proxy for that domain. It is an

important concept that the distinction between types of SIP servers

is logical, not physical.

Bob is not limited to registering from a single device. For example,

both his SIP phone at home and the one in the office could send

registrations. This information is stored together in the location

Rosenberg, et. al. Standards Track [Page 17]

RFC 3261

SIP: Session Initiation Protocol June 2002

service and allows a proxy to perform various types of searches to

locate Bob. Similarly, more than one user can be registered on a

single device at the same time.

The location service is just an abstract concept. It generally

contains information that allows a proxy to input a URI and receive a

set of zero or more URIs that tell the proxy where to send the

request. Registrations are one way to create this information, but

not the only way. Arbitrary mapping functions can be configured at

the discretion of the administrator.

Finally, it is important to note that in SIP, registration is used

for routing incoming SIP requests and has no role in authorizing

outgoing requests. Authorization and authentication are handled in

SIP either on a request-by-request basis with a challenge/response

mechanism, or by using a lower layer scheme as discussed in

Section

26.

The complete set of SIP message details for this registration example

is in

Section 24.1.

Additional operations in SIP, such as querying for the capabilities

of a SIP server or client using OPTIONS, or canceling a pending

request using CANCEL, will be introduced in later sections.

5 Structure of the Protocol

SIP is structured as a layered protocol, which means that its

behavior is described in terms of a set of fairly independent

processing stages with only a loose coupling between each stage. The

protocol behavior is described as layers for the purpose of

presentation, allowing the description of functions common across

elements in a single section. It does not dictate an implementation

in any way. When we say that an element "contains" a layer, we mean

it is compliant to the set of rules defined by that layer.

Not every element specified by the protocol contains every layer.

Furthermore, the elements specified by SIP are logical elements, not

physical ones. A physical realization can choose to act as different

logical elements, perhaps even on a transaction-by-transaction basis.

The lowest layer of SIP is its syntax and encoding. Its encoding is

specified using an augmented Backus-Naur Form grammar (BNF). The

complete BNF is specified in

Section 25; an overview of a SIP

message’s structure can be found in

Section 7.

Rosenberg, et. al. Standards Track [Page 18]

RFC 3261

SIP: Session Initiation Protocol June 2002

The second layer is the transport layer. It defines how a client

sends requests and receives responses and how a server receives

requests and sends responses over the network. All SIP elements

contain a transport layer. The transport layer is described in

Section 18.

The third layer is the transaction layer. Transactions are a

fundamental component of SIP. A transaction is a request sent by a

client transaction (using the transport layer) to a server

transaction, along with all responses to that request sent from the

server transaction back to the client. The transaction layer handles

application-layer retransmissions, matching of responses to requests,

and application-layer timeouts. Any task that a user agent client

(UAC) accomplishes takes place using a series of transactions.

Discussion of transactions can be found in Section 17. User agents

contain a transaction layer, as do stateful proxies. Stateless

proxies do not contain a transaction layer. The transaction layer

has a client component (referred to as a client transaction) and a

server component (referred to as a server transaction), each of which

are represented by a finite state machine that is constructed to

process a particular request.

The layer above the transaction layer is called the transaction user

(TU). Each of the SIP entities, except the stateless proxy, is a

transaction user. When a TU wishes to send a request, it creates a

client transaction instance and passes it the request along with the

destination IP address, port, and transport to which to send the

request. A TU that creates a client transaction can also cancel it.

When a client cancels a transaction, it requests that the server stop

further processing, revert to the state that existed before the

transaction was initiated, and generate a specific error response to

that transaction. This is done with a CANCEL request, which

constitutes its own transaction, but references the transaction to be

cancelled (

Section 9).

The SIP elements, that is, user agent clients and servers, stateless

and stateful proxies and registrars, contain a core that

distinguishes them from each other. Cores, except for the stateless

proxy, are transaction users. While the behavior of the UAC and UAS

cores depends on the method, there are some common rules for all

methods (

Section 8). For a UAC, these rules govern the construction

of a request; for a UAS, they govern the processing of a request and

generating a response. Since registrations play an important role in

SIP, a UAS that handles a REGISTER is given the special name

registrar.

Section 10 describes UAC and UAS core behavior for the

Section 11 describes UAC and UAS core behavior for

the OPTIONS method, used for determining the capabilities of a UA.

Rosenberg, et. al. Standards Track [Page 19]

RFC 3261

SIP: Session Initiation Protocol June 2002

Certain other requests are sent within a dialog. A dialog is a

peer-to-peer SIP relationship between two user agents that persists

for some time. The dialog facilitates sequencing of messages and

proper routing of requests between the user agents. The INVITE

method is the only way defined in this specification to establish a

dialog. When a UAC sends a request that is within the context of a

dialog, it follows the common UAC rules as discussed in

Section 8 but

also the rules for mid-dialog requests.

Section 12 discusses dialogs

and presents the procedures for their construction and maintenance,

in addition to construction of requests within a dialog.

The most important method in SIP is the INVITE method, which is used

to establish a session between participants. A session is a

collection of participants, and streams of media between them, for

the purposes of communication.

Section 13 discusses how sessions are

initiated, resulting in one or more SIP dialogs.

Section 14

discusses how characteristics of that session are modified through

the use of an INVITE request within a dialog. Finally,

section 15

discusses how a session is terminated.

The procedures of Sections

8, 10, 11, 12, 13, 14, and 15 deal

entirely with the UA core (

Section 9 describes cancellation, which

applies to both UA core and proxy core).

Section 16 discusses the

proxy element, which facilitates routing of messages between user

agents.

6 Definitions

The following terms have special significance for SIP.

Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI

that points to a domain with a location service that can map

the URI to another URI where the user might be available.

Typically, the location service is populated through

registrations. An AOR is frequently thought of as the "public

address" of the user.

Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a

logical entity that receives a request and processes it as a

user agent server (UAS). In order to determine how the request

should be answered, it acts as a user agent client (UAC) and

generates requests. Unlike a proxy server, it maintains dialog

state and must participate in all requests sent on the dialogs

it has established. Since it is a concatenation of a UAC and

UAS, no explicit definitions are needed for its behavior.

Rosenberg, et. al. Standards Track [Page 20]

剩余268页未读，继续阅读

stickvc

粉丝: 1
资源: 7

SIP协议详解：GB28181与Session Initiation Protocol

GB28181转RTSP、RTMP和HLS

国标gb28181 抓包

sip协议标准

GB28181文档

GB28181协议两个文档.zip

GB28181 协议

GB28181-2016与GB28181-2011两个标准文档

GB28181调研文档

GB28181协议两个文档_rezip_rezip.zip

wvp-GB28181_wvp-gb28181_wvpgb28181_GB28181_

最新资源