目錄

簡介

必要條件

需求

採用元件

網路拓撲

問題

解決方案

簡介

本文描述當由於來自提供商的多條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行。