FreeSWITCH中文网,电话机器人开发网 ,微信订阅号：
FreeSWITCH及VOIP,Openser,电话机器人等产品中文技术资讯、交流、沟通、培训、咨询、服务一体化网络。QQ群：293697898
FreeSWITCH及VOIP,Openser,电话机器人等产品中文技术资讯、交流、沟通、培训、咨询、服务一体化网络。QQ群：293697898
emsp;emsp;经常有人问我，为什么使用手机对打视频电话要比使用微信等第三方工具感觉上更流畅和清晰？
emsp;emsp;这里有许多原因，当然是我们这种没有经过运营商不管是信令层还是哪一层培训的人的一些自我理解，不一定对，如果有问题，请大家指正。
其一、传输
在VoLTE (Voice over LTE) 中，语音、视频和IP数据流的QoS层级是通过不同的QCI值和相关的QoS参数来区分的。每种服务类型都有特定的QoS需求，以确保其在LTE网络中的优先级、带宽、延迟等要求。
下文中的相关参数由AI生成，有些不一定对，但是基本的概念还是有的。
优先级: 非常高
延迟要求: < 100 ms
保证比特率 (GBR): 是
适用服务: 实时语音通话
Packet Delay Budget (PDB): 100 ms
Packet Error Loss Rate (PELR): 10^-2
用途: 确保语音通信的高优先级、低延迟和高可靠性。
优先级: 高
延迟要求: < 150 ms
保证比特率 (GBR): 是
适用服务: 实时视频通话
Packet Delay Budget (PDB): 150 ms
Packet Error Loss Rate (PELR): 10^-3
用途: 确保视频通信的足够带宽、适度延迟和较低的丢包率。
优先级: 中等到低
延迟要求: > 150 ms（具体取决于QCI值）
保证比特率 (GBR): 否（通常为非GBR服务）
适用服务: 非实时的互联网访问、文件传输等
Packet Delay Budget (PDB): 300 ms 或更高
Packet Error Loss Rate (PELR): 10^-6 或更低
用途: 满足一般数据流需求，保证合理的带宽和延迟。
其二、应用权限
不管是哪种手机，我们一般应用时，电话这作为手机的独立应用，它的权限是我们理解的最高的，那种专有的，或者开发模式下的，不属于我们讨论范畴。
结论：
按以上描述来说，传输时的Qos决定了我们能改变的部分的能力，但是在传输协商时，到底具备不具备视频条件，总不能我们直接就把视频怼上去？这里就牵扯到了sip precondition。
Prcondition的作用
在SIP中，Precondition 是一种机制，用于确保在会话实际建立或修改之前，某些条件（如带宽、QoS（服务质量）参数）已经得到满足。这种机制常用于需要确保媒体路径上的资源或其他条件被正确分配的场景中，以避免在会话建立后发现条件不满足导致服务中断或质量问题。
Precondition 机制通常涉及以下几个步骤：
初始Offer/Answer交换：在建立会话或修改会话的最初阶段，发送方会在SDP（Session Description Protocol，会话描述协议）中标注某些资源或条件需要满足的Precondition。
确认条件：接收方收到带有Precondition的SDP后，将尝试满足这些条件，如确保媒体路径上的资源已被正确分配。一旦条件满足，接收方将发送一个响应，表明条件已满足。
最终确认：当所有参与方都确认条件已经满足后，正式建立或修改会话。
SIP中的Precondition机制规范 Precondition机制主要定义在以下几个RFC（Request for Comments）规范中：
RFC 3312 - Integration of Resource Management and Session Initiation Protocol (SIP)
该文档定义了如何在SIP中使用Precondition机制，具体描述了如何在SDP中表达和协商需要满足的条件，如网络资源的可用性。
RFC 4032 - Update to the Session Initiation Protocol (SIP) Preconditions Framework
对RFC 3312进行了一些更新，主要涉及Precondition框架的使用和实现细节。
RFC 5027 - Security Preconditions for Session Description Protocol (SDP) Media Streams
该文档描述了如何在SDP媒体流中使用安全性Precondition，以确保在会话建立前，必要的安全性参数已经满足。
诸如：
**SDP1**: A在初始offer中包含了端到端qos预条件。
```
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
```
**SDP2**: 由于B使用RSVP，它可以知道在其“发送”方向上的资源何时可用，因为它将从网络接收到RESV消息。然而，它不知道另一方向的预留状态。B在其answer中向对等用户代理A请求接收方向资源预留的确认。
```
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recv
```
发送answer后，B开始为媒体流预留网络资源。当answer到此answer（2）时，它也开始执行资源预留。两个用户代理都使用RSVP，因此A向B发送PATH消息，B向A发送PATH消息。
随着时间的推移，B收到RESV消息确认预留。然而，B等待另一方向上的资源也被预留，因为它没有收到任何确认，预条件仍然没有满足。
**SDP3**: 当A收到RESV消息时，它向B发送一个更新的offer（5）：
```
m=audio 20000 RTP/AVP 0
c=IN IP4 192.0.2.1
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecv
```
**SDP4**: B返回一个answer（6），其中包含资源预留的当前状态（即sendrecv）：
```
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.4
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecv
```
此时，会话建立恢复，B返回一个180（振铃）响应（7）。
再次结论：
emsp;emsp;如果不能很好地结合实际的4G、5G相关接通前的Precondition，那么大量视频呼叫根本就不可能接通。而在各开源的产品中，不是对于Precondition不支持，而是没办法支持，这部分能力属于运营商预留的资源协商部分，开源产品想支持也无从支持，只能自个动手搓协议栈后，一步一步跟踪，但这样的话，这是个很巨大的坑，人力、物力、财力的消耗不是一点两点。