STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
北京邮电大学
BEIJING UNIVERSITY OF POSTS AND TELECOMMUNICATIONS
• 与传统Telephony业务互通的努力 • 增强的媒体协商能力 • 构建支持业务处理能力的基础结构 • 目的 – 加深对SIP协议基本处理方法的理解 – 理解协议扩展方式与方法
SIP协议分析
— SIP协议扩展分析 SIP协议扩展分析
李静林
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
SIP协议扩展的方法与原则
• 协议扩展的原因与目的 • SIP协议扩展原则
实现特定的语义 – 满足扩展需求 – 符合SIP基本协议处理机制和要求
与传统Telephony业务互通的努力
• IETF
– Session Initiation Protocol for Telephones – 俗称 SIP-T
• ITU-T
– Q.1912.5 – TRQ2815 – 俗称 SIP-I
• Transaction • Dialog • Session
满足特定的语法规则＋时序
– 兼容已经存在的系统
• SIP协议扩展方法
– 增加消息头 – 增加消息头的参数 – 增加消息 • SIP与传统Telephony业务互通的总原则
– Translation – Encapsulation
与传统Telephony业务互通的场景 PSTN – IP
SP Proxy
与传统Telephony业务互通的场景 SIP Bridging
Proxy SP1 TE GW PSTN SIP Network GW PSTN SP2 TE
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
TE PSTN
GW SIP Network
TE
• Translation
– ISUP SIP message mapping – ISUP parameter-SIP header mapping
消息映射 发起呼叫 振铃 连接建立 SIP INVITE 180 Ringing 200 OK（INVITE） ISUP IAM ACM ANM 参数映射 主叫号码 被叫号码 SIP Contact / From Request-URI / To ISUP Caller Party Number Called Party Number
• Encapsulation
– 'Transparent' Transit of ISUP Messages – SIP与ISUP协议不可能一一映射 – 如果为了保证SP1－SP2之间业务的无缝互通，只有SP1发出的 ISUP消息能够透传到SP2 – 将ISUP消息封装在SIP消息体里 – Content-Type: application/ISUP
1
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
SIP与传统Telephony业务互通的需求
• Reliable Transmission of Provisional Responses（临时响 应的可靠传输） • Early Media（早期媒体） • Mid-Call Transactions which do not change SIP state（不 改变SIP状态的Mid-Call传输） • Overlap Signalling（重叠信令） • Transmission of Dual-Tone Multifrequency (DTMF) Information（DTMF音传输） • RFC3398-Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping
– 5. SIP Mechanisms Required
需求的分析
PSTN
IAM T 20s 100 183 ACM 183 64 T1 ACM
SIP GW
INVITE
SIP Proxy
INVITE
SIP GW
IAM
PSTN
可靠的呼叫进展通知，保证PSTN侧不会超时
ANM 200 INVITE ACK 200 INVITE ACK
ANM
CPG ?
如何传递呼叫中事件
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
需求的分析（续）
UserA
INVITE SDP 100 ACM 183 SDP IAM
Reliable Provisional Responses、 EarlyMedia扩展需求
• 扩展目的
– 传递可靠的呼叫进展 – 传递被叫侧的媒体描述
GW
PSTN
• 扩展方法
– 扩展消息 PRACK
• 为1xx响应提供消息确认
– 扩展消息头 RSeq／RAck
• 保证PRACK与对应的1xx匹配
– 1xx响应扩展消息头：RSeq – PRACK请求扩展消息头：RAck
?
ANM 200 INVITE ACK
– 扩展消息头参数 100rel
• 保证UAS知道UAC是否要求1xx可靠传输 • 保证UAC知道UAS返回的1xx是需要可靠传输的 • UAC发送INVITE携带Require:100rel
– UAS发送的第一个1xx必须是可靠传输的临时响应 – 1xx必须携带Require:100rel
大多数终端是在收到Answer之后才开始向应用播放收到的RTP流 不然如何决定哪些媒体流应该被播放 不然如何决定RTP流状态报告应该如何回复
• UAC发送INVITE只携带Supported:100rel
– UAS可以根据自身需要决定是否需要发送可靠的临时响应 – UAC收到的1xx携带Require:100rel，则意味着需要可靠传输
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
兼容已有系统
• 已有系统不支持PRACK怎么办？
– UAC可能不支持发送PRACK消息 – UAS可能不支持发送可靠的1xx和接收PRACK
符合SIP处理机制
• 满足Transaction处理机制
– 1xx处理机制保持不变 – PRACK＋响应 组成新的Transaction
• 为什么不仿照ACK？ • Transaction的分类
• 为了保证兼容
– UAS不支持可靠传输的临时响应
• UAC发送的INVITE携带了Require:100rel
– UAS返回420 (Bad Extension)响应，并携带 Unsupported:100rel
• 满足Dialog处理机制
– 可靠传输的1xx将创建Dialog
• • • • Dialog不是INVITE-2xx建立的吗？（Dialog的定义） 可靠传输的1xx是对INVITE的确认 保证了INVITE请求之后的其他请求都将是Dialog内请求 1xx中携带To Tag
• UAC发送的INVITE仅携带Supported:100rel
– UAS正常处理
– UAC不支持可靠传输的临时响应
• UAC不支持可靠传输的临时响应，则INVITE不会携带 100rel
– UAS不会返回需要可靠传输的临时响应
– PRACK属于Dialog内请求
• PRACK具有与INVITE相同的Dialog信息（From、TO、 CallID） • PRACK的处理满足UA／Proxy对Dialog内请求的处理规则 （UA处理，Proxy转发）
• UAC支持可靠传输的临时响应，则INVITE必须携带100rel
2
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
符合SIP处理机制
• 满足Session处理机制（Offer-Answer）
– 如果INVITE携带Offer，可靠的1xx可以选择携带Answer
• 不携带Answer则该响应仅仅是防止超时
总结PRACK
PSTN
IAM
SIP GW
INVITE Supported:100rel SDP 100
SIP Proxy
INVITE Supported:100rel SDP
SIP GW
IAM
PSTN
– 如果INVITE不携带Offer，则可靠的1xx必须携带Offer
• 强制要求
– 如果可靠的1xx携带Offer，则PRACK必须携带Answer
• PRACK是1xx的“最终响应”
– 如果INVITE-1xx完成了Offer-Answer，PRACK-200PRACK可 以完成进一步的Offer-Answer
• PRACK－200PRACK是可靠传输的
ACM
180 Require:100rel,RSeq SDP PRACK RAck
180 Require:100rel,RSeq SDP
Session
ACM
PRACK RAck 200 PRACK 200 INVITE ACK ANM
– 如果可靠的1xx携带Answer，则必须建立Session
• 一次Offer-Answer结束了 • Early Session
Transaction
Dialog
ANM
200 PRACK 200 INVITE ACK
– 不影响RFC3261的Session处理机制
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
满足Mid-Call扩展需求
• 扩展目的
– 传递呼叫建立之后的Mid-Call事件 – 这种事件仅需要应用理解，与协议无关
• 为什么不用re-INVITE？
– INVITE修改状态
总结INFO
PSTN
IAM
SIP GW
INVITE Supported:100rel SDP 100 ACM
SIP Proxy
INVITE Supported:100rel SDP
SIP GW
IAM ACM
PSTN
• 扩展方法
– 扩展“新”的请求：INFO
180 Require:100rel,RSeq PRACK RAck 200 PRACK
180 Require:100rel,RSeq PRACK RAck 200 PRACK 200 SDP ACK INFO
• 兼容已有系统
– – – – INFO是End-End的请求，不影响路径中的状态 INFO没有任何扩展的消息头与消息头参数 INFO满足一切标准SIP请求／响应的处理规范 End-End路径中的任何一点不需要理解INFO，只需要按照标准 SIP请求转发就可以了
ANM
200 SDP ACK
ANM
• 满足SIP处理机制
– INFO-响应组成新的Transaction – INFO Transaction为Dialog内部Transaction
CPG
CPG
INFO 200
200
Transaction
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
关于INFO需要说明的一些问题
• INFO制定在RFC3261之前，其中的一部分规则 已经不适用于RFC3261了
– RFC2543：INFO可以被CANCEL – RFC3261：不建议对INVITE以外的请求发CANCEL
SIP与PSTN互通相关的基本RFC
• • • • • • • • • RFC2833-RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals RFC2976- The SIP INFO Method RFC3262-Reliability of Provisional Responses in the Session Initiation Protocol (SIP) RFC3372-Session Initiation Protocol for Telephones (SIP-T): Context and Architectures RFC3398-Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping RFC3578-Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP) RFC3666- Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows RFC3959-The Early
Session Disposition Type for the Session Initiation Protocol (SIP) RFC3960-Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)
• INFO不应该被用于DTMF的传递
– DTMF由RFC2833规定的RTP／RTCP中传递
• INFO和MESSAGE有什么区别？
– INFO是存在于INVITE建立的Dialog中的 – MESSAGE可以不属于Dialog
• INFO和re-INVITE有什么区别？
– INFO是不影响传递路径中各个实体的状态 – Re-INVITE会影响状态
3
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
增强的媒体协商能力
• SIP基本媒体协商
– 媒体协商的内容：SDP会话类型描述 – 媒体协商的要求：Offer-Answer模型 – SIP协议对媒体协商的支持：需要使用可靠传输的消息
呼叫建立时的媒体协商
UserA
INVITE Offer
UserB
UserA
INVITE
UserB
• 媒体协商能力的需求
– – – – 多媒体业务：在一个对话中可能会支持多条媒体流 对话的两方可能随时修改媒体流的数量和类型 媒体的修改可以是主叫与被叫任意一方发起 媒体的修改可以在呼叫的建立前，建立中，建立后的任何一 个时间段发生
主 叫 发 起
100 180
100 180
200 Answer ACK
200 Offer ACK Answer
被 叫 发 起
• 媒体协商的应用场景
– 呼叫建立之前的早期媒体协商 – 与呼叫建立同步的媒体协商 – 呼叫建立之后的媒体协商
呼叫建立过程中可以由主叫、被叫任意一方发起媒体协商
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
呼叫建立之后的媒体协商
UserA
INVITE Offer 100 180 200 Answer ACK
呼叫建立前的早期媒体协商
UserA
INVITE Offer 100
UserB
UserA
INVITE Offer 100 180 200 Answer ACK INVITE Offer 200 Answer ACK
UserB
UserB
UserA
INVITE 100rel 100
UserB
主 叫 发 起
18x Answer
18x Offer PRACK Answer 200 PRACK 200 INVITE ACK
主 叫 发 起
INVITE Offer 200 Answer ACK
被 叫 发 起
主 叫 发 起
PRACK Offer 200 Answer 200
被 叫 发 起
主叫只能在PRACK的时候才能发起媒体重协商
ACK
INVITE
呼叫建立之后可以由主叫、被叫任意一方发起媒体重协商
被叫被动发起媒体协商，被叫不能发起媒体重协商
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
扩展媒体协商能力
• 扩展原因分析
– INVITE请求在收到200最终响应之前不能再次发送 – PRACK只能由1xx可靠传输触发发送 – UAS只能返回响应，SIP的“请求－响应”机制导致除 了INVITE三次握手，只能由请求发起Offer，响应 返回Answer
兼容性考虑
• 已有系统不支持UPDATE怎么办？ • 扩展方法
– 规定消息头参数
• INVITE请求的Allow消息头中应该携带UPDATE • 1xx临时响应中Allow消息头可以携带UPDATE • 200最终响应中Allow消息头应该携带UPDATE
• 扩展目的
– 支持呼叫建立之前主叫和被叫任意一方发起媒体重 协商
– 兼容性处理
• 如果对端不支持UPDATE
– 405 Method Not Allowed – 405响应的Allow消息头列举可以支持的请求
• 扩展方法
– 扩展新的请求UPDATE
• 在任何时机由会话双方中的任意一方发起媒体重协商
• 符合SIP协议对请求的一般处理规定 • 对于Call建立之后的媒体重协商建议使用re-INVITE
4
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
符合SIP处理机制
• Transaction
– UPDATE＋响应 组成新的Transaction
总结UPDATE
UserA
INVITE Offer 18x Answer PRACK 200 PRACK
UserB
UserA
INVITE Offer 18x Answer PRACK 200 PRACK
UserB
• Dialog
– UPDATE属于Dialog内请求
• UPDATE一定存在于可靠的临时响应建立的EarlyDialog内 • UPDATE具有与INVITE相同的Dialog信息（From、TO、 CallID） • UPDATE的处理满足UA／Proxy对Dialog内请求的处理规 则（UA处理，Proxy转发）
• Session
– UPDATE一定是发起Offer – 200 OK 一定是返回Answer
主 叫 发 起
UPDATE Offer 200 UPDATE Answer
UPDATE Offer 200 UPDATE Answer
被 叫 发 起
Transaction
200 INVITE ACK 200 INVITE ACK
UPDATE与PRACK/1xx有什么区别？
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
媒体协商相关的RFCsuasa
• RFC3311－SIP UPDATE Method • RFC3261－ SIP: Session Initiation Protocol • RFC3262－Reliability of Provisional Responses in the Session Initiation Protocol (SIP) • RFC3264－An Offer/Answer Model with the Session Description Protocol (SDP)
构建支持业务处理能力的基础结构
• SIP协议对业务能力的扩展
– RFC3265－“SIP-Specific Event Notification”
• SUBSCRIBE／NOTIFY
– RFC3515－“SIP Refer Method”
• REFER
• SUBSCRIBE／NOTIFY
– SIP网络实体可以订购另一个实体的资源或呼叫状态 – 当订购内容改变，则订购的实体会得到相应通知
• Present
• REFER
– 第三方会话邀请
• Call Transfer • Conference
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
Specific Event Notification的模型
• 语义
User Subscriber Present Server Notifier
SUBSCRIBE 200 NOTIFY 200
Refer Method的模型
• 语义
UserA Agent
REFER 202 Accepted NOTIFY 200
– SUBSCRIBE
• 内容订购
UserB Agent
– REFER
• 通知对端需要联系第三 方
– NOTIFY
• 订购内容通知
– NOTIFY
Transaction • 联系进展通知
Transaction •
语法规则
– SUBSCRIBE+响应 new Transaction – NOTIFY+响应 new Transaction – SUBSCRIBE是dialogcreating method – 不创建Session – ……
• 语法规则
– REFER+响应 new Transaction – NOTIFY+响应 new Transaction – REFER是dialog-creating method – 不创建Session – ……
Transaction
Transaction
Dialog
NOTIFY 200
Dialog
NOTIFY 200
User向Present Server订购用户注册状态—Present业务
UserA向UserB发出第三方邀请—Call Transfer业务
5
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
SIP协议扩展的讨论
• INFO／PRACK／UPDATE扩展的目的是什么
– 完善协议会话处理能力
SIP协议扩展的方法与原则
• 协议扩展的原因与目的 • SIP协议扩展原则
– 满足扩展需求 – 符合SIP基本协议处理机制和要求
• Transaction • Dialog • Session
• SUBSCRIBE／NOTIFY／REFER／MESSAGE 扩展的目的是什么
– 增强SIP对特定业务需求的处理能力
– 兼容已经存在的系统
SIP不是声称不支持业务的吗？ 即便不是针对特定的业务，那也是针对一类业务啊？ just because it’s there
• SIP协议扩展方法
– 增加消息头 – 增加消息头的参数 – 增加消息
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
北京邮电大学
BEIJING UNIVERSITY OF POSTS AND TELECOMMUNICATIONS
如何全面的学习一个协议
• 协议的产生与发展
– 明确协议是什么 – 理解协议的设计目的 – 明确协议的设计目标
1、协议的背景资料，相关介绍，原始 协议浏览 2、协议规范的Abstract和Introduction 1、协议规范浏
览：Overview, Definitions 2、协议基本语义、语法、时序
• 协议基本分析
– 协议的体系结构 – 协议的基本规则 – 了解SIP协议做什么
SIP协议分析总结
• 协议基础架构分析
– – – – – 协议的设计原则 协议的实现原则 协议的控制模型 明确协议怎么做 明确协议为什么这么做
1、协议深入阅读，理解协议概念 2、总结协议的处理规则 3、回头看 1、协议的扩展应用 2、协议的扩展方法
• 协议扩展分析
– 协议扩展目的 – 协议扩展方法
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK
如何看待一个协议
• • 协议的历史观点
– 协议设计的目的与目标
SIP与H.323、BICC的比较
• 协议设计目标不一样
– SIP：Internet Telephony
• 尽可能的重用Internet应用技术 • 添加与会话控制相关能力 • 支持与PSTN互通
协议的现实观点
– 协议具体的应用位置，扮演的角， 起到的作用
历史与现实的差异，深刻理解 协议的设计理念，发展原因， 地位与作用
• •
协议的设计观点
– 协议的逻辑体系结构 – 协议消息的语义、语法、时序
– H.323：Telephony Over Internet（IP）
• 尽可能的与PSTN无缝融合 • 尽可能无缝的支持PSTN各种业务（补充业务）
协议的实现观点
– 协议的物理实现层次 – 协议的实现模型
设计与实现相辅相成，互为因 果； 加深对协议的理解
– BICC：Bearer independent call control
• 尽可能的与PSTN无缝融合 • 尽可能无缝的支持PSTN各种业务（补充业务）
• •
纯粹协议的观点
– 单纯的特定协议组网
混合协议的观点
– 多协议融合的协议组网
独立的利于理解协议特征，混 合的利于理解协议的特定需 求； 在网络中没有任何一个协议是 独立存在的
• 协议设计、实现方式不一样 • 协议网络组网结构、目的不一样 • 所有的“不一样”实际上都归结为设计目标不一样
6
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议