排除CUBE上多個M線路引起的傳真故障

簡介

本文描述當由於來自提供商的多條m線導致出站傳真失敗時，如何解決思科統一邊界元素(CUBE)上的問題。CUBE不能理解多個m行，但可以在CUBE上實施解決方法，以便通過使用會話發起協定(SIP)配置檔案來解決問題。

必要條件

需求

本文件沒有特定需求。

採用元件

本檔案中的資訊是根據以下硬體和軟體版本：

• 傳真伺服器
• 思科整合通訊管理員(CUCM)
• 立方體

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

網路拓撲

本檔案所述的範例使用以下網路拓撲：

問題

當提供商在語音到傳真切換期間向CUBE傳送Invite消息，並且其中包含包含兩個m線路的會話描述協定(SDP)時，CUBE的原始行為是拒絕帶有SIP 488 Not Acceptable Here消息的呼叫。

使用思科錯誤ID CSCtw96549後，此行為已更改。現在，如果提供商傳送帶有兩個m線路的SDP，則呼叫會按預期進行。

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

m=音訊
m=影象

但是，如果提供商傳送的SDP的m行格式相反，則CUBE不會正確處理它，並在Invite消息中將格式錯誤的SDP傳送到傳真伺服器。因此，所有呼叫都將失敗。

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

m=影象
m=音訊

提示：如需更多詳細資訊，請參閱Cisco錯誤ID CSCue70469。

解決方案

若要排解此問題，請發出傳出傳真測試通話並收集SIP偵錯(debug ccsip messages)。 從偵錯輸出中，可得出以下觀察結果：

• 語音呼叫建立沒有問題。
  
  
• 當將呼叫升級為傳真時，提供商端在檢測到V.21報頭時啟動切換。
  

  附註：被呼叫的端並不總是必須啟動切換的。多個傳真伺服器具有啟動切換的功能，即使它們是呼叫的發起終端。這是通過T.30指示器資料包中的呼叫(CNG)音調封裝完成的。

• 切換的重新邀請包含兩條媒體線路(m=)，因此m=image線路位於m=audio線路的上方，在這種情況下，思科錯誤ID CSCue70469中描述的缺陷會出現，且CUBE會斷開呼叫。

目前，在CUBE上沒有解決此問題的方案，但您可以更改外部因素以解決此問題：

• 僅使用一個m線路進行語音到傳真切換。
  
  
• 使用基於協定的傳遞。
  
  
• 讓提供商將m=audio行放在m=image行上。
  
  
• 使用傳真伺服器，以便在T.30指示器資料包中使用CNG啟動切換。

CUBE版本10.0利用了一個用於入站SIP配置檔案的新功能，其中SIP配置檔案應用於入站SIP消息，然後再將其呈現給SIP堆疊並進行處理。在此場景中使用入站SIP配置檔案的理念是將m=audio line全部刪除，以便CUBE只能使用單個m=image line。

以下是提供商希望將語音呼叫升級為傳真時的重新邀請消息示例：

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，因為「t38UDPRdundancy」已替換為：

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

總之，使用本文檔中介紹的解決方法（大多數依賴於提供商）來解決多個m行的問題。此外，已經觀察到，Xmedius伺服器也可以啟動切換，因為它強制伺服器傳送T.38 re-Invite消息並避免顯示多個m行。