通过研究可以发现，IMS客户端和一般的SIP客户端有许多不同之处，它相比一般的SIP客户端而言需要支持更多的功能，也更加复杂，对于IMS终端的要求也更高。其中关键的一点是IMS客户端必须符合IMS相关规范，才能够接入到IMS网络。为用户提供一系列的IMS 服务。 
　　（1）SIP扩展 

　　IMS客户端必须支持SIP扩展部分的有关规范，特别是3GPP所要求的那些SIP包头扩展部分，这样才能访问IMS网络。而一般SIP客户端只需要支持RFC3261。 

　　（2）认证机制 

　　IMS标准中定义了不同的认证机制，如HTTP摘要（RFC2617）、IMS-AKA （RFC 3310和3GPP TS 33.203）和pre-IMS认证（3GPP TR 33.878）等。IMS客户端需要支持更安全的认证方式（如IMS-AKA）才能保证IMS终端和IMS网络之间的安全访问。 

　　（3）IPSec 

　　IPSec在IP层上提供了多种安全机制，用于保证用户客户端和安全网关之间的安全通信。在IMS客户端和P- CSCF之间建立一个安全的IPSec通道，能确保IMS客户端安全地接入到IMS网络中，这个通道是在IMS注册过程中建立起来的，而一般SIP客户端不需要支持这种特性。 

　　（4）包压缩功能 

　　SIP包压缩能改善服务质量，特别是在无线环境下大大缩短呼叫建立时间。通过压缩网络和传输协议中的包头，能更有效地利用带宽，对SIP/SDP消息的压缩也提高了无线资源利用率。IMS客户端一般都是通过移动无线方式接入IMS网络的，所以包压缩的功能是必须的。而一般SIP客户端是通过宽带接入，所以不需要支持这个特性。 

　　（5）前提条件下的QoS保证 

　　前提条件下的QoS保证是指在会话建立过程中，必须在确保双方端到端的服务质量所需的媒体资源得以预留后，才能成功地建立起会话。比如在视频呼叫建立中，该机制用以验证会话中是否已经获得恰当的端到端服务质量。但是，这种机制比较复杂，延长了会话建立的时间。因此，仅在必要的时候，IMS客户端才会打开这种机制。 

　　（6）发现机制 

　　P-CSCF是IMS客户端访问IMS网络惟一的接入点，所有从IMS客户端来的SIP信息都必须经过P-CSCF。所以，在SIP信息发送前，IMS客户端必须知道P-CSCF的地址。该地址不是预先配置好的，而是IMS客户端通过发现机制而获得的。这些机制包括基于 OTA（空中下载）供给、基于GGSN（gateway GPRS support node，GPRS网关支持节点）和基于DHCP的P-CSCF发现机制，除非是手工地配置P-CSCF信息，否则IMS客户端必须支持这个功能。 

　　（7）IPv4/v6的支持 

　　一般SIP客户端只支持IPv4，但是3GPP最初规定IMS客户端应当支持IPv6。如果IMS核心网是IPv4和IPv6双栈，只支持IPv4的IMS客户端也能接入到这样的IMS网络中。 

　　（8）ISIM卡的支持 

　　IMS客户端通过ISIM（IMS subscriber identity module）卡中的信息来认证和注册到IMS网络。ISIM卡中包括了用户的私有身份、公共身份、家乡域、密钥等与认证和注册相关的重要信息。如果是 USIM（universal subscriber identity module）卡，也可以通过相关的算法推导出类似信息。但是IMS终端种类是多样性的，对非IMS移动终端，ISIM卡的支持不是必须的，可以通过其他方式实现IMS网络认证和注册。 

　　（9）CS域和IMS的结合应用 

　　3GPP中定义了CSI（combining CS bearer with IMS），即电路交换（circuit switch，CS）域和IMS的结合应用。IMS客户端间语音呼叫仍然使用CS域，同时利用分组交换（packet switch，PS）域传送非实时媒体流。这样能保证语音质量，提高频谱利用率，解决了目前通过GSM/UMTS传送IP语音包而造成的语音质量下降的问题。CSI的第一阶段不涉及网络侧，主要是IMS客户端间交换终端能力，保持CS域和PS域的同时通信。但是这种服务需要IMS终端支持双传输模式（dual
 transfer mode，DTM）（如果是GERAN接入）或者是MultiRAB（multiple radio access bearer）能力（如果是UTRAN接入），这样才能同时建立PS域会话和CS域通话。 

　　（10）语音无缝切换 

　　语音控制连续性（voice call continuity，VCC）是3GPP提出的解决CS域通话和IMS域会话之间的语音无缝切换的标准。支持VCC服务的IMS客户端和呼叫连续控制服务器配合，能保证用户进入和离开家庭或者办公室里的WLAN（无线局域网）时仍然能保持IMS域或CS域语音呼叫的连续性。但是这种服务要求IMS终端具备多种无线接入能力，如GSM/WLAN双模终端就具备这样的物理条件。 

      
      随着网络技术的迅速发展，传统的视频监控系统也逐步转向网络视频远程监控，网络视频监控系统就是将视频编码设备接入网络，通过网络中心的计算机设备实现视频信号的存储、转发、监看、下载等操作。网络视频监控系统必须要配合网络监控软件使用，网络监控软件主要有两种：一种是编码设备自带的免费客户端软件，另一种是收费的网络视频综合管理平台软件。下面简单介绍一下两种软件的区别：
1、兼容性：
    一般免费的客户端软件只能接入一种网络编码设备，而综合管理平台可以兼容多种型号、品牌的设备，扩容性比较强。
2、网络架构：
    免费的客户端一般为两层架构，即客户端直接访问前端编码器设备；而综合管理平台为三层架构，即所有的客户端访问流媒体转发服务器，由流媒体转发服务器将所有的网络视频信号转发给各个客户端。
    三层架构比两层架构的优势在于：
    
1）、网络安全性提高
    外界通过平台访问设备，只是访问的认证服务器和流媒体服务器，前端设备室屏蔽在流媒体服务器下面的，遭受网络攻击的话，只是流媒体服务器，不会对前端编码设备造成影响，而免费的二层架构，前端编码设备直接暴露在公网下，网络安全性下降。
       2）、设备便于管理
    如果需要添加、删除前端编码设备的话，只需要通过配置管理中心在流媒体转发服务器中添加、删除就可以了，其他都不需要改动，各个用户根据自己的权限，自然就可以看到或看不到新增加的编码设备。而如果用二层架构的免费软件，如果增加设备的话，还得告诉每个用户，记得添加一台设备，IP地址或域名是多少多少；如果是减少一台设备，也得告诉每个用户，那台设备我撤了，不是掉线了等等，太麻烦了。
       3）、用户便于管理
    如果想增加一个用户，删除一个用户或者更改一个用户的权限或密码，只需要通过配置管理中心在认证服务器中直接更改就可以了，其他不用动，但是免费的软件，就麻烦了，如果一个用户离职了，为了保证监控系统的安全，所有设备都需要删除这个用户或更改密码，要增加一个用户也不容易。
       4）、节省带宽
    如果多个用户访问同一路图像，那么流媒体服务器具有组播功能，直接分多份发送给用户，不会占用前端设备的带宽，但是，如果用两层架构的免费软件，前端设备就要发送多份给各个用户，带宽成倍增长。
       5）、登录方便
    使用网络视频综合管理平台软件，不管用户走到哪里，只需要知道认证服务器的IP地址，通过客户端或者IE登录认证服务器就可以了，而二层架构的免费软件想看那个图像，就要知道他的IP地址，如果前端编码设备多的话，使用起来既不方便，效率又低。
    以上可以看出，在多用户、多设备、多功能需求的时候，比较适合应用网络视频综合管理平台。

以太坊客户端Ethereum Wallet与Geth区别简介
最近有不少朋友在搭建交易平台，在咨询和技术交流的过程中发现很多朋友不太清楚Ethereum Wallet和Geth区别。甚至有朋友使用Geth的API接口来调用Ethereum Wallet客户端（本机安装）。那么，今天就给大家简单介绍一下这两个客户端的区别。
Ethereum Wallet简介
Ethereum Wallet客户端对应的是Mist项目，现在此客户端大多都称为Ethereum Wallet，也有称作Mist客户端的，知道它们两个指的是通一个客户端即可。此客户端使用JavaScript进行开发，支持windows、linux和OSX三类操作系统，是一个图形化操作界面的客户端。介绍到这里，大家可能就明白了，如果你想通过API来调用以太坊的接口，选择此方式是行不通的。
Ethereum Wallet客户端主要是为用户提供可视化操作的客户端，下载安装之后通过相应的图形化界面即可进行创建账户、转账、查询余额等操作。
下载地址:https://ethfans.org/wikis/Ethereum-Wallet-Mirror
官网下载地址： https://github.com/ethereum/mist/releases
安装教程:https://ethfans.org/wikis/%E4%BB%A5%E5%A4%AA%E5%9D%8A%E9%92%B1%E5%8C%85%20Mist%20%E4%BD%BF%E7%94%A8%E6%95%99%E7%A8%8B

Ethereum Wallet客户端主要功能
创建账户
兑换以太币：内置了比特币、其它竞争币与以太币兑换功能
部署智能合约：代币合约、众筹合约、自治组织合约等
以太币转账操作
备份钱包
等其他功能 
以上所有功能操作都是启动客户端程序之后，通过操作界面或菜单进行操作。智能合约部分需要事先编写好对应的代码，通过客户端进行发布。
Geth简介
Geth是go-ethereum项目的客户端，也是目前使用最广泛的客户端。支持windows、linux和OSX三类操作系统。针对此系统网上有大量的资料可以参考，github上的wiki文档使用说明也比较详细。
文档地址 https://github.com/ethereum/go-ethereum/wiki
通过此客户端可以进行基本所有的以太坊相关操作。主要功能分三类：
Geth客户端主要功能
JavaScript Console：通过后台进行命令操作；
Management API：管理相关的API；
JSON-RPC server：JSON-RPC相关调用API 
无论通过API或则console都可以进行相关操作，比如：
账号管理（创建账号、锁定账号、解除锁定等）；
查询账户信息；
查询交易信息；
查询gasPrice；
交易；
挖矿&停止挖矿；
部署智能合约
等其他相关功能。
使用Geth客户端可以通过对接API（目前交易平台常常使用的方式），或直接通过命令行进行操作。与Ethereum Wallet相比，没有可视化的操作界面，基本上都是通过命令来完成的。
后语
上面简单介绍了Ethereum Wallet客户端和Geth客户端的应用的对比。Geth客户端API接口封装的JAVA版本正在编写完善，有需要的朋友也可以联系。
 

RTSP、 RTMP、HTTP的共同点、区别

共同点：

1：RTSP RTMP HTTP都是在应用应用层。

2： 理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。

区别：

1：HTTP: 即超文本传送协议(ftp即文件传输协议)。

HTTP:（Real Time Streaming Protocol），实时流传输协议。

HTTP全称Routing Table Maintenance Protocol（路由选择表维护协议）。

2：HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。

RTMP和RTSP协议是流媒体协议。

3：RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。

4：RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。

5：RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。

RTSP、RTCP、RTP区别

1：RTSP实时流协议

作为一个应用层协议，RTSP提供了一个可供扩展的框架，它的意义在于使得实时流媒体数据的受控和点播变得可能。总的说来，RTSP是一个流媒体表示 协议，主要用来控制具有实时特性的数据发送，但它本身并不传输数据，而是必须依赖于下层传输协议所提供的某些服务。RTSP可以对流媒体提供诸如播放、暂 停、快进等操作，它负责定义具体的控制消息、操作方法、状态码等，此外还描述了与RTP间的交互操作（RFC2326）。

2：RTCP控制协议

RTCP控制协议需要与RTP数据协议一起配合使用，当应用程序启动一个RTP会话时将同时占用两个端口，分别供RTP和RTCP使用。RTP本身并 不能为按序传输数据包提供可靠的保证，也不提供流量控制和拥塞控制，这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制，向会话中的 所有成员周期性地发送控制信息，应用程序通过接收这些数据，从中获取会话参与者的相关资料，以及网络状况、分组丢失概率等反馈信息，从而能够对服务质量进 行控制或者对网络状况进行诊断。

RTCP协议的功能是通过不同的RTCP数据报来实现的，主要有如下几种类型：

SR：发送端报告，所谓发送端是指发出RTP数据报的应用程序或者终端，发送端同时也可以是接收端。(SERVER定时间发送给CLIENT)。

RR：接收端报告，所谓接收端是指仅接收但不发送RTP数据报的应用程序或者终端。(SERVER接收CLIENT端发送过来的响应)。

SDES：源描述，主要功能是作为会话成员有关标识信息的载体，如用户名、邮件地址、电话号码等，此外还具有向会话成员传达会话控制信息的功能。

BYE：通知离开，主要功能是指示某一个或者几个源不再有效，即通知会话中的其他成员自己将退出会话。

APP：由应用程序自己定义，解决了RTCP的扩展性问题，并且为协议的实现者提供了很大的灵活性。

3：RTP数据协议

RTP数据协议负责对流媒体数据进行封包并实现媒体流的实时传输，每一个RTP数据报都由头部（Header）和负载（Payload）两个部分组成，其中头部前12个字节的含义是固定的，而负载则可以是音频或者视频数据。

RTP用到的地方就是 PLAY ，服务器往客户端传输数据用UDP协议，RTP是在传输数据的前面加了个12字节的头(描述信息)。

RTP载荷封装设计本文的网络传输是基于IP协议，所以最大传输单元(MTU)最大为1500字节，在使用IP／UDP／RTP的协议层次结构的时候，这 其中包括至少20字节的IP头，8字节的UDP头，以及12字节的RTP头。这样，头信息至少要占用40个字节，那么RTP载荷的最大尺寸为1460字 节。以H264 为例，如果一帧数据大于1460，则需要分片打包，然后到接收端再拆包，组合成一帧数据，进行解码播放。

播放器在功能和性能上具有较高的要求，具体的实现上，需要主要解决的关键技术点主要包括有：多路高清解码、兼顾低时延与流畅性、音视频同步.

多路高清解码

　　多路高清解码播放每路都由多个线程配合来完成整个数据的处理流程，在多路播放的情况下则更为复杂。因此需要在系统的实现上具有高效的多线程管理机制，以及对各模块的组织、内部互联互通上做出良好的设计：

将繁琐的数据处理流程统一成了标准的数据接口，控制管理上方便有效； 

通过engine机制，对单路数据以及播放的管理提供了统一接口，对于多路播放实际上只需要管理多个engine即可；



低时延与流畅

在性能提高上通过减少对内存数据的拷贝以及额外的内存分配开销：

设计回环数据缓冲机制，对应用层输入的数据进行高效的缓存，在传输decode模块时，避免了数据拷贝； 

在数据解码中使用了ffmpeg的directbuffer机制，进一步的避免了数据的拷贝动作； 

数据再各模块之间传递时使用数据缓冲池，避免了额外的内存分配操作，同时也减少了因内存分配操作而带来的内存碎片；

　　在低时延与流畅的平衡性上，通过设置最大缓冲帧数和最小缓冲帧数来实现控制，具体实现策略为：  

　　通过比较待解码缓冲区和解码后还未显示的缓冲区里数据包的个数的和值，如果该值大于最大缓冲帧数，说明有很多数据在缓存里，延迟大了，这时就要加快显示速度（减小output模块的休眠时间），最大缓冲帧数就是影响延迟的；反之一样， 最小缓冲帧数就是流畅的保证，该值越大就越流畅；通过改变这个最大值最小值就可以平衡延迟与流畅。

音视频同步

　　由于声音对时间的敏感性，所以在同步的处理上，系统以声音作为基准来参考，对视频的输出来进行调整，从而保证音视频的同步性，具体实现为：

通过比较音频和视频的时间戳（pts）来对视频的显示速度进行调整，如当前的视频的pts比音频pts大于最小偏差值（目前设置为200MS），说明视频快了，就放慢是视频的显示速度；反之就加快视频的显示速度；但是，如果差距太大（目前设置为1000MS）， 大于最大偏差值时，加快视频的显示速度的效果不明显就采用丢帧方式，这个一般出现再刚开启的是时候。

因此，推荐采用第三方框架 Android VLC，官网地址（http://www.videolan.org/）。官网给力demo很强大，so库里面也实现了抓拍，音量调节，快放慢放等方法。 

也可参考Android大神农民伯伯的博客：http://www.cnblogs.com/mythou/category/505051.html