转载自博客：《SIP扩展与相关RFC介绍》。本文介绍了除SIP基础RFC3261外的所有扩展RFC都有哪些，以及这些RFC都是干什么的，为什么要定义这些扩展RFC。
原文地址：http://blog.csdn.net/kafeiwuzhuren/article/details/7257791
SIP扩展综述
SIP扩展可分成几个类型：
- SIP能力的某些欠缺；
- 业务能力增强，如IM、REFER；
- 安全性、Qos能力增强；
- SIP适用于传统电信网络应用模型的能力，包括IMS专用扩展；
1 事件通知 - RFC3265
-增加了消息SUBSCRIBE、NOTIFY，SIP头Allow-Events、Subscription State，响应202Accept、489等；该机制独立于dialog；
-SUBSCRIBE发起订阅，订阅拥有状态（激活、等待、终止）；收到2xx响应或NOTIFY消息时创建一个对话（与INVITE类似的对话），后续SUBSCRIBE与NOTIFY在对话中传递；对话有一个expire时间，超时前需要重新订阅；SUBSCRIBE的超时及取消机制与REGISTER类似；
-事件包，一种扩展机制；事件模板包，一种特殊的事件包；事件包定义自己的MIME类型；在NOTIFY的payload中携带状态信息；
2 状态发布 - RFC3903
-PUBLISH方法，用于client主动向状态代理发布状态，使用payload携带；
-Event head；
3 IM - RFC3428、RFC3862
-两种消息交互方式：页面模式与session模式；
-页面模式：每个消息是独立的，与它之前或之后的IM在protocol层无关；RFC3428定义的MESSAGE消息用于其实现，消息内容置于payload中，MIME正文填写text/plain；RFC3862定义了与SIP客户间的互操作，MIME使用message/cpim；
-Session模式：使用SIP建立session，之后使用MSRP来携带消息内容；
4 PRACK - RFC3262
-与传统电信网络中呼叫建立前信令对应的SIP临时消息，如180，在某些场景下不可缺少，故增加了临时消息可靠传输能力——对SIP基本状态机会产生什么影响？
-仅适用于INVITE的临时响应；
-本扩展的标识100rel；
-RSeq头，类似CSeq；PRACK的RACK头，依次包括RSeq与CSeq头的值；
-不能对100 Trying使用可靠传输机制，因为100只是用于终止INVITE等的重传；
5 UPDATE - RFC3311
-用于不影响当前dialog情况下更新会话描述，仅用于由INVITE产生的dialog，可在dialog的早期阶段和确定阶段发送，但不能在dialog建立前发送——如创建dialog的临时响应发送、应答前；
-早期阶段（early INVITE-initiated）：client获得1xx（非100）应答后，dialog可能在早期阶段后直接终结；
-确定阶段：得到2XX应答后；
-UPDATE仅用于dialog；
-UPDATE携带SDP offer，其2xx应答携带answer；
6 Precondition - RFC3312
-用于session建立前的资源预留，对应SIP扩展标签precondition；
-Caller在初始SDP中指明本次会话的约束，called对其响应（IMS中好像使用183），但既不建立会话也不提交给用户；在主被叫已知前提已经获得满足时主叫方再发送一个新的SDP offer，被叫方发送answer后session才建立；这在IMS中使用UPDATE；
-SDP中的约束信息如：a=des:qos sptimal e2e send
7 REFER - RFC3515
-发送者指引接收者去访问REFER请求中所标识的资源；Refer-To、Referred-By头域，202 Accepted响应；
-REFER与NOTIFY综合使用，实现呼叫转移功能；NOTIFY被用于Transferee通知Transferor第二个呼叫的状态；从NOTIFY看出，REFER创建了一个订阅，该订阅不带expire参数，expire值由接收方决定；发起方可以发送SUBSCRIBE来延长该时间；由事件通知框架的要求，接收到REFER后需要立即产生和发送NOTIFY；
-呼转的类型：
1）Unattended transfer，即盲转blind transfer，Transferor与Transferee之间存在一个呼叫，但与Transfer Target之间不存在呼叫；
可能的过程：Transferor向Transferee发送REFER，Transferee回送202 Accepted；Transferee向Transferor发NOTIFY(100 Trying)，并向Transfer Target发起INVITE，在收到200 OK时使用NOTIFY(100 OK)通知Transferor，然后Transferor或Transferee任一方BYE挂断primary call；
2）Attended transfer，即supervised transfer，Transferor与Transferee及Transfer Target间都存在呼叫；
-成功的呼转并不改变Transferor与Transferee间的媒体流，并不影响原有的session；任一方都可以在REFER后通过发送BYE消息来结束原有的session；
8 Path 头域 – RFC3327
-Path扩展可用于记录REGISTER从UA到registrar所经过的路径，即经过的proxy；IMS中用于归属网络向UA发请求；Path语法与record-route头类似；扩展标识“path”；
-如果UA支持path扩展，如果proxy希望发往UA的任何后续请求都通过自己或某个URI，则它在UA的REGISTER中加入一个path头记录该URI；registrar记录path及AOR及contact，在后续发往UA的请求中，path记录的URI被放到route头中，以使消息发送经过所指定的URI；
9 Private - RFC3325
-用于可信网络中判断终端用户、系统的身份；及提供终端用户指示其隐私要求的机制；
10 信令压缩 - RFC3486
-RFC3320，信令压缩规范，将文本信令压缩成二进制流；
-URI参数 comp=SigComp
-使用request URI与via、route头，指示节点的压缩支持；
11 INFO - RFC2976
-提供一种在sip session执行建立操作开始后，独立于sip信令路径发送session相关“控制”信息的机制；INFO的发送时机与UPDATE一样；
12 SIP-T – RFC3372
-在SIP消息体中包装ISUP消息；使用INFO(RFC 2976)消息传输呼叫中的信令；
13 SIP消息分段 – RFC3420
-MIME类型message/sipfrag；
14 SIP-Sec-Agree – RFC3329
-安全协商，允许UA与其第一跳服务器之间就后续通信中所使用的安全机制进行协商；
15 Media authorization – RFC3313
-P-Media-Authorization
16 服务路由发现 - RFC3608
-UA可以在发出的请求中包含一系列Route头，来使请求经过特定的proxy，从而获得相应服务；
-Service-Route头，用于UA学习服务路由；registrar在响应REGISTER的200 OK中使用Service-Route头，从而提供给UA；
17 IMS扩展头 – RFC3455
-专用于3GPP IMS；
-P-Charging-Vector，IMS计费ID（ICID）和相关接入网计费信息；
-P-Charging-Function-Address，归属网络中计费功能的地址；
-P-Visited-Network-ID，注册时传递拜访网络的标识；
-P-Access-Network-Info，拜访网络向归属网络传递信息；
-P-Called-Party-ID，
-P-Associated-URI，与用户相关联的其他URI；
18 其他SIP相关RFC介绍
1）RFC3665
-Session Initiation Protocol (SIP) Basic Call Flow Examples
2）3PCC - RFC3725
-3rd party call control in sip
3）SDP – RFC2327 RFC3264 RFC4566
- 新的SDP标准是RFC4566(2006.7)，替换了RFC2327与RFC3266；
4）RFC3960
- Early Media and Ringing Tone Generation in the Session Initiation
5）服务器定位 –RFC3263
-Session Initiation Protocol (SIP): Locating SIP Servers
6）RFC2806
-URLS for telephone calls
7）RFC3108
-Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
8）RFC3204
-MIME media types for ISUP and QSIG Objects
9）RFC3323
-A Privacy Mechanism for SIP
10）RFC3326
-The Reason Header Field
相关规范列表
-RFC 3261: SIP Session initiation protocol.
-RFC 3263: Session Initiation Protocol (SIP): Locating SIP Servers.
-RFC 2327: SDP Session Description Protocol.
-RFC 3420: Internet Media Type message/ipfrag.
-RFC 2976: The SIP INFO Method
-RFC 2806: URLS for telephone calls
-RFC 3108: Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections
-RFC 3204: MIME media types for ISUP and QSIG Objects
-RFC 3262: Reliability of Provisional Responses in SIP
-RFC 3264: An Offer/Answer Model with the Session Description Protocol (SDP)
-RFC 3265: SIP-Specific Event Notification
-RFC 3310: HTTP Digest Authentication Using AKA
-RFC 3311: The SIP UPDATE method
-RFC 3313: Media Authorization
-RFC 3323: A Privacy Mechanism for SIP
-RFC 3325: Asserted Identity within Trusted Networks
-RFC 3326: The Reason Header Field
-RFC 3327: Extension Header Field for Registering Non-Adjacent Contacts (Path)
-RFC 3372 : SIP for Telephones (SIP-T): Context and Architectures
-RFC 3428: The SIP MESSAGE method
-RFC 3455: Private Header Extensions to SIP for 3GPP
-RFC 3515: The SIP REFER method
-RFC 3581: An Extension to SIP for Symmetric Response Routing.
-RFC 3608: SIP Extension Header Field for Service Route Discovery During Registration
-RFC 3842: A Message Summary and Message Waiting Indication Event Package for SIP
-RFC 3856: SIP Extensions for Presence
-RFC 3891: The SIP "Replaces" Header
-RFC 3892: The SIP Referred-By Mechanism
-RFC 3959: early session disposition type for SDP
-RFC 4028: Session Timers in SIP
-ITU-T T.38 Annex D (04/2004) and RFC 3362 for support of T.38 in SIP
-IETF draft-levy-sip-diversion-08.
-draft-ietf-sipping-kpml-07.
885
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
