CUBE의 여러 M-행으로 인한 팩스 실패 문제 해결
소개
이 문서에서는 공급자로부터 여러 m회선으로 인해 아웃바운드 팩스 장애가 발생할 경우 Cisco CUBE(Unified Border Element)에서 문제를 해결하는 방법에 대해 설명합니다.CUBE는 여러 m-라인을 인식하지 못하지만 SIP(Session Initiation Protocol) 프로파일을 사용하여 문제를 해결하기 위해 CUBE에 해결 방법을 구현할 수 있습니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서의 정보는 다음 하드웨어 및 소프트웨어 버전을 기반으로 합니다.
- 팩스 서버
- Cisco CUCM(Unified Communications Manager)
- 큐브
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
네트워크 토폴로지
이 문서에서 설명하는 예제는 다음 네트워크 토폴로지를 사용합니다.
문제
공급자가 Voice-to-Fax 전환 중에 CUBE에 초대 메시지를 보내고 2개의 m-라인을 포함하는 SDP(Session Description Protocol)를 포함하는 경우, CUBE의 원래 동작은 SIP 488 Not Acceptable Here 메시지로 통화를 거부하는 것이었습니다.
Cisco 버그 ID CSCtw96549가 끝나면 이 동작이 변경되었습니다.이제 공급자가 두 개의 m-회선으로 SDP를 보내는 경우 통화가 예상대로 진행됩니다.
허용되는 m-라인 형식의 예는 다음과 같습니다.
m=오디오
m=이미지
그러나 공급자가 M-라인 형식이 반대로 SDP를 보내면 CUBE가 SDP를 올바르게 처리하지 않고 형식이 잘못된 SDP를 Invite 메시지의 팩스 서버로 보냅니다.따라서 모든 통화가 실패합니다.
다음은 허용되지 않는 m-라인 형식의 예입니다.
m=이미지
m=오디오
솔루션
이 문제를 해결하려면 아웃바운드 팩스 테스트 호출을 수행하고 SIP 디버깅(디버그 ccsip 메시지)을 수집합니다. 디버그 출력에서 다음과 같은 관찰이 가능합니다.
- 음성 통화는 문제 없이 설정됩니다.
- 통화를 팩스로 에스컬레이션할 시점이 되면 V.21 프리앰블이 감지되면 공급자 측에서 전환을 시작합니다.
- 스위치오버에 대한 재초대는 m=image 라인이 m=audio 라인 위에 놓이는 두 개의 미디어 라인(m=)을 포함합니다. 이 경우 Cisco 버그 ID CSCue70469에 설명된 결함이 발생하고 CUBE가 통화의 연결을 끊습니다.
현재 CUBE에서 이 문제에 대한 해결 방법이 없지만 문제를 해결하려면 외부 요소를 변경할 수 있습니다.
- Voice-to-Fax 스위치오버에는 m-라인 하나만 사용합니다.
- 프로토콜 기반 패스스루를 사용합니다.
- 공급자가 m=image 라인 위에 m=audio 줄을 배치하도록 합니다.
- T.30 지표 패킷에서 CNG를 사용하여 전환을 시작하려면 팩스 서버를 사용합니다.
CUBE 버전 10.0은 인바운드 SIP 프로필에 대한 새 기능을 활용합니다. SIP 프로파일은 인바운드 SIP 메시지에 적용되고 SIP 스택에 전달되어 처리됩니다.이 시나리오에서 인바운드 SIP 프로파일을 사용하는 배경에는 CUBE가 m=image 라인을 하나만 사용할 수 있도록 m=audio 줄을 모두 제거하는 것이 좋습니다.
다음은 공급자가 음성 통화를 팩스로 에스컬레이션하려는 경우 다시 초대 메시지의 예입니다.
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
================================
m=오디오 라인을 제거하기 위해 이 SIP 프로필 컨피그레이션을 적용할 수 있습니다.
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 메시지가 수신된 재초대에 대한 응답으로 공급자에게 전송될 때 RFC를 준수하고 응답 메시지에 제안 메시지와 동일한 수의 미디어 특성이 있는지 확인하기 위해 두 m 행을 모두 제공해야 합니다.
이 작업은 공급자를 가리키는 다이얼 피어에 적용되는 표준 아웃바운드 SIP 프로필을 통해 수행할 수 있습니다.
voice class sip-profiles 200
response 200 method re-invite sdp-header Attribute modify "t38UDPRedundancy"
"t38UDPRedundancy\x0D\x0Am=audio 0 RTP/AVP"
이렇게 하면 "t38UDUNDANCY"가 다음과 같이 대체되므로 여러 m-line으로 재초대가 올바르게 처리되고 공급자에 대한 응답이 RFC를 준수합니다.
"t38UDPRedundancy"
New line ( \x0D\x0A )
m=audio 0 RTP/AVP
요약하면, 여러 m-라인의 문제를 해결하기 위해 이 문서에 설명된 해결 방법(대부분 공급자 종속)을 사용합니다.또한 Xmedius Server는 서버가 T.38 다시 초대 메시지를 보내고 여러 m-line을 표시하지 않도록 하기 때문에 스위치오버를 시작할 수도 있습니다.
피드백