P-CSCF如何根据SDP参数的取值映射到Rx接口的Flow Status参数？
来自知识星球
P-CSCF如何根据SDP参数的取值映射到Rx接⼝的Flow Status参数？
这个问题的背景是：
1）5GC要为上层语音业务建专有Qos流（GBR）来提供Qos保证；
2）而上层的语音业务Qos是通过协商的SDP结果来确定Qos的；
3）因此，P-CSCF要做一件事情，就是把SDP中的参数，映射到Rx接口（以后是基于SBI的N5接口）的
Diameter参数中，发给PCF来执行策略，并触发专有Qos流的建立。
如何映射的规则在TS29.513的7 QoS Parameters Mapping中有详细介绍。
The main purpose of these mapping functions is the conversion of QoS parameters from one format to
another. QoS information may be:
• parts of a session description language (SDI), e.g. SDP, MPD;
• QoS parameters; and
• access specific QoS parameters.
• One QoS mapping function is located at the AF, which maps the application specific information into
the appropriate information that are carried over the Rx as specified in 3GPP TS 29.214 or N5
interface as specified in 3GPP TS 29.514.
• When the AF interworks with the PCF using the Rx interface, it shall derive a Media-Component-
Description AVP from the SDP parameters for each SDP media component using the same mapping
rules as defined in clause 6.2 of 3GPP TS 29.213.
这些映射功能的主要目的是将QoS参数从一种格式转换为另一种格式。QoS信息可以是：
• 会话描述语言（SDI）的一部分，例如SDP，MPD；
• QoS参数；以及
• 特定接入的QoS参数。
• 一个QoS映射函数位于AF，它将特定于应用的信息映射为适当的信息，这些信息通过Rx接口（如
3GPP TS 29.214中所述）或N5接口（如3GPP TS 29.514中所述）承载。
• 当AF使用Rx接口与PCF互通时，它应使用与3GPP TS 29.213第6.2条中定义的相同映射规则，从每个
SDP媒体组件的SDP参数中导出Media-Component-Description AVP。
可以看到，规范明确提到，SDP中的参数需要映射到Rx接口的Media-Component-Description AVP。
而Media-Component-Description AVP是由一大堆的子AVP构成的。
其中有一个子AVP叫Flow Status AVP，用于门控策略，指示上行和下行的业务流是否允许通过。Flow
Status AVP有四个取值，如下：
• ENABLED-UPLINK：上行使能，下行去使能。
• ENABLED-DOWNLINK：上行去使能，下行使能。
• ENABLED：上下行方向均使能。
• DISABLED：上下行方向均去使能。
那它是怎么根据SDP的参数映射的呢？
在29.513的Table 7.2.3-1: Rules for derivation of service information within Media Component
Description from SDP media component中明确给出了答案。
映射规则是表格中右侧的一段伪代码，代码如下：
”IF port in m-line = 0 THEN
"fStatus" := REMOVED;
ELSE
IF Transport in m-line is "TCP" or "TCP/MSRP" THEN (NOTE 9)
"fStatus" := ENABLED;
ELSE /* UDP or RTP/AVP transport
IF a=rtcp-mux is negotiated THEN
"fStatus" :=ENABLED; (NOTE 12 and 13)
ELSE
IF a=recvonly THEN
IF <SDP direction> = UE originated (NOTE 8) THEN
"fStatus" := ENABLED-DOWNLINK; (NOTE 4)
ELSE /* UE terminated (NOTE 8) */
"fStatus" := ENABLED-UPLINK; (NOTE 4)
ENDIF;
ELSE
IF a=sendonly THEN
IF <SDP direction> = UE originated (NOTE 8) THEN
"fStatus" := ENABLED-UPLINK; (NOTE 4)
ELSE /* UE terminated (NOTE 8) */
"fStatus" := ENABLED-DOWNLINK; (NOTE 4)
ENDIF;
ELSE
IF a=inactive THEN
"fStatus" :=DISABLED;
ELSE /* a=sendrecv or no direction attribute */
"fStatus" := ENABLED (NOTE 4)
ENDIF;
ENDIF;
ENDIF;
ENDIF;
ENDIF;
ENDIF;“
这段伪代码描述了一个根据SDP（Session Description Protocol）信息设置媒体流状态（"fStatus"）的逻
辑。 解读如下：
「1. 整体逻辑」
这段代码的核心目的是根据SDP协商的结果，确定媒体流的状态 "fStatus"。这个状态可能是
"REMOVED"、"ENABLED"、"ENABLED-DOWNLINK"、"ENABLED-UPLINK" 或 "DISABLED"。
「2. 逐行解读」
• 「IF port in m-line = 0 THEN」
• 检查SDP中 m= 行（媒体描述行）的端口号是否为0。
• 如果端口号为0，表示该媒体流被拒绝或移除。
• 「"fStatus" := REMOVED;」
• 将媒体流状态设置为 "REMOVED"。
• 「ELSE」
• 如果端口号不为0，继续执行以下逻辑。
• 「IF Transport in m-line is "TCP" or "TCP/MSRP" THEN (NOTE 9)」
• 检查 m= 行中的传输协议是否为 "TCP" 或 "TCP/MSRP"（Message Session Relay Protocol）。
• 「"fStatus" := ENABLED;」
• 如果传输协议是 "TCP" 或 "TCP/MSRP"，将媒体流状态设置为 "ENABLED"。
• 「ELSE /* UDP or RTP/AVP transport」
• 如果传输协议不是 "TCP" 或 "TCP/MSRP"，则假定它是 "UDP" 或 "RTP/AVP"（或其他基于UDP
的协议）。
• 「IF a=rtcp-mux is negotiated THEN」
• 检查SDP中是否协商了 a=rtcp-mux 属性。
• a=rtcp-mux 表示RTCP（RTP Control Protocol）和RTP（Real-time Transport Protocol）数据
包在同一个端口上复用。
• 「"fStatus" :=ENABLED; (NOTE 12 and 13)」
• 如果协商了 a=rtcp-mux，将媒体流状态设置为 "ENABLED"。
• 「ELSE」
• 如果没有协商 a=rtcp-mux，继续执行以下逻辑。
• 「IF a=recvonly THEN」
• 检查SDP中是否存在 a=recvonly 属性。
• a=recvonly 表示媒体流是单向的，只接收数据。
• 「IF <SDP direction> = UE originated (NOTE 8) THEN」
• 检查SDP协商的方向是否为UE发起（User Equipment originated）。
• 「"fStatus" := ENABLED-DOWNLINK; (NOTE 4)」
• 如果是UE发起，将媒体流状态设置为 "ENABLED-DOWNLINK"，表示数据流向UE（下
• 「ELSE /* UE terminated (NOTE 8) */」
• 如果不是UE发起，则认为是UE终止（User Equipment terminated）。
• 「"fStatus" := ENABLED-UPLINK; (NOTE 4)」
• 如果是UE终止，将媒体流状态设置为 "ENABLED-UPLINK"，表示数据流向网络（上
• 「ENDIF;」
• 结束 <SDP direction> 的判断。
• 「ELSE」
• 如果不是 a=recvonly，继续执行以下逻辑。
• 「IF a=sendonly THEN」
• 检查SDP中是否存在 a=sendonly 属性。
• a=sendonly 表示媒体流是单向的，只发送数据。
• 「IF <SDP direction> = UE originated (NOTE 8) THEN」
• 检查SDP协商的方向是否为UE发起。
• 「"fStatus" := ENABLED-UPLINK; (NOTE 4)」
• 如果是UE发起，将媒体流状态设置为 "ENABLED-UPLINK"，表示数据流向网络（上
• 「ELSE /* UE terminated (NOTE 8) */」
• 如果不是UE发起，则认为是UE终止。
• 「"fStatus" := ENABLED-DOWNLINK; (NOTE 4)」
• 如果是UE终止，将媒体流状态设置为 "ENABLED-DOWNLINK"，表示数据流向UE（下
• 「ENDIF;」
• 结束 <SDP direction> 的判断。
• 「ELSE」
• 如果不是 a=sendonly，继续执行以下逻辑。
• 「IF a=inactive THEN」
• 检查SDP中是否存在 a=inactive 属性。
• a=inactive 表示媒体流是双向的，但不发送也不接收数据。
• 「"fStatus" :=DISABLED;」
• 如果存在 a=inactive，将媒体流状态设置为 "DISABLED"。
• 「ELSE /* a=sendrecv or no direction attribute */」
• 如果不存在 a=inactive，则表示媒体流是双向的（a=sendrecv）或者没有方向属性。
• 「"fStatus" := ENABLED (NOTE 4)」
• 将媒体流状态设置为 "ENABLED"。
• 「ENDIF;」
• 结束 a=inactive 的判断。
• 「ENDIF;」
• 结束 a=sendonly 的判断。
• 「ENDIF;」
• 结束 a=recvonly 的判断。
• 「ENDIF;」
• 结束 a=rtcp-mux 的判断。
• 「ENDIF;」
• 结束传输协议的判断。
• 「ENDIF;」
• 结束端口号的判断。
「3. 总结」
这段代码通过一系列的条件判断，根据SDP协商中的端口号、传输协议和方向属性等信息，最终确定媒体
流的状态。简单来说：
• 「端口号为0：」 媒体流被移除 (REMOVED)。
• 「TCP 或 TCP/MSRP 协议：」 媒体流启用 (ENABLED)。
• 「UDP 或 RTP/AVP 协议：」
• 「协商了 a=rtcp-mux：」 媒体流启用 (ENABLED)。
• 「没有协商 a=rtcp-mux：」
• 「a=recvonly：」 根据SDP方向，UE发起为下行启用 (ENABLED-DOWNLINK)，UE终
止为上行启用 (ENABLED-UPLINK)。
• 「a=sendonly：」 根据SDP方向，UE发起为上行启用 (ENABLED-UPLINK)，UE终止为
下行启用 (ENABLED-DOWNLINK)。
• 「a=inactive：」 媒体流禁用 (DISABLED)。
• 「a=sendrecv 或无方向属性：」 媒体流启用 (ENABLED)。