微信视频聊天信令分析
VOLTE-SIP完整信令解析
VOLTE-SIP完整信令解析1.主叫与被之间的SIPSIPSIP呼叫业务流程如下：呼叫业务流程如下：2. SIP信令完整解析：(1). 用户 A ，摘机对用户 B 发起呼叫，用户 A 首先向 AS 服务器发起 INVITE 请求。
(2). AS 服务器回复 100 Trying 给用户 A 说明收到 INVITE 请求。
(3). AS 服务器通过认证确认用户认证已通过后，向被叫终端 B 转送 INVITE 请求。
(4). 用户 B 向 AS 服务器送呼叫处理中的应答消息， 100 Trying 。
(5). 用户 B 向 AS 服务器送 183 Session Progress 消息，提示建立对话的进度信息。
（此时被叫 QCI1 专用承载建立）(6). AS 服务器向主叫终端 A 转送 183 Session Progress 消息，终端 A 了解到整个 Session 的建立进度消息。
(7). 终端A 向AS 服务器回复临时应答消息PRACK ，表示收到183 Session Progress 消息。
（此时主叫 QCI1 专用承载建立）(8). AS 服务器向被叫终端 B 转送临时应答消息 PRACK ，终端 B 了解到终端 A 收到 183 Session Progress 消息。
(9). 被叫终端B 向AS 服务器发送200 OK 消息，表示183 Session Progress 请求已经处理成功。
(10). AS 服务器向主叫终端 A 转送 200 OK 消息。
(11). 主叫终端 A 向 AS 服务器发送 UPDATE 消息，意在与被叫终端 B 协商相关 SDP 信息。
(12). AS 服务器向被叫终端 B 转送 UPDATE 消息。
(13). 被叫终端 B 向 AS 服务器发送 200 OK 消息，表示 UPDATE 请求已经处理成功。
( 14). AS 服务器向主叫用户 A 转送 200 OK 消息，通知用户 AUPDATE 请求已经处理成功。
vonr语音通话的sip信令流程
vonr语音通话的sip信令流程
Vonr语音通话采用SIP(SessionInitiationProtocol)协议进行信令传输，下面是SIP信令流程的简要介绍：
1. 呼叫发起：用户A发起呼叫，向SIP服务器发送INVITE请求。
2. 呼叫转移：如果用户B在呼叫转移状态，则呼叫会被转移到用户C，此时SIP服务器会向用户C发送INVITE请求。
3. 呼叫确认：用户C收到INVITE请求后，会向SIP服务器发送200 OK响应，表示确认呼叫。
4. 媒体协商：在呼叫确认后，用户A和用户C需要协商音视频编解码器、分辨率等媒体信息。
5. 媒体传输：协商完成后，用户A和用户C开始进行音视频传输。
6. 呼叫结束：当通话结束时，用户A或用户C会向SIP服务器发送BYE请求，SIP服务器会向另一方发送200 OK响应，表示呼叫结束。
以上是Vonr语音通话的SIP信令流程概述，具体实现可能会有所不同。
- 1 -。
5G微信小视频卡顿影响感知案例
1、问题现象新开通SA站点，有用户投诉反映，使用微信发送小视频时延卡顿时间较长，需要分析原因。
2、问题分析2.1，基础排查后台查询站点状态正常，无告警。
需要使用Probe 对问题进行测试分析。
2.2，Probe信令分析通过信令分析，发现200M 3分钟左右的视频微信打开下载花了大概8~9s，与Probe测试观察到的速率相符。
Probe上看速率大概25M；从probe上可以看到此时调度的GTANT和RB都很少。
2.3，终端抓包分析从终端侧抓包来看，并不没有丢包乱序，但发包并不连续。
发几个包停一会，发几个包停一会且很规律，如果没有丢包乱序正常不应该出现这样的情况。
应该和服务器发包有关。
从时序图可见数据下载是不连续的，下一段数据开始需要从下一个Post Download 请求开始；说明小视频下载走的是HTTP 协议，并不是FTP 协议。
这个离线的视频是下载完才能播放所以要等所有的都下载完才能播放。
必然会增大时延。
第一个HTTP Post 里面的rang 是从0~131071；服务器端开始发数据，数据发完后回200 Ok 说明这一段数据已发完，并带total size 告诉终端一共有多少包；前景理论公众号公司锚点站点上层指示开关均已打开，占用锚点即终端显示5G 标识。
（终端显示5G 标识时，存在非占用5G 情况）接下来第二次发post 请求下一段数据，从131072 开始以此类推。
直到之后一次200 OK 已确认数据包发完，发FIN ACK 拆链；3、问题根因微信发送小视频使用HTTP 协议一段下载完再下载下一段，每段下载完成需要等一个RTT 才能开始下载下一段。
200M 的视频被分成200 段下载，导致下载完整段视频需要200*RTT+数传时间。
导致小视频下载卡顿时间较长。
4、解决方案当前APP 的实现机制无法从网络侧解决。
5、总结反思此问题已经在全省预警，已经在投诉组宣贯，写入《投诉问题汇总快速查询表》，后期遇到此类问题的投诉可以快速查询投诉问题汇总表，提高投诉响应时间及客户满意度。
视频通话分析
视频通话分析1：IP网络通讯协议在传统电话系统中，一次通话从建立系统连接到拆除连接都需要一定的信令来配合完成。
同样，在IP电话中，如何寻找被叫方、如何建立应答、如何按照彼此的数据处理能力发送数据，也需要相应的信令系统，一般称为协议。
目前在国际上，比较有影响的IP电话方面的协议包括ITU-T提出的H.323协议和IETF提出的SIP协议。
而MGCP主要应用于运营商市场，在行业市场鲜有应用。
1.1：协议概要分析1.1.1：H323协议H.323是ITU-T第16工作组的建议，由一组协议构成，其中有负责音频与视频信号的编码、解码和包装，有负责呼叫信令收发和控制的信令，还有负责能力交换的信令。
H.323的第4版本具备做电信级大网的特征，以它为标准构建的IP电话网能很容易地与传统PSTN（公共交换电话网络）电话网兼容，从这点上看，H.323更适合于构建电话到电话的电信级大网。
H.323协议族规定了在主要包括IP网络在内的基于分组交换的网络上提供多媒体通信的部件、协议和规程。
H.323一共定义了四种部件：终端，网关，网守和多点控制单元。
利用它们，H.323可以支持音频、视频和数据的点到点或点到多点的通信。
H.323协议族包括用于建立呼叫的H.225.0、用于控制的H.245、用于大型会议的H.332 以及用于补充业务的H.450.X等。
H.323 协议中包含3条信令控制信道：RAS (R=注册:Registration、A=许可:Admission 和S=状态:Status)信令信道、呼叫信令信道和H.245 控制信道。
3 条信道的协调工作使得H.323的呼叫得以进行。
H.323建议是一个较为完备的建议书，它提供了一种集中处理和管理的工作模式，这种工作模式与电信网的管理方式是匹配的，这就是为什么电信网中使用的IP电话几乎无例外地都采用了基于H.323的IP电话工作模式｡1.1.2：SIP协议SIP协议，即Session Initiation Protocol，是另一套IP电话的体系结构,是一个与H.323并列的协议。
VoLTE基础信令流程与详细解析
VOLTE信令流程VOLTE是基于SIP协议的语音通话，所有与IMS交互的信令全部为SIP信令，在理解VOLTE信令方面必须对SIP信令进行了解，EPC只是做为业务承载体。
由于SIP信令是以加密方式传输，SIP信令只有在CN侧和终端侧才能解码，基站CDL无法记录SIP信令，同时CDL 无法解码较多NAS层直传消息，所以本文中的信令说明部分不结合CDL信令进行说明1.注册流程及重要信令详解SIP 提供了发现机制，如果用户要发起和另一个用户的会话，SIP 必须发现可到达目的用户的当前主机，注册将记录地址URI 和一个或者多个联系地址相关联，这样才能进行呼叫等业务。
严格意义上说，SUBSCRIBE和NOTIFY过程不属于注册过程，但由于该过程在注册完成后紧跟着出现，所以本文将该过程放在注册流程中进行说明。
用户的注销过程与注册过程相似，主要就是注销请求中,expire值为0，所以本文中不再进行单独说明，注销过程无SUBSCRIBE信令，是因为UE注册时已有SUBSCRIBE。
信令说明如下：1.UE进行Attach，建立QCI=9的默认承载，并使用IMS APN建立PDN连接；2.建立立QCI=5的默认承载，用于传送SIP信令；3.UE通过QCI=5的默认承载向IMS发起注册请求；4.P-CSCF通过HSS获知用户信息不在数据库中，便向终端代理回送401 Unauthorized 质询信息，其中包含安全认证所需的令牌；5.终端将用户标识和密码根据安全认证令牌加密后，再次用REGISTER消息报告给P-CSCF服务器；6.P-CSCF将REGISTER 消息中的用户信息解密，验证其合法后，IMS核心网将该用户信息登记到数据库中，并向终端返回成功响应消息200 OK；7.用户向IMS订阅注册事件包8.服务器应答订阅成功9.IMS服务器发送notify消息，由于订阅的用户已经注册，所以IMS服务器回应Notify消息中，状态为active，同时携带XML信息10.终端发送Notify 200表示接收成功注册过程测试信令载图如下：注销过程测试信令截图如下：1)Activate Default EPS Bearer Context Request（QCI=5）该信令是用于建立QCI=5的默认承载，所有SIP信令都通过QCI=5的承载传输，该信令的内容已在该信令前的RRC重配置中附带下来。
sip协议的6种信令及功能
sip协议的6种信令及功能SIP协议是一种基于文本的协议，用于建立、修改和终止多媒体会话，包括语音、视频、即时消息和文件传输等。
SIP协议主要由6种信令组成，分别是INVITE、ACK、BYE、CANCEL、OPTIONS和REGISTER。
下面将详细介绍这6种信令的功能及使用场景。
一、INVITE信令INVITE信令是SIP协议中最重要的信令之一，它用于邀请一个用户参与一个会话。
当发起方想要建立一个新的会话时，它将发送一个INVITE请求给接收方，请求接收方加入该会话。
接收方可以选择接受或拒绝该请求。
如果接收方接受了请求，则将使用SDP协商来确定会话的参数。
使用场景：1.建立语音或视频通话；2.发起一个即时消息对话；3.创建文件传输会话。
二、ACK信令ACK信令是SIP协议中的确认信号，用于确认已经成功处理了先前发送的INVITE请求。
当接收方已经成功地响应了INVITE请求后，发起方需要发送ACK请求来确认它已经收到了响应，并且已经准备好开始通话。
使用场景：1.确认已经成功处理了先前发送的INVITE请求；2.开始语音或视频通话。
三、BYE信令BYE信令用于终止一个会话。
当一个用户想要结束会话时，它将发送一个BYE请求给另一个用户，以告知对方该会话已经结束。
接收方收到BYE请求后，也将发送一个BYE请求作为确认，并关闭所有相关的资源。
使用场景：1.结束语音或视频通话；2.结束即时消息对话；3.结束文件传输会话。
四、CANCEL信令CANCEL信令用于取消尚未完成的INVITE请求。
当发起方发送了INVITE请求但尚未收到响应时，它可以发送CANCEL请求来取消该请求。
接收方收到CANCEL请求后，将停止处理相关的INVITE请求。
使用场景：1.取消尚未完成的INVITE请求；2.中止正在进行的呼叫。
五、OPTIONS信令OPTIONS信令用于查询远程用户支持哪些功能和协议。
当一个用户想要了解另一个用户支持哪些功能和协议时，它可以发送OPTIONS请求来查询这些信息。
[微信协议分析]多媒体
![[微信协议分析]多媒体](https://img.taocdn.com/s3/m/78020a63f342336c1eb91a37f111f18583d00c6b.png)
[微信协议分析]多媒体声明：微信客户端协议是⼆进制协议⽽且加密，难以分析协议具体编码格式，我不做逆向⼯程。
只是简单抓包分析业务的实现流程，在这⾥记录下来⽤于参考学习，并不是破解协议。
语⾳⽚断语⾳⽚断的发送、接收都是通过长连接分包进⾏:发送：语⾳录制过程中，客户端每2秒发⼀次，每次2.5K左右接收：服务器将语⾳分⽚⽂件整体当成⼀条消息，和⽂本消息⼀样的⽅式推送总结，语⾳分⽚发送和⽂本相差不⼤，只是语⾳因为体积较⼤，录制过程中会同时上传操作，加快发送速度，取消时，删除已上传部分即可。
图⽚、视频⽚断、⼩视频都是⽂件类型，相同处理⽅式：发送：https短连接，不⾛长连接，所有发送完后SyncKey 会通过长连接回推接收：通过长连接接收图⽚的缩略图、视频截图 +下载地址，⽤户点击图⽚时，⾛https下载原图、视频⽂件实时对讲长连接⽤于对讲会话的建⽴和维护信令传输，语⾔通过UDP中转。
测试的两个客户端都在同⼀个路由器下⾯，但数据流量都是通过140.206.160.179 上海联通的服务器做中转，也就是没有做p2p直传。
对讲机同时只有⼀个⼈说话，多⼈同时说话需要做混⾳、降噪、回声消除等，对讲机的⾳质应该会更可控吧⼆⼈⾳视频会话建⽴过程应该和SIP 差不多，通过长连接发起会话邀请-回铃-接听-数据传输不同的是，⼆⼈⾳视频会⾛p2p，⽽且在发起邀请后就开始打洞，并且在对⽅接听前，也会不断的传输udp包，应该是探测p2p路径的可靠性和速率。
udp的路径选择：- 对于微信，⾳视频通话服务器带宽成本会特别⾼，p2p能节省巨⼤成本- p2p⼀般都要⽐服务器中转要好，但 p2p 建⽴较为耗时，所以在邀请阶段就开始p2p打洞- p2p速率也并不⼀定要⽐服务器中转好，最好在通话过程中，也能动态切换使⽤的链路。
微信业务测试分析
微信业务测试分析本次微信业务分析主要针对微信业务中的语音聊天功能传输速率进行分析。
观察微信业务信令流程，并对语音传输状态和挂机状态数据传输速率进行对比分析。
微信业务主要信令流程分析下图为用户微信登陆信令流程及相应信令参数：DNS流程用户消息上传流程由上图看出，用户登陆微信前须先进行DNS流程，之后为用户登陆消息的上传流程，登陆主要URI为。
用户语音上传及接收流程：用户语音接收语音上传在用户登陆成功之后，便发起语音聊天业务。
上图为部分信令流程，可见聊天过程均为一些HTTP形式的分包。
微信业务为HTTP业务的一部分。
总业务流量概况测试记录如下：time 业务行为 消息时长（s ） 17:03 开启微信业务并发送消息 4 17:06 重新获取好友消息、发送消息 5 17:07 收到消息 3 17:09 收到消息 2 17:09 发送消息 6 17:10 发送消息 12 17:10 收到消息 7 17:10 收到消息 2 17:12 发送消息 28 17:12 关闭微信业务测试过程总流量情况：参数 参数值 下行总流量 33.1Kbyte 上行总流量 66.42Kbyte GB 总业务时长 613s总流量分时分布如下：（图中横坐标为时间，纵坐标为流量：kbit ，统计粒度为1s ）上图中看出，流量分布较高时段均对应有业务行为时段。
上下行传输速率分时分布分析 上行传输速率分时分布：10203040506017:03:4417:04:0617:04:2817:04:5017:05:1217:05:3417:05:5617:06:1817:06:4017:07:0217:07:2417:07:4617:08:0817:08:3017:08:5217:09:1417:09:3617:09:5817:10:2017:10:4217:11:0417:11:2617:11:4817:12:1017:12:3217:12:5417:13:1617:13:38总业务流量分时分布总业务流量分时分布kbit从上图可以看出，上行传输速率较高时段均对应微信登陆及语音消息发送业务行为，微信登陆上行传输速率为7-8kib/s 左右，语音消息发送传输速率主要在9-14kbit/s 左右。