下载文档原格式
SIP协议栈协议名称：SIP协议栈一、引言SIP（Session Initiation Protocol，会话初始化协议）是一种用于建立、修改和终止多媒体会话的应用层协议。
本协议旨在定义SIP协议栈的标准格式，以便确保各种实现都能够互操作并保持一致性。
二、范围本协议适用于所有实现SIP协议栈的软件和硬件设备。
三、术语定义以下术语在本协议中具有如下定义：1. SIP：Session Initiation Protocol，会话初始化协议，用于建立、修改和终止多媒体会话。
2. 协议栈：指一系列协议的集合，用于实现特定协议的功能。
3. 实现：指使用SIP协议栈的软件或硬件设备。
四、协议规范1. SIP协议栈的实现应符合RFC 3261中定义的SIP标准，包括但不限于以下方面：a. SIP消息格式：SIP协议栈应能够正确解析和生成符合SIP消息格式的请求和响应。
b. 会话管理：SIP协议栈应能够正确处理会话的建立、修改和终止过程，包括发送和接收INVITE、ACK、BYE等消息。
c. 媒体协商：SIP协议栈应能够支持媒体类型和编解码器的协商，以便在会话中传输音频、视频和其他媒体数据。
d. 安全性：SIP协议栈应能够支持安全传输，如TLS和S/MIME等协议。
e. 代理和路由：SIP协议栈应能够正确处理代理和路由功能，包括请求的转发和响应的路由选择。
f. 事务处理：SIP协议栈应能够实现事务处理机制，以确保请求和响应的可靠传输。
g. 错误处理：SIP协议栈应能够正确处理错误情况，包括发送和接收错误响应、超时和重传等。
2. SIP协议栈的实现应具备良好的性能和可扩展性，能够处理大量并发会话和高负载情况。
3. SIP协议栈的实现应具备良好的兼容性，能够与其他实现互操作，并支持常见的SIP扩展和协议增强功能。
4. SIP协议栈的实现应提供丰富的API和开发工具，以便开发人员能够方便地使用和扩展SIP功能。
5. 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]。
会话发起协议Session Initiation ProtocolIETF RFC 3261摘要：本文档描述了会话发起协议（SIP），即有一个或多个参与者的用于创建、修改和终止会话的应用层控制（信令）协议。
这些会话包括Internet电话呼叫、多媒体分发和多媒体会议。
用于创建会话的SIP邀请携带允许参与者进行兼容的媒体类型协商的会话描述。
SIP使用称作代理服务器的元素帮助将请求路由到用户的当前位置，认证并授权用户访问服务，实现提供商呼叫路由策略，并为用户提供功能。
SIP同时提供注册功能，允许用户上载其当前的位置信息，以便代理服务器使用。
SIP运行在多个不同的传输协议上。
1介绍Internet上许多应用需要创建和管理会话，会话被认为是相关参与者之间的数据交换。
这些应用的实现由于参与者的实践而复杂化：用户可能在端点间移动，他们可通过多个名称寻址，他们可以在多种不同的媒体上通信，甚至是同时的。
已开发了多种用于携带各种实时多媒体会话数据（如语音、视频或文本消息）格式的协议。
通过使Internet端点（称为用户代理）能够发现他人并协商可能共享的会话特征，会话发起协议（SIP）能与其它协议很好地协作。
为了定位预期的会话参与者以及其他功能，SIP允许创建网络主机（称为代理服务器）基础设施，用户代理能向代理服务器发送注册信息、会话邀请以及其它请求。
SIP是用于创建、修改和终止会话的灵活的、通用的工具。
它独立于潜在的传输协议，并且不依赖于所建立的会话类型。
2SIP功能概要SIP是一个应用层控制协议，它能建立、修改和终止多媒体会话（会议），如Internet 电话呼叫。
SIP也能邀请参与者到已建立的会话中，如多播会议。
能从已建立的会议中增加（和删除）媒体。
SIP透明地支持名字映射和重定向服务，重定向服务支持个人移动性——用户可以维持一个外部可视的标识符，而不管其位置。
SIP支持建立和终止多媒体通信的5个方面：用户位置：确定用于通信的终端系统；用户可用性：确定被呼叫者参加通信的意愿；用户能力：确定使用的媒体和媒体参数；会话建立：“响铃”，在呼叫和被呼叫者建立会话参数；会话管理：包括传输和终止会话、修改会话参数以及调用服务。
中国电信“我的e家”技术规范―e家终端（e8）Technical standard for China Telecom “One Home” Service- Home Gateway (e8)（V3.0）2009-XX-XX发布2009-XX-XX实施目录前言 (IVIV)1 范围 (55)2 规范性引用文件 (55)3 缩略语 (77)4 设备总体定义 (88)4.1 设备在网络中的位置 (88)4.2 接口定义 (88)4.3 设备形态 (99)5 物理接口要求 (99)5.1 网络侧接口要求 (99)5.2 用户侧接口要求 (99)6 功能要求 (1010)6.1 网络协议及数据转发功能要求 (1010)6.2 WLAN AP功能要求 (1313)6.3 设备发现功能要求 (1515)6.4 业务发现和控制功能要求 (1515)6.5 VoIP语音功能处理要求 (1616)7 安全要求 (2323)7.1 网络访问的安全性 (2323)7.2 用户侧接口安全性 (2424)7.3 登录安全性 (2424)7.4 设备安全性 (2525)8 管理和维护要求............................ 错误!未定义书签。
错误!未定义书签。
8.1 基本要求................................ 错误!未定义书签。
错误!未定义书签。
8.2 本地管理和配置要求...................... 错误!未定义书签。
错误!未定义书签。
8.3 TR069远程管理和配置要求 ................ 错误!未定义书签。
错误!未定义书签。
8.4 OAM远程管理和配置要求 .................. 错误!未定义书签。
错误!未定义书签。
9 性能要求.................................. 错误!未定义书签。
错误!未定义书签。
Network Working Group W. Marshall, Ed. Request for Comments: 3313 AT&T Category: Informational January 2003 Private Session Initiation Protocol (SIP) Extensionsfor Media AuthorizationStatus of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2003). All Rights Reserved. AbstractThis document describes the need for Quality of Service (QoS) andmedia authorization and defines a Session Initiation Protocol (SIP)extension that can be used to integrate QoS admission control withcall signaling and help guard against denial of service attacks. The use of this extension is only applicable in administrative domains,or among federations of administrative domains with previouslyagreed-upon policies, where both the SIP proxy authorizing the QoS,and the policy control of the underlying network providing the QoS,belong to that administrative domain or federation of domains. Marshall, Ed. Informational [Page 1]Table of Contents1. Scope of Applicability (2)2. Conventions Used in this Document (3)3. Background and Motivation (3)4. Overview (4)5. Changes to SIP to Support Media Authorization (4)5.1 SIP Header Extension (5)5.2 SIP Procedures (5)5.2.1 User Agent Client (UAC) (6)5.2.2 User Agent Server (UAS) (6)5.2.3 Originating Proxy (OP) (7)5.2.4 Destination Proxy (DP) (7)6. Examples (8)6.1 Requesting Bandwidth via RSVP Messaging (8)6.1.1 User Agent Client Side (8)6.1.2 User Agent Server Side (10)7. Advantages of the Proposed Approach (12)8. Security Considerations (13)9. IANA Considerations (13)10. Notice Regarding Intellectual Property Rights (13)11. Normative References (14)12. Informative References (14)13. Contributors (15)14. Acknowledgments (15)15. Editor’s Address (15)16. Full Copyright Statement (16)1. Scope of ApplicabilityThis document defines a SIP extension that can be used to integrateQoS admission control with call signaling and help guard againstdenial of service attacks. The use of this extension is onlyapplicable in administrative domains, or among federations ofadministrative domains with previously agreed-upon policies, whereboth the SIP proxy authorizing the QoS, and the policy control of the underlying network providing the QoS, belong to that administrativedomain or federation of domains. Furthermore, the mechanism isgenerally incompatible with end-to-end encryption of message bodiesthat describe media sessions.This is in contrast with general Internet principles, which separate data transport from applications. Thus, the solution described inthis document is not applicable to the Internet at large. Despitethese limitations, there are sufficiently useful specializeddeployments that meet the assumptions described above, and can accept the limitations that result, to warrant informational publication of this mechanism. An example deployment would be a closed network, Marshall, Ed. Informational [Page 2]which emulates a traditional circuit switched telephone network.This document specifies a private header, facilitating use in thesespecialized configurations.2. Conventions Used in this DocumentThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].3. Background and MotivationCurrent IP telephony systems assume a perfect world in which there is either an unlimited amount of bandwidth, or network layer Quality of Service (QoS) is provided without any kind of policy control.However, the reality is that end-to-end bandwidth is not unlimitedand uncontrolled access to QoS, in general, is unlikely. The primary reason for this is that QoS provides preferential treatment of oneflow, at the expense of another. Consequently, it is important tohave policy control over whether a given flow should have access toQoS. This will not only enable fairness in general, but can alsoprevent denial of service attacks.In this document, we are concerned with providing QoS for mediastreams established via the Session Initiation Protocol (SIP) [3].We assume an architecture that integrates call signaling with mediaauthorization, as illustrated in the Figure below. The solid lines(A and B) show interfaces, whereas the dotted line (C) illustratesthe QoS enabled media flow:+---------+| Proxy |+--------->| || +---------+| ^A)| B) || { }| || vv +------++------+ C) | Edge || UA |........|router|......+------+ +------+Figure 1 - Basic ArchitectureMarshall, Ed. Informational [Page 3]In this architecture, we assume a SIP UA connected to a QoS enablednetwork with an edge router acting as a Policy Enforcement Point(PEP) [6]. We further assume that a SIP UA that wishes to obtain QoS initiates sessions through a proxy which can interface with the QoSpolicy control for the data network being used. We will refer tosuch a proxy as a QoS enabled proxy. We assume that the SIP UA needs to present an authorization token to the network in order to obtainQuality of Service (C). The SIP UA obtains this authorization token via SIP (A) from the QoS enabled proxy by means of an extension SIPheader, defined in this document. The proxy, in turn, communicateseither directly with the edge router or with a Policy Decision Point (PDP - not shown) [6] in order to obtain a suitable authorizationtoken for the UA.Examples of access data networks, where such a QoS enabled proxycould be used, include DOCSIS based cable networks and 3rd generation (3G) wireless networks.4. OverviewA session that needs to obtain QoS for the media streams inaccordance with our basic architecture described above goes throughthe following steps.The SIP UA sends an INVITE to the QoS enabled proxy, which for eachresulting dialog includes one or more media authorization tokens inall unreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliableresponse for the dialog. When the UA requests QoS, it includes themedia authorization tokens with the resource reservation.A SIP UA may also receive an INVITE from its QoS enabled proxy which includes one or more media authorization tokens. In that case, when the UA requests QoS, it includes the media authorization tokens with the resource reservation. The resource reservation mechanism is not part of SIP and is not described within the scope of this document.5. Changes to SIP to Support Media AuthorizationThis document defines a private SIP header extension to support amedia authorization scheme. In this architecture, a QoS enabled SIP proxy supplies the UA with one or more authorization tokens which are to be used in QoS requests. The extension defined allows network QoS resources to be authorized by the QoS enabled SIP proxy.Marshall, Ed. Informational [Page 4]5.1 SIP Header ExtensionA new P-Media-Authorization general header field is defined. The P- Media-Authorization header field contains one or more mediaauthorization tokens which are to be included in subsequent resource reservations for the media flows associated with the session, thatis, passed to an independent resource reservation mechanism, which is not specified here. The media authorization tokens are used forauthorizing QoS for the media stream(s). The P-Media-Authorizationheader field is described by the following ABNF [4]:P-Media-Authorization = "P-Media-Authorization" HCOLONP-Media-Authorization-Token*(COMMA P-Media-Authorization-Token)P-Media-Authorization-Token = 1*HEXDIGTable 1 below is an extension of tables 2 and 3 in [3] for the newheader field defined here. For informational purposes, this tablealso includes relevant entries for standards track extension methods published at the time this document was published. The INFO, PRACK, UPDATE, and SUBSCRIBE and NOTIFY methods are defined respectively in [11], [9], [12], and [10].Where proxy ACK BYE CAN INV OPT REG P-Media-Authorization R ad o - - o - - P-Media-Authorization 2xx ad - - - o - - P-Media-Authorization 101-199 ad - - - o - - Where proxy INF PRA UPD SUB NOTP-Media-Authorization R ad - o o - -P-Media-Authorization 2xx ad - o o - -Table 1: Summary of header fields.The P-Media-Authorization header field can be used only in SIPrequests or responses that can carry a SIP offer or answer. Thisnaturally keeps the scope of this header field narrow.5.2 SIP ProceduresThis section defines SIP [3] procedures for usage in mediaauthorization compatible systems, from the point of view of theauthorizing QoS.Marshall, Ed. Informational [Page 5]5.2.1 User Agent Client (UAC)The initial SIP INVITE message, mid-call messages that result innetwork QoS resource changes, and mid-call changes in calldestination should be authorized. These SIP messages are sentthrough the QoS enabled proxies to receive this authorization. Inorder to authorize QoS, the QoS enabled SIP proxy MAY need to inspect message bodies that describe the media streams (e.g., SDP). Hence,it is recommended (as may be appropriate within the applicabilityscope in Section 1 of this document) that such message bodies not be encrypted end-to-end.The P-Media-Authorization-Token, which is contained in the P-Media-Authorization header, is included for each dialog in all unreliableprovisional responses (except 100), the first reliable 1xx or 2xxresponse, and all retransmissions of that reliable response for thedialog sent by the QoS enabled SIP proxy to the UAC.The UAC should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorizationheader when requesting QoS for the associated media stream(s). This applies to both initial and subsequent refresh reservation messages(for example, in an RSVP-based reservation system). A reservationfunction within the UAC should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined inRFC 2750 [5] (excluding Length, but including P-Type which isincluded in each token). These Policy-Elements would typicallycontain the authorizing entity and credentials, and be used in anRSVP request for media data stream QoS resources.5.2.2 User Agent Server (UAS)The User Agent Server receives the P-Media-Authorization-Token in an INVITE (or other) message from the QoS enabled SIP proxy. If theresponse contains a message body that describes media streams forwhich the UA desires QoS, it is recommended (as may be appropriatewithin the applicability scope in Section 1 of this document) thatthis message body not be encrypted end-to-end.The UAS should use all the P-Media-Authorization-Tokens from the most recent request/response that contained the P-Media-Authorizationheader when requesting QoS for the associated media stream(s). This applies both to initial and subsequent refresh reservation messages(for example, in an RSVP-based reservation system). A reservationfunction within the UAS should convert each string of hex digits into binary, and utilize each result as a Policy-Element, as defined inRFC 2750 [5] (excluding Length, but including P-Type which isincluded in each token). These Policy-Elements would typically Marshall, Ed. Informational [Page 6]contain the authorizing entity and credentials, and be used in anRSVP request for media data stream QoS resources.5.2.3 Originating Proxy (OP)When the originating QoS enabled proxy (OP) receives an INVITE (orother) message from the UAC, the proxy authenticates the caller, and verifies that the caller is authorized to receive QoS.In cooperation with an originating Policy Decision Point (PDP-o), the OP obtains and/or generates one or more media authorization tokens.These contain sufficient information for the UAC to get theauthorized QoS for the media streams. Each media authorization token is formatted as a Policy-Element, as defined in RFC 2750 [5](excluding Length, but including P-Type which is included in eachtoken), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy’s resource management function may inspect message bodies that describe the media streams (e.g.,SDP), in both requests and responses in order to decide what QoS toauthorize.For each dialog that results from the INVITE (or other) messagereceived from the UAC, the originating proxy must add a P-Media-Authorization header with the P-Media-Authorization-Token in allunreliable provisional responses (except 100), the first reliable 1xx or 2xx response, and all retransmissions of that reliable responsethe proxy sends to the UAC, if that response may result in networkQoS changes. A response with an SDP may result in such changes.5.2.4 Destination Proxy (DP)The Destination QoS Enabled Proxy (DP) verifies that the called party is authorized to receive QoS.In cooperation with a terminating Policy Decision Point (PDP-t), the DP obtains and/or generates a media authorization token that contains sufficient information for the UAS to get the authorized QoS for the media streams. The media authorization token is formatted as aPolicy-Element, as defined in RFC 2750 [5] (excluding Length, butincluding P-Type which is included in each token), and then converted to a string of hex digits to form a P-Media-Authorization-Token. The proxy’s resource management function may inspect message bodies that describe the media streams (e.g., SDP), in both requests andresponses in order to decide what QoS to authorize.Marshall, Ed. Informational [Page 7]The Destination Proxy must add the P-Media-Authorization header with the P-Media-Authorization-Token in the INVITE (or other) request that it sends to the UAS if that message may result in network QoSchanges. A message with an SDP body may result in such changes.6. Examples6.1 Requesting Bandwidth via RSVP MessagingBelow we provide an example of how the P-Media-Authorization headerfield can be used in conjunction with the Resource ReservationProtocol (RSVP) [7]. The example assumes that an offer arrives inthe initial INVITE and an answer arrives in a reliable provisionalresponse [9], which contains an SDP description of the media flow.6.1.1 User Agent Client SideFigure 2 presents a high-level overview of a basic call flow withmedia authorization from the viewpoint of the UAC. Some policyinteractions have been omitted for brevity.When a user goes off-hook and dials a telephone number, the UACcollects the dialed digits and sends the initial (1)INVITE message to the originating SIP proxy.The originating SIP proxy (OP) authenticates the user/UAC andforwards the (2)INVITE message to the proper SIP proxy.Assuming the call is not forwarded, the terminating end-point sends a (3)18x response to the initial INVITE via OP. Included in thisresponse is an indication of the negotiated bandwidth requirement for the connection (in the form of an SDP description [8]).When OP receives the (3)18x, it has sufficient information regarding the end-points, bandwidth and characteristics of the media exchange. It initiates a Policy-Setup message to PDP-o, (4)AuthProfile.The PDP-o stores the authorized media description in its local store, generates an authorization token that points to this description, and returns the authorization token to the OP, (5)AuthToken.Marshall, Ed. Informational [Page 8]UAC ER-o PDP-o OP|(1)INVITE | | | Client Authentication |------------------------------------------->| and Call Authoriz.| | | | (2)INVITE| | | |-------------->| | | | (3)18x| | |(4)AuthProfile |<--------------| | |<--------------|| | |(5)AuthToken || | |-------------->| Auth. Token put into| | | (6)18x | P-Media-Authorization |<-------------------------------------------| header extension.|---(7)PRACK-------------------------------->|| |--(8)PRACK---->| |<-(9)200 (PRACK)|<--(10)200 (PRACK)--------------------------|| | | ||Copies the RSVP policy object ||from the P-Media-Authorization ||(11)RSVP-PATH | ||----------->| (12)REQ | || |-------------->| Using the Auth-Token and Authorized| | (13)DEC | Profile that is set by the SIP Proxy| |<--------------| the PDP makes the decision| | | |(14)RSVP-PATH| |------------------------------------------------>| | | |(15)RSVP-PATH|<--------------------------------------------------------------|Copies the RSVP policy object ||from the P-Media-Authorization ||(16)RSVP-RESV | ||----------->| (17)REQ | || |-------------->| Using the Auth-Token and Authorized| | (18)DEC | Profile that is set by the SIP Proxy| |<--------------| the PDP makes the decision| | | |(19)RSVP-RESV| |--------------------------------------------------->| | | |(20)RSVP-RESV|<----------------------------------------------------------------| | | |Figure 2 - Media Authorization with RSVP (UAC)The OP includes the authorization token in the P-Media-Authorization header extension of the (6)18x message.Marshall, Ed. Informational [Page 9]Upon receipt of the (6)18x message, the UAC stores the mediaauthorization token from the P-Media-Authorization header. Also, the UAC acknowledges the 18x message by sending a (7)PRACK message, which is responded to with (10) 200.Before sending any media, the UAC requests QoS by sending an(11)RSVP-PATH message, which includes the previously stored P-Media- Authorization-Token as a Policy-Element.ER-o, upon receipt of the (11)RSVP-PATH message, checks theauthorization through a PDP-o COPS message exchange, (12)REQ. PDP-o checks the authorization using the stored authorized mediadescription that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install"Decision, (13)DEC.ER-o checks the admissibility for the request, and if admissionsucceeds, it forwards the (14)RSVP-PATH message.Once UAC receives the (15)RSVP-PATH message from UAS, it sends the(16)RSVP-RESV message to reserve the network resources.ER-o, upon receiving the (16)RSVP-RESV message checks theauthorization through a PDP-o COPS message exchange, (17)REQ. PDP-o checks the authorization using the stored authorized mediadescription that was linked to the authorization token it returned to OP. If authorization is successful, PDP-o returns an "install"Decision, (18)DEC.ER-o checks the admissibility for the request, and if admissionsucceeds, it forwards the (19)RSVP-RESV message.Upon receiving the (20)RSVP-RESV message, network resources have been reserved in both directions.6.1.2 User Agent Server SideFigure 3 presents a high-level overview of a call flow with mediaauthorization from the viewpoint of the UAS. Some policyinteractions have been omitted for brevity.Since the destination SIP proxy (DP) has sufficient informationregarding the endpoints, bandwidth, and characteristics of the media exchange, it initiates a Policy-Setup message to the terminatingPolicy Decision Point (PDP-t) on receipt of the (1)INVITE.Marshall, Ed. Informational [Page 10]UAS ER-t PDP-t DP| | | | (1)INVITE| | | |<--------------| | | | Proxy Authentication| | | (2)AuthProfile| and Call Authoriz.| | |<--------------|| | | (3)AuthToken || | |-------------->| Auth. Token put into| | | (4)INVITE | P-Media-Authorization |<------------------------------------------| header extension| (5)18x | | ||------------------------------------------>| (6)18x|Copies the RSVP policy object |-------------->|from the P-Media-Authorization ||(7)RSVP-PATH | ||---------->| (8)REQ | || |-------------->| Using the Auth-Token and Authorized| | (9)DEC | Profile that is set by the SIP Proxy| |<--------------| the PDP makes the decision| | | |(10)RSVP-PATH| |-------------------------------------------------->| | | |(11)RSVP-PATH|<--------------------------------------------------------------|Copies the RSVP policy object ||from the P-Media-Authorization || (12)RSVP-RESV | ||---------->| | || | (13)REQ | || |-------------->| Using the Auth-Token and Authorized| | (14)DEC | Profile that is set by the SIP Proxy| |<--------------| the PDP makes the decision| | | |(15)RSVP-RESV| |--------------------------------------------------->| | | |(16)RSVP-RESV|<---------------------------------------------------------------| | | |<-(17)PRACK---------|<--(18)PRACK ------------------------------||---(19)200 (PRACK) ----------------------->|| | | |--(20)200 (PRACK)-->| | | |Figure 3 - Media Authorization with RSVP (UAS)PDP-t stores the authorized media description in its local store,generates an authorization token that points to this description, and returns the authorization token to DP. The token is placed in the(4)INVITE message and forwarded to the UAS.Marshall, Ed. Informational [Page 11]Assuming that the call is not forwarded, the UAS sends a (5)18xresponse to the initial INVITE message, which is forwarded back toUAC. At the same time, the UAS sends a (7)RSVP-PATH message whichincludes the previously stored P-Media-Authorization-Token as aPolicy-Element.ER-t, upon receiving the (7)RSVP-PATH message checks theauthorization through a PDP-t COPS message exchange. PDP-t checksthe authorization using the stored authorized media description that was linked to the authorization token it returned to DP. Ifauthorization is successful, PDP-t returns an "install" Decision,(9)DEC.ER-t checks the admissibility for the request, and if admissionsucceeds, it forwards the (10)RSVP-PATH message.Once the UAS receives the (11)RSVP-PATH message, it sends the(12)RSVP-RESV message to reserve the network resources.ER-t, upon reception of the (12)RSVP-RESV message, checks theauthorization through a PDP-t COPS message exchange. PDP-t checksthe authorization using the stored authorized media description that was linked to the authorization token that it returned to DP. Ifauthorization is successful, PDP-t returns an "install" Decision,(14)DEC.ER-t checks the admissibility for the request and if admissionsucceeds, it forwards the (15)RSVP-RESV message.Upon receiving the (16)RSVP-RESV message, network resources have been reserved in both directions.For completeness, we show the (17)PRACK message for the (5) 18xresponse and the resulting (19) 200 response acknowledging the PRACK.7. Advantages of the Proposed ApproachThe use of media authorization makes it possible to control the usage of network resources. In turn, this makes IP Telephony more robustagainst denial of service attacks and various kinds of servicefrauds. By using the authorization capability, the number of flows, and the amount of network resources reserved can be controlled,thereby making the IP Telephony system dependable in the presence of scarce resources.Marshall, Ed. Informational [Page 12]8. Security ConsiderationsIn order to control access to QoS, a QoS enabled proxy shouldauthenticate the UA before providing it with a media authorizationtoken. Both the method and policy associated with suchauthentication are outside the scope of this document, however itcould, for example, be done by using standard SIP authenticationmechanisms, as described in [3].Media authorization tokens sent in the P-Media-Authorization headerfrom a QoS enabled proxy to a UA MUST be protected from eavesdropping and tampering. This can, for example, be done through a mechanismsuch as IPSec or TLS. However, this will only provide hop-by-hopsecurity. If there is one or more intermediaries (e.g., proxies),between the UA and the QoS enabled proxy, these intermediaries willhave access to the P-Media-Authorization header field value, thereby compromising confidentiality and integrity. This will enable boththeft-of-service and denial-of-service attacks against the UA.Consequently, the P-Media-Authorization header field MUST NOT beavailable to any untrusted intermediary in the clear or withoutintegrity protection. There is currently no mechanism defined in SIP that would satisfy these requirements. Until such a mechanismexists, proxies MUST NOT send P-Media-Authorization headers throughuntrusted intermediaries, which might reveal or modify the contentsof this header. (Note that S/MIME-based encryption in SIP is notavailable to proxy servers, as proxies are not allowed to add message bodies.)QoS enabled proxies may need to inspect message bodies describingmedia streams (e.g., SDP). Consequently, such message bodies should not be encrypted. In turn, this will prevent end-to-endconfidentiality of the said message bodies, which lowers the overall security possible.9. IANA ConsiderationsThis document defines a new private SIP header for mediaauthorization, "P-Media-Authorization". This header has beenregistered by the IANA in the SIP header registry, using the RFCnumber of this document as its reference.10. Notice Regarding Intellectual Property RightsThe IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in thisdocument. For more information consult the online list of claimedrights.Marshall, Ed. Informational [Page 13]11. Normative References[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[3] 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.[4] Crocker, D. and P. Overell, "Augmented BNF for SyntaxSpecifications: ABNF", RFC 2234, November 1997.[5] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,January 2000.12. Informative References[6] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework forPolicy-based Admission Control", RFC 2753, January 2000.[7] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,"Resource Reservation Protocol (RSVP) -- Version 1 FunctionalSpecification", RFC 2205, September 1997.[8] Handley, M. and V. Jacobson, "SDP: Session DescriptionProtocol", RFC 2327, April 1998.[9] Rosenberg, J. and H. Schulzrinne, "Reliability of ProvisionalResponses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.[10] Roach, A. B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.[11] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.[12] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATEMethod", RFC 3311, September 2002.Marshall, Ed. Informational [Page 14]。
SIP百科SIP是类似于HTTP的基于文本的协议。
SIP可以减少应用特别是高级应用的开发时间。
由于基于IP协议的SIP利用了IP网络，固定网运营商也会逐渐认识到SIP技术对于他们的深远意义。
一、介绍什么是SIPSIP(Session Initiation Protocol)是一个应用层的信令控制协议。
用于创建、修改和释放一个或多个参与者的会话。
这些会话可以好似Internet多媒体会议、IP电话或多媒体分发。
会话的参与者可以通过组播（multicast）、网状单播（unicast）或两者的混合体进行通信。
SIP是类似于HTTP的基于文本的协议。
SIP可以减少应用特别是高级应用的开发时间。
由于基于IP协议的SIP利用了IP网络，固定网运营商也会逐渐认识到SIP技术对于他们的深远意义。
使用 SIP，服务提供商可以随意选择标准组件。
不论媒体内容和参与方数量，用户都可以查找和联系对方。
SIP 对会话进行协商，以便所有参与方都能够就会话功能达成一致以及进行修改。
它甚至可以添加、删除或转移用户。
SIP它既不是会话描述协议，也不提供会议控制功能。
为了描述消息内容的负载情况和特点，SIP 使用 Internet 的会话描述协议 (SDP) 来描述终端设备的特点。
SIP 自身也不提供服务质量 (QoS)，它与负责语音质量的资源预留协议 (RSVP) 互操作。
它还与若干个其他协议进行协作，包括负责定位的轻型目录访问协议 (LDAP)、负责身份验证的远程身份验证拨入用户服务 (RADIUS) 以及负责实时传输的 RTP 等多个协议。
SIP 的一个重要特点是它不定义要建立的会话的类型，而只定义应该如何管理会话。
有了这种灵活性，也就意味着SIP可以用于众多应用和服务中，包括交互式游戏、音乐和视频点播以及语音、视频和 Web 会议。
SIP 消息是基于文本的，因而易于读取和调试。
新服务的编程更加简单，对于设计人员而言更加直观。
Network Working Group J. Rosenberg Request for Comments: 3263 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. June 2002 Session Initiation Protocol (SIP): Locating SIP ServersStatus of this MemoThis document specifies an Internet standards track protocol for the Internet 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.Copyright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved.AbstractThe Session Initiation Protocol (SIP) uses DNS procedures to allow a client to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the next hop to contact. It also uses DNS to allow a server to send a response to a backup client if the primary client has failed. This document describes those DNS procedures in detail.Table of Contents1 Introduction (2)2 Problems DNS is Needed to Solve (2)3 Terminology (5)4 Client Usage (5)4.1 Selecting a Transport Protocol (6)4.2 Determining Port and IP Address (8)4.3 Details of RFC 2782 Process (9)4.4 Consideration for Stateless Proxies (10)5 Server Usage (11)6 Constructing SIP URIs (12)7 Security Considerations (12)8 The Transport Determination Application (13)9 IANA Considerations (14)10 Acknowledgements (14)11 Normative References (15)12 Informative References (15)Rosenberg & Schulzrinne Standards Track [Page 1]13 Authors’ Addresses (16)14 Full Copyright Statement (17)1 IntroductionThe Session Initiation Protocol (SIP) (RFC 3261 [1]) is a client-server protocol used for the initiation and management ofcommunications sessions between users. SIP end systems are calleduser agents, and intermediate elements are known as proxy servers. A typical SIP configuration, referred to as the SIP "trapezoid", isshown in Figure 1. In this diagram, a caller in domain A (UA1)wishes to call Joe in domain B (joe@B). To do so, it communicateswith proxy 1 in its domain (domain A). Proxy 1 forwards the request to the proxy for the domain of the called party (domain B), which is proxy 2. Proxy 2 forwards the call to the called party, UA 2.As part of this call flow, proxy 1 needs to determine a SIP serverfor domain B. To do this, proxy 1 makes use of DNS procedures, using both SRV [2] and NAPTR [3] records. This document describes thespecific problems that SIP uses DNS to help solve, and provides asolution.2 Problems DNS is Needed to SolveDNS is needed to help solve two aspects of the general call flowdescribed in the Introduction. The first is for proxy 1 to discover the SIP server in domain B, in order to forward the call for joe@B.The second is for proxy 2 to identify a backup for proxy 1 in theevent it fails after forwarding the request.For the first aspect, proxy 1 specifically needs to determine the IP address, port, and transport protocol for the server in domain B.The choice of transport protocol is particularly noteworthy. Unlike many other protocols, SIP can run over a variety of transportprotocols, including TCP, UDP, and SCTP. SIP can also use TLS.Currently, use of TLS is defined for TCP only. Thus, clients need to be able to automatically determine which transport protocols areavailable. The proxy sending the request has a particular set oftransport protocols it supports and a preference for using thosetransport protocols. Proxy 2 has its own set of transport protocols it supports, and relative preferences for those transport protocols. All proxies must implement both UDP and TCP, along with TLS over TCP, so that there is always an intersection of capabilities. Some formof DNS procedures are needed for proxy 1 to discover the availabletransport protocols for SIP services at domain B, and the relativepreferences of those transport protocols. Proxy 1 intersects itslist of supported transport protocols with those of proxy 2 and then chooses the protocol preferred by proxy 2.Rosenberg & Schulzrinne Standards Track [Page 2]............................ .............................. . . . . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |------------- | Proxy | . . | 1 | . . | 2 | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | | . . | | . . | UA 1 | . . | UA 2 | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . ............................ .............................. Figure 1: The SIP trapezoidIt is important to note that DNS lookups can be used multiple timesthroughout the processing of a call. In general, an element thatwishes to send a request (called a client) may need to perform DNSprocessing to determine the IP address, port, and transport protocol of a next hop element, called a server (it can be a proxy or a useragent). Such processing could, in principle, occur at every hopbetween elements.Since SIP is used for the establishment of interactive communications services, the time it takes to complete a transaction between acaller and called party is important. Typically, the time from when the caller initiates a call until the time the called party isalerted should be no more than a few seconds. Given that there canbe multiple hops, each of which is doing DNS lookups in addition toother potentially time-intensive operations, the amount of timeavailable for DNS lookups at each hop is limited.Scalability and high availability are important in SIP. SIP services scale up through clustering techniques. Typically, in a realisticversion of the network in Figure 1, proxy 2 would be a cluster ofhomogeneously configured proxies. DNS needs to provide the ability Rosenberg & Schulzrinne Standards Track [Page 3]for domain B to configure a set of servers, along with prioritization and weights, in order to provide a crude level of capacity-based load balancing.SIP assures high availability by having upstream elements detectfailures. For example, assume that proxy 2 is implemented as acluster of two proxies, proxy 2.1 and proxy 2.2. If proxy 1 sends a request to proxy 2.1 and the request fails, it retries the request by sending it to proxy 2.2. In many cases, proxy 1 will not know which domains it will ultimately communicate with. That information would be known when a user actually makes a call to another user in thatdomain. Proxy 1 may never communicate with that domain again afterthe call completes. Proxy 1 may communicate with thousands ofdifferent domains within a few minutes, and proxy 2 could receiverequests from thousands of different domains within a few minutes.Because of this "many-to-many" relationship, and the possibly longintervals between communications between a pair of domains, it is not generally possible for an element to maintain dynamic availabilitystate for the proxies it will communicate with. When a proxy getsits first call with a particular domain, it will try the servers inthat domain in some order until it finds one that is available. The identity of the available server would ideally be cached for someamount of time in order to reduce call setup delays of subsequentcalls. The client cannot query a failed server continuously todetermine when it becomes available again, since this does not scale. Furthermore, the availability state must eventually be flushed inorder to redistribute load to recovered elements when they come back online.It is possible for elements to fail in the middle of a transaction.For example, after proxy 2 forwards the request to UA 2, proxy 1fails. UA 2 sends its response to proxy 2, which tries to forward it to proxy 1, which is no longer available. The second aspect of theflow in the introduction for which DNS is needed, is for proxy 2 toidentify a backup for proxy 1 that it can send the response to. This problem is more realistic in SIP than it is in other transactionalprotocols. The reason is that some SIP responses can take a longtime to be generated, because a human user frequently needs to beconsulted in order to generate that response. As such, it is notuncommon for tens of seconds to elapse between a call request and its acceptance.Rosenberg & Schulzrinne Standards Track [Page 4]3 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 [4] and indicate requirement levels for compliant SIP implementations.4 Client UsageUsage of DNS differs for clients and for servers. This sectiondiscusses client usage. We assume that the client is stateful(either a User Agent Client (UAC) or a stateful proxy). Statelessproxies are discussed in Section 4.4.The procedures here are invoked when a client needs to send a request to a resource identified by a SIP or SIPS (secure SIP) URI. This URI can identify the desired resource to which the request is targeted(in which case, the URI is found in the Request-URI), or it canidentify an intermediate hop towards that resource (in which case,the URI is found in the Route header). The procedures defined herein no way affect this URI (i.e., the URI is not rewritten with theresult of the DNS lookup), they only result in an IP address, portand transport protocol where the request can be sent. RFC 3261 [1]provides guidelines on determining which URI needs to be resolved in DNS to determine the host that the request needs to be sent to. Insome cases, also documented in [1], the request can be sent to aspecific intermediate proxy not identified by a SIP URI, but rather, by a hostname or numeric IP address. In that case, a temporary URI, used for purposes of this specification, is constructed. That URI is of the form sip:<proxy>, where <proxy> is the FQDN or numeric IPaddress of the next-hop proxy. As a result, in all cases, theproblem boils down to resolution of a SIP or SIPS URI in DNS todetermine the IP address, port, and transport of the host to whichthe request is to be sent.The procedures here MUST be done exactly once per transaction, where transaction is as defined in [1]. That is, once a SIP server hassuccessfully been contacted (success is defined below), allretransmissions of the SIP request and the ACK for non-2xx SIPresponses to INVITE MUST be sent to the same host. Furthermore, aCANCEL for a particular SIP request MUST be sent to the same SIPserver that the SIP request was delivered to.Because the ACK request for 2xx responses to INVITE constitutes adifferent transaction, there is no requirement that it be deliveredto the same server that received the original request (indeed, ifthat server did not record-route, it will not get the ACK).Rosenberg & Schulzrinne Standards Track [Page 5]We define TARGET as the value of the maddr parameter of the URI, ifpresent, otherwise, the host value of the hostport component of theURI. It identifies the domain to be contacted. A description of the SIP and SIPS URIs and a definition of these parameters can be foundin [1].We determine the transport protocol, port and IP address of asuitable instance of TARGET in Sections 4.1 and 4.2.4.1 Selecting a Transport ProtocolFirst, the client selects a transport protocol.If the URI specifies a transport protocol in the transport parameter, that transport protocol SHOULD be used.Otherwise, if no transport protocol is specified, but the TARGET is a numeric IP address, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. Similarly, if no transport protocol is specified,and the TARGET is not numeric, but an explicit port is provided, the client SHOULD use UDP for a SIP URI, and TCP for a SIPS URI. This is because UDP is the only mandatory transport in RFC 2543 [6], and thus the only one guaranteed to be interoperable for a SIP URI. It wasalso specified as the default transport in RFC 2543 when no transport was present in the SIP URI. However, another transport, such as TCP, MAY be used if the guidelines of SIP mandate it for this particularrequest. That is the case, for example, for requests that exceed the path MTU.Otherwise, if no transport protocol or port is specified, and thetarget is not a numeric IP address, the client SHOULD perform a NAPTR query for the domain in the URI. The services relevant for the task of transport protocol selection are those with NAPTR service fieldswith values "SIP+D2X" and "SIPS+D2X", where X is a letter thatcorresponds to a transport protocol supported by the domain. Thisspecification defines D2U for UDP, D2T for TCP, and D2S for SCTP. We also establish an IANA registry for NAPTR service name to transportprotocol mappings.These NAPTR records provide a mapping from a domain to the SRV record for contacting a server with the specific transport protocol in theNAPTR services field. The resource record will contain an emptyregular expression and a replacement value, which is the SRV recordfor that particular transport protocol. If the server supportsmultiple transport protocols, there will be multiple NAPTR records,each with a different service value. As per RFC 2915 [3], the client discards any records whose services fields are not applicable. Forthe purposes of this specification, several rules are defined. Rosenberg & Schulzrinne Standards Track [Page 6]First, a client resolving a SIPS URI MUST discard any services thatdo not contain "SIPS" as the protocol in the service field. Theconverse is not true, however. A client resolving a SIP URI SHOULDretain records with "SIPS" as the protocol, if the client supportsTLS. Second, a client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X thatindicate transport protocols supported by the client. The NAPTRprocessing as described in RFC 2915 will result in the discovery ofthe most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. It will also allow the client to discover if TLS is available and its preferencefor its usage.As an example, consider a client that wishes to resolvesip:user@. The client performs a NAPTR query for thatdomain, and the following NAPTR records are returned:; order pref flags service regexp replacementIN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._.This indicates that the server supports TLS over TCP, TCP, and UDP,in that order of preference. Since the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of_sip._. That lookup would return:;; Priority Weight Port TargetIN SRV 0 1 5060 IN SRV 0 2 5060 If a SIP proxy, redirect server, or registrar is to be contactedthrough the lookup of NAPTR records, there MUST be at least threerecords - one with a "SIP+D2T" service field, one with a "SIP+D2U"service field, and one with a "SIPS+D2T" service field. The records with SIPS as the protocol in the service field SHOULD be preferred(i.e., have a lower value of the order field) above records with SIP as the protocol in the service field. A record with a "SIPS+D2U"service field SHOULD NOT be placed into the DNS, since it is notpossible to use TLS over UDP.It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query (i.e., above). However, for backwards compatibility with RFC 2543, a domain MUST maintain SRV records for the domain of the original query, even if the NAPTR record is in a different domain. As an example, eventhough the SRV record for TCP is _sip._, there MUSTalso be an SRV record at _sip._.Rosenberg & Schulzrinne Standards Track [Page 7]RFC 2543 will look up the SRV records for the domain directly. If these do not exist because the NAPTR replacement points to adifferent domain, the client will fail.For NAPTR records with SIPS protocol fields, (if the server is using a site certificate), the domain name in the query and the domain name in the replacement field MUST both be valid based on the sitecertificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to containreplacement values in a different domain, and the client could notvalidate that this was the desired behavior or the result of anattack.If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each.Queries are done using the service identifier "_sip" for SIP URIs and "_sips" for SIPS URIs. A particular transport is supported if thequery is successful. The client MAY use any transport protocol itdesires which is supported by the server.This is a change from RFC 2543. It specified that a client would lookup SRV records for all transports it supported, and merge the priority values across those records. Then, it would choose themost preferred record.If no SRV records are found, the client SHOULD use TCP for a SIPSURI, and UDP for a SIP URI. However, another transport protocol,such as TCP, MAY be used if the guidelines of SIP mandate it for this particular request. That is the case, for example, for requests that exceed the path MTU.4.2 Determining Port and IP AddressOnce the transport protocol has been determined, the next step is to determine the IP address and port.If TARGET is a numeric IP address, the client uses that address. If the URI also contains a port, it uses that port. If no port isspecified, it uses the default port for the particular transportprotocol.If the TARGET was not a numeric IP address, but a port is present in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which canbe contacted at the specific port from the URI and transport protocol Rosenberg & Schulzrinne Standards Track [Page 8]determined previously. The client SHOULD try the first record. Ifan attempt should fail, based on the definition of failure in Section 4.3, the next SHOULD be tried, and if that should fail, the nextSHOULD be tried, and so on.This is a change from RFC 2543. Previously, if the port wasexplicit, but with a value of 5060, SRV records were used. Now, A or AAAA records will be used.If the TARGET was not a numeric IP address, and no port was presentin the URI, the client performs an SRV query on the record returnedfrom the NAPTR processing of Section 4.1, if such processing wasperformed. If it was not, because a transport was specifiedexplicitly, the client performs an SRV query for that specifictransport, using the service identifier "_sips" for SIPS URIs. For a SIP URI, if the client wishes to use TLS, it also uses the serviceidentifier "_sips" for that specific transport, otherwise, it uses"_sip". If the NAPTR processing was not done because no NAPTRrecords were found, but an SRV query for a supported transportprotocol was successful, those SRV records are selected. Irregardless of how the SRV records were determined, the procedures of RFC 2782,as described in the section titled "Usage rules" are followed,augmented by the additional procedures of Section 4.3 of thisdocument.If no SRV records were found, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IPaddresses, each of which can be contacted using the transportprotocol determined previously, at the default port for thattransport. Processing then proceeds as described above for anexplicit port once the A or AAAA records have been looked up.4.3 Details of RFC 2782 ProcessRFC 2782 spells out the details of how a set of SRV records aresorted and then tried. However, it only states that the clientshould "try to connect to the (protocol, address, service)" withoutgiving any details on what happens in the event of failure. Thosedetails are described here for SIP.For SIP requests, failure occurs if the transaction layer reports a503 error response or a transport failure of some sort (generally,due to fatal ICMP errors in UDP or connection failures in TCP).Failure also occurs if the transaction layer times out without everhaving received any response, provisional or final (i.e., timer B or timer F in RFC 3261 [1] fires). If a failure occurs, the clientSHOULD create a new request, which is identical to the previous, but Rosenberg & Schulzrinne Standards Track [Page 9]has a different value of the Via branch ID than the previous (andtherefore constitutes a new SIP transaction). That request is sentto the next element in the list as specified by RFC 2782.4.4 Consideration for Stateless ProxiesThe process of the previous sections is highly stateful. When aserver is contacted successfully, all retransmissions of the request for the transaction, as well as ACK for a non-2xx final response, and CANCEL requests for that transaction, MUST go to the same server.The identity of the successfully contacted server is a form oftransaction state. This presents a challenge for stateless proxies, which still need to meet the requirement for sending all requests in the transaction to the same server.The problem is similar, but different, to the problem of HTTPtransactions within a cookie session getting routed to differentservers based on DNS randomization. There, such distribution is not a problem. Farms of servers generally have common back-end datastores, where the session data is stored. Whenever a server in thefarm receives an HTTP request, it takes the session identifier, ifpresent, and extracts the needed state to process the request. Arequest without a session identifier creates a new one. The problem with stateless proxies is at a lower layer; it is retransmittedrequests within a transaction that are being potentially spreadacross servers. Since none of these retransmissions carries a"session identifier" (a complete dialog identifier in SIP terms), anew dialog would be created identically at each server. This could, for example result in multiple phone calls to be made to the samephone. Therefore, it is critical to prevent such a thing fromhappening in the first place.The requirement is not difficult to meet in the simple case wherethere were no failures when attempting to contact a server. Whenever the stateless proxy receives the request, it performs the appropriate DNS queries as described above. However, the procedures of RFC 2782 are not guaranteed to be deterministic. This is because records that contain the same priority have no specified order. The statelessproxy MUST define a deterministic order to the records in that case, using any algorithm at its disposal. One suggestion is toalphabetize them, or, more generally, sort them by ASCII-compatibleencoding. To make processing easier for stateless proxies, it isRECOMMENDED that domain administrators make the weights of SRVrecords with equal priority different (for example, using weights of 1000 and 1001 if two servers are equivalent, rather than assigningboth a weight of 1000), and similarly for NAPTR records. If thefirst server is contacted successfully, the proxy can remain Rosenberg & Schulzrinne Standards Track [Page 10]stateless. However, if the first server is not contactedsuccessfully, and a subsequent server is, the proxy cannot remainstateless for this transaction. If it were stateless, aretransmission could very well go to a different server if the failed one recovers between retransmissions. As such, whenever a proxy does not successfully contact the first server, it SHOULD act as astateful proxy.Unfortunately, it is still possible for a stateless proxy to deliver retransmissions to different servers, even if it follows therecommendations above. This can happen if the DNS TTLs expire in the middle of a transaction, and the entries had changed. This isunavoidable. Network implementors should be aware of thislimitation, and not use stateless proxies that access DNS if thiserror is deemed critical.5 Server UsageRFC 3261 [1] defines procedures for sending responses from a serverback to the client. Typically, for unicast UDP requests, theresponse is sent back to the source IP address where the request came from, using the port contained in the Via header. For reliabletransport protocols, the response is sent over the connection therequest arrived on. However, it is important to provide failoversupport when the client element fails between sending the request and receiving the response.A server, according to RFC 3261 [1], will send a response on theconnection it arrived on (in the case of reliable transportprotocols), and for unreliable transport protocols, to the sourceaddress of the request, and the port in the Via header field. Theprocedures here are invoked when a server attempts to send to thatlocation and that response fails (the specific conditions aredetailed in RFC 3261). "Fails" is defined as any closure of thetransport connection the request came in on before the response canbe sent, or communication of a fatal error from the transport layer. In these cases, the server examines the value of the sent-byconstruction in the topmost Via header. If it contains a numeric IP address, the server attempts to send the response to that address,using the transport protocol from the Via header, and the port fromsent-by, if present, else the default for that transport protocol.The transport protocol in the Via header can indicate "TLS", whichrefers to TLS over TCP. When this value is present, the server MUST use TLS over TCP to send the response.Rosenberg & Schulzrinne Standards Track [Page 11]If, however, the sent-by field contained a domain name and a portnumber, the server queries for A or AAAA records with that name. It tries to send the response to each element on the resulting list ofIP addresses, using the port from the Via, and the transport protocol from the Via (again, a value of TLS refers to TLS over TCP). As inthe client processing, the next entry in the list is tried if the one before it results in a failure.If, however, the sent-by field contained a domain name and no port,the server queries for SRV records at that domain name using theservice identifier "_sips" if the Via transport is "TLS", "_sip"otherwise, and the transport from the topmost Via header ("TLS"implies that the transport protocol in the SRV query is TCP). Theresulting list is sorted as described in [2], and the response issent to the topmost element on the new list described there. If that results in a failure, the next entry on the list is tried.6 Constructing SIP URIsIn many cases, an element needs to construct a SIP URI for inclusion in a Contact header in a REGISTER, or in a Record-Route header in an INVITE. According to RFC 3261 [1], these URIs have to have theproperty that they resolve to the specific element that insertedthem. However, if they are constructed with just an IP address, for example:sip:1.2.3.4then should the element fail, there is no way to route the request or response through a backup.SRV provides a way to fix this. Instead of using an IP address, adomain name that resolves to an SRV record can be used:sip:The SRV records for a particular target can be set up so that thereis a single record with a low value for the priority field(indicating the preferred choice), and this record points to thespecific element that constructed the URI. However, there areadditional records with higher values of the priority field thatpoint to backup elements that would be used in the event of failure. This allows the constraint of RFC 3261 [1] to be met while allowingfor robust operation.Rosenberg & Schulzrinne Standards Track [Page 12]。
