RFC3262中文版
电信SIP规范(协议细则)
１ 范围．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． ３ ２ 编制说明 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． ３ ３ ＳＩＰ 及其扩展规范 ．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．． ４
中国电信 SIP规范
用户终端 代理服务 SIP-ISUP B2BUA
UA
器
互通单元
---
---
---
---
注册服务 器 --- 1.
2.
说明
本章主要描述 User Agent 的行为，但由于实现 proxy 功能的实体在处理消息时 可能转而承担 UAC 或 UAS 的角色，因此 16 章 中有些内容的描述也参照 了本章。但本章中的某些 细节性规定并不适合 UAC 或 UAS 在第 16 章中 的应用场合。 根据第 1 点的说明，本章 中对 Proxy 的要求实质上 是对实现 Proxy 功能的实 体在转而承担 UAC 或 UAS 角色时的要求，因此 本章内容对此种应用场合 下的 UAC 或 UAS 而言可 能都是部分要求。为了说 明上的方便，本章内容对 于“Proxy”只存在“要求” 或“不适用”，如果有特 殊考虑将在“说明”一栏 中进行解释
5.1 invite 消息................................................................................................................ 66 5.2 ACK........................................................................................................................67 5.3 BYE ........................................................................................................................ 67 5.4 CANCEL ................................................................................................................. 69 5.5 REGISTER............................................................................................................... 69 5.6 OPTIONS................................................................................................................. 70 5.7 INFO....................................................................................................................... 71 5.8 PRACK.................................................................................................................... 72
RFC2326(中文版)-实时流协议(RTSP)
RFC2326(中文版)-实时流协议(RTSP).txt我的人生有A 面也有B面，你的人生有S面也有B 面。
失败不可怕，关键看是不是成功他妈。
现在的大学生太没素质了！过来拷毛片，居然用剪切！有空学风水去，死后占个好墓也算弥补了生前买不起好房的遗憾。
实时流协议(RTSP) ( Real Time Streaming Protocol (RTSP) )备忘录的状态：本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和建议以得到改进。
请参考最新版的“Internet正式协议标准”(STD1)来获得本协议的标准化程度和状态。
本备忘录的发布不受任何限制。
版权声明：版权为The Internet Society 所有。
所有权利保留。
摘要：实时流协议（RTSP）是应用层协议，控制实时数据的传送。
RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控、点播成为可能。
数据源包括现场数据与存储在剪辑中数据。
该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP(RFC1889)上传送机制提供方法。
目录：1 绪论 51.1 目的 51.2 要求 61.3 术语 61.4 协议特点 71.5 RTSP扩展 81.6 操作模式 91.7 RTSP状态 91.8 与其他协议关系 102 符号协定 103 协议参数 103.1 RTSP版本 103.2 RTSP URL 113.3 会议标识 133.4 会话标识 133.5 SMPTE 相对时间戳 133.6正常播放时间 143.7 绝对时间 153.8 选择标签 153.8.1 用IANA注册新的选择标签 154 RTSP消息 154.1 消息类型 164.2 消息标题 174.3 消息主体 174.4 消息长度 185 普通标题域 186 请求 196.1 请求队列 196.2 请求标题域 197 回应 207.1 状态行 207.1.1 状态代码和原因分析 207.1.2 回应标题域 238 实体 238.1 实体标题域 248.2 实体主体 249 连接 259.1 流水线操作 259.2 可靠性及确认 2510 方法定义 2510.1 选择 2610.2 描述 2610.3 通告 2610.4 建立 2610.5 播放 2710.6 暂停 2710.7 断开 2710.8 获取参数 2810.9 设置参数 2810.10 重定向 2810.11 录制 2910.12 嵌入二进制数据 2911状态代码定义（Status Code Definitions） 29 11.1成功2xx（Success 2xx） 3011.1.1 存储空间低 250 3011.2 重定向（Redirection 3xx） 3111.3 客户端错误（Client Error ）4xx 3111.3.1方法不允许 3211.3.2参数不能理解 3211.3.3会议未找到 3311.3.4 带宽不足 3311.3.5 会话未找到 3411.3.6 本状态下该方法无效 3411.3.7 标题域对资源无效 3411.3.8 无效范围 3511.3.9 参数只读 3511.3.10 不允许合操作 3611.3.11 只允许合操作 3611.3.12 不支持的传输 3611.3.13 目标不可达 3711.3.14 选择不支持 3712 标题域定义（Header Field Definitions） 38 12.1 接受 3812.2 接受编码 3812.3 接受语言 3912.4 允许（Allow） 3912.5 授权（Authorization） 4012.6 带宽 4012.7 块大小 4012.8 缓存控制 4112.9 会议 4112.10 连接 4112.11 基本内容 4212.12 内容编码（Content-Encoding） 4212.13 内容语言 4312.14 内容长度（Content-Length） 4312.15 内容位置 4312.16 内容类型（Content-Type） 4412.17 序列号 4412.18 日期（Date） 4412.19 过期（Expires） 4512.20 来自（From） 4512.21 主机 4512.22 如果匹配 4512.23 从何时更改（If-Modified-Since） 46 12.24 最近更改（Last-Modified） 4612.25 位置（Location） 4612.26 代理授权 4712.27 代理要求 4712.28 公用性 4712.29 范围 4912.30 提交方（Referer） 4912.31 稍后再试 4912.32 要求 4912.33 RTP信息 4912.34 比例 4912.35 速度 4912.36 服务器（Server） 4912.37 会话 4912.38 时间戳 4912.39 传输 4912.40 不支持 4912.41 用户代理（User-Agent） 4912.42 变化 4912.43 通过 4912.44 WWW-授权（WWW-Authenticate） 5013 缓存 5014 实例 5014.1 要求媒体（单播） 5014.2 容器文件的流 5114.3 单个流容器文件 5114.4 组播现场媒体表示 5114.5 在存在的会话中播放媒体 5114.6 录制 5215 语法 5215.1 基本语法 5216 安全考虑（Security Considerations） 52 附录A RTSP协议状态机 53A.1 客户端状态机 53A.2 服务器端状态机 53附录B 同RTP协议的交互 53附录C 使用SDP进行RTSP会话描述 54C.1 定义 54C.1.1 控制URL 55C.1.2 媒体流 55C.1.3 有效载荷类型 55C.1.4 详细格式参数 55C.1.5 表示的范围 56C.1.6 有效时间 56C.1.7 连接信息 56C.1.8 实体标签 57C.2 合控制不可用 57C.3 合控制可用 57附录D 最简单的RTSP实现 58D.1 客户端 58D.1.1回放 58D.1.2 授权 58D.2 服务器 59D.2.1回放 59D.2.2授权 59附录E 作者地址 60附录F 致谢 60参考书目 60版权申明 611 绪论1.1 目的实时流协议（RTSP）建立并控制一个或几个时间同步的连续流媒体。
rfc3262-Reliability of Provisional Responses In SIP
Network Working Group J. Rosenberg Request for Comments: 3262 dynamicsoft Category: Standards Track H. SchulzrinneColumbia U.June 2002Reliability of Provisional Responsesin the Session Initiation Protocol (SIP)Status of this MemoThis document specifies an Internet standards track protocol for theInternet community, and requests discussion and suggestions forimprovements. Please refer to the current edition of the "InternetOfficial Protocol Standards" (STD 1) for the standardization stateand status of this protocol. Distribution of this memo is unlimited.Network Communication Protocol Map. To order: /map.html Easy to use sniffing tool: /packet.htmlCopyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.AbstractThis document specifies an extension to the Session InitiationProtocol (SIP) providing reliable provisional response messages.This extension uses the option tag 100rel and defines the ProvisionalResponse ACKnowledgement (PRACK) method.Table of Contents1 Introduction (2)2 Terminology (3)3 UAS Behavior (3)4 UAC Behavior (6)5 The Offer/Answer Model and PRACK (9)6 Definition of the PRACK Method (10)7 Header Field Definitions (10)7.1 RSeq (10)7.2 RAck (11)8 IANA Considerations (11)8.1 IANA Registration of the 100rel Option Tag (11)8.2 IANA Registration of RSeq and RAck Headers (12)9 Security Considerations (12)10 Collected BNF (12)11 Acknowledgements (12)12 Normative References (13)13 Informative References (13)14 Authors' Addresses (13)15. Full Copyright Statement (14)1 IntroductionThe Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-response protocol for initiating and managing communicationssessions. SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing, and are sent reliably. Provisional responses provide information on theprogress of the request processing, but are not sent reliably in RFC 3261.It was later observed that reliability was important in severalcases, including interoperability scenarios with the PSTN.Therefore, an optional capability was needed to support reliabletransmission of provisional responses. That capability is provided in this specification.The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests aretransmitted periodically by the Transaction User (TU) until aseparate transaction, ACK, is received that indicates reception ofthe 2xx by the UAC. The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, we do nearly the same thing. Reliableprovisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message isreceived. The PRACK request plays the same role as ACK, but forprovisional responses. There is an important difference, however.PRACK is a normal SIP message, like BYE. As such, its ownreliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy serverscompliant to RFC 2543 [4].Each provisional response is given a sequence number, carried in the RSeq header field in the response. The PRACK messages contain anRAck header field, which indicates the sequence number of theprovisional response that is being acknowledged. The acknowledgments are not cumulative, and the specifications recommend a singleoutstanding provisional response at a time, for purposes ofcongestion control.Rosenberg & Schulzrinne Standards Track [Page 2]2 TerminologyIn 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 SIP implementations.3 UAS BehaviorA UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel. While this specification does not allow reliable provisional responses for any method but INVITE, extensions that define new methods that can establish dialogs may make use ofthe mechanism.The UAS MUST send any non-100 provisional response reliably if theinitial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel.A UAS MUST NOT attempt to send a 100 (Trying) response reliably.Only provisional responses numbered 101 to 199 may be sent reliably. If the request did not include either a Supported or Require header field indicating this feature, the UAS MUST NOT send the provisional response reliably.100 (Trying) responses are hop-by-hop only. For this reason, the reliability mechanisms described here, which are end-to-end,cannot be used.An element that can act as a proxy can also send reliable provisional responses. In this case, it acts as a UAS for purposes of thattransaction. However, it MUST NOT attempt to do so for any request that contains a tag in the To field. That is, a proxy cannotgenerate reliable provisional responses to requests sent within the context of a dialog. Of course, unlike a UAS, when the proxy element receives a PRACK that does not match any outstanding reliableprovisional response, the PRACK MUST be proxied.There are several reasons why a UAS might want to send a reliableprovisional response. One reason is if the INVITE transaction will take some time to generate a final response. As discussed in Section 13.3.1.1 of RFC 3261, the UAS will need to send periodic provisional responses to request an "extension" of the transaction at proxies.The requirement is that a proxy receive them every three minutes, but Rosenberg & Schulzrinne Standards Track [Page 3]the UAS needs to send them more frequently (once a minute isrecommended) because of the possibility of packet loss. As a more efficient alternative, the UAS can send the response reliably, inwhich case the UAS SHOULD send provisional responses once every two and a half minutes. Use of reliable provisional responses forextending transactions is RECOMMENDED.The rest of this discussion assumes that the initial requestcontained a Supported or Require header field listing 100rel, andthat there is a provisional response to be sent reliably.The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number.The reliable provisional response MAY contain a body. The usage of session descriptions is described in Section 5.The reliable provisional response is passed to the transaction layer periodically with an interval that starts at T1 seconds and doubles for each retransmission (T1 is defined in Section 17 of RFC 3261). Once passed to the server transaction, it is added to an internallist of unacknowledged reliable provisional responses. Thetransaction layer will forward each retransmission passed from the UAS core.This differs from retransmissions of 2xx responses, whoseintervals cap at T2 seconds. This is because retransmissions of ACK are triggered on receipt of a 2xx, but retransmissions ofPRACK take place independently of reception of 1xx.Retransmissions of the reliable provisional response cease when amatching PRACK is received by the UA core. PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261. A matching PRACK is defined as one within the same dialog as the response, and whose method, CSeq-num, and response-num in the RAck header fieldmatch, respectively, the method from the CSeq, the sequence number from the CSeq, and the sequence number from the RSeq of the reliable provisional response.If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match anunacknowledged reliable provisional response, it MUST be responded to with a 2xx response. The UAS can be certain at this point that the provisional response has been received in order. It SHOULD ceaseretransmissions of the reliable provisional response, and MUST remove it from the list of unacknowledged provisional responses.If a reliable provisional response is retransmitted for 64*T1 seconds without reception of a corresponding PRACK, the UAS SHOULD reject the original request with a 5xx response.If the PRACK contained a session description, it is processed asdescribed in Section 5 of this document. If the PRACK insteadcontained any other type of body, the body is treated in the same way that body in an ACK would be treated.After the first reliable provisional response for a request has been acknowledged, the UAS MAY send additional reliable provisionalresponses. The UAS MUST NOT send a second reliable provisionalresponse until the first is acknowledged. After the first, it isRECOMMENDED that the UAS not send an additional reliable provisional response until the previous is acknowledged. The first reliableprovisional response receives special treatment because it conveysthe initial sequence number. If additional reliable provisionalresponses were sent before the first was acknowledged, the UAS could not be certain these were received in order.The value of the RSeq in each subsequent reliable provisionalresponse for the same request MUST be greater by exactly one. RSeq numbers MUST NOT wrap around. Because the initial one is chosen to be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up to 2**31 reliable provisional responses per request, which is morethan sufficient.The UAS MAY send a final response to the initial request beforehaving received PRACKs for all unacknowledged reliable provisionalresponses, unless the final response is 2xx and any of theunacknowledged reliable provisional responses contained a sessiondescription. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliableprovisional responses, but it MUST be prepared to process PRACKrequests for those outstanding responses. A UAS MUST NOT send newreliable provisional responses (as opposed to retransmissions ofunacknowledged ones) after sending a final response to a request.4 UAC BehaviorWhen the UAC creates a new request, it can insist on reliabledelivery of provisional responses for that request. To do that, it inserts a Require header field with the option tag 100rel into the request. A Require header with the value 100rel MUST NOT be present in any requests excepting INVITE, although extensions to SIP mayallow its usage with other request methods.Header field where PRACK___________________________________Accept R oAccept 2xx -Accept 415 cAccept-Encoding R oAccept-Encoding 2xx -Accept-Encoding 415 cAccept-Language R oAccept-Language 2xx -Accept-Language 415 cAlert-Info R -Alert-Info 180 -Allow R oAllow 2xx oAllow r oAllow 405 mAuthentication-Info 2xx oAuthorization R oCall-ID c mCall-Info -Contact R -Contact 1xx -Contact 2xx -Contact 3xx oContact 485 oContent-Disposition oContent-Encoding oContent-Language oContent-Length tContent-Type *CSeq c mDate oError-Info 300-699 oExpires -From c mIn-Reply-To R -Max-Forwards R mMin-Expires 423 -MIME-Version oOrganization -Table 1: Summary of header fields, A--OHeader field where PRACK__________________________________________Priority R -Proxy-Authenticate 407 mProxy-Authenticate 401 oProxy-Authorization R oProxy-Require R oRecord-Route R oRecord-Route 2xx,18x oReply-To -Require cRetry-After 404,413,480,486 o500,503 o600,603 oRoute R cServer r oSubject R -Supported R oSupported 2xx oTimestamp oTo c mUnsupported 420 mUser-Agent oVia c mWarning r oWWW-Authenticate 401 mTable 2: Summary of header fields, P--ZIf the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that it supports them if the UAS needs to send one, a Supported header MUST be included in the request with the option tag 100rel. The UAC SHOULD include this in all INVITErequests.If a provisional response is received for an initial request, andthat response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST beignored, and the procedures below MUST NOT be used.The provisional response MUST establish a dialog if one is not yetcreated.Assuming the response is to be transmitted reliably, the UAC MUSTcreate a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, theprovisional response may have created the dialog). PRACK requestsMAY contain bodies, which are interpreted according to their type and disposition.Note that the PRACK is like any other non-INVITE request within adialog. In particular, a UAC SHOULD NOT retransmit the PRACK request when it receives a retransmission of the provisional response being acknowledged, although doing so does not create a protocol error.Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recentlyreceived in-order reliable provisional response for the initialrequest. This sequence number MUST be maintained until a finalresponse is received for the initial request. Its value MUST beinitialized to the RSeq header field in the first reliableprovisional response received for the initial request.Handling of subsequent reliable provisional responses for the sameinitial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be inorder. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higherthan the value of the sequence number, that response MUST NOT beacknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache theresponse in the hopes of receiving the missing responses.The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them.5 The Offer/Answer Model and PRACKRFC 3261 describes guidelines for the sets of messages in whichoffers and answers [3] can appear. Based on those guidelines, this extension provides additional opportunities for offer/answerexchanges.If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by theUAC). That results in the establishment of the session beforecompletion of the call. Similarly, if a reliable provisionalresponse is the first reliable message sent back to the UAC, and the INVITE did not contain an offer, one MUST appear in that reliableprovisional response.If the UAC receives a reliable provisional response with an offer(this would occur if the UAC sent an INVITE without an offer, inwhich case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK. If the UAC receives a reliable provisional response with an answer, it MAY generate anadditional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK.Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of the offer and answer, even if the original INVITE itself has not been responded to.If the UAS had placed a session description in any reliableprovisional response that is unacknowledged when the INVITE isaccepted, the UAS MUST delay sending the 2xx until the provisionalresponse is acknowledged. Otherwise, the reliability of the 1xxcannot be guaranteed, and reliability is needed for proper operation of the offer/answer exchange.All user agents that support this extension MUST support alloffer/answer exchanges that are possible based on the rules inSection 13.2 of RFC 3261, based on the existence of INVITE and PRACK as requests, and 2xx and reliable 1xx as non-failure reliableresponses.6 Definition of the PRACK MethodThis specification defines a new SIP method, PRACK. The semantics of this method are described above. Tables 1 and 2 extend Tables 2 and 3 from RFC 3261 for this new method.7 Header Field DefinitionsThis specification defines two new header fields, RAck and RSeq.Table 3 extends Tables 2 and 3 from RFC 3261 for these headers.7.1 RSeqThe RSeq header is used in provisional responses in order to transmit them reliably. It contains a single numeric value from 1 to 2**32 - 1. For details on its usage, see Section 3.Example:RSeq: 988789Header field where proxy ACK BYE CAN INV OPT REG PRA______________________________________________________RAck R - - - - - - mRSeq 1xx - - - o - - -Table 3: RAck and RSeq Header Fields7.2 RAckThe RAck header is sent in a PRACK request to support reliability of provisional responses. It contains two numbers and a method tag.The first number is the value from the RSeq header in the provisional response that is being acknowledged. The next number, and themethod, are copied from the CSeq in the response that is beingacknowledged. The method name in the RAck header is case sensitive.Example:RAck: 776656 1 INVITE8 IANA ConsiderationsThis document registers a new option tag and two new headers, based on the IANA registration process of RFC 3261.8.1 IANA Registration of the 100rel Option TagThis specification registers a single option tag, 100rel. Therequired information for this registration, as specified in RFC 3261, is:Name: 100relDescription: This option tag is for reliability of provisionalresponses. When present in a Supported header, it indicatesthat the UA can send or receive reliable provisional responses. When present in a Require header in a request, it indicatesthat the UAS MUST send all provisional responses reliably.When present in a Require header in a reliable provisionalresponse, it indicates that the response is to be sentreliably.8.2 IANA Registration of RSeq and RAck HeadersThe following is the registration for the RSeq header:RFC Number: RFC3262Header Name: RSeqCompact Form: noneThe following is the registration for the RAck header:RFC Number: RFC3262Header Name: RAckCompact Form: none9 Security ConsiderationsThe PRACK request can be injected by attackers to forceretransmissions of reliable provisional responses to cease. As these responses can convey important information, PRACK messages SHOULD be authenticated as any other request. Authentication procedures arespecified in RFC 3261.10 Collected BNFThe BNF for the RAck and RSeq headers and the PRACK method aredefined here.PRACKm = %x50.52.41.43.4B ; PRACK in capsMethod = INVITEm / ACKm / OPTIONSm / BYEm/ CANCELm / REGISTERm / PRACKm/ extension-methodRAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method response-num = 1*DIGITCSeq-num = 1*DIGITRSeq = "RSeq" HCOLON response-num11 AcknowledgementsThe authors would like to thank Jo Hornsby, Jonathan Lennox, RohanMahy, Allison Mankin, Adam Roach, and Tim Schroeder for the comments on this document.12 Normative References[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:Session Initiation Protocol", RFC 3261, June 2002.[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.13 Informative References[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,"SIP: Session Initiation Protocol", RFC 2543, March 1999.14 Authors' AddressesJonathan Rosenbergdynamicsoft72 Eagle Rock AvenueFirst FloorEast Hanover, NJ 07936EMail: jdrosen@Henning SchulzrinneColumbia UniversityM/S 04011214 Amsterdam Ave.New York, NY 10027-7003EMail: schulzrinne@15. Full Copyright StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, publishedand distributed, in whole or in part, without restriction of anykind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, thisdocument itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose ofdeveloping Internet standards in which case the procedures forcopyrights defined in the Internet Standards process must befollowed, or as required to translate it into languages other thanEnglish.The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDINGBUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATIONHEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OFMERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Rosenberg & Schulzrinne Standards Track [Page 14]。
RFC6282(中文版)基于IEEE 802.15.4网路的IPv6报文压缩格式(6LoWPAN)
基于IEEE 802.15.4网路的IPv6报文压缩格式摘要本文更新了RFC4944，“在IEEE 802.15.4网路上传送IPv6报文”。
本文描述了一个在低功耗无线个人局域网（6LoWPANs）上传送IPv6报文的IPv6报头压缩格式。
这种压缩格式可以进行任意前缀的压缩因为它是依赖于共享上下文的。
至于共享上下文的信息是如何维护的不在本文讨论范围内。
本文描述的是多播地址的压缩和一个用于压缩下一报头的框架。
UDP 报头压缩正是在这个框架内描述的。
文档说明本文是一份因特网标准文档。
本文由因特网工程任务组（IETF）发布。
它代表IETF社区言论。
本文接收了公众的建议并由因特网工程指导委员会（IESG）改进和发行。
关于因特网标准的更多信息请参阅RFC5741的节2。
本文档的当前状态，勘误表和如何提供反馈等信息可以从这个网址得到：/info/rfc6282。
版权声明Copyright（c）2011，本文版权归IETF组织和文档的指明作者所有。
本文从属于BCP 78 和IETF组织法律相关的IETF文档（/license-info）从本文发布之日起生效。
请仔细审查这些文档，它们描述了你对本文的权利和约束。
从本文引用的代码必须包含简化BSD许可说明，如信托法律规定4.e节所描述的那样，本文提供的代码不会给出警告，如简化BSD许可里描述的那样。
1、简介[IEEE802.15.4]标准指定一个MTU是127字节，只留下大概80字节用于带有安全选项的介质访问控制（MAC）载荷，在一个最高速率只有250kbps或更少的无线链路上进行传输。
考虑到在如无线传感器网路这样的应用中要求有限的带宽，存储容量或电力资源，6LoWPAN 适配层格式[RFC4944]描述了在这样一个受限的链路上传送IPv6报文。
[RFC4944]定义了一个Mesh寻址报头以支持sub-IP转发，一个分片报头用于支持IPv6最小MTU的要求[RFC2460]，和IPv6报文的无状态报头压缩（LOWPAN_HC1和LOWPAN_HC2）以便把相对较大的IPv6和UDP报头减小到几个字节（在最好情况下）。
sip_rfc3265
SIP-Specific Event Notification
June 2002
Table of Contents
1. Introduction . ..................................................................................................5 1.1. Overview of Operation ..........................................................................5 1.2. Documentation Conventions . ................................................................5 2. Definitions . ....................................................................................................5 3. Node Behavior ...............................................................................................6 3.1. Description of SUBSCRIBE Behavior ..................................................6 3.1.1. Subscription Duration .......................................................
RFC中文目录以及常用协议对应的RFC版本
中文RFC文档阅读101-700ＲＦＣ102 主机-主机协议故障清除委员会的说明ＲＦＣ103 中断键的执行ＲＦＣ104 连接191ＲＦＣ105 通过UCSB 进行远程登录和远程输出返回的网络说明书ＲＦＣ106 用户/服务器站点协议的网络主机问卷ＲＦＣ107 主机-主机协议故障清除委员会的说明ＲＦＣ108 1971年2月17-19日在Urbana 举行的NWG 会议的人员列表ＲＦＣ124 在ＲＦＣ107 中有印刷错误ＲＦＣ132 ＲＦＣ107 的排版错误ＲＦＣ148 ＲＦＣ123 的注释ＲＦＣ149 最好的铺设计划ＲＦＣ154 风格显示ＲＦＣ156 伊利诺斯州站点的状态: 响应ＲＦＣ116ＲＦＣ179 连接的数字分配ＲＦＣ185 NIC 分发手册ＲＦＣ188 数据管理会议公告ＲＦＣ198 站点证明-林肯实验室360/67ＲＦＣ204_利用报路ＲＦＣ218 改变IMP 状态报告设备ＲＦＣ228 澄清ＲＦＣ232 网络图形会议延缓ＲＦＣ245 预定网络工作组会议ＲＦＣ246 网络图形会议ＲＦＣ256 IMPSYS 变更通知ＲＦＣ276 NIC过程ＲＦＣ285 网络图形ＲＦＣ324 RJE 协议会议ＲＦＣ335 新界面- IMP/360ＲＦＣ348_放弃过程ＲＦＣ404 文件迁移协议的注释ＲＦＣ405 给TIP 用户的第二封信ＲＦＣ456 UCSB 的数据重置服务ＲＦＣ457_FTP 的服务器与服务器交互ＲＦＣ496 IMP/TIP 内存更新时间表(修订版2)ＲＦＣ516 丢失消息的检测ＲＦＣ591 在NVT ASCII UCSB和在线系统之间的实验输入映象ＲＦＣ621 “注意圣诞节的时候要把长袜挂在烟囱下面”ＲＦＣ628 更深的数据语言的设计观念ＲＦＣ634 最近的网络图ＲＦＣ637 SU-DSL网络地址的更改ＲＦＣ677 双重数据库的维护ＲＦＣ692 对于IMP/HOST 协议的改动的注释(ＲＦＣS 687 AND 690) ＲＦＣ697_FTP的CWD命令ＲＦＣ698_Telnet扩展ASCII选项中文RFC文档阅读701-1000ＲＦＣ763 角色邮箱ＲＦＣ775_面向目录的FTP 命令ＲＦＣ779_Telnet发送-位置选项ＲＦＣ792_Internet 控制信息协议ＲＦＣ797 位图文件格式ＲＦＣ821_简单邮件传输协议ＲＦＣ826_以太网地址转换协议或转换网络协议地址ＲＦＣ827_Exterior 网关协议(EGP)ＲＦＣ854_Telnet协议说明书ＲＦＣ855_Telnet选项说明书ＲＦＣ856_Telnet二进制传输ＲＦＣ857_Telnet回声选项ＲＦＣ858_Telnet抑制前进选项ＲＦＣ859_Telnet状态选项ＲＦＣ860_Telnet定时标记选项ＲＦＣ861_Telnet扩展选项列表选项ＲＦＣ862_回声协议ＲＦＣ863 废除协议ＲＦＣ864 字符产生协议ＲＦＣ865 白天协议的引用ＲＦＣ866 激活用户ＲＦＣ867 白天协议ＲＦＣ868_时间协议ＲＦＣ872_局域网上的TCP协议ＲＦＣ877_IP 数据包通过公共数据网络的传输标准ＲＦＣ888_STUB Exterior Gateway ProtocolＲＦＣ890_外部网关协议执行表ＲＦＣ894_IP 数据包通过以太网网络传输标准ＲＦＣ895_IP 数据包通过试验性以太网网络的传输标准ＲＦＣ896_在IPTCP internet网络中的拥塞控制ＲＦＣ903_反向地址转换协议ＲＦＣ911 BERKELEY UNIX 4.2下的EGP网关ＲＦＣ917_因特网子网ＲＦＣ918 邮局协议ＲＦＣ925_多局域网地址解决ＲＦＣ930_Telnet终端类型选项ＲＦＣ932_子网地址分配方案ＲＦＣ937_邮局协议( 版本2)ＲＦＣ948_IP 数据包通过IEEE 802.3 网络传输的两种方法ＲＦＣ949_FTP 未公开的独特命令ＲＦＣ951_引导协议(BOOTP)ＲＦＣ955_朝向一个处理过程应用的传输服务ＲＦＣ962_TCP-4 的最初ＲＦＣ968 “这是开动前的黑暗”ＲＦＣ974_邮件路由与域名系统ＲＦＣ975_自治联邦ＲＦＣ976 UUCP 邮件互换格式标准ＲＦＣ985 Internet 网关要求- 起草ＲＦＣ988 主机扩展用于IP多点传送中文RFC文档阅读1001-1500ＲＦＣ1050_RPC远程步骤呼叫协议说明书ＲＦＣ1055_在串行线路上传输IP数据报的非标准协议ＲＦＣ1057_RPC远程步骤呼叫协议说明书版本2ＲＦＣ1073_Telnet窗口大小选项ＲＦＣ1075_远距离矢量多播选路协议ＲＦＣ1088_IP 数据包传输通过NetBIOS网络的标准ＲＦＣ1090_SMTP在X.25ＲＦＣ1091_TelnetTELNET终端类型选项ＲＦＣ1094_NFS网络文件系统协议说明书ＲＦＣ1096_Telnet X 显示定位选项ＲＦＣ1097_Telnet潜意识-信息选项ＲＦＣ1112_主机扩展用于IP多点传送ＲＦＣ1113_Internet电子邮件秘密增强第一部分- 信息加密和身份验证步骤ＲＦＣ1131_OSPF规范ＲＦＣ1132_802．2分组在IPX网络上传输的标准ＲＦＣ1134_+PPP协议：关于在点到点链路上进行多协议包传送的建议ＲＦＣ1142 OSI IS-IS 域内路由协议ＲＦＣ1144_低速串行链路上的TCPIP头部压缩ＲＦＣ1145 SNMPv2的管理模型ＲＦＣ1155_基于TCPIP网络的管理结构和标记ＲＦＣ1166_Internet数字ＲＦＣ1180_TCPIP指南ＲＦＣ1191_路径MTU探索ＲＦＣ1215_为使用SNMP定义Trap的惯例ＲＦＣ1239_试验管理系统库(MIB)到标准管理系统库(MIB)的重分配ＲＦＣ1242 基准术语用于网络互连设备ＲＦＣ1258 BSD 的远程登录ＲＦＣ1287_未来的Internet 体系结构ＲＦＣ1288_Finger用户信息协议ＲＦＣ1298_基于IPX协议的SNMPＲＦＣ1321_MD5 信息-摘要算ＲＦＣ1332_PPP Internet 协议控制协议(IPCP)ＲＦＣ1333_PPP 链接质量监控ＲＦＣ1355_网络中心数据库的保密和准确性问题ＲＦＣ1365 一种IP地址扩展提议ＲＦＣ1370_OSPF适用范围声明ＲＦＣ1387_RIP（版本2）协议分析ＲＦＣ1388_RIP协议版本2ＲＦＣ1393 Traceroute使用IP选项ＲＦＣ1397_在边界网关协议（Border Gateway Protocol）版本2ＲＦＣ1408_Telnet环境选项ＲＦＣ1413_鉴定协议ＲＦＣ1414_身份识别管理系统库(MIB)ＲＦＣ1418_SNMP优于OSIＲＦＣ1420_SNMP优于IPXＲＦＣ1426_SMTP服务扩展用于8bit-多用途网际邮件扩充协议(MIME)传输ＲＦＣ1428_Internet邮件从Just-Send-8到8bit-SMTPMIME的转换ＲＦＣ1433 直接ARPＲＦＣ1445_简单网络管理协议(SNMPv2)版本2的管理模式ＲＦＣ1454_下一代IP提议的比较ＲＦＣ1461 通过X.25多协议互连SNMP管理系统库(MIB)扩展ＲＦＣ1469_通过令牌－环局域网的IP多点传送ＲＦＣ1483_通过ATM适应层5的多协议封装中文RFC文档阅读1501-2000ＲＦＣ1558_LDAP研究过滤器的字符串表达ＲＦＣ1571_Telnet环境选项互用性问题ＲＦＣ1590_媒体类型注册过程ＲＦＣ1591_域名系统的结构和授权ＲＦＣ1597_私有Internet的地址分配ＲＦＣ1605_SONET to Sonnet翻译ＲＦＣ1606_用IP版本9的历史观ＲＦＣ1611_DNS服务器MIB扩展ＲＦＣ1612_DNS解析器MIB扩展ＲＦＣ1618_ISDN上的PPP(点对点)协议ＲＦＣ1628 UPS 管理信息基础ＲＦＣ1633_Internet 体系结构中的综合服务概述ＲＦＣ1635_怎样使用匿名FTPＲＦＣ1636 IAB工厂关于在Internet体系结构的安全报告-2月8-10号, 1994ＲＦＣ1643 以太网-类似界面类型的管理对象的定义ＲＦＣ1658 字符流设备使用SMIv2管理对象的定义ＲＦＣ1661_点对点协议(PPP)ＲＦＣ1671 向IPng 过渡和其他考虑的白皮书ＲＦＣ1690 Internet工程与计划组（IEPG）介绍ＲＦＣ1691 康奈尔大学数字图书馆文档体系结构ＲＦＣ1696 用SMIv2定义的调制解调器MIBＲＦＣ1713_DNS调试工具ＲＦＣ1715_地址分配效率比率HＲＦＣ1723_路由信息协议（版本2）ＲＦＣ1724_RIP 版本2 管理系统库(MIB) 扩展ＲＦＣ1738_统一资源定位器(URL)ＲＦＣ1752_推荐IP下一代协议ＲＦＣ1769_简单网络时间协议(SNTP)ＲＦＣ1771_边界网关协议版本4（BGP-4）ＲＦＣ1776_地址是信息ＲＦＣ1777_轻量级目录访问协议ＲＦＣ1787_在多供应Internet上的软件路由ＲＦＣ1796_不是所有ＲＦＣs是标准ＲＦＣ1797_A级子网实验ＲＦＣ1810_报告MD5性能ＲＦＣ1818_最好最新的实践ＲＦＣ1822 使用具备Photuris技术的指定IBM专利的权利的授予ＲＦＣ1823_LDAP 应用程序界面ＲＦＣ1827_IP 密码安全有效载荷(ESP)ＲＦＣ1828_使用键控MD5进行IP鉴别ＲＦＣ1860_IPv4变量长度子网表ＲＦＣ1867 HTML中基于表单的文件上传ＲＦＣ1869 SMTP服务扩展ＲＦＣ1878 变量长度子网表格用于IPv4ＲＦＣ1881 IPv6 地址分配管理ＲＦＣ1883 Internet协议,版本6(IPv6)说明书ＲＦＣ1886 DNS扩展支持IP版本6ＲＦＣ1901 基于社区的SNMPv2介绍ＲＦＣ1904 简单网络管理协议(SNMPv2)版本2的一致声明ＲＦＣ1918 个人Internets的地址分配ＲＦＣ1928 SOCKS V5的用户名/密码鉴定ＲＦＣ1930 自治系统(AS)创建,选择,和注册的指导方针ＲＦＣ1939 邮局办公协议-版本3ＲＦＣ1942 HTML表格ＲＦＣ1945 超文本传输协议--HTTP/1.0ＲＦＣ1956 在MIL域中注册ＲＦＣ1957 邮局协议(POP3)执行的一些观察ＲＦＣ1962 PPP压缩控制协议(CCP)ＲＦＣ1977 PPP BSD 压缩协议ＲＦＣ1979 PPP压缩协议ＲＦＣ1981 IP 版本6的路径MTU探索ＲＦＣ1982 序列号算法ＲＦＣ1988 有条件地授予权利给特殊的HP专利于连接Internet工程特遣队的Internet-标准网络管理框架中ＲＦＣ1993 PPP G和alf FZA 压缩协议ＲＦＣ1994 PPP挑战握手身份验证协议(CHAP)ＲＦＣ1997 BGP 组属性ＲＦＣ1998 BGP 社区属性在多本地路由中的应用中文RFC文档阅读2501-3000ＲＦＣ2508 低速串行链路下IP/UDP/RTP数据包头的压缩ＲＦＣ2511 Internet X.509认证请求消息格式ＲＦＣ2516 在以太网上传输PPP的方法（PPPoE）ＲＦＣ2526 IPv6保留的子网任意传送地址ＲＦＣ2541 DNS 安全操作考虑ＲＦＣ2547 BGP/MPLS VPNsＲＦＣ2554 SMTP服务认证扩展ＲＦＣ2560 x.509因特网公钥基础设施在线证书状态协议——OCSPＲＦＣ2570 标准互联网络管理框架第三版介绍ＲＦＣ2577 FTP 安全考虑ＲＦＣ2581 TCP拥塞控制ＲＦＣ2582 TCP的快速恢复算法NewReno修正ＲＦＣ2585 Internet X.509 公共键底部结构操作协议: FTP和HTTPＲＦＣ2597 确定的面向PHB组ＲＦＣ2598 面向加速PHBＲＦＣ2618 RADIUS 身份验证客户端管理系统库(MIB)ＲＦＣ2629 用XML 写I-Ds 和ＲＦＣ文档ＲＦＣ2633 S/多用途网际邮件扩充协议(MIME) 版本3 信息说明书ＲＦＣ2644 更改直接广播在路由器上的缺省值ＲＦＣ2669 DOCSIS 电缆设备管理系统库(MIB) 电缆设备管理信息基础用于DOCSIS 适应性电缆调制解调器和电缆调制解调器中断系统ＲＦＣ2670 音频频率(RF)界面管理信息基础用于MCNS/DOCSIS适应性RF界面ＲＦＣ2685 虚拟专用网标志符ＲＦＣ2702 基于MPLS的流量工程要求ＲＦＣ2706 ECML v1:电子商务字段名ＲＦＣ2713 LDAP（轻型目录存取协议）目录中JAVATM对象的表征模式ＲＦＣ2714 LDAP（轻型目录存取协议）目录中的CORBA对象参考方案ＲＦＣ2731 Dublin核心元数据在HTML上的编码ＲＦＣ2732 文本IPv6地址在URL上的格式ＲＦＣ2733 RTP有效载荷格式用于普通正向错误更正ＲＦＣ2736 RTP有效载荷格式说明书作者的指导方针ＲＦＣ2754 RPS IANA的发布ＲＦＣ2756 超文本缓存协议(HTCP/0.0)ＲＦＣ2764 IP VPN的框架体系ＲＦＣ2773 使用KEA和SKIPJACK加密ＲＦＣ2774 HTTP 扩展框架ＲＦＣ2781 UTF-16,ISO 10646的一种编码ＲＦＣ2784 通用路由封装（GRE）ＲＦＣ2788 网络服务监视MIBＲＦＣ2793 用于文本交谈的RTP负载ＲＦＣ2796 BGP路由映象ＲＦＣ2809 通过RADIUS的L2TP强制通道的执行ＲＦＣ2810 Internet 延迟交谈:体系结构ＲＦＣ2811 Internet延迟交谈：通道管理ＲＦＣ2813 Internet 延迟交谈:服务器协议ＲＦＣ2817 在HTTP/1.1中升级到TLSＲＦＣ2818 TLS之上的HTTPＲＦＣ2824 呼叫过程语言框架和要求ＲＦＣ2825 复杂网络:I18N的发布,域名,和其它Internet协议ＲＦＣ2829 LDAP的身份验证方法ＲＦＣ2830 轻量级目录访问协议(v3): 传输层安全扩展ＲＦＣ2833 用于DTMF数字信号、电话音和电话信号的RTP负载格式ＲＦＣ2854 text/html 媒体类型ＲＦＣ2855 IEEE 1394的DHCPＲＦＣ2861 TCP 拥塞窗口检验ＲＦＣ2862 用于实时指针的RTP负载格式ＲＦＣ2866 RADIUS（远程用户拨号认证系统）记帐协议ＲＦＣ2867 RADIUS 账目管理修改用于通道协议支持ＲＦＣ2868 RADIUS 属性用于协议支持ＲＦＣ2869 RADIUS 扩展ＲＦＣ2871 一个IP电话路由框架ＲＦＣ2873 在Ipv4优先域中的TCP过程ＲＦＣ2874 支持IPv6地址集合和重编号的DNS 扩展ＲＦＣ2882 网络访问服务要求: 扩展范围实践ＲＦＣ2887 可靠的多点传送设计空间用于大的数据传送ＲＦＣ2889 基准方法论用于局域网交换设备ＲＦＣ2890 GRE中Key和SequenceNumber扩展ＲＦＣ2893 IPv6 主机和软件路由器转换机制ＲＦＣ2898 PKCS #5: 基于密码的密码系统说明书版本 2.0. BＲＦＣ2906 AAA 授权要求ＲＦＣ2914 拥塞控制原理ＲＦＣ2917 核心MPLS IP VPN 体系结构ＲＦＣ2918 BGP-4（边界网关协议）的路由刷新功能ＲＦＣ2920 SMTP 针对命令流水线的服务扩展ＲＦＣ2923 TCP的路径MTU发现问题ＲＦＣ2932 IPv4 多点传送路由管理系统库(MIB)ＲＦＣ2935 Internet开放贸易协议(IOTP)HTTP 补充ＲＦＣ2939 新DHCP选项和信息类型的定义步骤和IANA指导方针ＲＦＣ2945 SRP身份验证和键交换系统ＲＦＣ2946 Telnet 数据加密选项ＲＦＣ2947 Telnet加密：DES3 64位密码回馈ＲＦＣ2948 Telnet加密：DES3 64位输出回馈ＲＦＣ2949 Telnet加密:CAST-128 64比特输出回馈ＲＦＣ2950 Telnet加密:CAST-128 64比特密码回馈ＲＦＣ2951 使用KEA和SKIPJACK进行TELNET身份验证ＲＦＣ2952 Telnet加密：DES 64位密码回馈ＲＦＣ2953 Telnet加密:DES 64比特输出回馈ＲＦＣ2957 The 应用/whoispp-请求目录-类型ＲＦＣ2958 The 应用/whoispp-回答目录-类型ＲＦＣ2959 实时传输协议管理信息库ＲＦＣ2964 超文本传输协议(HTTP)状态管理的应用ＲＦＣ2971 Internet信息访问协议(IMAP4)的标识符扩展ＲＦＣ2976 SIP信息方法ＲＦＣ2983 有区别的协议和通道ＲＦＣ2984 CAST-128密码算法在CMS中的使用ＲＦＣ2987 字符集注册和语言媒体特征标签ＲＦＣ2988 计算TCP重传时间的定时器ＲＦＣ2991 多路径分发在Unicast上和多点传送下一路程段选择ＲＦＣ2992 等值多-路径算法的分析ＲＦＣ2994 MISTY1加密算法的描述1.各协议对应的RFC版本号表1 协议列表序号协议功能版本号1 链路层RSTP 环路保护RFC4318IEEE 802.1w2 LACP 链路聚合IEEE 802.3ad3 LLDP 链路层网络拓扑发现IEEE 802.1ab4 网络ICMP 网络通断探测RFC792 RFC9505 ARP IP地址到MAC解析RFC8266 层RIP 路由RIPv2RFC24537 传输层TCP 传输控制协议RFC793 RFC25818 UDP 用户数据报协议RFC7689应用层SNMP 网络管理SNMPv3RFC3411—RFC341810 SIP 视频会议连接控制RFC254311 HTTPs WEB浏览RFC281812 FTP 基于TCP可靠文件传输RFC95913 TFTP 基于UDP可靠文件传输RFC135014 POP 读取邮件POPv3RFC193915 SMTP 简单邮件传输RFC80116 其他RTP/RTCP 音视频实时数据传输RFC3550 RFC3551RFC496117 PRP 双网冗余IEC 62439说明：●Vxworks中网络协议基本与4.4BSD网络兼容，但增强了实时性和某些特性。
RFC3262
and ACK messages are end-to-end. In order to achieve reliability for
provisional responses, we do nearly the same thing. Reliable
Each provisional response is given a sequence number, carried in the
RSeq header field in the response. The PRACK messages contain an
RAck header field, which indicates the sequence number of the
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-
response protocol for initiating and managing communications
sessions. SIP defines two types of responses, provisional and final.
6 Definition of the PRACK Method ...................... 10
7 Header Field Definitions ............................ 10
7.1 RSeq ................................................ 10
中国电信SIP规范第二分册(协议细则)
中国电信SIP 初始会话协议规范(第二分册)协议细则（暂行版）2004年4月发布 2004年4月试行中国电信集团公司发布前言SIP协议是下一代网络中的接口协议之一，属于应用控制协议。
本标准是以IETF 和ITU-T的相关标准为基础，结合中国电信网络的实际情况，并综合中国电信集团公司对下一代网络的实验成果制定的。
它是中国电信在下一代网络建设中引进、测试和研发软交换设备、SIP终端设备以及其他基于SIP协议相关设备的规范和依据。
鉴于SIP协议应用范围广泛，项目组在编写时将整个协议规范分为3个分册：第一分册：《总体要求》第二分册：《协议细则》第三分册：《信令流程》本分册为《协议细则》分册。
本标准由中国电信集团公司提出。
本标准由中国电信集团公司归口。
本标准于2004年4月首次发布。
本标准由中国电信集团公司负责解释目录1 范围 (1)2 编制说明 (1)3 SIP及其扩展规范 (2)3.1 SIP: Session Initiation Protocol [RFC3261] (2)3.2 Reliability of Provisional Responses in the Session Initiation Protocol (SIP) [RFC3262] (31)3.3 An Offer/Answer Model with the Session Description Protocol (SDP) [RFC3264] (33)3.4 Session Initiation Protocol (SIP)-Specific Event Notification [RFC3265] (36)4 SIP与PSTN的互通 (41)4.1 MIME media types for ISUP and QSIG Objects [RFC3204] (41)4.2 The SIP INFO Method [RFC2976] (42)4.3 Requirements for Interworking BICC/ISUP Network with Originating/Destination Networksbased on Session Initiation Protocol and Session Description Protocol [TRQ.2815] (43)4.4 Interworking between Session Initiation Protocol (SIP) and the Bearer Independent CallControl Protocol or ISDN User Part [Q.1912.5] (45)4.4.1 需要特殊考虑的ISUP消息 (60)5 消息参数 (63)5.1 invite消息 (63)5.2 ACK (64)5.3 BYE (65)5.4 CANCEL (66)5.5 REGISTER (66)5.6 OPTIONS (67)5.7 INFO (68)5.8 PRACK (69)中国电信SIP协议标准----协议细则1范围中国电信SIP规范第二部分是在中国电信SIP规范第一部分的基础上，针对SIP网络的不同逻辑实体，将第一部分所描述的总体要求进行细化，具体落实到每一相关的协议标准的每一章节，甚至到每一个消息或每一个参数。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
RFC3262中文版1.介绍会话发起协议（SIP）文档（RFC 3261 [1]）是使用请求－响应协议来开始并管理通信会话。
SIP 定义了两种响应：临时响应和最终响应。
最终响应传输请求处理的结果，并使用可靠传输方式。
临时响应告知正在处理请求，在RFC3261中不是可靠传输的。
后来在一些案例中发现可靠性非常重要，包括与PSTN交互的场景。
因此，一个可选的能力需要用来支持临时响应的可靠传输。
这种能力在此规范提供。
该可靠性机制模仿目前对INVITE请求的2xx最终响应的可靠性机制。
这些请求定期地由TU（事务用户）传输直到一个单独的事务，收到一个ACK表示接受到了由UAC发出的2XX响应。
对于INVITE 的2XX响应和ACK消息是端到端的可靠传输。
为了达到临时响应的可靠性，我们使用类似的方法。
可靠临时响应由TU使用指数backoff方式进行重传。
这些重传在收到PRACK后结束。
PRACK请求扮演了和ACK同样的角色，只不过是对应临时响应。
这是一个很重要的区别。
PRACK是一个普通的SIP消息，就像BYE那样。
因此，它的可靠性通过每个有状态代理服务器来保证“HOP－BY－HOP”（跳至跳）的可靠性。
和BYE一样，不同于ACK,PRACK有自己的响应。
如果不是这种情况，PRACK消息无法穿越代理服务器，兼容于RFC 2543 [4]。
每个临时响应都有一个序列号（sequence number）, 携带在响应的RSeq头字段。
PRACK包含一个RAck头字段，表明了它所确认的临时响应的序列号。
该确认不是累积的，本说明建议一次只发一个明显临时响应，以控制拥塞。
2.术语在这份文件中，关键词“必须”，“必须不”，“要求”，“应当”，“不应”，“应该”，“不应该”，“建议”，“或许”，和“可选”是被解释为在RFC 2119 [2]和表明为实现SIP标准要求的水平。
3.UAS行为当初始INVITE包含一个支持（Supported）头字段带有可选标签100rel。
UAS可能发送任何非100临时响应来可靠地回应INVITE，本说明不允许除对应INVITE之外的临时可靠响应，扩展定义了新的方法来建立对话可能会使用这种机制。
当初始INVITE包含一个必须（Required）头字段带有可选标签100rel。
UAS必须发送任何非100临时响应，如果UAS不愿意接受，它必须使用420（错误的扩展）携带不支持的带有可选标签100Rel 的头字段拒绝初始请求。
UAS不允许对100临时响应进行可靠传输。
只有101到199可以可靠传输。
如果请求既没有Supported或Require头字段来表明这个特性，UAS不允许可靠地发送临时响应。
100Trying响应只能hop-by-hop（跳至跳）,这个原因，这里描述的end-to-end（端到端）地可靠机制不能使用。
可以作为代理的成员（element）也能发送可靠的临时响应。
这种情况下，它在这个事务中作为UAS。
但是，它不能对带有一个标签的To头字段的任何请求做可靠临时响应。
这意味着一个代理不能对对话中发送的请求生成可靠临时响应。
不同于UAS，当代理成员（element）收到一个不匹配可靠临时响应的PRACK，该PRACK必须被代理。
为什么UAS可能想发送一个可靠的临时响应，有如下几个理由：第一，如果INVITE事务可能需要时间来产生最终响应。
如3261中13.3.1.1章节谈论的，UAS将需要发送定期的临时响应来向代理请求一个事务的“扩展”。
需求是一个代理会每隔3分钟收到请求，但是因为丢包地可能性UAS需要更频繁地发送请求（建议间隔一分钟）。
作为一个更有效率的解决方案UAS可以可靠地发送响应。
这样UAS应该每隔2.5分钟发送一个临时响应。
在扩展事务中使用可靠临时响应是建议性地。
剩余地讨论假设初始请求包换一个Supported或Require头字段列出100rel,并且有一个临时响应被可靠的传输。
临时响应被可靠传输是有UAScore根据3261 8.2.6章节的程序来构造的。
另外，它必须包含Require头字段带有可选标签100rel和Rseq头字段。
UAS可能发送任何非100临时响应来可靠地回应INVITE，事务中第一个可靠临时响应的头字段的值必须在1和2**31－1之间。
建议从这个范围内均一地选择。
Rseq编号空间用于一个单独地事务。
这个意味着对于不同请求的临时响应可能使用相同的Rseq值。
可靠临时响应可能包含一个包体。
会话描述的用途在第五章介绍。
可靠临时响应被定期地传输到事务层。
间隔从T1妙开始，然后每隔双倍地时间重传一次（T1在3261中17章节定义）。
一旦传输到服务层事务，它将被加到一个内部未确认可靠临时响应列表。
事务层将转发每个从UAScore中传过来的重传。
这个和2xx响应的重传不同，2xx的间隔时间是T2秒。
这是因为ACK的重传是由一个2xx接收来触发的，但PRACK的重传独立于1xx的接收。
当从UACore中收到一个匹配的PRACK那么可靠临时响应的重传就结束。
PRACK就像对话中的其他请求一样，UAScore 根据3261 的8.2 ，12.2.2 章节程序来处理。
一个匹配的PRACK定义类似为在同一会话里的响应，它的方法，Cseq－num和响应号在Rack头字段匹配，分别的对应于可靠临时响应的Cseq的方法，序列号和可靠临时响应中的Rseq中的序列号。
如果UA core收到一个PRACK请求不匹配任何未确认可靠临时响应，UAS必须给PRACK返回一个481响应。
如果PRACK匹配一个未确认可靠临时响应，那么它必须回复一个2xx响应。
UAS 可以通过这点来取人临时响应已被有序接收。
它应当停止可靠临时响应的重传，并且必须将它从未确认临时响应列表中去掉。
如果一个可靠临时响应重传了64×T1秒仍未接收到匹配的PRACK，UAS应当用5xx响应拒绝初始请求。
如PRACK包含一个会话描述，它将如5章节中所描述的进行处理。
如果PRACk包含其他类型的消息体，这个消息体会按ACK中的消息体的方式进行处理。
在请求的第一个可靠临时响应被确认后，UAS可能会发送额外的可靠临时响应。
UAS必须在在第一个被确认后才能发送第二个可靠临时响应。
第一个可靠临时响应会有特别的处理因为它负责传递初始序列号。
如果额外的可靠在第一个被确认之前发送，UAS不能确定他们是否被顺序收到。
接下来的针对相同请求的每个可靠临时响应中Rseq的值必须精确地进行加一操作。
Rseq序号不允许循环。
因为初始第一个选择小于2**31 - 1，但是最大地值是2**32 - 1，每个请求可以有超过2**31个临时可靠响应，这个值绰绰有余。
UAS可能在收到所有未确认可靠临时响应地PRACK之前发送对于这个请求的最终响应，除非最终响应是2xx并且所有的未确认可靠临时响应都包含一个会话描述。
在这种情况下，它必须在所有临时响应都被确认后才能发送最终响应。
如果UAS在所有可靠响应仍未确认前发送最终响应，那么它不应当继续重传未确认可靠临时响应，但是它必须准备处理针对于这些响应的PRACK请求。
UAS在发送了一个对于请求的最终响应后不允许再发送新的可靠临时响应（与未确认响应的的重传相对立）。
4.UAC行为当UAC建立了一个新的请求，它可以坚持对该请求进行临时响应的可靠传送。
为了实现该能力，它在请求中插入了一个带100rel可选标签的Require头字段。
带100rel可选标签的Require头字段只能在INVITE请求中使用，尽管SIP的扩展可能允许其他的请求方法使用它。
Header field where PRACKAccept R o Accept 2xx - Accept 415 c Accept-Encoding R o Accept-Encoding 2xx - Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx - Accept-Language 415 c Alert-Info R - Alert-Info 180 - Allow R o Allow 2xx o Allow r o Allow 405 m Authentication-Info 2xx o Authorization R oCall-ID c m Call-Info - Contact R - Contact 1xx - Contact 2xx - Contact 3xx o Contact 485 o Content-Disposition o Content-Encoding o Content-Language o Content-Length t Content-Type * CSeq c m Date o Error-Info 300-699 o Expires - From c mIn-Reply-To R -Max-Forwards R m Min-Expires 423 - MIME-Version o Organization - Table 1: Summary of header fields, A--OHeader field where PRACKPriority R -Proxy-Authenticate 407 mProxy-Authenticate 401 oProxy-Authorization R oProxy-Require R oRecord-Route R oRecord-Route 2xx,18x oReply-To -Require cRetry-After 404,413,480,486 o500,503 o600,603 oRoute R cServer r oSubject R -Supported R oSupported 2xx oTimestamp oTo c mUnsupported 420 mUser-Agent oVia c mWarning r o401 mTable 2: Summary of header fields, P--Z如果UAC不一定要求使用可靠临时响应，但只是表明如果UAS需要发送那么它会支持，带100rel 可选标签的Supported头字段必须出现在请求当中。
UAC应该在所有的INVITE请求中加入该字段。
如果收到了一个初始请求的临时响应，并且响应包含带100rel可选标签的Require头字段，那么响应会被可靠地传送。
如果响应是一个100（trying）（非101～199），那么这个可选标签必须忽略，如下的过程将不会用到。
如果对话还没建立那么临时响应必须建立一个对话。