RFC3261：SIP协议详解：动态会话控制标准

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

RFC 3261是网络工作小组（Network Working Group）由J. Rosenberg等多位专家共同编写的关于会话发起协议（Session Initiation Protocol, SIP）的官方标准文档。这份标准于2002年6月发布，旨在为互联网社区提供一种应用层控制（signaling）协议，用于建立、修改和终止包括互联网电话通话、多媒体分发以及多媒体会议在内的多方会话。 SIP的核心目的是为了创建一个统一的框架，使得不同网络服务提供商和设备能够相互通信，协同工作，以实现诸如VoIP（Voice over IP）电话等多媒体通信服务。它建立在TCP/IP协议栈之上，运行在应用层，与H.323等传统媒体通信协议相比，SIP以其轻量级设计和简单易用性而受到欢迎。 RFC 3261文档详述了SIP的工作原理，包括邀请机制（invitations），这些邀请携带着会话描述信息，描述了参与者的角色、媒体流配置以及所需的会话属性。它规定了SIP的消息结构（如INVITE、ACK、BYE、CANCEL等）、路由机制（通过URI标识参与者和网络资源）、会话管理流程（如会话状态转移、重定向）、以及错误处理和安全措施等内容。此外，RFC 3261还明确了该协议的发展历史，指出它取代了之前的RFC 2543，并强调了标准跟踪的状态，即任何对SIP的改进和讨论都应在互联网官方协议标准（STD 1）的当前版本中体现，且该文档的分发不受限制。版权方面，RFC 3261受国际互联网协会（The Internet Society）的保护，所有权利保留。阅读者可以参考此文档获取SIP的最新规范，但必须遵守相关的使用条款和版权要求。总结来说，RFC 3261是网络通信领域的重要里程碑，它为现代通信系统提供了关键的协议基础，推动了IP网络下多媒体通信的发展，并对后续的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页未读，继续阅读

SleepyPat

粉丝: 638
资源: 17

RFC3261：SIP协议详解：动态会话控制标准

sip协议中文本RFC3261

RFC3261 协议下载

RFC3261 SIP协议

IETF RFC3261 SIP协议中文版

RFC3261 SIP协议 PDF 中文和英文两个文件

中国通信行业RFC3261 SIP协议技术规范

RFC3261 SIP协议详解：中文版核心要素与实现要点

RFC3261 SIP协议详细教程：流程、报文与错误码解析

RFC3261，RFC3265 SIP协议

RFC3261 SIP

最新资源