SIP基础培训(共62张).pptx

上传人:醉**** 文档编号:8193268 上传时间:2022-03-15 格式:PPTX 页数:62 大小:3.09MB
返回 下载 相关 举报
SIP基础培训(共62张).pptx_第1页
第1页 / 共62页
SIP基础培训(共62张).pptx_第2页
第2页 / 共62页
点击查看更多>>
资源描述

《SIP基础培训(共62张).pptx》由会员分享,可在线阅读,更多相关《SIP基础培训(共62张).pptx(62页珍藏版)》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、SIP(Session Initiation Protocol)基础培训基础培训Jade 2016/11目录概述SIP消息SIP流程RTP协议DTMFSIP会话启动协议SIP(Session Initiation Protocol)是一个在IP网络上进行多媒体通信的应用层控制协议,它被用来创建、修改、和终结一个或多个参加者参加的会话进程。 SIP协议可用于发起会话,也可以用于邀请成员加入已经用其它方式建立的会话。基于文本编解码采用事务机制,每一个请求触发Server的操作方法,请求和响应构成一个事务,事务间彼此独立独立于底层传输协议:SIP协议承载在IP网,网络层协议为IP,传输层协议可用TC

2、P或UDP,推荐首选UDP。UDP DHCP DNS RSVP RTCP RTP SIP HTTP TCP Sigcomp IP4/IPv6 媒体编码媒体编码 SDP 接入网(GPRS,UMTS,WLAN,.) SIP在协议栈中的位置SIP 标准SIP核心标准RFC 3261 Session Initiation ProtocolSIP扩展标准RFC 2976 The SIP info methodRFC 3263 Locating SIP ServersRFC 3265 SIP-Specific Event Notification RFC 3311 UPDATE MethodRFC 332

3、6 The Reason Header Field RFC 3372 SIP for Telephones (SIP-T): Context and ArchitecturesRFC 3398 ISUP to SIP MappingRFC 3428 SIP Extension for Instant MessagingRFC 3262 Reliablity of Provisional Response in SIPSIP参考标准RFC 2327 Session Description ProtocolRFC 3264 Offer Answer Model with SDPSIP 应用组网SG

4、Soft SwitchTMGPSTN/PLMNInternetASStorage ServerSMSWPSPGW3rd Party ASSCPSMSSCEENUMSIP 逻辑实体UAS:用户代理服务端UAC:用户代理客户端, UAC和UAS是一个逻辑功能,发起请求的一方为UAC,处理请求的一方为UAS。根据此刻正在处理的消息,SIP设备实体不停在UAC和UAS间转换,即UACUAS角色在事物中存在。可以将UAC理解为初始化请求的一段代码,并且在事务中遵循UAC的规则。如果它接下来收到一个请求,那么在那个事务中,它就是作为UAS来处理请求;UAS同理。代理服务器:代理服务器接收SIP请求并将其路

5、由至其他代理服务器或最终用户重定向服务器:重定向服务器收到请求时,可以通过应答将路由信息推送到客户端,客户端收到应答可以重新向指定的服务器发起请求注册服务器:用来接受UAC的注册请求,登记用户的联系方式信息,如果存在定位服务器,把信息写入定位服务器以上为逻辑实体,物理实现上,注册服务器和代理服务器可以为同一物理设备,甚至所有服务器可以为同一物理设备。目录概述SIP消息SIP 流程RTP协议DTMFSIP 消息概述SIP 是一个使用UTF-8字符集的文本协议,协议定义了两类消息格式:请求消息和应答消息消息格式定义(类似HTTP):从消息格式中可以看出,请求消息和应答消息的start-line不同

6、,请求消息start-line为Request-Line,应答消息start-line为Status-LineRequest-Line定义如下:Request-Line = Method SP Request-URI SP SIP-Version CRLFStatus-Line定义如下:Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLFmessage-header由一些头域(header field)组成,包含哪些头域取决于具体的消息和Methodmessage-body:由头域中的Content-type组成,一般为s

7、ession description(SDP)说明:SP为空格,CRLF为回车换行SIP 消息概述实例请求消息格式应答消息格式Request-Line定义1Request-Line = Method SP Request-URI SP SIP-Version CRLFRFC3261定义了6种Method,可理解为request请求的子消息类型:REGISTER: 用于向注册服务器联系人地址INVITE:用于发起会话请求,邀请某个用户加入会话,发出invite的一方可以通过message body携带SD,指明本次会话的媒体类型及参数ACK:对INVITE的最终响应,该消息仅和INVITE配套使

8、用CANCEL:取消尚未完成的invite请求BYE:结束会话OPTIONS:查询服务器能力RFC 3262扩展定义了PRACK方法:对于临时应答(除100外的1xx类应答)的响应,保证临时应答端到端的可靠性RFC2976扩展定义了INFO方法RFC 3428扩展定义了MESSAGE方法RFC 3311扩展定义 了UPDATE方法RFC 3265 扩展定义了NOFIFY方法RFC 3892扩展定义了REFER方法支持哪些method可以通过头域中的Allow指示Request-Line定义2Request-Line = Method SP Request-URI SP SIP-Version

9、CRLFRequest-URI代表请求涉及的用户或者服务的地址格式:sip: user:passwordhost:port;uri-parameters?headersuser:用户地址标识,可以是标准的电话号码/文本形式的用户名password:可选,不推荐用户密码明文传输host:代表提供SIP服务的地址标识,可以是域名或者IP地址port:和host配对,指明提供SIP服务的TCP/UDP端口号uri-parameters: uri参数,格式类似HTTP,采用name=alue格式,具体参数含义参考协议headers:请求的头域,类似http,采用hname=halue&hname2=h

10、value格式,不常用。MethodRequest URISIP versionStatus-Line定义status-line= SIP-VERSION SP STATUS-CODE SP Reason-Phrase CRLFSTATUS-CODE由3位数字组成,代表请求处理的结果,Reason-Phrase为code对应的文本解释。STATUS-CODE可以理解为响应报文的子消息类型,第一个数字代表大类,后2个数字代表具体应答子类型1xx类应答:临时应答,代表请求已经收到,正在处理这个请求2xx类应答:最终应答,代表请求已经处理成功3xx类应答:重定向类,需要将该请求转发到其他服务器上处理

11、4xx类应答:客户端错误,请求消息的格式服务器无法接受,或者服务器不能处理5xx类应答:服务器错误,请求合法,但是服务器无法处理6xx类应答:请求不能被任何服务器处理典型的STATUS-CODE100:正在尝试-和Q.931 CALL PROCEEDING 类似,可能会被代理服务器、或者呼叫信令路径上的其他中间SIP服务器返回180:正在振铃-和Q.931 ALERTING类似。表示虚拟或者真实的电话正在振铃200: 请求成功执行(OK)300:在对请求中的地址进行解析时出现多个选择。它们会被返回,呼叫者可以从列表中挑出一个来重定向呼叫。401:在进行这项请求之前,用户需要授权403:禁止请求

12、不要再次尝试407:在行进之前,首先用户代理授权501:因为没有实现该服务,服务器不能供给该请603:被叫用户拒绝该呼叫以上为常用的status-code,更多code参考RFC 3261协议头域定义头域定义一From代表请求的发起者,和SIP URI类似,多一个tag参数,是一个随机数,作为一个标志使用To指明请求的接收者Call-ID唯一区别一个特定的邀请或者一个特定客户端的所有注册项Cseq请求中的Cseq头域包含了一个单个的数字序列号和请求的方法。Cseq头域是为了在会话中对事务进行排序的,提供事务的唯一标志,并且区分请求和请求的重发Contact会话参与者的联系方式头域定义二mess

13、age-body定义Message-body由头域中的Content-type决定,在SIP中,一般为基于RFC 2327 SDP的会话描述(Session Description),会话双方通过交换会话描述信息协商会话的媒体类型及相关参数,具体规范参考RFC3264 offer/answer model with sdp会话双方经过offer/answer协商会话描述信息后,可以开始通过RTP交换语音流会话过程中,可以通过re-Invite修改SDP会话媒体方向属性,以支持呼叫保持此处只指出VOIP媒体类型的关键信息,具体细节进一步参考RFC 2327 SDP协议本端IP媒体类型 端口 协议

14、媒体属性:RTP协议对应的语音压缩算法媒体方向属性:sendrecv: 收发双向sendonly: 本端只发不收,用于呼叫保持recvonly: 本端只收不发,用于呼叫保持SIP request消息SIP/协议版本响应消息头Call-id: 值via: 值消息头参数行To: 值Contact: 值From: 值Content-Length: 值Max-Forward: 值White SpaceSDPContent-Type: 值Cseq: 值SIP 响应消息格式SIP/协议版本响应消息头Call-id: 值via: 值消息头参数行To: 值Contact: 值From: 值Content-Le

15、ngth: 值Max-Forward: 值White SpaceSDPContent-Type: 值Cseq: 值目录概述SIP消息SIP流程RTP协议DTMF用户注册流程注册服务器SIP PhoneRequest: RegisterStatus: 401 Unauthorized/WWW-authenticateRequest: Register/AuthorizationStatus: 200 OK注册流程作用SIP客户端向网络侧注册自身的联系方式,完成用户身份的认证,作被叫时可以寻址到该用户用户注册流程实例注册服务器SIP PhoneRequest: RegisterRequest: R

16、egister/AuthorizationStatus: 200 OK用户去注册流程UAC携带自身的联系方式向注册服务器发起注册请求,和注册的区别在于,Contact头域为,Expire头域为0,表示要求服务器删除该联系人所有联系信息。或者通过Contact头域中的expire参数为0,表示删除联系的某条联系信息注册服务器根据要求删除联系人信息,并返回200响应注册服务器SIP PhoneRequest: Register Status: 200 OK去注册作用该用户离线,当有人呼叫该用户时,Server将响应该用户不存在用户去注册流程实例注册服务器SIP PhoneRequest: Regi

17、ster Status: 200 OK主被叫流程1. caller通过invite发起会话建立请求2. proxy响应100表示正在处理请求3. proxy要求caller进行认证4. caller返回ack,前文说过ack只和invite配套使用,并且协议规定对于对于非200的终结响应,终结事物必须给对方返回ACK5.caller携带认证信息和会话描述信息发起invite6. proxy指示通过响应100指示处理中7. proxy认证通过后,向被叫转发invite8. callee响应100表示正在处理请求9.callee处理请求ok,提示本地sip phone”振铃”,返回180响应给ca

18、ller,提示caller测phone”振铃”10. proxy转发180给caller,caller给用户“振铃”11. callee侧用户“摘机”,callee侧响应200给caller12. proxy将200转发给caller注:此处“振铃”或“摘机”在SIP电话上不一定是传统PSTN电话的操作方式,比如对于基于SIP的某种软电话,callee侧所谓“振铃”可能是弹出提示框“收到来自某某的呼叫,同时播放一段音乐“。但是他们的信令含义和PSTN呼叫流程是一致的Proxy Server SIP PhoneASIP PhoneB INVITE with Proxy-authorization

19、 & sdp15100 Trying6INVITE with sdp17100 Trying8180 Ringing9180 Ringing10200 OK sdp212200 OK sdp211INVITE with sdp11100 Trying2 407 Proxy Authentication Required3ACK4说明:支持“RFC 3262 临时应答可靠性扩展”时,在第10步后,caller可以给proxy响应RFC 3262新增的PRACK请求,表示收到了180这个临时应答,此处未画出。主被叫流程续13. caller给callee返回ACK,协议规定invite发起的请求的

20、200响应,必须返回ACK14. proxy将ACK转发calle双方可以通话,通话结束,假设主叫挂机15. caller向callee发送BYE,结束通话16. proxy向caller返回200(挂机不需ACK确认200响应)17. proxy向callee发送BYE,结束通话18. callee响应200,通话结束Proxy server SIP PhoneA(主叫)SIP PhoneB(被叫)Conversation (RTP/RTCP) ACK13ACK14BYE15200 OK for bye16BYE17200 OK for bye18根据SIP协议规定,代理服务器有三种,保留呼

21、叫状态的代理保留状态代理不保留状态代理,三种代理参与会话的程度依次减少,保留呼叫状态的代理掌握会话过程中的一切SIP事务,保留会话从开始到结束的的所有状态信息;保留状态只会保留一个事务的状态直到事务结束;不保留状态代理不保留任何事务信息,只是纯粹透传SIP消息此流程中的代理服务器属于保留呼叫状态的代理根据RFC3261规定,offer/answer有2种交互方式,方式1,invite(with sdp)/200 ok(with sdp)/ack(no sdp); 方式2,invtite(no sdp)/200 ok(with sdp)/ack(with sdp)。上面流程采用方式1挂机流程挂机

22、流程Re-Invite流程除了上图两种方式交换SDP外,还有通过Invite/183交换SDP,Update更新SDP属性的方式Proxy ServerSIP PhoneB通话中(参见主被叫流程)1SIP PhoneC 100 Trying 4 7 200 Ok with sdp9 Ack5 100 Trying 6 200 Ok with sdp8 AckRe-Invite流程流程1 2 Invite with sdp 3 Invite with sdp 100 Trying 12 15 200 Ok with sdp17 Ack with SDP13 100 Trying 14 200 O

23、k with sdp16 Ack with sdpRe-Invite流程流程2 10 Invite11 Invite步骤1. 通话建立步骤2-9:通过re-Invite流程更新SDP属性,通过Invite with SDP和200 OK with SDP方式步骤10-17:通过re-Invite流程更新SDP属性,通过200 OK with SDP和ACK with SDP方式说明Re-Invite主要用于更新SDP媒体的方向属性,比如在步骤2中SDP方向为sendonly,步骤6中方向为recvonly,则通话方B被保持;步骤14和步骤16中的SDP方向为sendrecv,则通话方B被取消保

24、持拍叉操作(拍叉键一般为FLASH键或电话面板上的R键为了支持呼叫保持,呼叫等待,三方通话,呼叫转移等补充业务,需要定义特殊按键触发SIP客户端发起对应的流程,因此定义了上表中的拍叉动作:只有两方通话时,任意一方可以按下拍叉键,保持对方,按下拍叉键一方为业务方;只有两方通话,按下拍叉+数字组合键无意义当前有三方处于呼叫状态(不一定在三方会议中),业务方均可以按下拍叉+0,1,2,3,4,发起对应的操作按键按键含义含义拍叉在通话过程中保持(hold)对方,本方发起二次拨号,对方听保持音(Server下发保持音)拍叉+0根据场景,作用如下:1.通话过程中拒绝第三方呼叫2.呼叫保持时挂断被保持方拍叉

25、+1呼叫保持时挂断通话方拍叉+2切换通话方:先hold当前通话方,随后恢复和保持方的通话拍叉+3进入三方通话拍叉+4发起呼叫转移呼叫保持Proxy Server SIP PhoneASIP PhoneB通话中(参见主被叫流程)1 100 Trying 4A/B/C角色可以互换,上图以A为业务方说明,实际B也可以作为业务方,发起各种拍叉动作Re-Invite流程用于修改SDP属性,可以用于保持一方(sendonly)或取消保持(sendrecv)SIP PhoneC 7 200 Ok with sdp9 Ack5 100 Trying 6 200 Ok with sdp recvonly8 Ac

26、k10 呼叫第三方流程步骤1.参见主被叫流程建立通话步骤2-9. 用户按下拍叉键,电话A播放二次拨号音,同时发起hold电话B过程步骤10:用户开始按键拨打电话C并建立通话,此时与C通话步骤11:用户按下拍叉+2,切换通话方,重复步骤2-9,保持当前通话方C步骤12:重复步骤2-9,取消保持B,恢复与B的通话,此过程中SDP属性为sendrecv注意:在步骤10后与C通话时,A可以按下拍叉+0,可以发起挂机流程,挂掉保持方B;也可以按下拍叉+1,挂掉当前通话方C,同时重复步骤2-9,恢复与保持方B的通话Re-Invite呼叫保持呼叫保持11 重复步骤2-9,hold C12 重复步骤2-9,u

27、nhold B 2 Invite with sdp sendonly 3 Invite with sdp sendonly呼叫等待Proxy Server SIP PhoneASIP PhoneB通话中(参见主被叫流程)1 Invite2SIP PhoneC 4 Invite步骤1.参见主被叫流程建立通话步骤2-5. 用户C拨打正在通话中的用户A用户A此时可以选择的操作:步骤6.1:用户A按下拍叉+2,保持当前通话方B,接通C,并与C通话步骤6.2:用户按下拍叉+0,拒绝接入C,继续与B通话注意:用户在执行步骤6.1接入C后,可以选择按下拍叉+0或拍叉+1去挂掉某一方通话 3 100 Tryi

28、ng 5 180 Ringing 5 180 Ringing6.1 发起呼叫保持流程 6.1 200 OK 6.1 200 OK6.2 486 Busy here6.2 486 Busy here三方通话流程Proxy Server SIP PhoneASIP PhoneB通话中1SIP PhoneC10 呼叫第三方流程11 重复2-9的会话修改流程,将会话修改为sendrecv,自此三方通话建立完毕步骤1.参见主被叫流程建立通话步骤2-9. 用户A按键拍叉+2,保持通话方B步骤10. 用户A呼叫用户C,并通话步骤11:用户A按下拍叉+3,进入三方通话,用户A和B重复步骤2-9,恢复与B通话(

29、此时re-Invite流程中SDP媒体方向属性为sendrecv)三方通话实际是业务方A分别到B和C各有一条媒体方向属性为sendrecv的双向RTP流,A负责来自B的语音转发C,将来自C的语音转发B,实现三方会议 100 Trying 4 7 200 Ok with sdp9 Ack5 100 Trying 6 200 Ok with sdp recvonly8 AckRe-Invite呼叫保持呼叫保持 2 Invite with sdp sendonly 3 Invite with sdp sendonly呼叫转移Proxy Server SIP PhoneASIP PhoneB1 A呼叫

30、B2 A呼叫C SIP PhoneC步骤1:用户A呼叫B,并建立通话步骤2:用户拍叉呼叫C并建立通话步骤3-4:用户按下拍叉+4,发起呼叫转移步骤5-10:server通过交替向B和C发起re-Invite流程,使得B和C协商SDP信息步骤11:B和C开始通话步骤12:server通知用户A呼叫转移成功步骤14和步骤15:用户B和用户C和用户A发起挂机流程此为商用server处理呼叫转移的流程,对于brekeke等免license试用版本,流程上有一些差异,主要体现在brekeke会透传Refer命令给C,C向B发起re-Invite,建立通话,随后B/C和A发起挂机流程3 Refer C t

31、o B4 202 Accepted5 Invite without SDP 6 200 OK with C-SDP 7 Invite with C-SDP 8 200 OK with B-SDP 9 Ack with B-SDP 10 Ack without SDP 11 B和C通话12 Notify refer OK13 200 OK14 Bye from B15 Bye from C目录概述SIP消息SIP流程FAXRTP&RTCPDTMFFAX概述VoIP FAX传真方式G.711A passthroughG.711U passthroughT38FAX流程FAX传真流程与呼叫流程从SI

32、P信令过程看,没有本质区别,主要分为:建立语音通话FAX发送方或接收方检测到传真音,发起re-Invite协商fax SDP属性发起传真传真结束,FAX发送方或就接收方发起re-Invite返回原通话挂机Proxy Server FAX发送方FAX接收方呼叫建立通话B5318-42 VoIP采用D2解决方案,一般是传真接收方先检测到传真音,发起re-Invite进入传真模式re-Invite协商FAX sdp传真re-Invite返回原通话挂机流程目录概述SIP消息SIP流程RTP&RTCPDTMFRTPRTCP概述RTP提供为多媒体实时数据流提供端到段的传输服务,为数据流提供了有效载荷类型通

33、知序列号时间戳信息传输监控信息(RTCP)。RTP本身并不提供QoS保证,如重传机制拥塞控制,RTP提供的序列号可以用于接收方重组报文,不能保证不同序号的各个报文按序投递给上层。由于TCP的重传机制和拥塞控制机制,不适用实时数据的传输,因此RTP一般工作在UDP之上,但是RTPRTCP本身不是OSI协议的单独的一个层次,是一个单独的应用。RTCP(Real-Time Transport Control Protocol)用于采用RTP协议的会话方交换统计信息,RTP负责实时数据流的传输,RTCP实现会话期间的流量控制和拥塞控制。RTP提供了良好的扩展性,除标准定义的功能外,厂商可以扩展新的功能

34、。RFC3550定义了RTPRTCP标准RTP包格式RTP包头定义V:version,2bit版本号,目前最新为2P:padding,1bit代表payload最后是否有补足字节,补足字节数由payload最后一个字节指定X:extension,1bit代表是否存在extension header跟在CSRC后CC:CSRC count,4bit指示CSRC字段重复多少次,在mixer场景出现M:marker,由具体的profile确定,可以理解由PT决定(参考RFC3551),标志为1时,该包可能携带了特别的控制信息PT:payload type(参考RFC3551),有效载荷类型,多媒体编

35、码方式sequence number:16bit序列号,初值为随机数的分组编号,用于接收方判断是否丢包和重组报文RTP包格式续RTP包头定义timestamp:32bit时间戳,发送的有效载荷的第一个字节的采样时刻,用于接收方同步和抖动计算,比如某种语音编码的数据流,采样频率为8000HZ,一次采样20ms的语音块需要采样次数为0.02s*8000HZ=160,则连续2个RTP报文中的timestamp间隔为160,协议要求timestamp的初始值为随机值;如果同一时刻采用的数据使用多个RTP报文发送,则timestamp相同。对于同一会话方可能同时传送视频和音频,但是视频和音频RTP中的t

36、imestamp初值和采样周期均可能不同,在接收方通过2个RTP流中的timestamp信息,不能实现这2个流的同步,通过RTCP传递的绝对时间(RTCP中的NTP timestamp)可以解决帮助实现这2个流的同步。RTP包格式续RTP包头定义SSRC:32bit的同步源标识发送一个RTP分组的发送方标识,从而避免使用网络地址。协议要求该标识在一个会话中的多方不能相同,并提供了冲突解决方法CSRC:贡献源,可能包含多个SSRC,由CC指定,用来标识mixer混合了多少个SSRC的数据Mixer: 用于会话方带宽不对称的场景,为了避免会话方都采用较低质量低带宽的编码方式,定义了RTP rela

37、y,称为mixer,它将多个RTP流重新混合为一个RTP流,发送给带宽较低的会话方,CSRC则定义了某个RTP报文中混合了哪些SSRC的数据RTP包格式实例RTCP包格式RTCP包格式前1个字节和RTP类似,包头格式根据RTCP报文类型字段具体定义,RTCP定义了如下报文类型,不同的报文类型携带不同的控制信息:SR报文由3部分组成:header发送方的发送统计信息(sender info)发送方的接收统计信息(report block,可选,可重复多次)SSRC同RTP中的SSRCNTP timestamp:NTP格式的绝对时间RTP timestamp同RTP中时间戳Senders xxx

38、count:累计发送的包数和字节数SSRC_1:对端的SSRCxxx lost:本周期内(自动上一个SRRR后)丢包数jitter:数据包到达间隔的统计方差,用于拥塞控制其他参考协议RR报文由2部分组成:header接收方的接收统计信息(report block,可选,可重复多次)Report block同SRSDES报文由2部分组成:header源描述(可重复多次,SC指定)SDES intems包含:CNAME,NAME,EMAIL,PHONE,LOC,TOOL,NOTE,PRIV,均为TLV结构,T值从1开始,依次递增。CNAME:cononial name,格式一般为userhost,

39、 代表会话方标识。与SSRC的区别在于,SSRC在一次多次会话中变化,而此标识不变。比如一个会话方同时传送语音和视频时,两个RTP流对应的RTCP报文中的CNAME应一致,从而接收方会将2个RTP流做同步处理NAME:用户名EMAILPHONELOC:用户的联系方式信息NOTE:可以用于传送发送方接收方的状态信息或者其他信息(具体由profile定义,参考RFC3551)PRIV:私用扩展SDES项,自扩展定义项。BYE报文表示一个或多个SSRC离开本次会话由3部分组成:headerSSRC会话结束原因(opt)APP报文用于实验性质的新特性或功能开发,由应用定义 RTCP包格式实例附:Pay

40、load type(摘自RFC3551)附:关于RTP包中的marker bit位For audio:对于发送舒适噪音或不发送任何RTP报文后发送的第一个携带有效语音的报文需要将marker bit置1For video: 一个video frame的最后一个RTP报文要将marker bit置1,其他置0目录概述SIP消息SIP流程code流程RTP&RTCPDTMFDTMFDTMF:dual-tone multi-frequency双音多频,最初用于PSTN电话机和交换机间自动长途中转,伴随着业务需求的发展,后来用于通过电话机实现的交互式应答系统,比如拨打10086或招行9555电话,会弹

41、出相应提示,用户输入的数字如何传递给对方,就是通过DTMF技术,其本质上是在已处于呼叫的电话上如何传递用户命令或事件给对端在传统的电话机上,拨号面板是一个44的矩阵,每行代表一个低频,每列代表一个高频,每按下一个键就会发送一个低频和高频的正弦波信号组合,模拟信号达到交换机,交换机根据这个信号特征,就知道用户按下了什么键伴随着voip和其他通信技术的发展,出现了软终端SIP终端,原来通过高低频组合模拟信号的方式对于某些场景已经不再适用,需要新的方式实现DTMF技术VOIP下的DTMF针对VOIP场景,目前有几种实现DTMF的方式,归结外带外和带内两种。带外方式:SIP INFO(RFC 2976

42、),针对SIP(RFC 3261)的扩展,用来传递会话中的控制信息,比如DTMF事件传真控制信令,缺点是由于采用带外方式,无法保证控制信令先于业务到达。带内方式:INBAND方式:纯带内方式,通话中产生的DTMF事件(用户按下键盘的数字)和话音做同样的处理,直接在RTP包中发送,要求对端能够根据DTMF数字的高低频特性识别出该DTMF事件。RFC2833方式:IETF为通过RTP传输DTMF事件/其他线路事件(比如传真)和普通多频电话音而开发,通过特定Payload Type(经过SIP/SDP协商)的RTP封包携带相应事件,其封包格式借鉴RFC2198 基于RTP的冗余语音格式由于INBAN

43、D方式和普通语音通过RTP方式传输相同,此处主要描述RFC2833和SIP INFO方式。RFC2833RFC2833描述了如何通过RTP承载DTMF信令/音频信号/电话事件,此处重点描述如何承载DTMFRFC2833 DTMF的RTP payload的格式定义event定义如下:E:结束位,标识该封包含有事件的结束,该封包中的duration指示了事件的持续时间R:保留位volume :DTMF事件音频信号的强度,单位dBm0,6bit可表示范围0-63dBm0,有效范围0-35dBm0duration:DTMF事件的持续时间,单位为RTP timestamp的单位,以采样频率为8000时,

44、本地段16bit可以表示的持续时间最大为8秒(1/8000 * 216约等8192ms)RFC2833实例SDP协商telephone event的payload type采用RFC2833方式承载DTMF时,需要会话双方协商payload type(常用payload type定义在RFC3551,并规定PT为96127用于动态分配)rtpmap:97 telephone-event/8000fmtp:97 0-15定义了RTP载荷类型为97,用于携带0-15 DTMF事件进一步细节请参考RFC 2189和RFC2327SIP INFORFC 2976是针对RFC 3261 SIP的扩展,该

45、扩展定义了一种新的SIP INFO方法,用于承载会话相关的控制消息。比如用于控制电话呼叫业务的ISUP和ISDN信令消息。SIP INFO应用场景:协议只是建议上除场景可以用SIP INFO方法,具体怎么用(message body定义)没有定义,只是按照SIP的method机制新增了INFO方法而已,因此目前应该是各个厂商自己定义INFO方法的message bodySIP INFO流程UASUARequest: INFOStatus: 200 OKStatus: 415 Unsupported Media Type SIP INFO DTMF实例UASUARequest: INFOStat

46、us: 200 OKDTMF方法协商DTMF方法有3种,会话双方应该采用哪种,没有协议规定会话双方如何协商采用哪一种,基于如下特性可以按如下原则实现:1. 由于采用RFC2833方式时,会话双方需要协商承载DTMF的RTP报文的动态payload type,在SIP会话建立期间,SDP offer/answer协商出payload type时,则采用RFC2833方式2. SIP INFO方法在SIP中的Allow头域进行了声明,在SIP会话建立期间,如果双方都支持SIP INFO方法,则采用SIP INFO方法3. 最后再考虑采用INBAND方式但是如果提供了用户配置优先使用哪种DTMF方法时,由于双方配置的方法可能不一致,会使问题变得复杂,建议的策略:1. 如果双方协商出了payload type,则使用RFC28332. 如果双方未协商除payload type,如果发起DTMF的一方被配置为RFC2833则应使用INBAND或SIP INFO(前提是双方支持SIP INFO方法),如果发起DTMF的一方未配置为RFC2833方式,则使用其配置的方式(使用IP INFO时需要双方都支持,否则使用INBAND)演讲完毕,谢谢观看!

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 技术资料 > 其他杂项

本站为文档C TO C交易模式,本站只提供存储空间、用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。本站仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知淘文阁网,我们立即给予删除!客服QQ:136780468 微信:18945177775 电话:18904686070

工信部备案号:黑ICP备15003705号© 2020-2023 www.taowenge.com 淘文阁