理解SIP协议：RFC3261详解与操作指南

rfc3261

会话初始化协议

需积分: 12 77 浏览量更新于2023-06-30 收藏 677KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"该资源是关于SIP (Session Initiation Protocol) RFC3261协议的文档，详细阐述了SIP的功能、术语、操作概述、协议结构、消息定义、头字段、消息体、消息帧、用户代理行为、请求取消、注册以及能力查询等方面的内容。" SIP（Session Initiation Protocol）是一种应用层控制协议，用于创建、修改和终止一个或多个参与者的会话。这些会话可以包括互联网电话呼叫、多媒体分发和多媒体会议。RFC3261是SIP协议的标准定义，取代了之前的RFC2543。文档首先介绍了SIP的基本功能和操作概览，包括其在会话管理中的作用。然后，它详细定义了SIP协议的术语，帮助理解协议中的专业词汇。接着，文档概述了SIP协议的操作流程，包括协议结构，其中分为请求(Requests)和响应(Responses)两种类型的消息。 SIP消息部分详细描述了请求和响应的格式，以及头字段(Header Fields)的分类，包括标准形式和紧凑形式(Compact Form)。消息体(Bodies)部分讨论了消息体的类型和长度，这对于携带会话描述信息（如SDP）至关重要。为了实现SIP协议，文档详细规定了用户代理(User Agent, UAs)的行为，包括用户发起方(UAC, User Agent Client)和用户接收方(UAS, User Agent Server)的角色。UAC的行为涉及请求的生成和发送，以及响应的处理。而UAS则负责检查方法、头字段，处理内容，并根据扩展应用进行响应的生成。此外，还提到了无状态用户接收方(UAS)的行为。文档中还涵盖了取消请求(Canceling a Request)的过程，包括客户端和服务器端的行为。注册(Registrations)章节详细说明了如何使用REGISTER请求来添加、删除、获取和刷新绑定，以及设置内部时钟、发现注册器、发送请求和处理错误响应等步骤。最后，文档探讨了查询能力(Querying for Capabilities)的方法，通过OPTIONS请求构建来了解对等方支持的功能。 RFC3261提供了SIP协议的全面指南，是实现和理解SIP通信的核心参考资料。无论是开发者、网络管理员还是研究者，都能从中获得有关SIP协议的详尽信息。

资源详情

资源推荐

RFC 3261 SIP: Session Initiation Protocol June 2002

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 ﬁeld 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

ﬁeld 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

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 ﬁeld). 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 ofﬁce could send registrations. This information is stored together in the location 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 conﬁgured 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 dis-

cussed 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 deﬁned by that layer.

Not every element speciﬁed by the protocol contains every layer. Furthermore, the elements speciﬁed by

Rosenberg, et al. Standards Track [Page 16]

RFC 3261 SIP: Session Initiation Protocol June 2002

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 speciﬁed using an augmented Backus-

Naur Form grammar (BNF). The complete BNF is speciﬁed in Section 25; an overview of a SIP message’s

structure can be found in Section 7.

The second layer is the transport layer. It deﬁnes 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 ﬁnite 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 speciﬁc 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 REGISTER method. Section 11 describes UAC and UAS core behavior for the OPTIONS

method, used for determining the capabilities of a UA.

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 deﬁned in this speciﬁcation 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 modiﬁed through the use of an INVITE request

Rosenberg, et al. Standards Track [Page 17]

RFC 3261 SIP: Session Initiation Protocol June 2002

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 Deﬁnitions

The following terms have special signiﬁcance 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 an-

swered, 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 deﬁnitions are needed for its behavior.

Call: A call is an informal term that refers to some communication between peers, generally set up for the

purposes of a multimedia conversation.

Call Leg: Another name for a dialog [31]; no longer used in this speciﬁcation.

Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the ter-

minating BYE request. A call stateful proxy is always transaction stateful, but the converse is not

necessarily true.

Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or

may not interact directly with a human user. User agent clients and proxies are clients.

Conference: A multimedia session (see below) that contains multiple participants.

Core: Core designates the functions speciﬁc to a particular type of SIP entity, i.e., speciﬁc to either a

stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are

transaction users.

Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog

is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identiﬁed by

a call identiﬁer, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.

Downstream: A direction of message forwarding within a transaction that refers to the direction that re-

quests ﬂow from the user agent client to user agent server.

Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that

does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are ﬁnal.

Rosenberg, et al. Standards Track [Page 18]

RFC 3261 SIP: Session Initiation Protocol June 2002

Header: A header is a component of a SIP message that conveys information about the message. It is

structured as a sequence of header ﬁelds.

Header Field: A header ﬁeld is a component of the SIP message header. A header ﬁeld can appear as one

or more header ﬁeld rows. Header ﬁeld rows consist of a header ﬁeld name and zero or more header

ﬁeld values. Multiple header ﬁeld values on a given header ﬁeld row are separated by commas. Some

header ﬁelds can only have a single header ﬁeld value, and as a result, always appear as a single header

ﬁeld row.

Header Field Value: A header ﬁeld value is a single value; a header ﬁeld consists of zero or more header

ﬁeld values.

Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the

URI in the address-of-record of a registration.

Informational Response: Same as a provisional response.

Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A

caller retains this role from the time it sends the initial INVITE that established a dialog until the

termination of that dialog.

Invitation: An INVITE request.

Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of

establishing a new session. A callee retains this role from the time it receives the INVITE until the

termination of the dialog established by that INVITE.

Location Service: A location service is used by a SIP redirect or proxy server to obtain information about

a callee’s possible location(s). It contains a list of bindings of address-of-record keys to zero or more

contact addresses. The bindings can be created and removed in many ways; this speciﬁcation deﬁnes

a REGISTER method that updates the bindings.

Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it

arrives the second time, its

Request-URI

is identical to the ﬁrst time, and other header ﬁelds that

affect proxy operation are unchanged, so that the proxy would make the same processing decision on

the request it made the ﬁrst time. Looped requests are errors, and the procedures for detecting them

and handling them are described by the protocol.

Loose Routing: A proxy is said to be loose routing if it follows the procedures deﬁned in this speciﬁcation

for processing of the Route header ﬁeld. These procedures separate the destination of the request

(present in the

Request-URI

) from the set of proxies that need to be visited along the way (present

in the Route header ﬁeld). A proxy compliant to these mechanisms is also known as a loose router.

Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or

responses.

Method: The method is the primary function that a request is meant to invoke on a server. The method is

carried in the request message itself. Example methods are INVITE and BYE.

Rosenberg, et al. Standards Track [Page 19]

RFC 3261 SIP: Session Initiation Protocol June 2002

Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server re-

solved by the

Request-URI

. Typically, a UA is manually conﬁgured with an outbound proxy, or can

learn about one through auto-conﬁguration protocols.

Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon receiv-

ing an incoming request. Rather than issuing one request and then waiting for the ﬁnal response before

issuing the next request as in a sequential search, a parallel search issues requests without waiting for

the result of previous requests.

Provisional Response: A response used by the server to indicate progress, but that does not terminate a

SIP transaction. 1xx responses are provisional, other responses are considered ﬁnal.

Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of

making requests on behalf of other clients. A proxy server primarily plays the role of routing, which

means its job is to ensure that a request is sent to another entity “closer” to the targeted user. Proxies

are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A

proxy interprets, and, if necessary, rewrites speciﬁc parts of a request message before forwarding it.

Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs

in the Contact header ﬁeld in the response.

Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it re-

ceives, directing the client to contact an alternate set of URIs.

Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives

in those requests into the location service for the domain it handles.

Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK,or

CANCEL.

Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation.

Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the

client to the server.

Ringback: Ringback is the signaling tone produced by the calling party’s application indicating that a

called party is being alerted (ringing).

Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that

must be traversed when sending a particular request. A route set can be learned, through headers like

Record-Route, or it can be conﬁgured.

Server: A server is a network element that receives requests in order to service them and sends back re-

sponses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and

registrars.

Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, pro-

ceeding to the next one only after the previous has generated a ﬁnal response. A 2xx or 6xx class ﬁnal

response always terminates a sequential search.

Rosenberg, et al. Standards Track [Page 20]

剩余201页未读，继续阅读

tianyuan0405

粉丝: 1
资源: 4

会员权益专享

理解SIP协议：RFC3261详解与操作指南

RFC3261 协议下载

rfc3261 sip协议

RFC3261 SIP协议

rfc3261(sip协议)中文版

rfc3261中文版 下载

rfc3261中文版 pdf 下载

rfc3261中文版 pdf csdn

letf rfc 3261

rfc3261 nounce count

freeswitch sofia模块架构

rfc文档1一3093

上述中，info与rfc2833的包差异在哪儿

dtmf协商在sip包的那个字段内

WARNING | reSIProcate | RESIP:STATS | 0x7f74ff91c0 | StatisticsMessage.cxx:98 | RESIP:TRANSACTION

freeswitch

qtpjsip-2.5.1

inband传输不需要协商吗?

SIP协议 RFC3261 中文版pdf

SIP协议的RFC文档 rfc3261

SIP协议中文版RFC3261

会员权益专享

最新资源

rfc3261中文版下载