SIP协议详解：RFC3261标准协议解读

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

SIP协议 SIP（Session Initiation Protocol）是一种应用层控制协议，用于创建、修改和终止多参与者之间的会话。该协议广泛应用于VoIP（Voice over Internet Protocol）、即时通信、视频会议等领域。 **SIP协议的基本概念** SIP协议是一种基于文本的协议，使用UTF-8编码，通过UDP或TCP协议传输。SIP消息分为两种类型：请求消息和响应消息。请求消息用于发起会话，而响应消息用于响应请求。 **SIP协议的主要组件** 1. 用户代理（User Agent）：是SIP协议的终端设备，如IP电话、软电话等。 2. 代理服务器（Proxy Server）：负责转发SIP消息，帮助用户代理发现彼此的位置。 3..Redirect Server：负责重定向SIP消息，用于实现呼叫转移等功能。 **SIP协议的工作流程** 1. 注册（Registration）：用户代理向代理服务器注册其位置信息。 2. 邀请（Invitation）：用户代理向其他用户代理发送邀请，以发起会话。 3. 应答（Response）：被邀请的用户代理响应邀请，表明是否接受会话。 4. 确认（Acknowledgment）：确认会话的建立，开始传输媒体流。 5. 终止（Termination）：会话结束，释放资源。 **SIP协议的优点** 1. 高度灵活性：SIP协议可以应用于各种网络环境和设备。 2. 可扩展性：SIP协议可以轻松地扩展到新的应用场景。 3. 高度可靠性：SIP协议具有高可靠性，能够确保会话的稳定性。 **SIP协议的应用** 1. VoIP电话：SIP协议广泛应用于VoIP电话，实现基于Internet的电话通信。 2. 视频会议：SIP协议用于实现视频会议，支持多方视频通话。 3. 即时通信：SIP协议用于实现即时通信，支持文本、图片和视频等多种媒体格式。 **RFC3261-SIP协议的特点** RFC3261是SIP协议的最新版本，具有以下特点： 1. 改进的安全机制：RFC3261引入了新的安全机制，提高了协议的安全性。 2. 增强的可扩展性：RFC3261提供了更多的扩展机制，支持更多的应用场景。 3. Improved scalability：RFC3261优化了协议的性能，提高了协议的可扩展性。 SIP协议是一种功能强大且灵活的协议，广泛应用于VoIP电话、视频会议、即时通信等领域。RFC3261是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页未读，继续阅读

Hilbert（*^*）

粉丝: 123
资源: 18

SIP协议详解：RFC3261标准协议解读

RFC3261中文SIP协议文档解读

深入探究RFC3261：SIP协议的核心标准

RFC3261：SIP协议详解与动态应用

rfc3261-sip协议描述

RFC3261-SIP协议中文版

rfc3261-SIP英文版.pdf

SIP协议标准RFC3261-RFC2543

rfc3261（中文版）_rfc3261_sip协议_

RFC3261 ——SIP协议中文版

rfc3261(sip协议).pdf

最新资源