sip资源预留
Precondtion的定义
建立媒体PDP上下文的过程称为资源预留。
对于双方的UE而言，建立PDP上下文的执行过程是相互独立的。这意味着在资源被成功预留之前，根本无法保证所协商的媒体会话是否可以建立起来。
因此，其作用主要是为了保证在确认本地和主叫方的资源预留都已成功之前，被叫方不应振铃,以最大程度减少被叫方振铃但接听电话又失败的情况
Precondtion流程-流程图
A B
| |
|-------------(1) INVITE SDP1---------------> |
| |
|<------(2) 183 Session Progress SDP2-------- |
| |
|-- -----------(3) PRACK------------- --> |
| |
|<- -------(4) 200 OK (PRACK)-------- --- |
| |
|-------------(5) UPDATE SDP3 ---------------> |
| |
|<--------(6) 200 OK (UPDATE) SDP4----------- |
| |
|<-------------(7) 180 Ringing--------------- |
|
|-----------------(8) PRACK-----------------> |
| |
|<------------(9) 200 OK (PRACK)------------- |
| |
| |
| |
|<-----------(10) 200 OK (INVITE)------------ |
| |
|------------------(11) ACK-----------------> |
| |
| |
普通的呼叫流程如下
A B
| |
|-------------(1) INVITE SDP1---------------> |
| |
| |
|<-------------(7) 180 Ringing--------------- |
| |
| |
|<-----------(10) 200 OK (INVITE)------------ |
| |
|------------------(11) ACK-----------------> |
| |
Precondtion流程-普通流程区别
从两个图来看，两个流程中均用到了offer/answer的机制，precondtion流程在通话前协商了两次（invite-183、update-200ok），而普通的流程只是协商了一次（invite-200ok）。
Precondtion的流程比普通的呼叫流程更安全。Precondtion两次的媒体的协商保证了资源预留成功之后才能振铃接通呼叫，避免了普通流程中通话接通后无声音的情况。
Precondtion的振铃消息采用了100rel的可靠机制，保证主叫侧能正常振铃。普通的呼叫流程中，可能丢失180消息，这种情况导致被叫侧没有振铃声，但是可以正常接通的异常情况
Precondtion流程-相关包体
INVITE：
a=curr:qos local none
a=curr:qos remote none
a=des:qos none local sendrecv
a=des:qos optional remote sendrecv
183：
a=curr:qos local none
a=curr:qos remote none
a=des:qos none local sendrecv
a=des:qos optional remote sendrecv
a=conf:qos remote sendrecv
Update
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos none remote sendrecv
200ok
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos none local sendrecv
a=des:qos optional remote sendrecv
Precondtion流程-相关头域
主叫precondtion
当终端做主叫，要求precondtion，那么在invite消息中必须携带两个头域，一个头域support：precondtion
100rel；另外的一个头域是require：precondtion
被叫precondtion
当终端收到invite消息中，其中携带了require：precondtion消息，终端必须回复18*消息，并在该消息中携带
头域require：100rel。
precondtion流程的相关头域信息，只是在流程中第一个offer/answer中，在第二个offer/answer中没有相关头域的出现。在update-200ok中没有相关头域出现
Precondtion的分类
端到端
端到端状态值表示端到端的资源预留状态,
“e2e”表示:端到端 .端到端状态用于端到端资源
预留机制
分段
分段状态值表示两个UA的接入的网络侧的资
源预留状态. local“和”remote“表示:分段状态. .分段状用
于一个或两个UA在接入网中分别执行资源预留 。（高阳终端现在是分段的资源预留）
相关的sdp参数
当前状态:current-status = "a=curr:" precondition-type
SP status-type SP direction-tag
期望状态:desired-status = "a=des:" precondition-type
SP strength-tag SP status-type
SP direction-tag
确认状态:confirm-status = "a=conf:" precondition-type SP status-type SP direction-tag
预置条件处理类型:
precondition-type = "qos" | token
强度标志:
strength-tag = ("mandatory" | "optional" | "none"
= | "failure" | "unknown")
状态类型:
status-type = ("e2e" | "local" | "remote")
方向标志:
direction-tag = ("none" | "send" | "recv" | "sendrecv")
概念介绍：方向标志表示特定属性(当前,期望和确认状态)可以使用的方向."send","recv","local"和"remote"表示SDP描述中的方向表示.在offer中,"send"表示offer方->answer方,"local"表示offer方的接入网络.在answer中,"send"表示answer方->offer方,"local"表示answer方的接入网络.
实例分析
invite
a=curr:qos local none
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos none remote sendrecv
Invite中sdp代表：第一个a行=本地qos资源现在还没有资源预留，第二个a行：远端qos资源现在没有资源预留；第三个a行：本地预期的qos资源是双向的资源预留，强度是可选。第4个a行：远端预期的qos资源是双向的资源预留，强度为none。
183：
a=curr:qos local none
a=curr:qos remote none
a=des:qos none local sendrecv
a=des:qos optional remote sendrecv
a=conf:qos remote sendrecv
被叫回复183消息，展示被叫的资源预留的现状和预期。第一个offer/answer结束，但是资源预留并没有结束。183消息总增加了conf行。要求对方达到确认行中条件的时候发送确认消息给自己
Update
a=curr:qos local sendrecv
a=curr:qos remote none
a=des:qos optional local sendrecv
a=des:qos none remote sendrecv
当主叫终端满足条件时：Update中第一个a行a=curr:qos local sendrecv与183消息中conf a行中的条件一致。主叫终端发送update消息。标志自己完成了资源预留
200ok
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos none local sendrecv
a=des:qos optional remote sendrecv
资源预留成功，你听到振铃了么？
构造的规则
生成一个offer
对于分段状态类型。必须生成两个当前状态行: 一行带标志"local",另一行带标志"remote".每个分段(如:本端和远端),UA必须添加一个或两个期望状态行.对于某个特定的分段(本端或远端),事务状态表中两个方向的标志相同(如:都是"mandatory"),UA必须添加一带"sendrecv"标志的期望状态行.如果两个标志不同,则UA生成两期望行,一行带标志"send",另一行带"recv"标志.
生成一个answer
关于期望强度:我们定义了一由弱到强的顺序:"none","optional"和"mandatory"."Mandatory"是最高级标志,"none"是最低级标志.某个answer方可以提升级别,但不能降低此级别.因此,由"none"到"optional",由"none"到"mandatory",或由"optional"到"mandatory",都有允许的,反之不可以.
异常处理
预置条件不满足
当前充当answer方的UAS不能或不想满足offer中的预置条件时,它应该使用回送580响应拒绝offer.
Server-Error = "580" ;Precondition Failure
拒绝一个媒体流
在offer/answer模型中,answer方想拒绝一个媒体流时,它可以把相应的端口号设置为0.预置条件处理时不能改变此值;端口号设置为0的流仍被拒绝.
不论是offer方还是answer方都必须忽略对端口号为0的流的预置条件处理.它们不对恢复会话建立产生影响.
未知的预置条件类型
一个UA在offer中收到一个强度标志为"mandatory"的预置条件,但又不能识别它,此UA必须拒绝此offer,一个UA按照8节中规则拒绝未知的offer,只是把"failure"改为"unknown"标志,如下所示:
m=audio 20000 RTP/AVP 0
a=des:foo unknown e2e send