SIP协议详解：RFC3261与呼叫建立过程

需积分: 0 186 浏览量更新于2024-07-23 收藏 595KB PDF 举报

"SIP-RFC3261是关于Session Initiation Protocol (SIP)的互联网标准草案，由多个行业专家共同撰写，并于2002年发布。它取代了之前的RFC2543，旨在定义一个应用层控制（信令）协议，用于创建、修改和终止具有一个或多个参与者的会话，包括互联网电话通话、多媒体分发和多媒体会议。" SIP（Session Initiation Protocol）是一种应用层协议，根据RFC3261定义，其主要目的是在互联网上初始化交互式通信会话。这个协议的核心功能包括建立、管理和结束语音、视频通话以及多媒体会议等各类会话。SIP的设计灵感来源于电子邮件和HTTP协议，因此它的语法和语义与这些协议有相似之处。在RFC3261中，会话的建立通常由一个邀请（ Invitation）消息开始，这个邀请携带着会话描述信息，这些信息包含了参与者如何加入会话所需的媒体类型、编码格式以及其他参数。这些描述通常采用Session Description Protocol (SDP)进行封装。一旦接收方接受邀请，双方将协商出一个双方都支持的会话配置，然后开始数据传输。 SIP架构是基于代理服务器的，包括两种主要类型的服务器：用户代理服务器（User Agent Server, UAS）和代理服务器（Proxy Server）。用户代理服务器代表终端用户处理SIP消息，而代理服务器则可以转发消息，帮助路由和管理会话。代理服务器在提高系统扩展性和提供高级服务（如重定向、认证、计费）方面扮演着关键角色。此外，RFC3261还定义了注册（Registration）过程，允许用户向一个注册服务器表明他们的可达性，以便其他用户能够找到他们。注册服务器存储这些信息，使得呼叫可以路由到正确的地址。在安全性方面，SIP支持多种机制来保护通信，如Transport Layer Security (TLS) 用于加密通信，SIP Identity和Signature Frameworks用于验证消息的来源和完整性。 SIP-RFC3261是互联网标准的重要组成部分，它为现代通信系统提供了基础，包括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

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页未读，继续阅读

baidu_16120909

粉丝: 0
资源: 2

SIP协议详解：RFC3261与呼叫建立过程

SIP-RFC3261(中文版)

SIP-RFC3261.rar_rfc3261_sip

rfc3261中文版 下载

rfc3261中文版 pdf csdn

rfc3261中文版 pdf 下载

letf rfc 3261

rfc3261(sip协议)中文版

freeswitch sofia模块架构

rfc3261 nounce count

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

最新资源

rfc3261中文版下载