sdp

最近我们的各个产品都在整合国标GB28181的功能扩展，有EasyNVR的国标GB28181向上级联、有EasyGBS的下级接入与对上级联、有EasyCVR的多协议接入与GB28181输出，大家都在做GB28181，国标的成熟与兴起是政策与执行相互促进推动的结果，以前没有一个这么完善的协议能统一平台相互级联的思路，如今有了，那么各种类型的系统支持GB28181就是必然的； EasyNVR将RTSP/Onvif设备汇聚并向上级平台级联： EasyGBS国标接入与向上级联： EasyCVR能将各种协议汇聚并向上GB28181级联： 同时，我们也有在做WebRTC的更底层的开拓，发现WebRTC的实时性效果确实是出奇的好，我们综合分析了一下： WebRTC的视频传输采用的是RTP/RTCP协议，与GB/T28181一样； WebRTC在信令上各有各的自定义交换方式，与SIP协议类似，其主要目的就是做SDP等信息交换； 如果能衔接WebRTC的信令交换方式与国标SIP的信令交换方式，那WebRTC的RTP/RTCP是不是就可以与GB/T28181的RTP/RTCP贯通？ 那么GB/T28181是不是就可以借助到WebRTC的各种底层框架优势？ WebRTC+GB28181，延时、对讲、回音，是不是统统都没问题了？ 是的，我们正在按照这个思路在开发！ 来源： oschina 链接：

USB Battery Charging V1.2 Specification 定义了USB充电器的类型或者叫做充电源。 1. 支持的充电器类型 1.1 Standard Downstream Port(SDP) 这种USB端口存在于主机PC中，这个是与USB的规格书一致的。 当一个USB外设接到SDP端口上的时候，有下列几种情况： 当总线挂起的时候电流应该小于2.5mA. 如果总线没有挂起并且没有配置，或者连接到一个总线供电的hub上，电流应该小于100ma 如果总线没有挂起且配置好了，电流应该小于等于200ma。 1.2 DCP 或者叫做wall charger 这些充电端口可以供应高达1500ma的电流给移动设备充电。 然而这些DCP端口不支持通过USB接口进行数据传输。 电池充电规格书定义了数据线应该被短接在这种DCP情况下。 充电类型的检查依赖于这些数据线。 1.3 charging Dedicated Port (CDP) CDP端口是一个在主机端的特殊端口，能够提供高达1500ma的电流，与此同时，可以枚举设备以供正常的USB使用。 1.4 Proprietary charger (专有的充电器) 这些适配器不像正常的标准充电器那样，短接数据线。他们有自己的组合，上拉或者下拉数据线。 1.5 Floated charger 这种类型的充电器被看做是不兼容的充电器类型

一、主机控制接口协议 HCI 蓝牙主机-主机控模型 蓝牙软件协议栈堆的数据传输过程： 1、蓝牙控制器接口数据分组：指令分组、事件分组、数据分组 （1）、指令分组 如：Accpet Connection Request Opcode为：0x0409 参数长度为: 07 参数中蓝牙地址为：00:0d:fd:5f:16:9f 角色为：从设备 0x01 大端数据模式 指令为：09 04 07 9f 16 5f fd 0d 00 01 （2）、事件分组 如上图： Opcode :0x0409 状态： 0x00 总长度： 4字节 命令状态：0x0f （3）、数据分组 ACL 数据分组 注： PB Packet_Boundary BC Broadcast Flag SCO 数据分组 （4）、RS232分组指示器: 2、HCI控制命令 （1）、链路控制指令 （2）、链路策略指令 （3）、主机控制器与基带指令 （4）、信息指令参数 （5）、状态指令参数 （6）、测试指令 （7）、错误代码 二、逻辑链路控制与适配协议 L2CAP L2CAP位于基带之上，将基带的数据分组转换为便于高层应用的数据分组格式，并提供协议复用和服务质量交换等功能。L2CAP只支持ACL数据传输，不支持SCO数据。 L2CAP本身不提供加强信道可靠性和保证数据完整性的机制，其信道的可靠性依靠基带提供。 1、协议复用

SIP请求的类型，也称作SIP方法。RFC3261 中定义了六种方法。另外八种方法有独立的RFC扩展描述。 SIP请求或方法在协议中被视为“动词”，因为它们请求另一个UA或服务器执行一项特定的动作。INVITE、 REGISTER、BYE、ACK、 CANCEL 和 OPTIONS是SIP最初定义的六种方法。REFER、SUBSCRIBE、NOTIFY、PUBLISH、MESSAGE、UPDATE、 INFO 和 PRACK这些方法是在扩展的RFC中定义的。 UA收到不支持的请求方法时，回应501 Not Implemented response消息。方法名是大小写敏感的，为了区分头域字段，方法名通常全部使用大写字母，而头域字段内容允许大小写混合。注意：代理服务器转发请求不需要理解请求的方法。代理服务器把未知的方法视为OPTIONS处理，换句话说，它应该尽可能地把请求转发给宿端。这样，UA引入新特性或方法就不需要中间代理的额外支持。UA应当在请求和应答消息中携带Allow头域以说明它所支持的方法。 INVITE INVITE方法用于UA之间建立媒体会话。在电信领域中，它类似于ISDN的Setup消息或ISUP里的初始地址消息 (IAM)。 对于INVITE请求的最终应答，都需要用ACK方法确认。 INVITE消息通常带有消息体，消息体包含主叫方的媒体信息

今天谈的这个主题（tone）存在于我们的日常打电话过程中。先举两个场景：1，你拿起固话话筒准备打电话，按电话号码前先从话筒里听到“嗡”的连续音，这叫dial tone(拨号音，表示你可以拨电话号码了)，你拨完号码对方振铃后你又听到有规律的“嘟-嘟-”的断续音，这叫ring back tone(回铃音，表示对方已振铃了)。2，你给企业服务号（比如中国移动的10086）打电话，对方叫你按键选择，当你按下键后会听到按键声，这叫DTMF tone（双音多频音）。感觉到它存在于我们日常的打电话过程中了吧。现在我们就从技术的角度谈谈这些tone。 在语音通信中tone主要分两大类：CPT（call progress tone，呼叫过程音）tone和DTMF（dual tone multi frequency，双音多频音）tone。CPT tone存在于通话过程中，主要用于告诉用户目前在什么状态，主要有dial tone(拨号音)/ringback tone(回铃音)/busy tone（忙音）等。CPT tone是单频音，即由一个频率的正弦波形成。CPT tone没有全球统一的标准，而是各个国家有自己的标准，比如中国的标准，欧洲的标准，美国的标准等。下表就是我们国家的标准： 还有其他类型的CPT tone，由于用的相对较少，这里就不一一列出了。相对于CPT tone是单频音，DTMF

一.业务背景 天猫国际营销活动分析实时排行榜是在大促中帮助业务快速的分析商家或者品牌的交易和流量的数据情况，给下一步大促的销售目标，流量蓄水等等做出运营决策；尤其是在活动当天当发现行业的问题之后，仅仅靠子行业的拆分不足以确定具体的问题，也不一定有具体的业务抓手，所以需要有到商家、品牌和商品粒度的数据来快速定位问题。 二.原技术方案 原始技术方案的架构如下图所示，可以看到是非常典型的Lambda架构，实时和离线分别是两套系统，离线数据通过MaxCompute（原MaxCompute）轻度汇总同步至MySQL，实时增量数据通过Blink清洗后同步至HBase，最后在数据服务里面以View的形式将实时和离线数据合并，提供对外服务。 整个架构在实际业务执行中会有非常多的痛点，典型的有以下几个： 1）ADS层模型任务多 流计算和批处理任务都分别需要开发基于商品，卖家，品牌粒度的满足应用层的三个ADS模型数据，三个数据同步任务，分别需要创建三个oneservice服务，满足三个数据模块应用。 2）计算过程数据膨胀 在营销活动分析的场景下，看数据都是基于天猫国际业务类型和行业为大前提，因此通常在离线和实时的计算任务中，我们都是并行同时计算好不同的bu类型和所有的行业粒度的数据，这就导致了计算的过程中的数据的大量膨胀。 3）流批分离 当前产品上根据时间进行选择读取实时数据还是离线数据

目录 前言 正文 前言 WebRTC除了通过API接口控制某些参数外，还能通过SDP信息进行音视频参数的控制，特别是在进行JS SDK开发时，这种情况是非常普遍的。 正文 首先来看一段SDP信息（只包含音频信息）： v=0 o=- 8275923203002055919 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS 6a6d1509-69e0-4fc2-b447-5b4391f9ad69_STS m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 105 13 110 113 126 c=IN IP4 0.0.0.0 a=rtcp:9 IN IP4 0.0.0.0 a=ice-ufrag:QLMT a=ice-pwd:V0cOn+fDmd49138wk42548PU a=ice-options:trickle a=fingerprint:sha-256 6B:CD:36:F6:8D:F1:CB:E7:44:0A:E9:3B:D4:A1:A4:F3:7F:93:9 来源： oschina 链接： https://my.oschina.net/u/4267539/blog/4655229

点击上方「蓝字」关注我们 上一篇我们讲了RTSP PAUSE消息，本篇我们来看下RTSP TEARDOWN消息！ TEARDOWN作用 TEARDOWN是拆卸的意思，对于RTSP而言，就是结束流传输，同时释放与之相关的资源，TEARDWON之后，整个RTSP连接也就结束了！好了，接下来我们来仔细看一下： TEARDOWN格式 首先还是看一下TEARDOWN请求的消息格式： 如图中， TEARDOWN 消息中，指定了 URI ，不用多说了； RTSP版本号 也是我们的老朋友了； CSeq 表示序列号； Authorization 表示认证信息； User-Agent 是用户代理； Session 表示会话ID（SETUP消息请求之后RTSP sever返回的会话id）。 感觉不够直观，哈哈，来来来，抓包献上，分析协议没有抓包总感觉像缺了灵魂： 该TREADOWN消息中，消息序列号为10，用户代理为LibVLC/3.0.11，这是我们使用VLC播放器rtsp流的一个代理，消息序列号为10， Session为之前SETUP请求后服务端返回的session字段的值，用于表示此次会话连接！ 发出去请求后，服务端同样也会回馈response的消息，response的格式如下： 回复消息中包含 RTSP 版本号 ， 状态码 以及针对 状态码的描述 ；同时返回消息的 序列号 （对应请求序列号）以及