목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

네트워크 토폴로지

문제

솔루션

소개

이 문서에서는 공급자로부터 여러 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=오디오

팁:자세한 내용은 Cisco 버그 ID CSCue70469를 참조하십시오.

솔루션

이 문제를 해결하려면 아웃바운드 팩스 테스트 호출을 수행하고 SIP 디버깅(디버그 ccsip 메시지)을 수집합니다. 디버그 출력에서 다음과 같은 관찰이 가능합니다.

- 음성 통화는 문제 없이 설정됩니다.

- 통화를 팩스로 에스컬레이션할 시점이 되면 V.21 프리앰블이 감지되면 공급자 측에서 전환을 시작합니다.

참고:전환 시작을 위해 호출되는 측에서 반드시 필요한 것은 아닙니다.일부 팩스 서버는 통화가 시작되는 터미널임에도 불구하고 전환을 시작하는 기능을 제공합니다.이는 T.30 지표 패킷에서 CNG(Calling) 신호음을 캡슐화하여 수행합니다.

- 스위치오버에 대한 재초대는 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을 표시하지 않도록 하기 때문에 스위치오버를 시작할 수도 있습니다.