<4D F736F F F696E74202D20CDF8C2E7D0ADD2E9B7D6CEF6D3EBCAB5CFD D >

Size: px

Start display at page:

Download "<4D F736F F F696E74202D20CDF8C2E7D0ADD2E9B7D6CEF6D3EBCAB5CFD D >"

枪倪
4 years ago
Views:

1 北京邮电大学 BEIJING UNIVERSITY OF POSTS AND TELECOMMUNICATIONS 协议分析协议扩展分析李静林协议扩展机制与传统 Telephony 业务互通的努力增强的媒体协商能力构建支持业务处理能力的基础结构目的加深对协议基本处理方法的理解理解协议扩展方式与方法协议扩展的方法与原则协议扩展的原因与目的协议扩展原则满足扩展需求符合基本协议处理机制和要求 Dialog Session 兼容已经存在的系统协议扩展方法增加消息头增加消息头的参数增加消息实现特定的语义满足特定的语法规则 + 时序与传统 Telephony 业务互通的努力 IETF Session Initiation Protocol for Telephones 俗称 -T ITU-T Q TRQ2815 俗称 -I 与传统 Telephony 业务互通的总原则 Translation Encapsulation 与传统 Telephony 业务互通的场景 IP SP TE TE Network Translation ISUP message mapping ISUP parameter- header mapping 消息映射发起呼叫振铃连接建立 Ringing OK() ISUP 参数映射主叫号码被叫号码 Contact / From Request-URI / To ISUP Caller Party Number Called Party Number TE 与传统 Telephony 业务互通的场景 Bridging SP1 Network Encapsulation 'Transparent' Transit of ISUP Messages 与 ISUP 协议不可能一一映射如果为了保证 SP1-SP2 之间业务的无缝互通, 只有 SP1 发出的 ISUP 消息能够透传到 SP2 将 ISUP 消息封装在消息体里 Content-Type: application/isup SP2 TE 1

2 与传统 Telephony 业务互通的需求 Reliable Transmission of Provisional Responses( 临时响应的可靠传输 ) Early Media( 早期媒体 ) Mid-Call s which do not change state( 不改变状态的 Mid-Call 传输 ) OverlapSignalling( 重叠信令 ) Transmission of Dual-Tone Multifrequency (DTMF) Information(DTMF 音传输 ) RFC3398-Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol () Mapping 5. Mechanisms Required 需求的分析 T 20s 可靠的呼叫进展通知, 保证侧不会超时如何传递呼叫中事件? 64 T1 CPG 需求的分析 ( 续 )? 183 大多数终端是在收到之后才开始向应用播放收到的 RTP 流不然如何决定哪些媒体流应该被播放不然如何决定 RTP 流状态报告应该如何回复 Reliable Provisional Responses EarlyMedia 扩展需求扩展目的传递可靠的呼叫进展传递被叫侧的媒体描述扩展消息 PR 为 1xx 响应提供消息确认扩展消息头 RSeq/ 保证 PR 与对应的 1xx 匹配 1xx 响应扩展消息头 :RSeq PR 请求扩展消息头 : 扩展消息头参数 rel 保证 UAS 知道 UAC 是否要求 1xx 可靠传输保证 UAC 知道 UAS 返回的 1xx 是需要可靠传输的 UAC 发送携带 Require:rel UAS 发送的第一个 1xx 必须是可靠传输的临时响应 1xx 必须携带 Require:rel UAC 发送只携带 Supported:rel UAS 可以根据自身需要决定是否需要发送可靠的临时响应 UAC 收到的 1xx 携带 Require:rel, 则意味着需要可靠传输兼容已有系统已有系统不支持 PR 怎么办? UAC 可能不支持发送 PR 消息 UAS 可能不支持发送可靠的 1xx 和接收 PR 为了保证兼容 UAS 不支持可靠传输的临时响应 UAC 发送的携带了 Require:rel UAS 返回 420 (Bad Extension) 响应, 并携带 Unsupported:rel UAC 发送的仅携带 Supported:rel UAS 正常处理 UAC 不支持可靠传输的临时响应 UAC 不支持可靠传输的临时响应, 则不会携带 rel UAS 不会返回需要可靠传输的临时响应 UAC 支持可靠传输的临时响应, 则必须携带 rel 符合处理机制满足处理机制 1xx 处理机制保持不变 PR+ 响应组成新的为什么不仿照? 的分类满足 Dialog 处理机制可靠传输的 1xx 将创建 Dialog Dialog 不是 -2xx 建立的吗?(Dialog 的定义 ) 可靠传输的 1xx 是对的确认保证了请求之后的其他请求都将是 Dialog 内请求 1xx 中携带 To Tag PR 属于 Dialog 内请求 PR 具有与相同的 Dialog 信息 (From TO CallID) PR 的处理满足 UA/ 对 Dialog 内请求的处理规则 (UA 处理, 转发 ) 2

3 符合处理机制满足 Session 处理机制 (-) 如果携带, 可靠的 1xx 可以选择携带不携带则该响应仅仅是防止超时如果不携带, 则可靠的 1xx 必须携带强制要求如果可靠的 1xx 携带, 则 PR 必须携带 PR 是 1xx 的最终响应如果 -1xx 完成了 -,PR-PR 可以完成进一步的 - PR-PR 是可靠传输的如果可靠的 1xx 携带, 则必须建立 Session 一次 - 结束了 Early Session 不影响 RFC3261 的 Session 处理机制总结 PR Dialog Supported:rel Require:rel,RSeq PR PR Supported:rel Require:rel,RSeq PR PR Session 满足 Mid-Call 扩展需求扩展目的传递呼叫建立之后的 Mid-Call 事件这种事件仅需要应用理解, 与协议无关为什么不用 re-? 修改状态扩展新的请求 :INFO 兼容已有系统 INFO 是 End-End 的请求, 不影响路径中的状态 INFO 没有任何扩展的消息头与消息头参数 INFO 满足一切标准请求 / 响应的处理规范 End-End 路径中的任何一点不需要理解 INFO, 只需要按照标准请求转发就可以了满足处理机制 INFO- 响应组成新的 INFO 为 Dialog 内部总结 INFO CPG Supported:rel Require:rel,RSeq PR PR INFO Supported:rel Require:rel,RSeq PR PR INFO CPG 关于 INFO 需要说明的一些问题 INFO 制定在 RFC3261 之前, 其中的一部分规则已经不适用于 RFC3261 了 RFC2543:INFO 可以被 CANCEL RFC3261: 不建议对以外的请求发 CANCEL INFO 不应该被用于 DTMF 的传递 DTMF 由 RFC2833 规定的 RTP/RTCP 中传递 INFO 和 MESSAGE 有什么区别? INFO 是存在于建立的 Dialog 中的 MESSAGE 可以不属于 Dialog INFO 和 re- 有什么区别? INFO 是不影响传递路径中各个实体的状态 Re- 会影响状态与互通相关的基本 RFC RFC2833-RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC2976- The INFO Method RFC3262-Reliability of Provisional Responses in the Session Initiation Protocol () RFC3372-Session Initiation Protocol for Telephones (-T): Context and Architectures RFC3398-Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol () Mapping RFC3578-Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol () RFC3666- Session Initiation Protocol () Public Switched Telephone Network () Call Flows RFC3959-The Early Session Disposition Type for the Session Initiation Protocol () RFC3960-Early Media and Ringing Tone Generation in the Session Initiation Protocol () 3

4 增强的媒体协商能力基本媒体协商媒体协商的内容 : 会话类型描述媒体协商的要求 :- 模型协议对媒体协商的支持 : 需要使用可靠传输的消息媒体协商能力的需求多媒体业务 : 在一个对话中可能会支持多条媒体流对话的两方可能随时修改媒体流的数量和类型媒体的修改可以是主叫与被叫任意一方发起媒体的修改可以在呼叫的建立前, 建立中, 建立后的任何一个时间段发生媒体协商的应用场景呼叫建立之前的早期媒体协商与呼叫建立同步的媒体协商呼叫建立之后的媒体协商呼叫建立时的媒体协商呼叫建立过程中可以由主叫被叫任意一方发起媒体协商呼叫建立之后的媒体协商呼叫建立之后可以由主叫被叫任意一方发起媒体重协商呼叫建立前的早期媒体协商 PR 主叫只能在 PR 的时候才能发起媒体重协商被叫被动发起媒体协商, 被叫不能发起媒体重协商 rel PR PR 扩展媒体协商能力扩展原因分析请求在收到最终响应之前不能再次发送 PR 只能由 1xx 可靠传输触发发送 UAS 只能返回响应, 的请求 - 响应机制导致除了三次握手, 只能由请求发起, 响应返回扩展目的支持呼叫建立之前主叫和被叫任意一方发起媒体重协商扩展新的请求 UPDATE 在任何时机由会话双方中的任意一方发起媒体重协商兼容性考虑已有系统不支持 UPDATE 怎么办? 规定消息头参数请求的 Allow 消息头中应该携带 UPDATE 1xx 临时响应中 Allow 消息头可以携带 UPDATE 最终响应中 Allow 消息头应该携带 UPDATE 兼容性处理如果对端不支持 UPDATE 405 Method Not Allowed 405 响应的 Allow 消息头列举可以支持的请求符合协议对请求的一般处理规定对于 Call 建立之后的媒体重协商建议使用 re- 4

5 符合处理机制 UPDATE+ 响应组成新的 Dialog UPDATE 属于 Dialog 内请求 UPDATE 一定存在于可靠的临时响应建立的 EarlyDialog 内 UPDATE 具有与相同的 Dialog 信息 (From TO CallID) UPDATE 的处理满足 UA/ 对 Dialog 内请求的处理规则 (UA 处理, 转发 ) Session UPDATE 一定是发起 OK 一定是返回总结 UPDATE PR PR UPDATE UPDATE PR PR UPDATE UPDATE UPDATE 与 PR/1xx 有什么区别? 媒体协商相关的 RFCs RFC3311- UPDATE Method RFC3261- : Session Initiation Protocol RFC3262-Reliability of Provisional Responses in the Session Initiation Protocol () RFC3264-An / Model with the Session Description Protocol () 构建支持业务处理能力的基础结构协议对业务能力的扩展 RFC Specific Event Notification SUBSCRIBE/ RFC3515- Refer Method REFER SUBSCRIBE/ 网络实体可以订购另一个实体的资源或呼叫状态当订购内容改变, 则订购的实体会得到相应通知 Present REFER 第三方会话邀请 Call Transfer Conference Dialog Specific Event Notification 的模型 User Subscriber SUBSCRIBE Present Server Notifier 语义 SUBSCRIBE 内容订购订购内容通知语法规则 SUBSCRIBE+ 响应 new + 响应 new SUBSCRIBE 是 dialogcreating method 不创建 Session User 向 Present Server 订购用户注册状态 Present 业务 Dialog Refer Method 的模型 Agent REFER 202 Accepted Agent 语义 REFER 通知对端需要联系第三方联系进展通知语法规则 REFER+ 响应 new + 响应 new REFER 是 dialog-creating method 不创建 Session 向发出第三方邀请 Call Transfer 业务 5

6 协议扩展的讨论 INFO/PR/UPDATE 扩展的目的是什么完善协议会话处理能力 SUBSCRIBE//REFER/MESSAGE 扩展的目的是什么增强对特定业务需求的处理能力不是声称不支持业务的吗? 即便不是针对特定的业务, 那也是针对一类业务啊? just because it s there 协议扩展的方法与原则协议扩展的原因与目的协议扩展原则满足扩展需求符合基本协议处理机制和要求 Dialog Session 兼容已经存在的系统协议扩展方法增加消息头增加消息头的参数增加消息北京邮电大学 BEIJING UNIVERSITY OF POSTS AND TELECOMMUNICATIONS 协议分析总结如何全面的学习一个协议协议的产生与发展明确协议是什么理解协议的设计目的明确协议的设计目标协议基本分析协议的体系结构协议的基本规则了解协议做什么协议基础架构分析协议的设计原则协议的实现原则协议的控制模型明确协议怎么做明确协议为什么这么做协议扩展分析协议扩展目的协议扩展方法 1 协议的背景资料, 相关介绍, 原始协议浏览 2 协议规范的 Abstract 和 Introduction 1 协议规范浏览:Overview, Definitions 2 协议基本语义语法时序 1 协议深入阅读, 理解协议概念 2 总结协议的处理规则 3 回头看 1 协议的扩展应用 2 协议的扩展方法如何看待一个协议协议的历史观点协议设计的目的与目标协议的现实观点协议具体的应用位置, 扮演的角色, 起到的作用协议的设计观点协议的逻辑体系结构协议消息的语义语法时序协议的实现观点协议的物理实现层次协议的实现模型纯粹协议的观点单纯的特定协议组网混合协议的观点多协议融合的协议组网历史与现实的差异, 深刻理解协议的设计理念, 发展原因, 地位与作用设计与实现相辅相成, 互为因果 ; 加深对协议的理解独立的利于理解协议特征, 混合的利于理解协议的特定需求 ; 在网络中没有任何一个协议是独立存在的与 H.323 BICC 的比较协议设计目标不一样 :Internet Telephony 尽可能的重用 Internet 应用技术添加与会话控制相关能力支持与互通 H.323:Telephony Over Internet(IP) 尽可能的与无缝融合尽可能无缝的支持各种业务 ( 补充业务 ) BICC:Bearer independent call control 尽可能的与无缝融合尽可能无缝的支持各种业务 ( 补充业务 ) 协议设计实现方式不一样协议网络组网结构目的不一样所有的不一样实际上都归结为设计目标不一样 6

Network Working Group Request for Comments: 3372 BCP: 63 Category: Best Current Practice A. Vemuri Qwest Communications J. Peterson NeuStar September

Network Working Group Request for Comments: 3372 BCP: 63 Category: Best Current Practice A. Vemuri Qwest Communications J. Peterson NeuStar September 2002 Internet SIP-T C Internet 2002 PSTN Public Switched