Cisco MediaSense常见问题

简介

本文档介绍Cisco Media Sense服务器的常见问题。 

先决条件

要求

Cisco 建议您了解以下主题：

• 思科 MediaSense
• 思科统一通信管理器(CUCM)

使用的组件

本文档中的信息基于以下软件和硬件版本：

思科MediaSense 10.5

1.在Unified Communications Manager电话分流下，如何关联不同呼叫场景的参考呼叫ID?

在Cisco MediaSense中，每个呼叫的元数据仅提供分组设备和远端设备（可以是会议网桥或任何其他电话）的xRefCi（参考呼叫ID）和设备ref（分机）。

xRefCi参数是Unified Communication Manager特定媒体流的标识符。它们并不总是与录制的轨道对应1:1。

1.1. MediaSense搜索和播放呼叫关联功能

MediaSense为呼叫生成多个会话，在保留/恢复或转接时记录，这使得很难识别呼叫中的所有录制会话。为了能够在单个呼叫中关联这些录制会话，MediaSense引入了称为呼叫关联的新功能。通过此功能，所有强关联的具有通用xRefci值的呼叫都分组在一起。MediaSense 10.5支持内置网桥录制的呼叫关联功能。

1.2.座席保持/恢复场景

1. 座席A(extn 1000)和主叫方C(extn 2000)相互呼叫并处于通话状态。
2. 座席A将呼叫置于保持状态。
3. 座席A恢复呼叫。

此场景有两个录制会话：

• 会话Id为S1，包含这两条路径，在座席将呼叫置于保留状态之前的时间段/分段：
  trackNumber = 0，带参与者A(deviceRef = 1000,xRefCi = aaaa)
  trackNumber = 1，参与者为B(deviceRef = 2000,xRefCi = ccc)
• 使用sessionId = S2的会话，其中包含这两条路径，用于座席恢复呼叫后的时间段/网段。
  trackNumber = 0，带参与者A(deviceRef = 1000,xRefCi = aaaa)
  trackNumber = 1，参与者为B(deviceRef = 2000,xRefCi = ccc)

当座席将呼叫置于保持状态时，MediaSense不会记录呼叫的段。

1.3.客户暂候/恢复方案

1. 座席A(extn 1000)和主叫方C(extn 2000)相互呼叫并处于通话状态。
2. 客户C将呼叫置于暂候状态。
3. 客户C恢复呼叫。

整个呼叫记录在此场景的一个会话中：

• sessionId = S1，具有以下两个路径：
  trackNumber = 0，带参与者A(deviceRef = 1000,xRefCi = aaaa)
  trackNumber = 1，参与者为B(deviceRef = 2000,xRefCi = ccc)

在此场景中，当客户将呼叫置于保留状态时，MediaSense还会记录呼叫的分段。

1.4.座席转接至另一个座席方案 

1. 主叫方C(extn 2000)呼叫座席A(extn 1000)
2. 座席A(extn 1000)与座席B(3000)协商
3. 座席A(extn 1000)完成转接。
4. 座席B(extn 3000)挂机。

使用Unified Communications Manager 9.x及更低版本，以下是结果：

1.主叫方C(extn 2000)呼叫座席A(extn 1000)

会话S1已启动，跟踪0为A(extn 1000)，跟踪1为C(extn 2000)。

2.座席A(extn 1000)将呼叫转接到另一座席B(extn 3000)。 将A和B设备都设置为分流。

3.主叫方C(extn 2000)侦听通话等待音乐(MoH)。
4.座席A(extn 1000)与B(extn 3000)对话。

• 会话S1已结束
• 会话S2已启动，跟踪0为A(extn 1000)，跟踪1为B(extn 3000)
• 会话S3已启动，跟踪0为B(extn 3000)，跟踪1为A(extn 1000)

考虑事项:

• 会话S1因座席A电话将呼叫方C置于保持状态而结束。
• 会话S2和S3存在，因为两部电话都配置为分机。
• S2和S3中的参与者和两个参与者的xRefCi是相同的，但彼此处于相反的位置。
• S1的xRefCi值不反映在S2或S3中，因为咨询被视为独立呼叫。

5.座席A(extn 1000)完成转接。

6.C（扩展2000）与B（扩展3000）通话。

7.A（扩展1000）已断开连接。

会话S2已结束。

会话S3已更新，跟踪0为B(extn 3000)，跟踪1为C(extn 2000)。

考虑事项:

• 远端传输会触发现有录制会话的UPDATE。
• 远端参与者更改为S1。
• S3新的远端xRefCi与S1的远端xRefCi匹配。
• 座席B(extn 3000)挂机。
• C(extn 2000)和B(extn 3000)已断开。
•   会话S3已结束

注意：远端传输会更新现有会话。分机电话仍是路径0中的唯一参与者，但路径1中的参与者将更改为新参与方。

对于Unified Communications Manager 10.0及更高版本，以下是结果：

1.主叫方C(extn 2000)呼叫座席A(extn 1000)。

C(extn 2000)与座席A(extn 1000)对话。 会话S1 — 已启动 — 路径0为A(extn 1000)，路径1为C(2000)

2.座席A(extn 1000)咨询座席B(extn 3000)。

3. C(Extn 2000)侦听MoH。A(extn 1000)与B(extn 3000)对话。

• 会话S1 — 已结束
• 会话S2 — 已启动 — 路径0是A(extn 1000)，路径1是B(extn 3000)
• 会话S3 — 已启动 — 路径0为B(extn 3000)，路径1为A(extn 1000)

考虑事项:

• 会话S1结束，因为座席A电话将呼叫方C置于保持状态。
• 会话S2和S3都存在，因为两部电话都配置为分机。
• S2和S3中两个参与者的参与者和xRefCi相同，但位置相反。
• S1 xRefCi值不反映在S2或S3中，因为咨询被视为独立呼叫

4.座席A(extn 1000)完成转接。

5. C（2000年期）与B（3000年期）会谈。
6. A（1000外）已断开。

• 会话S3 — 已结束
• 会话S2 — 结束
• 会话S4 — 已启动 — 路径0为B(extn 3000)，路径1为C(extn 2000)

考虑事项:

• 远端传输触发一个录制会话的结束和另一个录制会话的开始。
• 尽管新会话开始，其xRefCi值将与以前的会话匹配。
• S4远端xRefCi与S1远端xRefCi匹配，S4近端xRefCi与S3近端xRefCi匹配。

7. B座席(Extn 3000)挂机。

8. C(extn 2000)和B(extn 3000)已断开连接。

• 会话S4 — 结束

注意：远端传输导致一个记录会话的结束和另一个记录会话的开始。

1.5.与另一个座席方案进行座席会议 

1. 主叫方C(extn 2000)呼叫座席A(extn 1000)。
2. 座席A(extn 1000)咨询座席B(extn 3000)。
3. 座席A(extn 1000)完成会议。
4. 座席A(extn 1000)从会议中丢弃。
5. 座席B(extn 3000)挂机。

对于Unified Communications Manager 9.x及更早版本，以下是结果：

1.主叫方C(extn 2000)呼叫座席A(extn 1000)。

2. C（2000年期）与A（1000年期）会谈。
会话S1已启动 — 路径0是A(extn 1000)，路径1是C(extn 2000)。

3.座席A(extn 1000)咨询座席B(extn 3000)。

4. C(extn 2000)听到MoH A(extn 1000)与B(extn 3000)的会谈

• 会话S1已结束
• 会话S2已启动 — 路径0是A(extn 1000)，路径1是B(extn 3000)
• 会话S3已启动 — 路径0为B(extn 3000)，路径1为A(extn 1052)

考虑事项:

• 会话S1结束，因为座席A电话将呼叫方C置于保持状态。
• 会话S2和S3存在，因为两部电话都配置为分机。
• S2和S3中两个参与者的参与者和xRefCi相同，但位置相反。
• S1 xRefCi值不反映在S2或S3中，因为咨询被视为独立呼叫。

5.座席A(extn 1000)完成会议。

6. C(extn 2000)与A(extn 1000)和B(extn 3000)通话。

• 会话S2结束
• 会话S3已更新 — 路径0为B（分机3000），路径1为会议网桥
• 会话S4已启动 — 路径0是A(extn 1000)，路径1是会议网桥

考虑事项:
远端传输会触发现有录制会话的UPDATE。
会议的完成：
咨询期间：

• 咨询电话有主呼叫处于保留状态和活动咨询呼叫。
• 被咨询的电话只有一个活动呼叫（咨询呼叫）。

当会议完成时（所有相关方）:

• 咨询电话的咨询呼叫终止。
• 咨询电话的主呼叫将获得到会议桥的远端转接。
• 被咨询的电话将远端转接到会议桥。

因此：

• S2终止，因为它代表咨询电话的咨询呼叫，该呼叫也终止。
• S4开始；它表示A主呼叫的继续和远端转接，但由于先前由于先前的保持而终止，原S1无法更新。
• S3被更新，因为B的远端只是从A传输到会议网桥。
• S4近端xRefCi值将匹配S1近端xRefCi值。

7.座席A（1000以外）从会议中丢弃。

8. A（1000外）已断开。 与B(extn 2000)通话的会话S3已更新 — 跟踪0为B(extn 3000)，跟踪1为C(extn 2000)。

考虑事项:

• 将会议降级为正常的双方呼叫的实施方式是，其余两个电话的远端相互转接
• 远端传输会触发现有录制会话的UPDATE。
• S3和S1的近端xRefCi值匹配。请注意，只有一个会话保持活动状态，因为呼叫方C未启用分组。

9. B座席(Extn 3000)挂断。

10. C（扩展2000）和B（扩展3000）已断开。
会话S4已结束。

考虑事项:

• 远端传输会更新现有会话。分机电话仍是路径0中的唯一参与者，但路径1中的参与者将更改为新参与方。
• 创建会议，将所有电话转接到会议网桥。因此，会议的作用就像一组传输。现有会话在这些会话中更新，分组电话仍是路径0中的唯一参与者，但路径1中的参与者将更改会议网桥。
• 一旦第三方从会议中退出，各方将相互转接。这将再次更新现有会话，分组电话仍是路径0中的唯一参与者，但路径1中的参与者将更改为对方。
• 如果第四方被添加到会议网桥，则元数据中没有任何指示，除非第四方也启用了自己的分组。

对于Unified Communications Manager 10.x及更高版本，以下是结果：

1.主叫方C(extn 2000)呼叫座席A(extn 1000)。

2. C(extn 2000)与A(extn 1000)会话S1通话 — 已启动 — 跟踪0是A(extn 1000)，跟踪1是C(extn 2000)。

3.座席A(extn 1000)咨询座席B(extn 3000)。

4. C(extn 2000)听MoH A(extn 1000)与B(extn 3000)通话。

• 会话S1 — 已结束
• 会话S2 — 已启动 — 路径0是A(extn 1000)，路径1是B(extn 3000)
• 会话S3 — 已启动 — 路径0为B(extn 3000)，路径1为A(extn 1000)

考虑事项:

• 会话S1结束，因为座席A的电话已将呼叫方C置于保持状态。
• 会话S2和S3存在，因为两部电话都配置为分机。
• S2和S3中两个参与者的参与者和xRefCi相同，但位置相反。
• S1 xRefCi值不反映在S2或S3中，因为咨询被视为独立呼叫

5.座席A(extn 1000)完成会议。

6. C(Extn 2000)与A(Extn 1000)和B(Extn 3000)通话

• 会话S2 — 结束
• 会话S3 — 已结束
• 会话S4 — 已启动 — 路径0是A(extn 1000)，路径1是会议网桥
• 会话S5 — 已启动 — 路径0为B(extn 3000)，路径1为会议网桥

考虑事项:

远端传输触发一个录制会话的结束和另一个录制的开始。会议的完成情况如下：

• 咨询期间：
  • 咨询电话的主呼叫处于保留状态，而咨询呼叫处于活动状态
  • 被咨询的电话只有一个活动呼叫（咨询呼叫）
• 当会议完成时（所有相关方）:
• 咨询电话的咨询呼叫终止
• 咨询电话的主呼叫获得到会议网桥的远端转接
• 被咨询的电话将远端转接到会议桥
• 因此：
  • 创建了两个新会话，因为代理A和代理B都启用了分组
  • S4近端xRefCi值和S1近端xRefCi值匹配
  • S5近端xRefCi值和S3近端xRefCi值匹配
  • S4和S5的远端xRefCi值不匹配，即使两者都连接到同一会议网桥

7.座席A（1000以外）从会议丢弃

8. A（1000外）已断开。 C（扩展2000）与B通话（扩展3000）

• 会话S4 — 结束
• 会话S5 — 已结束
• 会话S6 — 已启动 — 路径0为B(extn 3000)，路径1为C(extn 2000)

考虑事项:

• 将会议降级为正常的双方呼叫的实施方式是，其余两个电话的远端相互转接
• 远端传输触发一个录制会话的结束和另一个录制会话的开始
• S6和S5具有匹配的近端xRefCi值。请注意，只有一个会话保持活动状态，因为呼叫方C未启用分组

9. B座席(Extn 3000)挂机

10. C（扩展2000）和B（扩展3000）已断开

• 会话S6 — 结束

考虑事项:

• 远端传输会导致一个会话的结束和另一个会话的开始
• 创建会议，将所有电话转接到会议网桥。因此，会议的作用就像一组传输。现有会话已结束，并且会在分流电话和会议网桥之间创建新会话
• 一旦第三方从会议中退出，各方将相互转接。这将结束包括会议网桥的会话，并在两个剩余终端之间启动新会话
• 如果第四方被添加到会议网桥，则元数据中没有任何指示，除非第四方也启用了自己的分组

2.如何在统一边界要素分组下关联不同呼叫会话的参考呼叫ID?

使用统一边界元素分组时，很少有情况会导致呼叫被拆分为多个录制会话。在大多数情况下，保留/恢复、转接和会议操作不会启动新的录制会话。在创建新会话的少数情况下，有一个公用值CCID（呼叫关联ID）。 此值对呼叫中的所有会话都是通用的。CCID是Cisco-GUID的十进制形式，Cisco-GUID是由思科语音路由器生成的唯一呼叫密钥。收到呼叫的第一台路由器生成此密钥，并将其沿线传递给所有后续设备，包括Cisco MediaSense。

统一边界元素本身不生成xRefCi值，但为了与Unified Communications Manager电话分组呼叫创建相似性，Cisco MediaSense还为每个统一边界元素呼叫合成一对xRefCi值。在跟踪级别的元数据中可以看到这些内容，以及在会话级别显示的CCID。

这些情况会导致统一边界要素录制被拆分为多个会话：

2.1.呼叫中编解码器更改

如果传输、会议、会议丢弃或其他操作导致双方重新协商其编解码器，Cisco MediaSense将结束当前录制会话并启动新的录制会话。两个会话共享相同的CCID和相同的xRefCi值对。

2.2.咨询转让

咨询转接是从一个座席到另一个座席的转接，在该转接中，两个座席在原来呼叫方等待时相互通话。呼叫的查询段以某种方式与整个呼叫相关，并且可以配置Unified Communications Manager，使查询呼叫DO通过CUBE。但是，统一边界元素和Cisco MediaSense不知道这些呼叫是相关的，它们为此会话创建新的CCID和新的xRefCi值对。

通过比较参与者设备参考和时间戳字段，这些呼叫可以彼此关联。请考虑以下场景：

1. 主叫方C(extn 2000)呼叫座席A(extn 1000)(sessionId = S1,CCID = C1)
2. 座席A咨询座席B(extn 3000)(sessionId = S2,CCID = C2)
3. 座席A丢弃，呼叫方C与座席B对话(sessionId = S1,CCID = C1)

此场景中的红色标志在步骤2中。在此期间，代理A(deviceRef 1000)同时参与两个录制会话：

• 会话= S1 / CCID = C1和
• 会话= S2 / CCID = C2

因此，S1与S2相关，C1与C2相关。

2.3.咨询呼叫检测

首先，我们需要明确的咨询呼叫定义：

当前参与者在现有会话中向该会话之外且排除该会话中其他参与者的终端发出的任何辅助呼叫。

理论上，此场景可能包括座席让来电者暂候，以便与他的老板核实是否有好休息，甚至有座席让来电者暂候，以接收他妻子的来电，但我们目前忽略了这些可能性。

客户端应用程序可以通过跟踪Cisco MediaSense事件流来实时检测查询呼叫。如果客户端观察到会话STARTED事件包含给定的设备Ref，而另一个会话STARTED事件包含相同的设备Ref，且没有干预会话ENDED事件，则可以断定在两个会话STARTED事件中找到的会话ID和CCID是关联的。 

过去，客户端可以使用Cisco MediaSense API检查与给定主呼叫关联的任何咨询呼叫。假设客户端知道代理A在CCID <C1>中使用了extn 1000。查找任何相关咨询呼叫的说明：

步骤1.通过发出getSessionByCCID(<C1>)检索主调用的会话元数据。

步骤2.提取sessionStartDate（调用它<Ta>）和sessionDuration。

步骤3.通过向<Ta>添加sessionDuration来计算sessionEndDate（调用<Tb>）。

步骤4.运行此API请求：

https://Mediasense IP地址：8443/ora/queryService/query/getSessionsByDeviceRef?value=1000&minSessionStartDate=<Ta>&maxSessionStartDate=<Tb>

此查询可以返回多个会话。  如果是，则可以假定所有呼叫都与同一呼叫关联。

2.4.从多个参与者查询呼叫检测

查询呼叫检测部分中提到的步骤，查找从接收初始电话呼叫的设备发出的所有查询呼叫。但是，如果从随后将呼叫转接到的设备发出咨询呼叫，会如何？

请考虑以下步骤：

1. 呼叫者呼叫座席1
2. 座席1咨询座席2，然后丢弃
3. 主叫方与座席2通话
4. 座席2咨询座席3，然后丢弃
5. 主叫方与座席3通话

此过程未捕获座席2和座席3之间的咨询呼叫。

由于这是统一边界元素调用，我们可以利用调用方和每个代理之间的所有连接都包含在同一记录会话中这一事实，以及所有涉及的代理都作为同一会话的参与者在同一会话中同时列出的事实。因此，从主会话元数据中，我们可以收集所有涉及的deviceRef的列表。调用getSessionsByDeviceRef时，指定主会话的时间范围，并为每个请求指定一个deviceRef。

或者，可以通过单个getSessions请求来简化流程，例如：

{
    "requestParameters": [
        {
            "fieldName": "deviceRef",
            "fieldConditions": [
                {
                    "fieldOperator": "equals",
                    "fieldValues": [
                        "1000"
                    ],
                    "fieldConnector": "OR"
                },
                {
                    "fieldOperator": "equals",
                    "fieldValues": [
                        "2000"
                    ],
                    "fieldConnector": "OR"
                },
                {
                    "fieldOperator": "equals",
                    "fieldValues": [
                        "3000"
                    ],
                    "fieldConnector": "OR"
                },
                {
                    "fieldOperator": "equals",
                    "fieldValues": [
                        "4000"
                    ]
                }
            ],
            "paramConnector": "AND"
        },
        {
            "fieldName": "sessionStartDate",
            "fieldConditions": [
                {
                    "fieldOperator": "between",
                    "fieldValues": [
                        <Ta>, // session start time
                        <Tb>// session end time
                    ]
                }
            ]
        }
    ]
}

此查询返回与原始主呼叫及其所有转接相关联的所有咨询呼叫。

此过程实际上过于广泛地传播网络。例如，如果deviceRef 4000上的代理执行并终止了一个完全独立的呼叫，该呼叫在<Ta>之后和他被添加到有关的呼叫之前开始，则此过程包括集中的该独立呼叫。但是，可以利用主会话元数据中的可用信息来解决此问题。  每个参与者的信息包括加入会话的时间偏移和任期。客户端代码可以使用该信息从上面收到的列表中删除不相关的会话。或者，它可以形成一系列直接getSessions或getSessionByDeviceRef查询，正确地框定每个座席处于主呼叫期间的时间段。

2.5.总结

在上一节中，我们介绍了检索与给定Cisco MediaSense录制会话关联的所有会话的程序。但是，我们也看到，给定呼叫可以分为多个会话，如在呼叫中编解码器发生更改时。 

我们如何检索与连接到呼叫者交互的所有会话相关的所有录制（以及咨询）? 

答案是扩展此说明以检测多个咨询呼叫。首先，我们收集共享有关主会话的CCID的所有会话。然后，我们根据所有这些会话记录建立参与者列表。接下来，我们将时间范围计算为从最早会话开始到最近会话结束的会话的sessionStartDate。最后，我们可以执行图中所示的getSessions查询。

与以前一样，我们最终可以捕获太多录音，因此我们可以执行后处理步骤，从其列表中删除那些不相关的会话。

3.您如何将Cisco MediaSense中的呼叫与其在其他解决方案组件中的显示相关联？

3.1.标识符关联表

这两个表 — 一个用于统一通信管理器呼叫，一个用于统一边界要素呼叫。每列代表一个解决方案组件或协议，第一列代表Cisco MediaSense。每行代表特定类型的标识符。

要读取表，请从一个表示您知道的数据项的单元格开始，然后水平查看列表示要查找的解决方案组件。该单元格中的条目以名称指示目标组件中已知的完全相同的数据项。如果目标组件在该行中有一个空单元格，则该组件不知道该数据项。目标组件列中该单元格不为空的另一行。

例如，使用Unified Communications Manager呼叫时，假设您知道GED-188 CallReferenceID，并且您想在Cisco MediaSense中找到该呼叫。从GED-188列左勾选，您会看到MediaSense列中没有值，因此无法直接映射到它。

但是，有一列可以在行之间使用zig-zag:统一通信管理器CDR客户端可以通过搜索IncomingProtocolCallRef与GED-188 CallReferenceID匹配的记录来选择正确的Unified Communications Manager CDR记录。该记录包含一个名为destLegCallIdentifier的值，该值与MediaSense NearEnd xRefCi相同，因此可用于在Cisco MediaSense中查找相应记录。

但是，在呼叫结束后的某段时间内，Unified Communications Manager CDR记录才会写入，因此此方法只能在历史上使用。

还有另一条路。从GED-188 CallReferenceID向下查看。结果，您还可以使用AlertingDevice和AnsweringDevice匹配MediaSense中的deviceRef字段。该方法也能实时工作。

考虑事项:

1. 在统一通信管理器呼叫的录音中，Cisco MediaSense实际上确实从UCM接收Cisco-GUID，但它与其他解决方案设备捕获的GUID不同。因此，MediaSense甚至不存储该值。
2. 对于座席到座席的呼叫，TCD.InstrumentPortNumber是目标座席的分机。在TCD.ANI中可以找到呼叫代理的分机。
3. CCID是十进制形式的Cisco-GUID，它是4组10位十进制数字的连字符分隔集。这些可以转换为十六进制形式，只需将每个10位十进制数转换为8位十六进制数，然后删除连字符。在UCCE中使用Cisco-GUID时，它以十六进制形式显示。

4.您如何确定哪个路径具有主叫方，哪个路径具有被叫方？

4.1.对于CUBE分组的呼叫

对于CUBE呼叫，跟踪0始终映射到锚点段媒体流。锚点支路是已配置媒体记录配置文件的拨号对等体。第二个跟踪映射到非锚点支路。

如果在入站拨号对等体上启用了媒体录制配置文件，则锚点支路将成为in-leg。换句话说，主叫方显示在路径0中，被叫方显示在路径1中。

如果在出站拨号对等体上启用了媒体录制配置文件，则锚点支路将成为出站分支。  在这种情况下，主叫方显示在路径1中，被叫方显示在路径0中。

4.2.用于Unified CM电话分组的呼叫

对于Unified CM分流，在简单的呼叫场景中，您可以使用元数据中的xRefCi字段来确定哪个方在哪个媒体跟踪中。数字较小的xRefCi通常指主叫方的跟踪。被叫方的跟踪在数字上更大（通常为1，但在负载合理的系统下可能更大）。 但是，这些xRefCi值最终会包围为零。因此，如果发现一个值是高数，而另一个值是小数，则假定它们的位置是相反的。

在更复杂的场景中，此算法并不总是有效。如果调用了附加服务（如传输和会议），并且UC Manager群集包含多个节点，则xRefCi值不一定按顺序生成，并且您不能假定其顺序有任何含义。确定特定对xRefCi值的排序顺序是否可信的直接方法是查看xRefCi值的第一个字节。此字节表示创建该特定标识符的UC Manager节点ID。如果两个xRefCi值的第一个字节相同，则其顺序正确。如果它们不同，则排序可能不正确。

对于这些情况，实时确定呼叫方向的唯一方法是从任何其他来源（例如JTAPI事件源）获取信息。呼叫结束后，只需几分钟，您就可以确定呼叫方向并检查UC Manager的呼叫CDR数据。具体而言，CDR记录中的origLegCallIdentifier字段始终代表呼叫方。

5.会话状态为CLOSED_ERROR的可能原因是什么？

会话状态为CLOSED_ERROR的可能原因包括：

1.呼叫控制服务器收到来自媒体（录制）服务器针对打开或关闭请求的错误响应。
2.呼叫控制服务器检测到SIP信令错误，例如缺少ACK。
3.会话已成功关闭，但所有路径的大小为零。

当会话处于ACTIVE状态时，元数据中没有持续时间是正常的，因为在会话关闭之前，持续时间是未知的。

对于处于CLOSED_ERROR状态的会话，如果事件或getSessions数据中不存在会话或跟踪持续时间字段，则此跟踪的介质不可用。

6.已修剪会话和已删除会话之间有何区别？

请考虑以下两个查询：

6.1.使用getAllPrunedSessions查询

此查询返回一组会话，其所有会话状态均为DELETED:

https://Mediaserver IP address:8443/ora/queryService/query/getAllPrunedSessions?minSessionStartDate=1301788800000&maxSessionStartDate=1312329599000

6.2.使用getSessions查询

 此查询不返回会话：

https://MediaServer IP address:8443/ora/queryService/query/getSessions
{
            "requestParameters": 
            [{ 
                        "fieldName" : "sessionState", 
                        "fieldConditions": 
                        [{ 
                                    "fieldOperator" : "equals", 
                                    "fieldValues" : [ "DELETED" ] 
                        }],
                        "paramConnector" : "AND" 
            },
            { 
                        "fieldName" : "sessionStartDate", 
                        "fieldConditions": 
                        [{ 
                                    "fieldOperator" : "between", 
                                    "fieldValues" : [ "1301788800000", "1312329599000" ] 
                        }] 
            }] 
}

6.3.为什么修剪和删除会话中的行为不同？

行为差异是设计的。请参阅MediaSense文档中的以下部分：

• API参数说明：getAllPrunedSessions API说明：

使用此API搜索所有已修剪的录制……术语“已修剪”是指Cisco MediaSense系统删除的录制。如果已使用deleteSessions API明确删除任何录制，则这些删除的录制不会被视为已修剪的录制。

• 主动存储管理：

会话被修剪后，与这些会话关联的元数据将保留在数据库中，即使这些会话被标记为“修剪”后也是如此。 与录制本身相比，此元数据不占用大量存储空间，但确实需要一些空间，应定期删除。为帮助执行本练习，客户端可能会定期发出修剪会话的API请求，或者客户端可能会选择接收已修剪会话的事件并显式删除那些客户端不再需要的事件。

要澄清，这两个问题完全不同。事实上，第二个查询（它搜索状态为DELETED的所有会话）始终返回空集。正常的日常查询过滤掉具有“已删除”状态的会话，即使这是所请求的。唯一的例外是getAllPrunedSessions。此例外旨在帮助应用程序查找已修剪的会话，以便应用程序可以请求删除这些会话。

一旦在从getAllPrunedSessions获取的已修剪会话列表上使用deleteSessions API，这些会话将不再显示在getAllPrunedSessions的结果中。此类会话会立即从元数据中完全删除。

另一种方法是，修剪的会话与删除的会话不同：

1. MediaSense系统中的算法已将已修剪会话标记为删除。没有人参与裁剪这些会议的决定。因此，即使这些会话被移至DELETED状态，这些会话实际上也不会从元数据中删除。需要人工（或应用）干预。由于这些会话处于DELETED状态，因此大多数查询无法看到这些会话。但是，这些会话对getAllPrunedSessions查询API可见。此外，如果为这些会话生成了任何mp4文件，则这些mp4文件将继续存在于磁盘上，并可继续下载，直到修剪的会话实际被删除。
2. 删除的会话通过显式调用deleteSessions API进行标记。可以对已修剪的会话或尚未删除的会话进行此标记。一旦删除会话API删除了会话，此会话将不再对任何查询可见。这包括getAllPrunedSessions API。这些删除的会话会立即从元数据中删除，以便可以回收磁盘空间。
   
   

7.如何配置媒体分流的TDM网关？

当您有呼叫流经的PSTN网关，并且您想记录这些呼叫时。这些呼叫是TDM到SIP的呼叫。但是，媒体分流仅在SIP到SIP呼叫上可用。

可以记录这些呼叫。这些呼叫可以再次通过路由器。配置指南和其他详细信息可在本白皮书中找到。

8.使用寻线组时如何捕获实际目的电话？

使用CUBE中的媒体分组时，MediaSense元数据通常包含被叫方的扩展。但是，如果调用的号码是Communications Manager寻线组引导号，则默认情况下元数据仅包含该引导号。它不包含实际应答呼叫的电话的分机。

有一个Communications Manager设置可以更改此设置。在寻线/引导配置页面上，找到标题为“连接方转换”的部分。必须打开“显示线路组成员DN为连接方”设置。

此功能在Communications Manager 9.0(1)及更高版本中提供。

9.为什么建议将Unified Communications Manager基于网络的录制作为首选分组机制？

使用Unified Communications Manager基于网络的录制(NBR)，您可以使用网关录制呼叫。NBR允许Unified Communications Manager路由录制呼叫，而不管设备、位置或地理位置。使用NBR时，呼叫录制媒体可以源自IP电话或通过SIP中继连接到Unified Communications Manager的网关。Unified Communications Manager根据呼叫流和呼叫参与者动态选择正确的媒体源。

当集成多业务路由器(ISR)不可用时，NBR会自动回退到内置网桥(BiB)，因为不需要单独的记录配置。当客户希望在录制策略中包括座席 — 座席咨询呼叫，因为统一边界元素无法录制咨询呼叫，因此需要单独启用BiB时，此功能非常有用。

NBR和BiB呼叫都可以使用xRefci进行关联，后者可从Unified Communications Manager JTAPI获得。不需要CISCO-GUID，这意味着不需要CTI服务器和CTIOS连接。由于存在单个关联标识符，因此各组件之间的关联性更强，并且可以以独立于呼叫流的统一方式完成。

使用NBR时，直接拨号和拨号程序发起的去话呼叫可以与其在其他解决方案组件中的外观相关联。

使用NBR时，TDM网关记录会自动使用，而不会拆分路由器的容量。目前，MediaSense 10.5不支持TDM网关录制。

10.为什么节点升级到MediaSense 10.5需要更长时间？

节点升级可能需要数小时，具体取决于其保留的录音数量和大小。对于MediaSense 10.5，当您升级具有超大数据集的节点时，每100万次录制大约需要额外90分钟。

11.俄罗斯时区变化对MediaSense搜索和播放应用有何影响？

如果MediaSense搜索和播放应用的用户位于任何受影响的时区，或者他们在搜索条件中选择受影响的时区，则会受到影响。与MediaSense接口的第三方合作伙伴产品在更新各自的时区表之前会受到类似影响。

解决方法是选择与GMT的正确偏移匹配的时区，即使城市不再正确。

12. MediaSense支持哪些语言？

以下是MediaSense支持的语言：

• 阿拉伯语
• 丹麦语
• 荷兰语
• 英语(美国)
• 芬兰语
• 法语
• 德语
• 意大利语
• 日语
• 韩语
• 挪威语
• 波兰语
• 巴西葡萄牙语
• 俄语
• 简体汉语
• 西班牙语
• 瑞典语
• 繁体中文
• 土耳其语

13.如何监控MediaSense系统性能？

要监控MediaSense系统性能，请使用RTMT工具或Cisco Prime协作保证工具分析这些关键绩效指标(KPI)的值。

有关RTMT工具或Cisco Prime协作保证工具的详细信息，请参阅《Cisco MediaSense用户指南》的“Unified RTMT管理”和“Cisco Prime协作保证管理”部分。

14.如何配置浏览器以在MediaSense中运行浏览器播放器？

根据浏览器，执行以下步骤以运行浏览器内播放器：

admin:set useHostNameForMediaURL 
admin:set useHostNameForMediaURL true

admin:utils service restart Cisco MediaSense Configuration Service

The import was successful.