SIP协议及其在视频监控系统中的应用.ppt_第1页
SIP协议及其在视频监控系统中的应用.ppt_第2页
SIP协议及其在视频监控系统中的应用.ppt_第3页
SIP协议及其在视频监控系统中的应用.ppt_第4页
SIP协议及其在视频监控系统中的应用.ppt_第5页
已阅读5页,还剩45页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

http SIP协议及其在视频监控系统中的应用 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 什么是SIP SIP是一个应用层的信令控制协议 用于创建 修改和释放一个或多个参与者的会话 SIP可以邀请参与者加入一个已经存在的一个会话中 例如一个多播会议 SIP可以动态的在会话中添加和删除媒体数据 SIP支持名字映射和重定向服务 什么是SIP SIP的会话控制功能会话维护会话协商内容不作任何限制 比如终端的能力 终端的数据端口号等等 可以使用SDP或者其他的协议进行协商 这一点使得SIP有很好的扩展性 会话中可以承载的数据语音 视频即时消息其他的自定义数据游戏SIP的名字映射功能SIP使用SIP逻辑地址来映射实际地址 这样用户发起呼叫时 不需要知道目标的真正地址 就可以达到呼叫的目的 这样可以很方便实现终端的移动性 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP的设计原则 模仿HTTP1 1的风格重用HTTP编码 所有消息基于文本 便于开发 使用UTF 8字符集重用Internet寻址方案 使用RFC2369中定义的URI和URL格式 可以非常的灵活的和其他遵循这一定义的协议协作 对底层传输协议不做假设可以使用于多种协议 如UDP TCP TLS SCTP等等 虽然对底层传输协议不做假设 但是需要注意的是 它仍然将底层协议分为两类 一类为不可靠的数据报传输协议 unreliabledatagramtransports 一类为流式的传输协议 stream orientedtransports 区分这两类协议的主要目的在于 在是否重传消息时需要区别对待 最常用的协议为UDP协议 SIP的设计原则 逻辑地址和联系地址相分离逻辑地址用于标志用户联系地址用于表明用户当前的位置 即当前的实际地址 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP的架构 采用客户端 服务器 C S 架构主要单元用户代理 UserAgent SIP服务器 Servers 代理服务器 Proxy 重定向服务器 Redirector 注册服务器 Registar SIP的架构 代理服务器 Proxy 用来接收请求 并寻找请求传送的下一条地址 转发请求 可以分为有状态的和无状态的 有状态的代理服务器记住它接收的请求 回送的响应以及它转出的请求 无状态的代理服务器则不记录任何请求相关的信息 重定向服务器 Redirector 不转发请求 而是向请求发出者发送重定向响应 指示被呼叫方的地址 注册服务器 Registar 完成用户代理的注册和注销功能接收管辖范围内的用户代理的注册请求 并将用户代理的真实地址记录在定位服务器中 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP的层次 语法和编码层这层定义了SIP的语法和编码格式SIP使用AugmentedBNF来定义所有的SIP消息格式SIP URI sip userinfo hostporturi parameters headers SIPS URI sips userinfo hostporturi parameters headers userinfo user telephone subscriber password user 1 unreserved escaped user unreserved user unreserved password unreserved escaped hostport host port 传输层 TransportLayer 这需要和SIP使用的何种传输协议相区分 定义如何选择底层传输协议 如果数据包太大 需要使用可靠的流式协议 如TCP 定义在不同的传输协议下 如何发送请求和接收响应 SIP的层次 事务层 TransactionLayer 这层是SIP协议的核心层次 事务是SIP协议的核心元素 一个事务是由客户端事务发送给服务器事务的请求 和对应该请求的服务器事务发送回客户机事务的所有响应的组合 事务分为客户端事务 和服务端事务 每一个事务都包含多个状态 这些状态之间的跳转可以使用一个有限状态机来描述 事务主要用来匹配请求和响应 处理应用层重传 尽力的保证消息的可靠传输 维护应用层超时 用户代理 有状态的代理服务器以及注册服务器都包含事务层 无状态的代理服务器不包含事务层 SIP的层次 事务用户层 TU 事务用户层工作在事务层之上 无状态的代理服务器不包含事务层 所以也不包含事务用户层 其他的SIP实体都包含事务用户层 当TU想要发送一个SIP请求时 创建一个客户端事务 当对应的请求到达服务器 服务器产生一个对应的服务端事务 TU也可以产生一个CANCEL事务来取消一个客户端事务 CANCEL事务通过SIP的CANCEL消息来实现 它是一个单独的事务 但它的目标是被取消的事务 如果被取消的事务已经完成了 那么这个CANCEL事务就完全不起作用 就因为这个原因 通常只有针对客户端的INVITE事务使用CANCEL事务 因为其他的事务在正常情况下存在的时间都很短 而INVITE事务一般会牵涉到用户的输入 持续时间比较长 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP的主要机制 地址分离机制SIP协议采用逻辑地址和联系地址相分离的机制 逻辑地址用来标识用户 联系地址用来表明用户的当前位置一个地址可以对应多个联系地址 联系地址的选择机制可以通过依据权重 或者并发的模式 注销注册机制这个机制用来实现逻辑地址向联系地址的绑定 用户通过注册和注销来实现这种绑定 告知当前的实际位置 通过REGISTER命令来实现这个机制 目标更新机制在会话中主动通知另一方 联系地址的改变 SIP的主要机制 呼叫重定向机制当用户呼叫一个逻辑地址时 重定向服务器使用注册注销机制的结果 将逻辑地址翻译成联系地址 并将这一结果通知用户 由用户使用联系地址重新发起呼叫呼叫协商机制通过会话建立过程中双方携带的信息来确定双方的能力 需要传输的媒体等等 可以在会话中增加 减少以及改变会话中传送的媒体 路由机制可以由客户端选择所需要经过的路由节点 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP的鉴权 采用和HTTP非常接近的认证方式 用RFC2617 HTTPBasicAndDigestAccessAuthentication中基于挑战响应的协议过程和消息结构 禁止了不安全的 Basic 认证 使用 Digest 认证方式 基于用户名和密码的认证方式在网络中不传递密码明文服务器产生一个随机数nonce给客户端客户端依据nonce加上密码以及一些相关信息使用MD5算出一个hash值 将这个hash值传递回服务器 因为MD5算法在不可逆上的安全性 保证就算被不怀好意者截取以后 也很难得到真正的密码 服务器根据同样的算法计算出MD5hash值 将这个结果和客户端传递来的值作比较 匹配则认证通过 一般使用在注册和注销过程中 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP消息格式 一个SIP请求消息的例子INVITEsip 180062000265273827 10 18 34 73 5360SIP 2 0Route Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK4009098743From tag 1419225769To Call ID 829237863 10 18 34 104CSeq 20INVITEContact Max Forwards 5User Agent mediasip 2 0Subject MediaSipExpires 120Allow INVITE ACK UPDATE INFO CANCEL BYE OPTIONS REFER SUBSCRIBE NOTIFY MESSAGEContent Type application sdpContent Length 206 SIP消息格式 一个SIP消息回应的例子SIP 2 0200OKRecord Route Via SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK4009098743From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20INVITEContact Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Type application sdpContent Length 249 SIP消息格式 采用UTF 8编码格式和HTTP协议基本相同SIP地址通常的格式为sip user password host port uri parameters headers uri parameters为附加的URL参数 格式为parameter name parameter value多个参数以分号分隔开 可扩展 SIP实体必须忽略不认识的URL参数headers为构建请求时添加的附加头域 这个部分通常不出现在SIP消息中 格式为hname hvalue多个参数以与号分隔开 SIP消息格式 每个消息由一个起始行 消息头 一个空行 以及一个可选的消息体构成generic message start line message headerCRLF message body 每个起始行和消息头都是以回车加换行结束 CRLF 起始行只能占据一行消息头域可以跨越多行 如果头域部分某行是以空格 x20 或制表符 x09 开始 那么表示这一行是前一行的延续 可以把 CRLF 空格 或 CRLF 制表符 当作一个空格来处理 这样的序列被称为LWS linearwhitespace SIP消息格式 起始行起始行分为请求起始行和应答起始行start line Request Line Status Line请求起始行 Request Line 格式为 Request Line MethodSPRequest URISPSIP VersionCRLFMethod 请求的方法 RFC3261中定义的有REGISTER INVITE ACK CANCEL BYE OPTIONS 在别的SIP补充RFC中还定义了其他的方法 如RFC3248中定义了MESSAGE方法 Request URI 请求的目的地址 参见SIP地址的说明 SIP Version SIP的版本号 在RFC3261中定义为SIP 2 0应答起始行 Status Line 格式为 Status Line SIP VersionSPStatus CodeSPReason PhraseCRLFSIP Version SIP的版本号 在RFC3261中定义为SIP 2 0Status Code 应答的状态码 可以为如下值1xx 表示请求已经收到 正在继续处理请求 通常只针对INVITE请求发送这个响应 2xx 成功响应 表示请求已经被接受并已经被正确处理3xx 重定向响应 表示请求需要被进一步的处理 通常是给出一个转移地址 4xx 请求错误 通常是请求消息格式错误 或者不能满足服务器的要求 5xx 服务器内部错误 表示服务器不能处理这个正常的请求消息 6xx 全局出错消息 表示所有的服务器都不能处理这个消息 Reason Phrase 应答对应的文字描述 SIP消息格式 消息头格式为fieldname field value header paramsters大部分多个相同的头域可以压缩为一个 多个field value之间使用逗号 分隔开 例如 下面两个是等价的Route Route Route 消息可以根据需要携带不同消息头 有些消息头是必须的 比如From To Call ID CSeq Max Forwards ViaFrom一般用来表示消息的发起者的逻辑地址 在REGISTER消息中表示注册的发起者 响应消息中的From头和请求消息中的一样 并不是变成了请求中的To头 To一般表示消息的接收者的逻辑地址 在REGISTER消息中表示本次注册的逻辑地址 在请求消息中不携带tag字段 在响应中由回应方分配 Call ID会话的标志 和From To中的tag参数一起标志一个会话 为保证唯一性Call ID的一般格式为 伪随机数 主机名或IP地址 在同一个会话中的所有消息这三个字段必须相同 如果是会话之外消息 则没有什么要求 CSeq会话中的消息的序号 消息方法名 用来区分一个会话中的不同消息请求 消息序号是一个递增的值 会话外的消息对序号没有要求 但是消息方法名要和请求起始行中相同 Max Forwards消息的最大转发数 防止消息在网络中因为不可知的原因产生环路以后 不会无限制的消耗网络和服务器的资源 服务器在转发请求时 先要将这个值减一再发送 SIP消息格式 Via用来记录消息相应的返回地址 branch参数按照RFC3261中的规定必须是唯一的 用来标志一个SIP事务 但在老版本的SIP标准 RFC2543 中并不是唯一的 为了区别这两种情况 RFC3261中规定 branch参数的开始7个字符必须为 z9hG4bK 只有在两种情况下可以不唯一 针对会话请求的非成功 non 2xx 响应的ACK 它的branch字段需要和对应的INVITE一样 用来联系这个ACK和INVITE 而对成功 2xx 响应的ACK 它的branch字段和对应的INVITE是不同的 CANCLE方法 它的branch字段需要和要取消的请求消息相同 用来标志所要取消的事务 Contact这个消息头用来指示通讯方的实际地址 这个不同于From和To中记录的的逻辑地址 在REGISTER中携带的Contact表示要绑定到逻辑地址 To 上的实际地址 User Agent标识SIP代理程序Subject标识一个会话的主题 通常只有INVITE消息才携带这个头字段 Expires在INVITE中表示这次呼叫建立过程的最大时长 如果超过这个时间还没有建立成功 呼叫就失败了 发起者应该发送CANCEL取消这次呼叫 而接受者应该回应一个487的错误 在REGISTER中 表示这次注册绑定的有效时间 如果为0则表示注销 SIP消息格式 Content Type指定消息体的媒体类型Content Length指定消息体的长度Route用来指定消息所要经过的服务器 当中间服务器在接收到消息时 需要根据是否携带lr参数来做不同的动作 如果携带lr参数 表示是根据RFC3261指定的路由 服务器只要检查第一个Route头是否为自己 如果为自己 将它从消息中移除 然后将消息发给下一个Route字段或者Request URI中的携带的地址 如果没有lr参数 表示是依据RFC2543指定的严格路由 在消息发送的时候发现第一个Route字段没有lr参数 需要将这个Route中的地址 填写到Request URI中 而将Request URI作为一个Route字段添加在所有Route字段之后 遵照RFC3261的代理服务器收到一个请求时 需要检查Request URI是否指向的是自己曾经在Record Route填写的内容 如果是的话 需要从最后一个Route字段中恢复真正的Request URI 出现这个现象的原因可能是因为上一跳是一个遵从RFC2543的SIP服务器 Record Route如果中间服务器仍然需要出现在会话的后续请求中 那么它需要在响应中在所有其他的Record Route字段之前添加这个字段 填上自己的地址 遵从RFC3261的中间服务器必须加上lr参数 会话的发起方在发送后续的请求中 需要将所有的Record Route头字段依顺序转换成Route字段 Allow用来表示SIP实体可以接收处理的SIP方法 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP的主要流程 一般的消息流程采用C S架构客户端发起请求服务器端给回应 SIP的主要流程 请求消息 以MESSAGE方法为例 MESSAGEsip 10 18 34 75 5065SIP 2 0Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK1495426073From tag 2717189648To Call ID 251252407810318334310450601031833431045060CSeq 1MESSAGEContact User Agent SIP NET1 0evaluationversionMax Forwards 70Content Type application global eye v10 xmlContent Length 312 回应消息SIP 2 0200OKVia SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK1495426073From tag 2717189648To tag 980420199Call ID 251252407810318334310450601031833431045060CSeq 1MESSAGEMax forwards 70User agent SIP NET1 0evaluationversionAllow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Type application global eye v10 xmlContent Length 375 SIP的主要流程 注册流程终端向注册服务器发起第一个注册请求 不携带任何鉴权信息如果注册服务器不需要认证 那么 就直接返回200OK 否则返回401错误 并在响应中携带服务器的认证挑战信息 nonce 终端向注册服务器发起第二个注册请求 其中携带用来认证的用户和密码信息 密码是以结合挑战信息 nonce 用MD5加密之后传递的 注册服务器使用终端同样的算法计算结果 和请求中的值相比较 如果认证通过 那么记录下请求中的地址绑定信息 SIP的主要流程 注册请求一REGISTERsip 10 18 34 104 5900SIP 2 0Via SIP 2 0 UDP10 18 34 104 5900 rport branch z9hG4bK1525468063From tag 4224369265To Call ID 955142972 10 18 34 104CSeq 1REGISTERContact Max Forwards 5Expires 300Content Length 0401回应SIP 2 0401UnauthorizedVia SIP 2 0 UDP10 18 34 104 5900 rport 5900 branch z9hG4bK1525468063From tag 4224369265To tag 3878116472Call ID 955142972 10 18 34 104CSeq 1REGISTERWWW Authenticate Digestrealm testrealm nonce 42385386681596732431151298277 opaque 42385386681596732431151298277 qop auth Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Length 0 SIP的主要流程 注册请求二REGISTERsip 10 18 34 104 5900SIP 2 0Via SIP 2 0 UDP10 18 34 104 5900 rport 5900 branch z9hG4bK3241190465From tag 4224369265To Call ID 955142972 10 18 34 104CSeq 2REGISTERContact Authorization Digestusername test realm testrealm nonce 42385386681596732431151298277 uri sip 10 18 34 104 5900 response f7f90e49a7744311e51c001d6166ecc4 algorithm MD5 cnonce 0a4f113b opaque 42385386681596732431151298277 qop auth nc 00000001Max forwards 5Expires 300Content Length 0200OK回应SIP 2 0200OKVia SIP 2 0 UDP10 18 34 104 5900 rport 5900 branch z9hG4bK3241190465From tag 4224369265To tag 2180340491Call ID 955142972 10 18 34 104CSeq 2REGISTERContact expires 300 q 1 0Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Length 0 SIP的主要流程 呼叫流程呼叫发起方发起呼叫 使用INVITE消息呼叫接受方返回1xx响应 表示已经收到请求 在进一步的处理 这时可能用振铃提示用户有呼叫呼入 用户应答以后 发送200OK响应 表示接受呼叫 呼叫发起方发送ACK 用来确认呼叫的应答已经收到 对于呼叫发起方来说 收到200OK发送ACK之后 就认为呼叫已经建立成功 如果长时间没有收到回应 可以使用CANCEL方法取消呼叫 而对于呼叫接受方来说 在收到ACK之后 才认为呼叫已经建立成功 如果在发送200OK响应之后长时间没有收到ACK 可以使用BYE方法结束呼叫 取消流程取消请求只对呼叫发起方有效 接受方如果不能建立呼叫 要么直接发送错误响应 3xx 6xx 要么在发送成功响应 2xx 之后 用BYE方法结束会话 在INVITE发出之后和收到任何的1xx消息之间不可以发送 因为这时候如果发出 因为网络的原因可能导致CANCEL消息先于INVITE到达接受方 在收到1xx消息后 可以发送CANCEL消息 呼叫接受方在收到CANCEL时如果还没有对呼叫发送最终的响应 那么应该立即发送487响应 RequestTerminated 如果已经发送了响应 那么就不理睬这个CANCEL消息 如果发起方在发送CANCEL仍然收到了呼叫建立成功的响应 如果这时仍然想结束呼叫 那么应该使用BYE消息 这种情况通常是发生在CANCEL到达接受方之前 接受方发送了成功响应 在收到最终响应后 不可以发送CANCEL消息 SIP的主要流程 INVITE请求INVITEsip 180062000265273827 10 18 34 73 5360SIP 2 0Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK4009098743From tag 1419225769To Call ID 829237863 10 18 34 104CSeq 20INVITEContact Max Forwards 5User Agent mediasip 2 0Subject MediaSipExpires 120Allow INVITE ACK UPDATE INFO CANCEL BYE OPTIONS REFER SUBSCRIBE NOTIFY MESSAGEContent Type application sdpContent Length 206 1xx响应SIP 2 0101DialogEstablishementVia SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK4009098743From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20INVITEContact Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Length 0 SIP的主要流程 2xx响应SIP 2 0200OKVia SIP 2 0 UDP10 18 34 104 5060 rport 5060 branch z9hG4bK4009098743From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20INVITEContact Allow INVITE ACK OPTIONS CANCEL BYE SUBSCRIBE NOTIFY MESSAGE INFO REFER UPDATEContent Type application sdpContent Length 249 ACK确认ACKsip 180062000265273827 10 18 34 73 5360SIP 2 0Via SIP 2 0 UDP10 18 34 104 5060 rport branch z9hG4bK444599471From tag 1419225769To tag 1745846615Call ID 829237863 10 18 34 104CSeq 20ACKContact Max Forwards 5User Agent mediasip 2 0Content Length 0 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP事务 SIP事务的分类因为呼叫建立的过程和其他的消息过程相比较特殊 也要复杂一些 所以特别的将所有事务区分为INVITE事务和非INVITE事务 再加上客户端和服务端的组合就分为如下四种 INVITE客户端事务 INVITEClientTransaction INVITE服务端事务 INVITEServerTransaction 非INVITE客户端事务 non INVITEClientTransaction 非INVITE服务端事务 non INVITEServerTransaction SIP事务中的定时器当SIP使用不可靠的传输协议 如UDP SIP协议定义了一些列的定时器 来进行重传和超时控制 尽可能的保证消息能够可靠的传输 T1用来表示数据包的估计往返时间 默认值为500毫秒 T2用来表示非INVITE事务服务器的估计响应时间 默认值为4秒 T4用来表示网络中消息的估计存在时间 默认值为5秒 SIP事务中请求和响应的匹配当用响应匹配请求时 规定使用Via字段的branch参数来区别 另外还要比较CSeq中的方法字段 以便区别是针对CANCEL还是针对被取消的请求 当用请求匹配请求时如果branch字段的开始为 z9hG4bK 那么表示这个请求是依照RFC3261发出的 需要匹配branch 以及CSeq中的方法部分 ACK需要对应INVITE 其它的请求方法必须相同 如果branch字段的开始不为 z9hG4bK 那么表示这个请求是按照RFC2543发出的 需要用Request URI Totag Fromtag Call ID CSeqnumber 以及第一个Via头等等 SIP事务 INVITE客户端事务TimerA用来控制INVITE请求消息的重传间隔 初始为T1 默认为500毫秒 每次重传之后 就翻倍 TimerB用来控制INVITE在没有收到任何响应的情况下 最大的重传总时间 为64倍的T1 那么在没有收到任何响应的情况下重传间隔如下T1 2 T1 4 T1 8 T1 16 T1 32 T1TimerD用来控制收到错误响应之后 对每个响应回应ACK的最大持续时间收到2XX以后 就到了结束状态 并不包含ACK 因为对于不同的TU 在收到200OK响应之后 可能会作不同的动作 对于客户端来说 需要发送ACK回应 而对于中间服务器来说 只需要转发回应就可以了 在Proceeding状态 没有任何的定时器来进行状态跳转的 这就出现了一个问题 如果服务器在发送1xx响应之后 出错了 不再发送后续的响应 那么这时客户端的呼叫就会一直保持在这个状态 这就需要由TU来控制会话的最大建立时间 如果在这个时间到达之后 会话还没建立成功 就取消呼叫请求 并释放资源 SIP事务 INVITE服务端事务TimerG用来控制错误响应的重传间隔 初始值为T1 每次重传之后就翻倍 直到大于T2之后 就变成T2 TimerH用来控制错误响应重传总时长 值为64 T1 这样由TimerG控制的错误响应重传时间间隔为 T1 2 T1 4 T1 T2 T2 T2 T2 T2 T2 T2TimerI用来吸收客户端重传的ACK确认包 在Proceeding和Completed状态下 如果收到了INVITE请求消息 都需要重传最后一个响应 收到2xx消息时 和INVITE类似 立即转到了Terminated状态 后续的ACK响应以及它的重传都是由TU来控制的 同样的和INVITE客户端事务中的Proceeding状态类似 也没有任何的定时器来触发状态的跳转 如果TU由于某种原因再也不发送响应 那么呼叫资源就会一直占用 这里也需要呼叫最大建立时间的限制 SIP事务 非INVITE客户端事务TimerE用来控制请求消息的重传间隔 初始值为T1 每次重传之后翻倍 直到大于T2之后 就使用T2 如果收到了零时响应 TimerE仍然存在 只不过将值直接置为T2 TimerF用来控制消息重传的总时长 值为64 T1 这样由TimerE控制在没有零时响应情况下的请求重传时间间隔为 T1 2 T1 4 T1 T2 T2 T2 T2 T2 T2 T2TimerK用来吸收服务端重传的响应 值为T4 SIP事务 非INVITE服务端事务TimerJ用来吸收客户端重传的消息请求 值为64 T1 在Proceeding和Completed状态下 如果收到了INVITE请求消息 都需要重传最后一个响应 和前面类似Trying和Proceeding两个转态下没有任何的定时器来实现状态跳转 如果TU不发送任何的回应 那么这个消息状态就一直会存在下去 也需要有一个超时机制来释放资源 SIP协议 什么是SIP SIP的设计原则SIP的架构SIP的层次SIP的主要机制SIP的鉴权SIP的消息格式SIP的主要流程SIP事务SIP在视频监控系统中的应用 SIP在视频监控系统中的应用 使用SIP XML来传递信令消息使用MESSAGE方法 信令使用XML携带 采用SIP消息的重传来尽力保证消息的可靠传递 使用SIP SDP来建立媒体会话使用INVITE方法来建立呼叫 使用SDP来协商媒体格式 传输地址 等等 使用OPTIONS信令来检测会话双方是否存在 使用标准的SIP协议来建立呼叫 比较容易和别的系统融合 比如说和视频会议系统 IPTV系统等 SIP在视频监控系统中的应用 视频监控的示意性流程 SIP在视频监控系统中的应用 穿越NAT的原理什么是NAT NAT就是网络地址转换 主要是因为IPV4网络地址的缺乏而采用的技术 NAT内的主机一般使用私网地址 如10 xxx xxx xxx 192 168 xxx xxx 访问外

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论