RFC3264协议PDF版_rfc3264中文版资源-CSDN文库

3264

PDF

5星 · 超过95%的资源需积分: 21 178 浏览量 2010-10-31 23:20:59 上传评论 2 收藏 36KB PDF 举报

资源推荐

资源详情

资源评论

Network Working Group J. Rosenberg

Request for Comments: 3264 dynamicsoft

Obsoletes: 2543 H. Schulzrinne

Category: Standards Track Columbia U.

June 2002

An Offer/Answer Model with the Session Description Protocol (SDP)

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Abstract

This document defines a mechanism by which two entities can make use

of the Session Description Protocol (SDP) to arrive at a common view

of a multimedia session between them. In the model, one participant

offers the other a description of the desired session from their

perspective, and the other participant answers with the desired

session from their perspective. This offer/answer model is most

useful in unicast sessions where information from both participants

is needed for the complete view of the session. The offer/answer

model is used by protocols like the Session Initiation Protocol

(SIP).

Table of Contents

1 Introduction ........................................ 2

2 Terminology ......................................... 3

3 Definitions ......................................... 3

4 Protocol Operation .................................. 4

5 Generating the Initial Offer ........................ 5

5.1 Unicast Streams ..................................... 5

5.2 Multicast Streams ................................... 8

6 Generating the Answer ............................... 9

6.1 Unicast Streams ..................................... 9

6.2 Multicast Streams ................................... 12

7 Offerer Processing of the Answer .................... 12

8 Modifying the Session ............................... 13

Rosenberg & Schulzrinne Standards Track [Page 1]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

8.1 Adding a Media Stream ............................... 13

8.2 Removing a Media Stream ............................. 14

8.3 Modifying a Media Stream ............................ 14

8.3.1 Modifying Address, Port or Transport ................ 14

8.3.2 Changing the Set of Media Formats ................... 15

8.3.3 Changing Media Types ................................ 17

8.3.4 Changing Attributes ................................. 17

8.4 Putting a Unicast Media Stream on Hold .............. 17

9 Indicating Capabilities ............................. 18

10 Example Offer/Answer Exchanges ...................... 19

10.1 Basic Exchange ...................................... 19

10.2 One of N Codec Selection ............................ 21

11 Security Considerations ............................. 23

12 IANA Considerations ................................. 23

13 Acknowledgements .................................... 23

14 Normative References ................................ 23

15 Informative References .............................. 24

16 Authors’ Addresses .................................. 24

17 Full Copyright Statement............................. 25

1 Introduction

The Session Description Protocol (SDP) [1] was originally conceived

as a way to describe multicast sessions carried on the Mbone. The

Session Announcement Protocol (SAP) [6] was devised as a multicast

mechanism to carry SDP messages. Although the SDP specification

allows for unicast operation, it is not complete. Unlike multicast,

where there is a global view of the session that is used by all

participants, unicast sessions involve two participants, and a

complete view of the session requires information from both

participants, and agreement on parameters between them.

As an example, a multicast session requires conveying a single

multicast address for a particular media stream. However, for a

unicast session, two addresses are needed - one for each participant.

As another example, a multicast session requires an indication of

which codecs will be used in the session. However, for unicast, the

set of codecs needs to be determined by finding an overlap in the set

supported by each participant.

As a result, even though SDP has the expressiveness to describe

unicast sessions, it is missing the semantics and operational details

of how it is actually done. In this document, we remedy that by

defining a simple offer/answer model based on SDP. In this model,

one participant in the session generates an SDP message that

constitutes the offer - the set of media streams and codecs the

offerer wishes to use, along with the IP addresses and ports the

offerer would like to use to receive the media. The offer is

Rosenberg & Schulzrinne Standards Track [Page 2]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

conveyed to the other participant, called the answerer. The answerer

generates an answer, which is an SDP message that responds to the

offer provided by the offerer. The answer has a matching media

stream for each stream in the offer, indicating whether the stream is

accepted or not, along with the codecs that will be used and the IP

addresses and ports that the answerer wants to use to receive media.

It is also possible for a multicast session to work similar to a

unicast one; its parameters are negotiated between a pair of users as

in the unicast case, but both sides send packets to the same

multicast address, rather than unicast ones. This document also

discusses the application of the offer/answer model to multicast

streams.

We also define guidelines for how the offer/answer model is used to

update a session after an initial offer/answer exchange.

The means by which the offers and answers are conveyed are outside

the scope of this document. The offer/answer model defined here is

the mandatory baseline mechanism used by the Session Initiation

Protocol (SIP) [7].

2 Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED",

"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",

and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and

indicate requirement levels for compliant implementations.

3 Definitions

The following terms are used throughout this document:

Agent: An agent is the protocol implementation involved in the

offer/answer exchange. There are two agents involved in an

offer/answer exchange.

Answer: An SDP message sent by an answerer in response to an offer

received from an offerer.

Answerer: An agent which receives a session description from

another agent describing aspects of desired media

communication, and then responds to that with its own session

description.

Rosenberg & Schulzrinne Standards Track [Page 3]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

Media Stream: From RTSP [8], a media stream is a single media

instance, e.g., an audio stream or a video stream as well as a

single whiteboard or shared application group. In SDP, a media

stream is described by an "m=" line and its associated

attributes.

Offer: An SDP message sent by an offerer.

Offerer: An agent which generates a session description in order

to create or modify a session.

4 Protocol Operation

The offer/answer exchange assumes the existence of a higher layer

protocol (such as SIP) which is capable of exchanging SDP for the

purposes of session establishment between agents.

Protocol operation begins when one agent sends an initial offer to

another agent. An offer is initial if it is outside of any context

that may have already been established through the higher layer

protocol. It is assumed that the higher layer protocol provides

maintenance of some kind of context which allows the various SDP

exchanges to be associated together.

The agent receiving the offer MAY generate an answer, or it MAY

reject the offer. The means for rejecting an offer are dependent on

the higher layer protocol. The offer/answer exchange is atomic; if

the answer is rejected, the session reverts to the state prior to the

offer (which may be absence of a session).

At any time, either agent MAY generate a new offer that updates the

session. However, it MUST NOT generate a new offer if it has

received an offer which it has not yet answered or rejected.

Furthermore, it MUST NOT generate a new offer if it has generated a

prior offer for which it has not yet received an answer or a

rejection. If an agent receives an offer after having sent one, but

before receiving an answer to it, this is considered a "glare"

condition.

The term glare was originally used in circuit switched

telecommunications networks to describe the condition where two

switches both attempt to seize the same available circuit on the

same trunk at the same time. Here, it means both agents have

attempted to send an updated offer at the same time.

Rosenberg & Schulzrinne Standards Track [Page 4]

RFC 3264 An Offer/Answer Model Session Description Protocol June 2002

The higher layer protocol needs to provide a means for resolving such

conditions. The higher layer protocol will need to provide a means

for ordering of messages in each direction. SIP meets these

requirements [7].

5 Generating the Initial Offer

The offer (and answer) MUST be a valid SDP message, as defined by RFC

2327 [1], with one exception. RFC 2327 mandates that either an e or

a p line is present in the SDP message. This specification relaxes

that constraint; an SDP formulated for an offer/answer application

MAY omit both the e and p lines. The numeric value of the session id

and version in the o line MUST be representable with a 64 bit signed

integer. The initial value of the version MUST be less than

(2**62)-1, to avoid rollovers. Although the SDP specification allows

for multiple session descriptions to be concatenated together into a

large SDP message, an SDP message used in the offer/answer model MUST

contain exactly one session description.

The SDP "s=" line conveys the subject of the session, which is

reasonably defined for multicast, but ill defined for unicast. For

unicast sessions, it is RECOMMENDED that it consist of a single space

character (0x20) or a dash (-).

Unfortunately, SDP does not allow the "s=" line to be empty.

The SDP "t=" line conveys the time of the session. Generally,

streams for unicast sessions are created and destroyed through

external signaling means, such as SIP. In that case, the "t=" line

SHOULD have a value of "0 0".

The offer will contain zero or more media streams (each media stream

is described by an "m=" line and its associated attributes). Zero

media streams implies that the offerer wishes to communicate, but

that the streams for the session will be added at a later time

through a modified offer. The streams MAY be for a mix of unicast

and multicast; the latter obviously implies a multicast address in

the relevant "c=" line(s).

Construction of each offered stream depends on whether the stream is

multicast or unicast.

5.1 Unicast Streams

If the offerer wishes to only send media on a stream to its peer, it

MUST mark the stream as sendonly with the "a=sendonly" attribute. We

refer to a stream as being marked with a certain direction if a

direction attribute was present as either a media stream attribute or

Rosenberg & Schulzrinne Standards Track [Page 5]

剩余24页未读，继续阅读

评论收藏

内容反馈

xidianyouxm

2014-08-16

挺好的，可惜没有中文版的。
xiaoxiaota

2016-01-15

标准文档,用来参考
海鸟和鱼

2013-10-18

PDF格式，蛮清晰的
小猪多人运动中

2020-04-27

够用够用感谢分享
juliusespv

2012-12-12

可以参考规范的内容。

前往

页

来去黑暗中

粉丝: 17
资源: 14

RFC3264协议PDF版

第三方电话呼叫控制

RFC 2866 协议英文版（PDF格式）

RFC3550中文版.pdf

RFC-3550-RTP协议-中文版.pdf

RTSP协议详细描述(中文版)-rfc2326.pdf

RFC1661 PPP中文版

ICMP协议_RFC777(中文版PDF)

rfc793(tcp传输控制协议).pdf

rfc791 IP协议标准 PDF

STUN协议RFC5389.pdf

HTTP协议(RFC2616)中文版.pdf

SIP协议 RFC3261 中文版pdf

RFC3550_RTP协议中文版

RFC 6749-OAuth 2.0授权框架(中文版).pdf

NAT协议_RFC1631 (中文版PDF)

WebSocket协议手册(rfc6455中文翻译).pdf

rfc3561.pdf

rfc768(UDP协议标准文档).pdf

RFC3261(SIP协议)文字版中英文版 RFC4566&RFC6550&RFC2327(SDP描述协议).zip

HTTP协议详解PDF可打印版RFC2616

Qt 5实现串口调试助手 （源工程文件、0积分下载）

【SystemVerilog】路科验证V2学习笔记（全600页）.pdf

AutoSAR标准协议4.2.2

光伏-储能并网系统仿真.rar

NPPJSONViewer.zip

GD32替换STM32注意事项.pdf

XCP协议的规范文档

VS2015安装证书，JavaScript_ProjectSystem.msi，JavaScript_LanguageService.msi

CANoe通过CAPL脚本实现自动测试

最新资源

Qt 5实现串口调试助手（源工程文件、0积分下载）