<think>
我们正在讨论
FreeSWITCH中的两个概念：Channel
-State
-Number（通道状态编号）和variable_sip_term_cause（SIP终止原因变量）。根据用户提供的引用[2]和[3]，我们可以看到一些相关信息。
引用[2]提到：
variable_sip_term_cause: 31
引用[3]则是一个CHANNEL_HANGUP事件的示例，其中包含了一些呼叫相关的信息，如callUuid、ani、dnis等，但没有直接提到Channel
-State
-Number。
不过，根据
FreeSWITCH的知识，我们可以解释如下：
1. Channel
-State
-Number（通道状态编号）：
在
FreeSWITCH中，通道（Channel）在呼叫过程中会经历不同的状态（State）。这些状态可以用一个数字（State Number）来表示。常见的状态包括：
0: DOWN（通道建立但未初始化）
1: ROUTING（正在路由）
2: EXECUTE（正在执行应用，如播放声音或桥接）
3: EXCHANGE_MEDIA（媒体交换中）
4: PARK（暂停状态）
5: CONSUME_MEDIA（媒体消耗状态？）
6: HIBERNATE（休眠）
7: RESET（重置）
8: HANGUP（挂机）
9: DONE（完成）
10: REPORTING（报告状态，生成CDR等）
每个状态对应一个数字，我们可以通过通道变量`channel_state`或`state`来获取当前通道的状态编号。
2. variable_sip_term_cause（SIP终止原因变量）：
这是一个通道变量，用于记录SIP会话终止的原因。这个原因通常是一个数字，对应SIP响应码或
FreeSWITCH内部定义的原因值。
例如，引用[2]中记录的是31，这个数字是
FreeSWITCH内部定义的一个原因值。我们可以查阅
FreeSWITCH的源代码或文档来了解这些数字的含义。
常见的SIP响应码（不完全对应，但可以参考）：
487: 请求被终止（通常由主叫方挂断引起）
486: 用户忙
31: 在
FreeSWITCH中，31通常表示“正常挂机”（NORMAL_CLEARING），但具体需要看
FreeSWITCH的定义。
实际上，
FreeSWITCH定义了一些挂机原因，可以在`switch_channel.c`中找到枚举`switch_termination_cause_t`。例如：
NONE = 0
USER_BUSY = 17
NO_ANSWER = 18
USER_NOT_REGISTERED = 20
NORMAL_CLEARING = 16 （注意：这里31不在标准枚举中，可能是扩展的原因）
注意：引用[2]中给出的31，我们需要确认具体含义。根据经验，31可能是
FreeSWITCH内部扩展的，表示“正常结束”（Normal Clearing）？但通常16表示正常结束。所以31可能是某个特定场景下的值。
实际上，在
FreeSWITCH源代码中，我们可以在`switch_termination_cause.h`文件中找到定义。但不同的版本可能略有不同。如果用户遇到具体的数值，可以查阅对应版本的源代码。
如何使用？
1. 获取通道状态编号：
在拨号计划（Dialplan）中，可以通过`${channel_state}`获取当前通道的状态编号。
在事件中，比如`CHANNEL_STATE`事件，会包含一个`Channel
-State
-Number`字段。
2. 获取SIP终止原因：
通常在呼叫挂断后，可以在`CHANNEL_HANGUP`或`CHANNEL_HANGUP_COMPLETE`事件中找到`variable_sip_term_cause`变量。
在拨号计划中，如果在该通道挂断之前，也可以通过`${sip_term_cause}`获取（但通常挂断后变量就不可用了，所以一般通过事件获取）。
示例：
在事件套接字（Event Socket）中监听事件，当挂机事件发生时，可以获取到这两个值。
在拨号计划中，我们可以这样使用状态编号：
```xml
<condition field="${state}" expression="^EXECUTE$">
<!
-- 注意：这里表达式匹配的是状态名称，不是数字。实际上，条件表达式也可以匹配数字，比如状态编号为2时是EXECUTE状态
-->
<action application="log" data="INFO Now in execute state"/>
</condition>
```
或者，我们也可以匹配数字：
```xml
<condition field="${state}" expression="^2$">
<!
-- 2 对应 EXECUTE 状态
-->
</condition>
```
对于`sip_term_cause`，我们可以在挂机后的事件中获取，例如在CDR（呼叫详细记录）中记录该值。
注意：在挂机事件中，我们还可以看到`Hangup
-Cause`变量，它通常是一个文本描述（如`NORMAL_CLEARING`），而`sip_term_cause`则是数字形式。
因此，用户可能需要结合这两个变量来分析呼叫结束的原因。
根据引用[3]中的事件示例（CHANNEL_HANGUP_COMPLETE事件），我们并没有直接看到`variable_sip_term_cause`，但看到了一个`callType`和`eventType`。不过，这是一个自定义的事件格式，可能不是原始的
FreeSWITCH事件。
在原始的
FreeSWITCH事件中，`CHANNEL_HANGUP_COMPLETE`事件会包含很多变量，其中可能包括：
Hangup
-Cause: 文本原因
variable_sip_term_cause: 数字原因
因此，我们可以在事件监听中获取这些变量。
总结：
- Channel
-State
-Number：通道状态编号，表示当前通道所处的状态，可以通过`${state}`或事件中的`Channel
-State
-Number`获取。
- variable_sip_term_cause：SIP终止原因的数字编码，通常在挂机事件中获取。
由于31这个值在引用[2]中出现，我们需要说明：31的具体含义需要参考
FreeSWITCH版本和定义。在常见的
FreeSWITCH版本中，挂机原因的数字编码定义在`switch_termination_cause.h`中，我们可以找到如下（部分）：
```
typedef enum {
SWITCH_CAUSE_NONE = 0, // 0
SWITCH_CAUSE_UNALLOCATED_NUMBER = 1, // 1
...
SWITCH_CAUSE_NORMAL_CLEARING = 16, // 16
SWITCH_CAUSE_USER_BUSY = 17, // 17
SWITCH_CAUSE_NO_USER_RESPONSE = 18, // 18
...
SWITCH_CAUSE_ORIGINATOR_CANCEL = 28, // 28
...
} switch_termination_cause_t;
```
注意：31并没有在标准枚举中，可能是扩展的。在
FreeSWITCH源代码中搜索，我们可能会发现31的定义（如果有的话）或者它是某个SIP响应码的映射。
实际上，
FreeSWITCH将SIP响应码映射到自己的挂机原因。例如，SIP的487响应可能会映射为`SWITCH_CAUSE_ORIGINATOR_CANCEL`（28）。而对于31，我们可以推测它可能是自定义的。
在
FreeSWITCH源码中，有一个函数将SIP响应码转换为终止原因，在`sofia_glue.c`中，函数`sofia_convert_sip_code_to_cause`。在该函数中，487被映射为28（ORIGINATOR_CANCEL）。而31这个值可能是直接从一个SIP响应码487转换而来？实际上，487的16进制是0x1E7，而31是十进制的31（0x1F），所以不是直接转换。
因此，我们建议用户查阅具体的
FreeSWITCH版本中挂机事件里的变量，或者查看
FreeSWITCH源代码中的定义。
为了帮助用户，我们可以提供一些常见的挂机原因数字：
16: 正常结束 (NORMAL_CLEARING)
17: 用户忙 (USER_BUSY)
18: 用户无响应 (NO_USER_RESPONSE)
28: 主叫方取消 (ORIGINATOR_CANCEL)
所以，31可能是一个特定的值，需要进一步确认。
最后，我们生成相关问题：
</think>
###
FreeSWITCH 中 Channel
-State
-Number 与 variable_sip_term_cause 详解
#### 一、Channel
-State
-Number：通道状态编号
**含义**
表示
FreeSWITCH 通道（Channel）的生命周期状态，用数字标识通道所处的处理阶段。状态流转遵循固定顺序，反映呼叫建立→媒体交互→释放的全过程。
**作用与取值**
| 状态编号 | 常量名 | 含义 | 典型触发场景 |
|
---------|
---------------------|
----------------------------|
-------------------------------|
| `0` | `CS_NEW` | 新建通道 | 收到 INVITE 请求时[^1] |
| `1` | `CS_INIT` | 初始化中 | 解析 SIP 头部信息 |
| `2` | `CS_ROUTING` | 路由决策中 | 执行拨号计划(Dialplan)匹配 |
| `3` | `CS_EXECUTE` | 执行应用 | 运行 `bridge`/`playback` 等指令 |
| `4` | `CS_EXCHANGE_MEDIA`| 媒体流交互中 | RTP 流建立成功 |
| `8` | `CS_HANGUP` | 挂机中 | 收到 BYE 请求或主动挂断[^3] |
| `9` | `CS_REPORTING` | 生成呼叫记录 | 写入 CDR(呼叫详单) |
| `10` | `CS_DESTROY` | 通道销毁 | 资源回收完成后 |
**使用示例**
```xml
<!
-- 监听状态变化
-->
<action application="set" value="hangup_after_bridge=true"/>
<action application="bridge" data="user/1001"/>
<!
-- ESL 获取实时状态
-->
freeswitch@internal> uuid_getvar 2a1d3c8e
-4f5g
-6h7i
-8j9k ${state}
当前状态: 4 (CS_EXCHANGE_MEDIA)
```
---
#### 二、variable_sip_term_cause：SIP 终止原因码
**含义**
记录会话终止的根本原因，采用标准 Q.850 原因码格式，用于精准诊断呼叫失败问题。
**常见取值与含义**
| 原因码 | 常量名 | 含义 | 典型场景 |
|
-------|
------------------------|
------------------------|
-----------------------------|
| `16` | `NORMAL_CLEARING` | 正常挂断 | 双方主动结束通话[^3] |
| `17` | `USER_BUSY` | 用户忙 | 被叫返回 486 Busy Here |
| `18` | `NO_USER_RESPONSE` | 用户无应答 | 振铃超时(默认 30 秒) |
| `21` | `CALL_REJECTED` | 被叫拒绝 | 返回 603 Decline |
| `28` | `INVALID_NUMBER_FORMAT`| 号码格式错误 | 无法匹配路由规则[^2] |
| `31` | `NORMAL_UNSPECIFIED` | 未指定正常终止 | 网关连接中断(如引用[2]案例) |
**使用方法**
1. **事件订阅**：通过 ESL 监听 `CHANNEL_HANGUP_COMPLETE` 事件获取
```bash
/event plain CHANNEL_HANGUP_COMPLETE
```
2. **CDR 记录**：在 `cdr_csv` 模块中
配置记录字段
```xml
<param name="cdr
-variables" value="sip_term_cause"/>
```
3. **拨号计划处理**：根据不同原因码执行补救策略
```xml
<condition field="${sip_term_cause}" expression="^18$">
<action application="voicemail" data="default ${domain} ${dialed_extension}"/>
</condition>
```
---
#### 三、核心交互关系
```mermaid
graph TD
A[收到 INVITE<br>状态=0]
--> B{Routing<br>状态=2}
B
-->|成功| C[Execute<br>状态=3]
B
-->|失败| D[挂机<br>状态=8]
C
--> E[Media Exchange<br>状态=4]
E
-->|挂机请求| F[Hangup<br>状态=8]
F
--> G[上报原因码<br>sip_term_cause=XX]
G
--> H[生成CDR<br>状态=9]
```
**典型场景分析**
1. **呼叫成功**：
`状态流转`: 0→2→3→4→8→9→10
`原因码`: 16 (正常结束)
2. **被叫忙**：
`状态流转`: 0→2→3→8→9→10
`原因码`: 17 (USER_BUSY)[^3]
3. **路由失败**：
`状态流转`: 0→2→8→9→10
`原因码`: 28 (INVALID_NUMBER_FORMAT)[^2]
---
#### 四、调试技巧
1. **实时状态追踪**
```bash
fs_cli
-x "/uuid_debug 2a1d3c8e
-4f5g
-6h7i
-8j9k"
```
2. **原因码过滤日志**
```bash
grep "sip_term_cause=31" /var/log/
freeswitch/
freeswitch.log
```
3. **自定义原因码映射**
在 `vars.xml` 中添加映射规则：
```xml
<X
-PRE
-PROCESS cmd="set" data="termination_31=NORMAL_UNSPECIFIED"/>
```
> ⚠️ 注意：`sip_term_cause` 仅在呼叫结束时生成，需通过事件或 CDR 获取完整信息[^3]。
---
### 总结
- **Channel
-State
-Number**：描述通道生命周期的状态机，数字标识关键处理阶段
- **variable_sip_term_cause**：Q.850 标准原因码，精确诊断呼叫终止根源
- **关联性**：状态`8`(HANGUP) 触发原因码生成，状态`9`(REPORTING) 将原因码写入 CDR
本文介绍如何配置非工作时间的值班电话系统，包括修改fifo.conf.xml文件来设定轮循策略、电话号码及振铃时间等参数，并在dialplan中进行相应配置，最后通过IVR实现座席的灵活签入与签出。
扫一扫
935
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
