排除CUBE上多条M线路导致的传真故障

简介

本文档介绍当来自提供商的多条m行导致出站传真故障时如何解决思科统一边界元素(CUBE)上的问题。CUBE不了解多条m行，但可以在CUBE上实施解决方法，以便使用会话初始协议(SIP)配置文件解决问题。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

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

• 传真服务器
• 思科统一通信管理器 (CUCM)
• CUBE

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

网络拓扑

本文档中介绍的示例使用此网络拓扑：

问题

当提供商在语音到传真切换期间向CUBE发送邀请消息，并且包括包含两条m行的会话描述协议(SDP)时，CUBE的原始行为是拒绝带有SIP 488 Not Acceptable Here消息的呼叫。

在Cisco Bug ID CSCtw96549之后，此行为已更改。现在，如果提供商发送带有两条m线路的SDP，呼叫将按预期进行。

以下是接受的m行格式的示例：

m=audio
m=image

但是，如果提供商发送m行格式相反的SDP，CUBE将无法正确处理该SDP，并会在“邀请”消息中向传真服务器发送格式错误的SDP。因此，所有呼叫都会失败。

以下是未接受m行格式的示例：

m=image
m=audio

提示：有关更多详细信息，请参阅Cisco Bug ID CSCue70469。

解决方案

要解决此问题，请发出出站传真测试呼叫并收集SIP调试(debug ccsip消息)。 从调试输出中，可以进行以下观察：

• 无问题地建立语音呼叫。
  
  
• 当应将呼叫升级到传真时，在检测到V.21前导码时，由提供商端发起切换。
  

  注意：对于被调用以启动切换的端，并非总是强制。多个传真服务器能够启动切换，即使它们是呼叫发起的终端。这是通过在T.30指示器数据包中封装呼叫(CNG)音来完成的。

• 切换的重新邀请具有两条媒体线路(m=)，使得m=image线路置于m=audio线路的上方，在这种情况下，Cisco Bug ID CSCue70469中描述的缺陷出现，CUBE断开呼叫。

目前，CUBE上没有解决此问题的方法，但您可以更改外部因素以解决此问题：

• 仅使用一条m线路进行语音到传真交换。
  
  
• 使用基于协议的直通。
  
  
• 让提供商将m=audio线放在m=image线上。
  
  
• 在T.30指示器数据包中使用CNG，使用传真服务器启动切换。

CUBE版本10.0利用入站SIP配置文件的新功能，在将SIP配置文件呈现给SIP堆栈并进行处理之前，SIP配置文件应用于入站SIP消息。在此场景中使用入站SIP配置文件的思想是将m=audio行全部删除，以便CUBE只能使用单条m=image行。

以下是提供商希望将语音呼叫升级到传真时重新邀请消息的示例：

Received:
INVITE sip:025027141@192.0.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnm30rd10dofho0fo9011sb0000g00.1
Call-ID: 6B6CB982-B41D11E3-898F851F-F1ADD198@192.0.2.2
From: <sip:026455288@25027100.xyz>;tag=7qapqh6u-CC-36
To: "Administrator" <sip:025027141@25027100.xyz>;tag=85A6C018-2489
CSeq: 1 INVITE
Contact: <sip:192.0.2.1:5060;transport=udp>
Max-Forwards: 69
Content-Length: 431
Content-Type: application/sdp
v=0
o=HuaweiSoftX3000 22157305 22157306 IN IP4 192.0.2.1
s=Sip Call
c=IN IP4 192.0.2.1
t=0 0
m=image 53200 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
m=audio 53190 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=ecan:fb on -
a=X-fax
================================

可以应用此SIP配置文件配置以删除m=audio线路：

voice class sip-profiles 966
request REINVITE sdp-header Audio-Media modify "(.*)" "a=sendrecv"
voice service voip
sip
voice-class sip profiles 966 inbound
or 
dial-peer voice XYZ voip
voice-class sip profiles 966 inbound

此SIP配置文件将m=audio线路更改为a=sendrecv，该线路在SDP中充当不相关的线路。这允许CUBE向传真服务器端发送重新邀请消息，并等待200 OK响应。

您还必须解决一个更重要的方面：当响应收到的重新邀请将200 OK消息发送给提供商时，它必须同时显示m行，以符合RFC并确保响应消息的媒体属性数量与提供消息相同。

您可以通过在指向提供商的拨号对等体上应用的标准出站SIP配置文件来完成此操作：

voice class sip-profiles 200
response 200 method re-invite sdp-header Attribute modify "t38UDPRedundancy"
 "t38UDPRedundancy\x0D\x0Am=audio 0 RTP/AVP"

这可确保正确处理带有多条m行的重新邀请，并确保对提供商的响应符合RFC要求，因为“t38UDPRedduncy”替换为:

"t38UDPRedundancy"
New line ( \x0D\x0A )
m=audio 0 RTP/AVP

总之，请使用本文档中介绍的解决方法（大部分都依赖于提供商），以解决多m行的问题。此外，已观察到Xmedius服务器也可以启动切换，因为它强制服务器发送T.38重新邀请消息并避免显示多条m线路。