此产品的文档集力求使用非歧视性语言。在本文档集中,非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言,文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。
思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言,希望全球的用户都能通过各自的语言得到支持性的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任,并建议您总是参考英文原始文档(已提供链接)。
本文档介绍Cisco Media Sense服务器的常见问题。
Cisco 建议您了解以下主题:
本文档中的信息基于以下软件和硬件版本:
思科MediaSense 10.5
在Cisco MediaSense中,每个呼叫的元数据仅提供分组设备和远端设备(可以是会议网桥或任何其他电话)的xRefCi(参考呼叫ID)和设备ref(分机)。
xRefCi参数是Unified Communication Manager特定媒体流的标识符。它们并不总是与录制的轨道对应1:1。
MediaSense为呼叫生成多个会话,在保留/恢复或转接时记录,这使得很难识别呼叫中的所有录制会话。为了能够在单个呼叫中关联这些录制会话,MediaSense引入了称为呼叫关联的新功能。通过此功能,所有强关联的具有通用xRefci值的呼叫都分组在一起。MediaSense 10.5支持内置网桥录制的呼叫关联功能。
此场景有两个录制会话:
当座席将呼叫置于保持状态时,MediaSense不会记录呼叫的段。
整个呼叫记录在此场景的一个会话中:
在此场景中,当客户将呼叫置于保留状态时,MediaSense还会记录呼叫的分段。
使用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)对话。
考虑事项:
5.座席A(extn 1000)完成转接。
6.C(扩展2000)与B(扩展3000)通话。
7.A(扩展1000)已断开连接。
会话S2已结束。
会话S3已更新,跟踪0为B(extn 3000),跟踪1为C(extn 2000)。
考虑事项:
注意:远端传输会更新现有会话。分机电话仍是路径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)对话。
考虑事项:
4.座席A(extn 1000)完成转接。
5. C(2000年期)与B(3000年期)会谈。
6. A(1000外)已断开。
考虑事项:
7. B座席(Extn 3000)挂机。
8. C(extn 2000)和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)的会谈
考虑事项:
5.座席A(extn 1000)完成会议。
6. C(extn 2000)与A(extn 1000)和B(extn 3000)通话。
考虑事项:
远端传输会触发现有录制会话的UPDATE。
会议的完成:
咨询期间:
当会议完成时(所有相关方):
因此:
7.座席A(1000以外)从会议中丢弃。
8. A(1000外)已断开。 与B(extn 2000)通话的会话S3已更新 — 跟踪0为B(extn 3000),跟踪1为C(extn 2000)。
考虑事项:
9. B座席(Extn 3000)挂断。
10. C(扩展2000)和B(扩展3000)已断开。
会话S4已结束。
考虑事项:
对于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)通话。
考虑事项:
5.座席A(extn 1000)完成会议。
6. C(Extn 2000)与A(Extn 1000)和B(Extn 3000)通话
考虑事项:
远端传输触发一个录制会话的结束和另一个录制的开始。会议的完成情况如下:
7.座席A(1000以外)从会议丢弃
8. A(1000外)已断开。 C(扩展2000)与B通话(扩展3000)
考虑事项:
9. B座席(Extn 3000)挂机
10. C(扩展2000)和B(扩展3000)已断开
考虑事项:
使用统一边界元素分组时,很少有情况会导致呼叫被拆分为多个录制会话。在大多数情况下,保留/恢复、转接和会议操作不会启动新的录制会话。在创建新会话的少数情况下,有一个公用值CCID(呼叫关联ID)。 此值对呼叫中的所有会话都是通用的。CCID是Cisco-GUID的十进制形式,Cisco-GUID是由思科语音路由器生成的唯一呼叫密钥。收到呼叫的第一台路由器生成此密钥,并将其沿线传递给所有后续设备,包括Cisco MediaSense。
统一边界元素本身不生成xRefCi值,但为了与Unified Communications Manager电话分组呼叫创建相似性,Cisco MediaSense还为每个统一边界元素呼叫合成一对xRefCi值。在跟踪级别的元数据中可以看到这些内容,以及在会话级别显示的CCID。
这些情况会导致统一边界要素录制被拆分为多个会话:
如果传输、会议、会议丢弃或其他操作导致双方重新协商其编解码器,Cisco MediaSense将结束当前录制会话并启动新的录制会话。两个会话共享相同的CCID和相同的xRefCi值对。
咨询转接是从一个座席到另一个座席的转接,在该转接中,两个座席在原来呼叫方等待时相互通话。呼叫的查询段以某种方式与整个呼叫相关,并且可以配置Unified Communications Manager,使查询呼叫DO通过CUBE。但是,统一边界元素和Cisco MediaSense不知道这些呼叫是相关的,它们为此会话创建新的CCID和新的xRefCi值对。
通过比较参与者设备参考和时间戳字段,这些呼叫可以彼此关联。请考虑以下场景:
此场景中的红色标志在步骤2中。在此期间,代理A(deviceRef 1000)同时参与两个录制会话:
因此,S1与S2相关,C1与C2相关。
首先,我们需要明确的咨询呼叫定义:
当前参与者在现有会话中向该会话之外且排除该会话中其他参与者的终端发出的任何辅助呼叫。
理论上,此场景可能包括座席让来电者暂候,以便与他的老板核实是否有好休息,甚至有座席让来电者暂候,以接收他妻子的来电,但我们目前忽略了这些可能性。
客户端应用程序可以通过跟踪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和座席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查询,正确地框定每个座席处于主呼叫期间的时间段。
在上一节中,我们介绍了检索与给定Cisco MediaSense录制会话关联的所有会话的程序。但是,我们也看到,给定呼叫可以分为多个会话,如在呼叫中编解码器发生更改时。
我们如何检索与连接到呼叫者交互的所有会话相关的所有录制(以及咨询)?
答案是扩展此说明以检测多个咨询呼叫。首先,我们收集共享有关主会话的CCID的所有会话。然后,我们根据所有这些会话记录建立参与者列表。接下来,我们将时间范围计算为从最早会话开始到最近会话结束的会话的sessionStartDate。最后,我们可以执行图中所示的getSessions查询。
与以前一样,我们最终可以捕获太多录音,因此我们可以执行后处理步骤,从其列表中删除那些不相关的会话。
这两个表 — 一个用于统一通信管理器呼叫,一个用于统一边界要素呼叫。每列代表一个解决方案组件或协议,第一列代表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字段。该方法也能实时工作。
考虑事项:
对于CUBE呼叫,跟踪0始终映射到锚点段媒体流。锚点支路是已配置媒体记录配置文件的拨号对等体。第二个跟踪映射到非锚点支路。
如果在入站拨号对等体上启用了媒体录制配置文件,则锚点支路将成为in-leg。换句话说,主叫方显示在路径0中,被叫方显示在路径1中。
如果在出站拨号对等体上启用了媒体录制配置文件,则锚点支路将成为出站分支。 在这种情况下,主叫方显示在路径1中,被叫方显示在路径0中。
对于Unified CM分流,在简单的呼叫场景中,您可以使用元数据中的xRefCi字段来确定哪个方在哪个媒体跟踪中。数字较小的xRefCi通常指主叫方的跟踪。被叫方的跟踪在数字上更大(通常为1,但在负载合理的系统下可能更大)。 但是,这些xRefCi值最终会包围为零。因此,如果发现一个值是高数,而另一个值是小数,则假定它们的位置是相反的。
在更复杂的场景中,此算法并不总是有效。如果调用了附加服务(如传输和会议),并且UC Manager群集包含多个节点,则xRefCi值不一定按顺序生成,并且您不能假定其顺序有任何含义。确定特定对xRefCi值的排序顺序是否可信的直接方法是查看xRefCi值的第一个字节。此字节表示创建该特定标识符的UC Manager节点ID。如果两个xRefCi值的第一个字节相同,则其顺序正确。如果它们不同,则排序可能不正确。
对于这些情况,实时确定呼叫方向的唯一方法是从任何其他来源(例如JTAPI事件源)获取信息。呼叫结束后,只需几分钟,您就可以确定呼叫方向并检查UC Manager的呼叫CDR数据。具体而言,CDR记录中的origLegCallIdentifier字段始终代表呼叫方。
会话状态为CLOSED_ERROR的可能原因包括:
1.呼叫控制服务器收到来自媒体(录制)服务器针对打开或关闭请求的错误响应。
2.呼叫控制服务器检测到SIP信令错误,例如缺少ACK。
3.会话已成功关闭,但所有路径的大小为零。
当会话处于ACTIVE状态时,元数据中没有持续时间是正常的,因为在会话关闭之前,持续时间是未知的。
对于处于CLOSED_ERROR状态的会话,如果事件或getSessions数据中不存在会话或跟踪持续时间字段,则此跟踪的介质不可用。
请考虑以下两个查询:
此查询返回一组会话,其所有会话状态均为DELETED:
https://Mediaserver IP address:8443/ora/queryService/query/getAllPrunedSessions?minSessionStartDate=1301788800000&maxSessionStartDate=1312329599000
此查询不返回会话:
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" ] }] }] }
行为差异是设计的。请参阅MediaSense文档中的以下部分:
使用此API搜索所有已修剪的录制……术语“已修剪”是指Cisco MediaSense系统删除的录制。如果已使用deleteSessions API明确删除任何录制,则这些删除的录制不会被视为已修剪的录制。
会话被修剪后,与这些会话关联的元数据将保留在数据库中,即使这些会话被标记为“修剪”后也是如此。 与录制本身相比,此元数据不占用大量存储空间,但确实需要一些空间,应定期删除。为帮助执行本练习,客户端可能会定期发出修剪会话的API请求,或者客户端可能会选择接收已修剪会话的事件并显式删除那些客户端不再需要的事件。
要澄清,这两个问题完全不同。事实上,第二个查询(它搜索状态为DELETED的所有会话)始终返回空集。正常的日常查询过滤掉具有“已删除”状态的会话,即使这是所请求的。唯一的例外是getAllPrunedSessions。此例外旨在帮助应用程序查找已修剪的会话,以便应用程序可以请求删除这些会话。
一旦在从getAllPrunedSessions获取的已修剪会话列表上使用deleteSessions API,这些会话将不再显示在getAllPrunedSessions的结果中。此类会话会立即从元数据中完全删除。
另一种方法是,修剪的会话与删除的会话不同:
当您有呼叫流经的PSTN网关,并且您想记录这些呼叫时。这些呼叫是TDM到SIP的呼叫。但是,媒体分流仅在SIP到SIP呼叫上可用。
可以记录这些呼叫。这些呼叫可以再次通过路由器。配置指南和其他详细信息可在本白皮书中找到。
使用CUBE中的媒体分组时,MediaSense元数据通常包含被叫方的扩展。但是,如果调用的号码是Communications Manager寻线组引导号,则默认情况下元数据仅包含该引导号。它不包含实际应答呼叫的电话的分机。
有一个Communications Manager设置可以更改此设置。在寻线/引导配置页面上,找到标题为“连接方转换”的部分。必须打开“显示线路组成员DN为连接方”设置。
此功能在Communications Manager 9.0(1)及更高版本中提供。
使用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网关录制。
节点升级可能需要数小时,具体取决于其保留的录音数量和大小。对于MediaSense 10.5,当您升级具有超大数据集的节点时,每100万次录制大约需要额外90分钟。
如果MediaSense搜索和播放应用的用户位于任何受影响的时区,或者他们在搜索条件中选择受影响的时区,则会受到影响。与MediaSense接口的第三方合作伙伴产品在更新各自的时区表之前会受到类似影响。
解决方法是选择与GMT的正确偏移匹配的时区,即使城市不再正确。
以下是MediaSense支持的语言:
要监控MediaSense系统性能,请使用RTMT工具或Cisco Prime协作保证工具分析这些关键绩效指标(KPI)的值。
有关RTMT工具或Cisco Prime协作保证工具的详细信息,请参阅《Cisco MediaSense用户指南》的“Unified RTMT管理”和“Cisco Prime协作保证管理”部分。
关键绩效指标 | RTMT计数器 | 建议阈值 |
---|---|---|
呼叫成功率 | MediaSense呼叫控制服务>无错误的录制会话数 MediaSense呼叫控制服务>记录会话数有错误 |
99.99% 呼叫成功率=无错误的录制会话数/(无错误的录制会话数+有错误的录制会话数)* 100 |
API响应API的平均时间 | Cisco MediaSense API服务>平均查询响应时间 | 60秒 |
录制开始平均设置延迟 | Cisco MediaSense呼叫控制服务>平均设置延迟 | 3秒 |
CPU平均利用率 | 处理器> %CPU时间 | 90% |
内存平均利用率 | 内存> %内存已用 | 70% |
RTP/UDP数据包丢弃 | 网络接口(Network Interface)> Rx Dropped(Rx丢弃)> eth0 网络接口(Network Interface)> Rx错误(Rx Errors)> eth0 |
0 0 |
根据浏览器,执行以下步骤以运行浏览器内播放器:
Internet Explorer 9 | Internet Explorer 11 | Mozilla Firefox |
---|---|---|
1.在MediaSense搜索和播放中,单击录制会话的“播放”图标。 | 前提条件:在新安装MediaSense 11.0时,请确保使用相应的完全限定域名(FQDN)将MediaSense节点添加到集群。 如果升级到MediaSense 11.0,请确保先前使用主机名添加的MediaSense节点现在应由各自的FQDN显示。在MediaSense服务器配置窗口(Cisco MediaSense管理> System > MediaSense服务器配置)中检查MediaSense服务器列表(MediaSense Server Configuration)。 |
1.在Mozilla Firefox的受信任颁发机构中为mp4url的端口8446添加MediaSense节点的自签名证书。 |
2.单击“是”以信任证书。 注意:通过验证证书技术详细信息中的FQDN,验证所提供的自签名证书是否属于目标MediaSense节点。 |
请执行下列步骤: 1.将hostnameformediaurl CLI设置为“true”,使MediaSense只使用FQDN准备mp4url和其余的媒体。 admin:set useHostNameForMediaURL admin:set useHostNameForMediaURL true 2.重新启动配置服务以激活属性。 admin:utils service restart Cisco MediaSense Configuration Service 注意:如果服务未正确重新启动,请再次执行相同的命令。 |
2.要添加自签名证书,请单击录制会话的下载图标,然后选择mp4。 此时将显示“Connection is Untrusted”弹出窗口。 |
3.单击与所选录制对应的“播放”图标。 浏览器内播放器播放所选录制会话。 |
执行以下步骤,将MediaSense自签名证书添加到Windows受信任颁发机构。 1.打开MediaSense搜索和播放功能。 The import was successful. 12.单击“确定”。 |
2.要添加自签名证书,请单击录制会话的下载图标,然后选择mp4。 此时将显示“此连接不受信任”弹出窗口。注意:通过验证证书技术详细信息中的FQDN,验证所提供的自签名证书是否属于目标MediaSense节点。 |
3.单击“我了解风险”链接。 | ||
4.单击“添加例外”。 系统将显示Add Security Exception弹出窗口。 |
||
5.单击“确认安全例外”。 特定MS节点8446端口的自签名证书将添加到浏览器的受信任颁发机构。 |