SIP 3261协议详解：互联网会话初始化协议

sip协议

rfc3261

需积分: 1 136 浏览量更新于2024-06-27 收藏 808KB PDF 举报

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

领优惠券(最高得80元）

"SIP 3261协议是Session Initiation Protocol（会话初始化协议）的一个版本，由RFC 3261定义，是互联网标准跟踪协议，用于创建、修改和终止多参与者之间的会话，如电话通话、多媒体分发和多媒体会议。" SIP（Session Initiation Protocol）是一种应用层控制协议，它在互联网上被广泛用于启动、管理和结束涉及一个或多个参与者的交互式通信会话。RFC 3261是SIP协议的规范，取代了早期的RFC 2543，旨在提供更加稳定和可扩展的标准。此文档详细定义了SIP协议的规则和操作方式，鼓励社区进行讨论和提出改进建议。 SIP协议的核心功能包括： 1. **会话建立**：SIP邀请（INVITE）消息用于发起会话，比如进行一次VoIP电话。邀请消息中包含了会话的详细描述，如媒体类型、编码和传输参数等。 2. **会话修改**：一旦会话建立，参与者可以使用SIP消息（如UPDATE或REINVITE）来修改会话属性，例如更改音视频编码、增加或减少参与者等。 3. **会话终止**：参与者可以通过发送CANCEL或BYE消息来结束会话。 4. **会话管理**：注册（REGISTER）消息用于用户代理（UA）向SIP服务器注册其位置，便于接收呼叫。ACK和200 OK消息则确认了请求的成功处理。 5. **重定向与路由**：SIP服务器可以使用3xx响应消息重定向请求到其他位置，而记录-路由（Record-Route）和联系人（Contact）头字段则帮助确定消息的路由。 6. **状态维护**：PRACK、INFO和SUBSCRIBE/NOTIFY消息用于维护会话状态，例如确认媒体流的接收、传递实时信息或订阅事件通知。 SIP协议的特点包括其灵活性、分布式架构和与底层传输协议（如TCP或UDP）的解耦。这使得SIP能够适应各种网络环境，支持多种服务提供商和设备。此外，SIP与Session Description Protocol (SDP)一起工作，SDP负责描述会话的媒体特性。 SIP的应用不仅限于语音通信，还包括视频通话、即时消息、多媒体会议和在线游戏等。由于其开放性和可扩展性，SIP成为了互联网通信领域的一个关键协议。通过遵循RFC 3261标准，开发者和供应商可以确保他们的SIP实现与其他系统兼容，促进跨平台的互操作性。不过，SIP协议的实施也涉及到安全问题，如身份验证、隐私保护和防止拒绝服务攻击等，这些都需要在实际应用中得到妥善处理。 SIP 3261协议作为互联网标准，为多参与者通信提供了灵活、可扩展的框架，促进了各种实时通信服务的发展。

资源详情

资源推荐

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

醉心编码

粉丝: 1w+
资源: 37

SIP 3261协议详解：互联网会话初始化协议

SIP: Understanding the Session Initiation Protocol

RFC 3261 SIP spec.

RFC 3261（SIP协议）.chm

sip Java协议栈

SIP 协议栈结构，SIP 信令格式

知道协议以及他们的端口

一文读懂 sip 协议

SIP 协议栈结构，SIP 信令格式。

sip协议包分析

sip协议栈有哪些并介绍一下

请编写一个sip Android音视频客户端

Java接入sip协议

详细介绍一下SIP协议、RTP协议和R2S协议

sip注册的信令流程。

jain-sip-ri

sip协议介绍，1000字以内

python sip消息解析

帮我开发一个 java swrig架构基于SIP协议电话呼叫系统

sip协议组件接口说明文档

Avatar_Utils-1.0.6-py3-none-any.whl.zip

最新资源