팩스 릴레이 문제 해결

소개

이 문서에서는 기본적인 트러블슈팅 및 Cisco 팩스 릴레이 관련 문제의 해결에 대해 설명합니다. 

사전 요구 사항

요구 사항

Cisco IOS^® 게이트웨이의 패킷 텔레포니 네트워크를 통해 팩스 통화를 전달하는 데 여러 가지 기술이 사용됩니다.

• Cisco 전용 팩스 릴레이

• T.38 팩스 릴레이

• 팩스 통과

• 팩스 빠른 속도

• T.37 팩스 저장 및 전달

또한 현재 VoX(Voice over "X")라는 세 가지 주요 패킷 텔레포니 기술이 사용되고 있습니다.

• VoIP(Voice over IP)

• VoFR(Voice over Frame Relay)

• VoATM(Voice over ATM)

이 문서에서는 VoIP 네트워크를 통해 작동하는 Cisco IOS 게이트웨이의 Cisco 전용 팩스 릴레이를 주로 다룹니다. T.38 팩스 릴레이 및 기타 VoX 기술에 대해서도 설명합니다.

팩스 및 팩스 릴레이의 기술적인 복잡성에 대해서는 자세히 다루지 않지만 일반적인 팩스 릴레이 문제의 대부분을 해결할 수 있습니다. 팩스 및 Cisco 팩스 릴레이에 대한 개요도 제공됩니다.

사용되는 구성 요소

이 문서의 정보는 주로 Cisco IOS Software Release 12.2(5)를 기반으로 하지만, 대부분의 정보는 다른 Cisco IOS Software 릴리스에도 유용합니다.

일부 디버그 정보는 Cisco IOS Software Release 12.2(7)를 실행한 Cisco IOS 게이트웨이에서 가져왔습니다. 이 점은 이 문서의 디버깅 섹션에 나와 있습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

팩스 및 팩스 릴레이 개요

대부분의 최신 팩스 장치는 그룹 3을 준수합니다. 팩스 그룹 3은 주로 T.4 및 T.30 ITU 권장 사항으로 구성된 표준 기반 기술입니다.

T.4는 팩스 장치가 팩스 이미지를 인코딩하는 방법에 관한 것이고, T.30은 팩스 협상 및 통신 프로토콜을 상세히 설명한다.

그룹 3 팩스 장치는 PSTN(Public Switched Telephone Network)에서 사용하도록 설계되었습니다. PSTN은 사람의 음성을 위해 설계되었기 때문에 그룹 3은 아날로그 모뎀과 마찬가지로 아날로그 인코딩 또는 변조 신호를 사용합니다.

아날로그 모뎀과 팩스 기기는 모두 디지털 장치이며, PSTN을 통해 디지털 정보를 전달하려면 변조된 아날로그 신호를 사용해야 합니다. 이러한 변조된 신호는 보통 상이한 오디오 톤으로서 들릴 수 있다.

VoX 네트워크의 게이트웨이는 음성 통화와 팩스 통화를 동일하게 처리합니다. 두 가지 유형의 통화는 게이트웨이가 구성된 음성 압축 코덱을 DSP(Digital Signal Processor)에 로드하도록 합니다.

DSP에 대한 자세한 내용은 음성 하드웨어: C542 및 C549 DSP(Digital Signal Processor)를 참조하십시오.

음성 압축 코덱은 일반적으로 높은 압축 코덱이므로 각 음성 통화에 사용되는 대역폭이 더 적습니다.

G729 및 G723과 같은 높은 압축 코덱은 음성에 최적화되어 있으며 낮은 대역폭(8kbps, G.729의 오버헤드는 제외)으로 음성을 압축하지만, G.729 및 기타 높은 압축 코덱은 팩스에 최적화되어 있지 않습니다.

실제로 이러한 코덱을 사용할 때 팩스 전송의 변조 신호는 일반적으로 올바르게 전달되지 않으며 그 결과 팩스 호출이 실패합니다.

압축 코덱에 대한 자세한 내용은 VoIP(Voice over IP) - 통화별 대역폭 소비를 참조하십시오.

압축률이 낮거나 압축이 전혀 없는 코덱(예: 에코 제거 또는 음성 활동 탐지가 없는 G.726 및 G.711)을 사용할 경우 팩스를 성공적으로 전송할 수 있습니다.

음성 코덱을 통해 팩스를 전송하는 이러한 방법을 보통 인밴드 팩스 또는 팩스 통과라고 한다.

고속화라고 하는 기술을 사용하면 게이트웨이가 구성된 음성 압축 코덱을 음성 통화용 DSP에 처음 로드하고 팩스 신호음이 감지되면 저압축 코덱으로 변경할 수 있습니다.

인밴드 팩싱에서는 초기 변조 신호가 소스 라우터의 코덱에서 인코딩 및 압축되어 음성 샘플처럼 VoX 네트워크를 통과합니다.

그러면 종단 게이트웨이는 샘플을 압축 해제하고 디코딩한 다음 종단 팩스 장치에 재생합니다.

팩스 릴레이는 다르게 작동합니다. 변조신호를 종료하고, 디지털정보를 추출한 후, 데이터망을 통해 디지털정보를 데이터패킷으로 중계하는 프로토콜이다.

종단 측에서 디지털 정보는 패킷으로부터 추출되고 변조되어 재생된다.

팩스 기본 정보

팩스 통화는 팩스 협상과 페이지 전송이라는 두 부분으로 나눌 수 있습니다.

반이중 팩스 협상은 팩스 통화가 시작될 때 발생합니다. V.21 변조 HDLC(High-level Data Link Control) 데이터 프레임은 300bps의 속도로 전달됩니다.

이러한 데이터 프레임은 시작 및 종료 팩스 장치 사이에 표준 순서로 전송됩니다.

이 교환에서는 각 팩스 장치가 기능을 교환하며, 두 팩스 장치 모두 페이지 전송이 발생하기 전에 팩스 세션 특성에 동의합니다.

이 그림에서는 PSTN을 통한 기존 팩스 통화를 보여 줍니다.

교환되고 협상되는 일부 기능은 페이지 전송 속도, ECM(Error Correction Mode), 해상도, 페이지 코딩, 스캔 시간입니다.

페이지 전송 속도(트레이닝)는 팩스가 정보를 전송하는 속도를 결정하는 중요한 협상입니다.

팩스는 처음에 교환된 파라미터를 기반으로 가능한 가장 높은 변조 속도로 트레이닝하려고 노력한다. 더 빠른 속도의 학습이 실패하면 팩스 장치는 더 낮은 속도로 다시 학습합니다.

페이지 전송은 팩스 협상 단계의 트레이닝 부분이 이전에 합의된 매개변수를 사용하여 완료될 때 발생합니다. 페이지 정보는 203H x 98V dots per inch의 표준 해상도로 스캔 라인으로 코딩됩니다.

팩스 이미지는 일반적으로 MH(Modified Huffman) 또는 MR(Modified Read) 인코딩으로 압축되고 인코딩됩니다. MH는 일반적으로 20:1 비율로 압축합니다. MR 인코딩은 일반적으로 MH에 비해 20% 압축 개선을 제공하지만 오류에 대해서는 약간 덜 탄력적입니다.

페이지 전송이 발생하면 통화 설정 협상에서 사용되는 초기 300 BPS보다 높은 비트 속도가 사용됩니다. 페이지 전송에 사용된 비트율은 트레이닝 내에서 확인된다.

다음은 팩스 페이지 전송에 사용되는 몇 가지 일반적인 요금입니다.

• V.27ter - 2,400/4,800BPS

• V.29 - 7200/9600BPS

• V.17 - 14400BPS

참고: 페이지 전송(V.27ter, V.29, V.17) 및 팩스 협상(V.21)에 사용되는 이러한 V.XX 사양은 아날로그 전화 회선을 통해 디지털 데이터를 전송하는 방법을 정의하는 사양입니다.

대부분의 데이터 모뎀이 훨씬 빠른 속도로 마이그레이션되었지만 데이터 모뎀도 이러한 사양을 사용할 수 있습니다.

팩스 릴레이 기본 사항

팩스 릴레이는 이러한 코덱이 팩스 트래픽을 전달하려고 할 때 고압축 음성 코덱(G729, g723 등)의 부족을 해결하기 위해 사용되는 기술입니다.

팩스 통화는 일반 음성 통화인 것처럼 처리되므로 각 게이트웨이의 DSP가 음성 모드로 전환되고 그 후 사람의 음성이 수신되어 처리됩니다.

통화 중에 CED(Fax Answer) 또는 CNG(Call Tone)가 들리면 DSP는 음성 처리를 방해하지 않습니다. VoX 통화 구간 전반에서 신호음이 계속 울릴 수 있습니다.

일반 팩스 시스템은 CED를 생성하거나 CNG를 수신한 후 팩스 핸드셰이크의 일부로 T.30 DIS 메시지를 전송합니다. 이 프로세스는 일반적으로 종료 팩스 시스템에서 발생합니다.

종단 게이트웨이의 DSP는 DIS 메시지의 시작 부분에서 HDLC 플래그 시퀀스를 탐지하고 팩스 릴레이 전환을 시작합니다. 즉, 음성 코덱을 언로드하고 팩스 코덱을 로드하여 발생하는 팩스 호출을 처리합니다.

팩스 통화의 각 쪽에 있는 DSP가 팩스 코덱을 사용하도록 VoX 네트워크의 다른 쪽에 있는 DSP에도 알림이 전송됩니다. 사용된 팩스 릴레이 프로토콜에 따라 알림 메커니즘이 다릅니다.

DSP는 로드된 팩스 코덱을 사용하여 T.30 HDLC 프레임을 복조하고 팩스 정보를 추출하여 다음 팩스 릴레이 프로토콜 중 하나를 사용하여 라우터 간에 전달합니다.

• 독점적인 Cisco Fax Relay for VoIP - Fax Relay는 VoIP 네트워크를 통해 팩스를 전달하는 기본 모드이며 Cisco Fax Relay는 기본 팩스 릴레이 유형입니다. 이 기능은 Cisco IOS Software Release 11.3 이상에서 지원되었으며 널리 사용 가능하며 RTP를 사용하여 팩스 데이터를 전송합니다.

• 표준 기반 T.38 fax for VoIP - T.38은 일부 플랫폼에서 Cisco IOS Software 릴리스 12.1(3)T 이상에서 사용할 수 있습니다. VoIP 다이얼 피어에 구성된 fax relay protocol t38 명령으로 이 기능을 활성화할 수 있으며 UDP를 사용하여 팩스 데이터를 전송합니다.

• 표준 기반 FRF.11 Annex D for VoFR and VoATM.

인밴드 팩스나 팩스 패스스루와 달리 팩스 릴레이는 T.30 팩스 톤을 특정 HDLC 프레임으로 분할하고(복조), 팩스 릴레이 프로토콜을 사용하여 VoX 네트워크를 통해 정보를 전송한 다음 비트를 먼 쪽의 톤으로 다시 변환합니다(변조).

양쪽 송신 및 수신 톤의 팩스 기기는 복조/변조 팩스 릴레이 프로세스를 인식하지 못합니다.

Cisco 팩스 릴레이와 T.38 팩스 릴레이는 T.37 팩스 상점과 전달의 차이점이 있습니다. T.37은 VoIP 게이트웨이가 이 정보를 수신할 수 있도록 표준 기반 방법을 제공합니다.

현재 대부분의 Cisco 음성 게이트웨이는 IP 네트워크를 통해 팩스 트래픽을 전송하는 두 가지 방법을 지원합니다.

1. Fax Pass-Through(팩스 통과) - 팩스 통과 모드에서 게이트웨이는 팩스 호출과 음성 호출을 구분하지 않습니다

2. Cisco Fax Relay — 팩스 릴레이 모드에서 게이트웨이는 T.30 팩스 신호 처리를 종료합니다

Cisco 팩스 릴레이와 T.38 팩스 릴레이는 T.37 팩스 상점과 전달의 차이점이 있습니다. T.37은 VoIP 게이트웨이가 이 정보를 수신할 수 있도록 표준 기반 방법을 제공합니다.

• 팩스 시스템에서 보낸 팩스로 SMTP 가능 메일 서버로 전달합니다. 그런 다음 메일 서버는 사용자에게 팩스를 전자 메일 메시지로 전달할 수 있습니다.

• 메일 서버의 이메일 메시지를 일반 팩스 장치에서 수신할 팩스 신호로 변조합니다.

이 다이어그램은 VoX 네트워크를 통한 팩스 릴레이를 보여줍니다. 시작 및 종료 게이트웨이에 대한 팩스 연결은 게이트웨이의 FXS 포트에 직접 연결할 수도 있고, PBX 또는 PSTN을 통해 게이트웨이의 E1, BRI(Basic Rate Interface), FXO 또는 E&M 포트에 연결할 수도 있습니다.

컨피그레이션 고려 사항

팩스 릴레이는 Cisco 3810, 2600, 3600, 5300과 같은 VoIP/VoFR/VoATM 플랫폼에서 기본적으로 사용됩니다. 두 라우터 간에 음성 통화가 성공적으로 완료되면 팩스 통화가 작동하는 것으로 간주되지만 팩스 릴레이가 작동하지 않거나 성능을 개선해야 할 경우 문제를 해결하기 위한 전조로 사용할 수 있는 몇 가지 팩스 릴레이 관련 명령이 있습니다.

• 팩스 속도

• 팩스 릴레이 ECM 비활성화

• 팩스 NSF

• 팩스 프로토콜

fax rate 명령

fax rate 명령은 컨피그레이션 모드에서 VoFR 또는 VoIP 다이얼 피어에 구성됩니다. 기본 설정은 팩스 속도 음성이며 각 다이얼 피어의 컨피그레이션에는 나타나지 않습니다.

vnt-3660-23(config-dial-peer)#fax rate ?
  12000    FAX   12000 BPS
  14400    FAX   14400 BPS
   2400    FAX   2400  BPS
   4800    FAX   4800  BPS
   7200    FAX   7200  BPS
   9600    FAX   9600  BPS
  disable  Disable Fax Relay
  voice    Highest possible speed allowed by voice rate

팩스 속도 음성 설정은 팩스 속도를 코덱 대역폭으로 제한합니다. 이 제한은 다이얼 피어가 음성을 8kbps로 압축하는 기본 G.729 음성 코덱을 사용하도록 구성된 경우 팩스 속도 음성 설정에 따라 팩스 통화가 이 코덱 대역폭을 초과하지 않도록 합니다.

팩스는 처음에 14400BPS 또는 9600BPS의 더 높은 대역폭에서 협상을 시도했더라도 7200BPS의 대역폭으로 제한됩니다.

일반적으로 PSTN을 통해 연결할 때 특정 시간 내에 완료된 팩스가 이제 2배의 시간이 걸린다는 불만이 있습니다. g729와 같은 저대역폭 코덱이 기본 팩스 속도 음성 설정으로 구성된 경우 이 동작이 필요합니다.

fax rate 명령을 사용하면 코덱 압축보다 큰 대역폭을 사용하도록 팩스 전송을 구성할 수 있습니다.

명령 팩스 속도 14400을 사용하면 구성된 음성 코덱에 관계없이 팩스 호출을 최대 14400BPS로 협상할 수 있습니다. 이 컨피그레이션을 사용하면 완료 시간이 길어지는 문제가 해결됩니다.

VoX 네트워크 내에서 fax rate 명령이 제공하는 주요 목적은 통화당 결정적인 대역폭 사용량을 제공하는 것입니다.

VoX 네트워크 내에서 음성 통화와 팩스 통화가 동일한 양의 대역폭을 사용하도록 하기 때문에 팩스 속도 음성 설정이 기본값입니다. 이러한 고려 사항은 팩스 속도가 코덱 대역폭보다 더 큰 값으로 변경될 때 이해됩니다.

또한 일부 팩스 기기는 기본값과 다른 속도로 더 안정적으로 작동할 수 있습니다. 이 경우 fax rate 명령을 사용하여 다른 속도로 작업을 테스트할 수 있습니다.

라우터 출력에서 fax rate 명령을 실행하면 팩스 릴레이도 비활성화할 수 있습니다. 유효한 트러블슈팅 기술은 팩스 릴레이를 비활성화하고 G711과 같은 고대역폭 코덱을 구성하는 것입니다.

이 기법은 6의 "문제 해결" 섹션에서 설명합니다. 팩스 릴레이를 비활성화하고 통과를 위해 코덱을 변경합니다.

fax-relay ECM disable 명령

fax-relay ECM disable 명령은 Cisco 전용 팩스 릴레이에만 사용할 수 있으며 한 쌍의 팩스 머신 간의 ECM(오류 수정 모드) 협상을 비활성화하기 위해 실행됩니다.

ECM은 팩스된 페이지가 오류 없이 전송될 수 있도록 하며, 일반적으로 고급 모델에서 볼 수 있는 기능입니다.

안타깝게도 ECM은 지터 및 패킷 손실에 대한 허용 오차(약 2%)가 낮지만, 이 협상된 기능을 활성화하면 손실 있는 VoX 네트워크에서 팩스 실패율이 높아질 수 있습니다. 종료 팩스의 불완전한 출력은 패킷 손실로 인한 장애의 증상입니다.

두 팩스 시스템이 팩스 협상 단계 내에서 동의하면 ECM이 활성화되지만 팩스 릴레이 내에서 라우터는 팩스 톤을 실제 HDLC 프레임 형식으로 복조합니다.

따라서 라우터는 ECM 상태를 나타내는 프레임의 필드를 가로채고 덮어쓸 수 있습니다. 팩스 시스템에서 ECM을 지원하는 것으로 전송하면 라우터가 이 매개변수를 변경하여 다른 팩스 시스템에서 ECM이 지원되지 않는 것으로 간주하도록 할 수 있습니다.

두 팩스 모두 ECM을 비활성화해야 하므로, 팩스 데이터는 표준 T.4 데이터와 함께 전송되어야 합니다.

ECM을 비활성화하면 훨씬 높은 패킷 손실(약 10%) 및 지연에도 팩스 안정성이 크게 향상됩니다. 또한 이 명령을 사용하면 패킷 손실 은폐라는 Cisco IOS 기능이 자동으로 활성화되므로, 손실 된 스캔 라인이 팩스 시스템을 스푸핑하여 모든 데이터를 받았다고 생각할 수 있습니다.

ECM은 손실 많은 VoX 네트워크에서 팩스 전송의 성공률을 높일 수 있지만, 기본적인 네트워크 문제는 그대로 남아 있으며 다른 문제가 발생하기 전에 해결해야 합니다.

VoIP 다이얼 피어에서 수행되는 간단한 구성 단계는 ECM을 비활성화하는 것입니다. 명령 참조에 나와 있는 것처럼 이 명령은 현재 VoIP 다이얼 피어에서만 작동합니다. VoFR 및 VoATM에 대해 구성할 수 있지만 ECM을 비활성화하지는 않습니다.

vnt-3660-23(config-dial-peer)#fax-relay ECM ?
disable Disables ECM mode for fax relay

fax NSF 명령

fax NSF 명령은 독점적 팩스 기능의 전송을 방지하는 데 사용됩니다. 라우터의 팩스 릴레이 구현에서는 T.30 사양을 기반으로 팩스 톤을 복조하고 디코딩하므로 독점적인 브레이크 팩스 릴레이인 트랜잭션 또는 인코딩으로 인해 팩스 전송이 실패합니다. 특정 브랜드의 팩스기는 이러한 독점적 인코딩을 사용하여 향상된 기능을 사용할 수 있음을 나타내므로 팩스 제조업체가 제품을 다른 제품과 구별할 수 있습니다. 이 기능 알림은 팩스 협상 내의 선택적 NSF(Non Standard Facilities) 필드에서 발생합니다.

fax NSF 명령을 실행하면 라우터가 NSF를 덮어쓰므로 표준 팩스 트랜잭션만 발생합니다. 표준 그룹 3 요구 사항을 초과하고 Cisco 팩스 릴레이를 중단하는 공급업체별 시설은 사용할 수 없습니다. 일반적으로 이 명령이 실행되면 NSF는 모두 0으로 설정되며, 이는 NSF 필드로 인한 문제를 해결합니다.

vnt-3660-23(config-dial-peer)#fax NSF ?
 WORD  Two-digit country code + four-digit manufacturer code
vnt-3660-23(config-dial-peer)#fax NSF 000000

fax protocol 명령

VoIP에서 사용할 팩스 릴레이 프로토콜(T.38 또는 Cisco 팩스 릴레이)을 지정하려면 fax protocol 명령이 필요합니다.

vnt-3660-23(config-dial-peer)#dial-peer voice 3 voip
vnt-3660-23(config-dial-peer)#fax protocol ?
cisco   Use Cisco proprietary protocol
system  Use choice specified in global fax protocol CLI
t38     Use T.38 protocol

cisco 옵션은 Cisco 팩스 릴레이를 구성합니다. t38 옵션은 Cisco 팩스 릴레이를 비활성화하고 T.38을 활성화합니다. Cisco 5350 및 5400과 같은 특정 음성 플랫폼은 T.38만 지원합니다. 상호운용성을 위해 T.38은 Cisco 팩스 릴레이가 기본값인 플랫폼에서 명시적으로 구성해야 합니다. system(시스템) 옵션을 사용하면 다이얼 피어가 voice service voip 명령으로 전역적으로 구성된 팩스 릴레이 프로토콜을 상속받을 수 있습니다. voice service voip 명령에서 아무 것도 구성되지 않은 경우 기본값은 Cisco fax relay입니다.

fax protocol 명령의 기본 설정은 system 옵션입니다. 시스템 옵션이 기본적으로 Cisco 팩스 릴레이로 설정되므로, 전역으로 명시적으로 구성된 항목이 없는 경우 VoIP 다이얼 피어는 항상 기본적으로 Cisco 팩스 릴레이로 설정됩니다.

<snip>

!
voice service voip
!

!--- Note that there is no fax protocol configured so the !--- default is Cisco fax relay. Any dial-peer that points !--- here uses Cisco fax relay as the fax protocol.

<snip>

!
dial-peer voice 3 voip
destination-pattern 1000
session target ipv4:10.1.1.1
!

!--- Note that because fax protocol is not configured under !--- this VoIP dial-peer, the default is fax protocol system, !--- which automatically tells this dial-peer to inherit the !--- fax configuration from voice service voip above.

<snip>

문제 해결

이러한 단계는 VoIP, VoATM 및 VoFR을 통한 팩스 릴레이와 관련된 대부분의 문제를 해결하는 것으로 나타났습니다. 특정 캡슐화 유형 또는 팩스 릴레이 유형과 관련된 정보가 표시됩니다.

1. 문제 파악 및 격리

팩스 릴레이 문제를 해결할 때 첫 번째 단계는 문제를 가장 간단한 형태로 줄이는 것입니다. 여러 팩스 시스템에서 팩스 트래픽을 전달할 수 없는 경우 많은 문제가 발생합니다. 문제가 있는 두 팩스를 격리하여 간단한 토폴로지에 집중하는 것이 가장 쉽습니다. 이러한 시스템이 서로 어떻게 연결되어 있는지 확인하고 이 쌍 간의 문제를 먼저 해결합니다. 또한 토폴로지의 완전한 그림을 그리고 팩스가 어떻게 상호 연결되어 있는지 확인하는 것이 좋습니다.

한 번에 하나의 문제를 해결하는 것은 혼란을 최소화하고 체계적인 문제 해결을 허용합니다. 이 문제를 해결하는 방법으로 네트워크의 다른 팩스 릴레이 문제도 해결할 수 있습니다. 대부분의 팩스 릴레이 문제는 VoX 컨피그레이션 또는 네트워크 설계가 잘못되었기 때문입니다. 이로 인해 기본 연결 문제 및 물리적 회선 또는 패킷 손실 및 지터 문제가 발생합니다.

문제를 확인하고 격리한 후 다음 단계는 기본 VoX 컨피그레이션을 확인하고 네트워크 상태를 모니터링하는 것입니다.

2. 기본 연결 확인

기본적인 팩스 연결 문제는 다음 요인으로 인해 발생할 수 있습니다.

1. 일반적인 음성 연결 문제.

   팩스 연결을 조사하기 전에 일반 음성 통화를 완료할 수 있는지 확인합니다. 연결된 전화기가 없으면 팩스기의 플러그를 뽑고 일반 전화기를 연결하십시오. 일반 음성 통화가 연결되지 않으면 VoX 관련 문제일 수 있으며 팩스 문제 해결을 계속하기 전에 일반적인 음성 연결 문제로 문제를 해결할 수 있습니다.

2. 다이얼 피어와 관련된 컨피그레이션 문제:

   • 잘못된 다이얼 피어가 일치합니다.

     VoX 네트워크를 통해 양방향으로 음성 통화를 성공적으로 완료할 수 있는지 확인한 후 show call active voice brief 명령을 실행하고 각 음성 통화와 일치하는 다이얼 피어를 확인합니다.

     

     참고: 참고: VoIP 트렁크가 있는 경우 show call active voice brief 명령을 사용하여 모든 통화 구간을 볼 수 있습니다. 일부 버전의 Cisco IOS Software Release 12.2에서는 show call active 명령에 버그가 있으며 VoIP 트렁크를 통해 수신되는 팩스 통화가 더 이상 나타나지 않습니다. show call active fax brief 명령을 실행하면 통화가 나열됩니다. 이 버그에 대한 자세한 내용은 Cisco 버그 ID CSCdx50212 및 Cisco 버그 ID CSCdv02561을 참조하십시오 .

     

     참고: 참고: 구성된 다이얼 피어가 일치하는 피어인지 확인하십시오. 이 명령 출력에서 아웃바운드 VoIP 통화 레그가 피어 ID 100을 사용함을 확인할 수 있습니다.

     show call active voice brief 명령

     ms-3640-13b#show call active voice brief <snip> Total call-legs: 2 1218 : 51710253hs.1 +415 pid:400 Answer 400 active dur 00:01:08 tx:3411/68220 rx:3410/68200 Tele 3/0/0:43: TX:68200/6820/0ms g729r8 noise:0 acom:2 i/0:-51/-44 dBm 1218 : 51710396hs.1 +272 pid:100 Originate 100 active dur 00:01:09 TX:3466/69320 rx:3467/69340 IP 2.1.1.2:17092 rtt:56ms pl:64730/0ms lost:0/1/0 delay:69/69/70ms g729r8 Total call-legs: 2

     팩스 릴레이 문제의 일반적인 원인은 올바르게 구성된 다이얼 피어가 일치하는 피어가 아니기 때문입니다. 또한 종료 게이트웨이에 구성된 특정 인바운드 VoIP 다이얼 피어가 없는 것이 일반적이며, Cisco IOS Software는 첫 번째 적절한(기본) VoIP 다이얼 피어를 인바운드 다이얼 피어로 선택합니다. 이 인바운드 다이얼 피어에 대한 매개변수가 발신 게이트웨이의 아웃바운드 다이얼 피어와 일치하지 않을 수 있습니다.

     아웃바운드 및 인바운드 VoIP 다이얼 피어에서 컨피그레이션이 항상 동일할 필요는 없습니다. 그러나 팩스 릴레이 문제가 발생할 경우 종료 라우터에 전용 인바운드 VoIP 다이얼 피어가 있고 해당 컨피그레이션이 시작 라우터의 아웃바운드 VoIP 다이얼 피어 컨피그레이션과 일치하는지 확인합니다. ISDN 연결 라우터에 대한 이 컨피그레이션은 수신 패턴 "5..."의 발신 게이트웨이와 종단 게이트웨이의 인바운드에 대해 일치하는 특정 VoIP 다이얼 피어의 예입니다.

     시작 게이트웨이	게이트웨이 종료 중
     !--- Incoming POTS peer: Dial-peer voice 1 pots Incoming called number. Direct-inward-dial Port 1/0:15 !--- Outgoing VoIP peer: Dial-peer voice 2 voip Destination-pattern 5… Session target ipv4:10.10.10.10 Fax rate 14400 fax protocol t38 ls-redundancy 0 hs-redundancy 0	!--- Outgoing POTS peer : Dial-peer voice 10 pots Destination-pattern 5… No digit-strip Port 2/0:15 !--- Incoming VoIP peer: Dial-peer voice 20 voip Incoming called-number 5… Fax rate 14400 fax protocol t38 Ls-redundancy 0 Hs-redundancy 0

     인바운드 및 아웃바운드 모두 일치하는 다이얼 피어, VoIP 및 POTS에 대한 자세한 내용은 Voice - Understanding Inbound and Outbound Dial Peers is Matched on Cisco IOS Platforms(Voice - 인바운드 및 아웃바운드 다이얼 피어가 Cisco IOS 플랫폼에서 일치하는 방식 이해)에서 확인할 수 있습니다.

     다이얼 피어 일치를 확인하는 데 사용할 수 있는 또 다른 방법은 debug voip ccapi inout 명령을 실행하는 것입니다. 이 명령의 디버그 출력에서는 호출된 번호와 일치하는 모든 다이얼 피어를 나열하는 ssaSetupPeer 메시지를 표시합니다. 아웃바운드 VoIP 다이얼 피어가 선택되었음을 나타내는 아웃바운드 피어 옵션과 함께 ccCallSetupRequest 메시지가 표시됩니다. 동일한 대상에 대해 여러 VoIP 다이얼 피어가 구성된 경우 초기 통화 설정이 실패하고 다른 다이얼 피어가 시도되었을 수 있습니다. 이 경우 디버그에 다른 ccCallSetupRequest가 나타납니다.

     debug voip ccapi inout - 시작 게이트웨이
     .Jun 4 21:06:43.461: ssaSetupPeer cid(19) peer list: tag(400) called number (5074) .Jun 4 21:06:43.461: ccCallSetupRequest (Inbound call = 0x13, outbound peer =100, dest=, params=0x62F1CC70 mode=0, *callID=0x62F1CFD8, prog_ind = 0)

     종료 음성 게이트웨이에서 debug voip ccapi inout 통화 추적의 첫 번째 줄(여기에 표시된 것처럼)은 종료 게이트웨이의 인바운드 VoIP 다이얼 피어를 참조하는 peer_tag 옵션이 있는 cc_api_call_setup_ind 메시지입니다.

     debug voip ccapi inout - 게이트웨이 종료
     .Jun 4 21:06:43.461: cc_API_call_setup_ind (vdbPtr=0x62F07650, callInfo={called=5074,called_oct3=0x80, calling=5075, calling_oct3=0x0,>calling_oct3a=0x83, calling_xlated=false, subscriber_type_str=Unknown,fdest=1, peer_tag=400, prog_ind=0},callID=0x635F72D0)

   • 한 쪽 또는 양쪽에서 다이얼 피어가 잘못 구성됨

     올바른 다이얼 피어가 일치하는지 확인한 후(이 경우 시작 게이트웨이의 경우 다이얼 피어 100, 종료 라우터의 경우 다이얼 피어 400) 컨피그레이션에서 다이얼 피어가 팩스에 대해 올바르게 구성되었는지 확인합니다. 통화의 양쪽에서 확인할 수 있는 몇 가지 일반적인 오류는 다음과 같습니다.

     • 저대역폭 코덱이 사용 중인 동안 팩스 릴레이가 비활성화됩니다(즉 다이얼 피어에서 fax rate disable 명령이 실행됨).

     • 한 음성 게이트웨이의 다이얼 피어가 Cisco 팩스 릴레이에 대해 구성되었지만 다른 음성 게이트웨이는 Cisco 5350/5400입니다. Cisco 5350/5400은 T.38만 지원하므로 협상에 실패합니다.

     • 종료 게이트웨이의 인바운드에서 사용되는 기본 다이얼 피어 및 기본 매개변수는 시작 게이트웨이의 아웃바운드 다이얼 피어와 일치하지 않습니다.

   • 잘못된 비교 유형

     미국의 준딩형은 µ-law이고, 유럽과 아시아는 a-law이다. show voice call 명령을 실행하여 현재 구성된 값을 확인할 수 있습니다. BRI 또는 E1 포트에서 라우터의 첨부 유형이 연결된 디바이스의 첨부 유형과 일치하지 않을 경우 통화가 실패하거나 연결이 끊어지기도 하지만 목소리가 심하게 왜곡되어 사람이 인식할 수 없게 되고 낮은 피치의 높은 노이즈 수준이 나타납니다.

     Cisco IOS Software Release 12.2(3)에서는 compand-type 명령이 BRI 포트에 없고 companding 유형이 기본값입니다. 이 버그에 대한 자세한 내용은 Cisco 버그 ID CSCdv00152 및 Cisco 버그 ID CSCdv01861을 참조하십시오.

3. 다이얼 피어와 관련이 없는 기타 기본 연결 문제는 다음과 같습니다.

   • 게이트웨이 쌍에서 Cisco IOS Software 비호환성.

     Cisco IOS Software 릴리스가 반드시 일치해야 하는 것은 아니지만 문제가 발생할 때 릴리스를 확인하는 것이 좋습니다.

   • cRTP(Compressed Real-Time Transport Protocol)

     cRTP와 관련된 몇 가지 알려진 문제가 있습니다. 이러한 문제에 대한 수정 사항을 사용할 수 있으며, Cisco IOS 소프트웨어 업그레이드가 적절한 조치 방법인지 확인하기 위해 문제가 발생할 때 cRTP를 비활성화하는 것이 좋습니다.

   • Cisco AS5300 음성 게이트웨이에서 VCWare 및 Cisco IOS Software가 호환되는지 확인합니다.

4. PSTN에서 팩스 연결 문제가 발생했습니다.

   음성 통화가 양방향으로 작동하지만 팩스 통화가 하나 이상의 방향으로 실패하면 두 시스템 간의 일반 팩스가 PSTN에서 작동하는지 확인합니다. 즉, 팩스 시스템이 VoX 네트워크를 통과하지 않고 PSTN을 통해 서로 성공적으로 팩스를 전송하는지 확인합니다. 그렇지 않은 경우 팩스 릴레이 문제를 고려하기 전에 팩스 머신에 해결해야 할 문제가 있을 수 있습니다.

3. 디지털 인터페이스에서 SLIP 및 기타 오류 확인

팩스 릴레이를 수행하는 라우터에서 사용하는 T1 또는 E1 디지털 연결이 있는 경우 오류가 없는지 확인합니다. 팩스 릴레이는 특히 슬립(slip)과 같은 디지털 인터페이스의 오류에 매우 민감합니다. 음성 통화에서는 오류가 눈에 띄지 않지만 팩스가 실패할 수 있습니다.

vnt-3660-23c#show contr t1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is long gain36 0db
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20010805, FPGA: 15
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
Data in current interval (132 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs,
0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
 0 Unavail Secs

시작 및 종료 게이트웨이의 T1 또는 E1 컨트롤러는 일반적으로 오류가 발생하지 않습니다. 오류가 발생하면 통화 내에서 show controller(T1, E1, 1/0은 다름) 명령을 여러 번 반복하여 오류 수가 증가하는지 확인합니다. 슬립의 가장 흔한 문제는 클럭킹 오류가 발생하는 동기화 문제이다.

패킷 음성 네트워크에서는 일반적으로 라우터가 회선에서 클럭킹하는지 확인하는 것으로 충분합니다. 그렇지 않은 경우 clock source line 명령이 컨트롤러 레벨에서 입력되는지 확인합니다. 그러나 VoATM 또는 TDM 네트워크에서는 클럭킹 계층이 설정되어 있고 라우터가 네트워크를 통해 클럭을 전달해야 하므로 추가 사항을 고려해야 합니다. Clocking Plan 문서는 동기 Clocking에 대한 자세한 정보를 제공합니다.

26xx/366x 라우터에서 AIM VOICE 카드를 사용할 때 network-clock-participate 및 network-clock-select 명령을 추가하지 않으면 컨트롤러에서 "제어 슬립(controlled slips)"이 표시됩니다.

Cisco MC3810 플랫폼에서는 network-clock-select 명령을 구성하고 show network-clock 명령을 실행하여 컨피그레이션이 적용되었는지 확인해야 합니다.

Cisco 7200VXR 플랫폼에서 음성 카드에는 frame-clock-select 명령이 필요합니다. 기본적으로 내부 TDM 버스는 로컬 발진기에서 구동되지 않으므로 이 명령은 7200VXR 음성 게이트웨이에서 특히 중요합니다. E1 트렁크는 일반적으로 텔레포니 네트워크에 동기화되므로 은폐된 클럭킹 오류와 간헐적인 팩스 전송 문제가 발생합니다. 자세한 내용은 Cisco 버그 ID CSCdv10359를 참조하십시오.

C4224 MFT 카드의 경우 회선에서 클록을 허용하려면 컨트롤러 t1 x/y 아래에서 clock source loop-timed 명령을 실행해야 합니다. 이 설정은 컨트롤러 클록을 시스템 전체 클록에서 분리합니다. 그런 다음 network-clock-select 명령을 설정해야 합니다. 이 경우 network-clock-select 1 t1 x/y가 됩니다.

4. 팩스 인터페이스 유형 확인

Cisco 3660, 5300, 5350, 5400 및 5800을 포함하는 일부 플랫폼에서는 기본적으로 라우터가 팩스 인터페이스 유형 모뎀으로 설정됩니다. fax interface-type modem 전역 환경 설정 명령은 팩스 호출을 DSP가 아닌 모뎀(일반적으로 T.37 Store and Forward 팩스)으로 강제합니다. Cisco 팩스 릴레이가 작동하려면 팩스 호출을 DSP로 전송해야 합니다. 즉 fax interface-type vfc 명령으로 구성해야 합니다.

vnt-3660-23c(config)#fax interface-type ?
modem Use modem card
vfc   Use Voice Feature Card

vnt-3660-23c(config)#fax interface-type vfc
You must reload the router

라우터를 다시 로드해야 합니다. 그렇지 않으면 명령이 적용되지 않습니다. Cisco 팩스 릴레이(또는 T.38)를 사용하는 플랫폼에서 팩스 호출이 실패하므로 이 명령은 확인해야 할 중요한 명령입니다.

12.2 이전 버전의 Cisco IOS Software 릴리스에서는 fax interface-type vfc 명령이 필요하지 않았습니다. 이 문제는 음성 게이트웨이 중 하나가 Cisco IOS Software Release 12.2 이상으로 업그레이드될 때 흔히 나타납니다.

5. 팩스 통화 중에 팩스 코덱이 로드되었는지 확인합니다

각 팩스 기기는 팩스 협상 단계가 완료될 때 LCD 화면에 원격 팩스 ID를 표시합니다. 팩스 코덱을 성공적으로 다운로드하지 못한 경우 팩스 시스템이 협상을 완료할 수 없을 것입니다. 반면, 원격 팩스 ID가 표시되지 않으면 이 영역에서 추가 디버깅하는 것이 적절합니다.

음성 게이트웨이가 팩스 전송을 감지하고 팩스 코덱을 성공적으로 로드하도록 하는 방법에는 두 가지가 있습니다.

1. debug vtsp all 명령과 debug voip ccapi inout 통화 추적을 실행합니다. 이러한 디버깅에 대해서는 이 문서의 디버깅 섹션에서 자세히 설명합니다.

2. show voice trace 명령을 실행합니다. show 명령은 debug 명령보다 라우터에서 리소스를 덜 많이 사용하며 프로덕션 네트워크에서 사용하는 것이 좋습니다. 다음은 ISDN 인터페이스의 show voice trace 명령의 출력 예입니다.

BrisVG200gwy01#show voice trace 1/0:15
1/0:15 1
1/0:15 2
1/0:15 3
1/0:15 4
1/0:15 5
1/0:15 6
1/0:15 7
1/0:15 8
1/0:15 9
1/0:15 10 State Transitions: timestamp (state, event) -> ...
63513.792 (S_SETUP_REQUEST, E_TSP_PROCEEDING) ->
63515.264 (S_SETUP_REQ_PROC, E_TSP_ALERT) ->
63515.264 (S_SETUP_REQ_PROC, E_CC_BRIDGE) ->
63515.332 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.332 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63515.348 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.348 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63515.356 (S_SETUP_REQ_PROC, E_CC_CAPS_IND) ->
63515.356 (S_SETUP_REQ_PROC, E_CC_CAPS_ACK) ->
63518.656 (S_SETUP_REQ_PROC, E_CC_REQ_PACK_STAT) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_VP_DELAY) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_VP_ERROR) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_RX) ->
63518.660 (S_SETUP_REQ_PROC, E_DSP_GET_TX) ->
63521.028 (S_SETUP_REQ_PROC, E_CC_REQ_PACK_STAT) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_VP_DELAY) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_VP_ERROR) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_RX) ->
63521.028 (S_SETUP_REQ_PROC, E_DSP_GET_TX) ->
63524.128 (S_SETUP_REQ_PROC, E_TSP_CONNECT) ->

!--- Fax tone detected:

63529.352 (S_CONNECT, E_DSP_TONE_DETECT) ->
63529.356 (S_LFAX_WAIT_ACK, E_PH_CODEC_ACK) ->

!--- Fax codec being downloaded to DSPs:

63529.356 (S_LFAX_DOWNLOAD, E_pH_CODEC_FAX) ->
63529.356 (S_LFAX_DOWNLOAD, E_DSPRM_PEND_SUCCESS) ->

6. 팩스 릴레이를 비활성화하고 통과를 위해 코덱 변경

이전 단계에서는 음성 통화가 작동하고 팩스가 PSTN을 통해 작동하며 팩스 릴레이 경로의 모든 디지털 인터페이스에 오류가 없음을 확인했습니다. 이 단계에서는 팩스가 팩스 릴레이를 비활성화한 상태로 통과할 수 있는지 여부를 결정합니다. VoIP/VoATM/VoFR 다이얼 피어에서 다음을 입력합니다.

vnt-3660-23(config)#voice-port 2/0:15
vnt-3660-23(config-voiceport)#no echo-cancel enable
vnt-3660-23(config)#dial-p voice 3
vnt-3660-23(config-dial-peer)#fax rate disable
vnt-3660-23(config-dial-peer)#codec g711ulaw
vnt-3660-23(config-dial-peer)#no vad

두 게이트웨이 모두에서 이러한 명령을 입력해야 합니다. 이러한 명령은 팩스 릴레이를 비활성화하고, 에코 취소를 비활성화하며, 통화에 VAD 없이 고대역폭 코덱을 사용하도록 강제합니다. 그런 다음 라우터는 일반 음성 통화처럼 신호음을 샘플링하고 고대역폭 코덱(G.711)을 사용하여 가능한 가장 정확한 샘플을 캡처합니다. 반대편에서 재생되는 톤은 최대한 정확합니다. 이 단계에서 주의할 점은 G.711은 64kbps 대역폭 코덱이므로, 각 통화는 추가 전송 프로토콜 오버헤드가 추가될 때 최대 80kbps(VoIP의 경우)를 소비한다는 것입니다.

이번 검사에서 양성이 나왔다면 두 가지가 성사됐다. 먼저, 통화당 대역폭 소모가 네트워크의 주요 문제가 아닌 경우, 팩스 릴레이 문제에 대한 잠재적인 팩스 패스스루 해결 방법이 있습니다. 둘째, 대역폭 소모가 문제가 될 경우 팩스 릴레이 소프트웨어로 문제를 해결하여 TAC 케이스를 열어야 합니다.

이 테스트가 실패할 경우 팩스 릴레이를 사용하여 팩스 호출이 실패하는 원인이 무엇이든 이 테스트에서도 실패하는 원인이 될 수 있습니다. 가장 먼저 떠오르는 것은 네트워크에 많은 양의 지터 또는 패킷 손실이 발생할 수 있다는 것입니다.

7. VoX 네트워크에서 패킷 손실 확인

패킷 손실이 있는지 가장 쉽고 정확하게 확인하는 방법은 다음과 같습니다.

1. VoX 다이얼 피어에서 VAD를 비활성화합니다.

2. 팩스 장치가 연결된 동일한 포트 간에 음성 통화를 합니다. (팩스 장치는 일반 전화기로 사용할 수 있으며, 팩스 장치가 연결된 동일한 포트에 핸드셋을 연결할 수도 있습니다.)

3. 통화가 연결되면 다음을 수행합니다.

   1. show voice dsp 명령을 실행합니다. 출력에서 DSP 채널 중 하나에 구성된 코덱이 로드되어 있음을 확인할 수 있습니다. 일반적으로 "TX/RX-PAK CNT" 열은 전송 및 수신 패킷 카운터가 동일하다는 것을 보여주며, 이는 패킷이 손실되지 않음을 의미합니다. 카운터가 같지 않으면 패킷이 손실될 수 있습니다. 차이가 증가하고 패킷이 손실되는지 확인하려면 30초 간격으로 show voice dsp 명령을 여러 번 입력합니다.

   2. show voice call summary 명령을 실행하여 어떤 포트(해당하는 경우 타임 슬롯)가 음성 통화에 할당되었는지 확인합니다. terminal monitor를 입력한 다음 show voice call 명령을 음성 포트(해당하는 경우 타임 슬롯)와 함께 실행하여 자세한 DSP 통계를 확인합니다. 출력의 "***DSP VOICE VP_ERROR STATISTICS***" 섹션에서 카운터를 찾습니다. 보통 0개 또는 20개 미만입니다. 카운터가 20보다 크면 패킷 손실을 조사합니다.

네트워크에 손실이 있는 것으로 나타나면 팩스 릴레이가 안정적으로 작동하기를 기대하는 것은 타당하지 않습니다. ECM을 비활성화할 수도 있지만, QoS가 엔드 투 엔드로 프로비저닝되어 음성 및 팩스 릴레이 트래픽이 우선 순위가 지정되고 혼잡 내에서 손실되지 않도록 하기 위해 추가 조사가 필요할 수 있습니다. Related Information 섹션에는 음성 품질 문제를 해결하는 방법에 대한 자세한 정보가 포함되어 있습니다.

8. 팩스 릴레이 ECM 비활성화(Cisco 전용 VoIP만 해당)

패킷 손실 및 지터가 많은 네트워크의 경우 ECM을 비활성화하여 팩스 릴레이 통화를 개선합니다. 지터와 패킷 손실을 더 많이 허용할 수 있도록 ECM을 끄려면 fax-relay ECM disable(이 문서의 Configuration 섹션에서 자세히 설명함) 명령을 실행합니다.

손실 네트워크에서 팩스 릴레이 성능을 향상시키려면 fax-relay ECM disable 명령을 실행하되, 이 명령은 기본적인 트러블슈팅에도 권장됩니다. 네트워크에 눈에 띄는 지터 문제가 없는 경우에도 이 명령을 사용하면 팩스 릴레이 문제를 확인하는 데 도움이 될 수 있습니다. 이 명령은 VoFR 및 VoATM 다이얼 피어에서 사용할 수 있지만 현재 VoIP에서만 작동합니다.

참고: 이 명령은 패킷 손실 은폐 기능도 활성화합니다.

vnt-3660-23(config-dial-peer)#dial-peer voice 3
vnt-3660-23(config-dial-peer)#fax-relay ECM disable

9. T.38 패킷 이중화 사용(T.38 VoIP에만 해당)

VoIP용 T.38을 팩스 릴레이 프로토콜로 사용하는 경우 두 게이트웨이의 해당 다이얼 피어에서 이 명령을 구성하면 T.38 패킷 이중화 기능을 켤 수 있습니다.

vnt-3660-23(config-dial-peer)#fax protocol t38 
 Ls-redundancy X Hs-redundancy Y

여기서 X > 0 및 Y = 0(Ls-redundancy만 변경)

Cisco 전용 팩스 릴레이를 사용 중인 경우 ECM을 비활성화하는 대체 또는 추가 옵션은 T.38 패킷 리던던시 기능을 테스트할 수 있도록 팩스 릴레이 프로토콜을 T.38로 변경하는 것입니다. 이 기능은 패킷 손실로 인한 장애를 완화할 수 있지만 T.38 Packet Redundancy는 대역폭 사용량을 크게 증가시키며 가능한 경우 패킷 손실을 제거하는 것이 좋습니다.

10. fax NSF 명령을 모든 0으로 설정합니다

fax NSF 명령은 독점적 인코딩에 대한 팩스 협상 내의 NSF 필드를 변경하는 팩스 시스템 브랜드에 유용합니다. 이 명령을 사용하면 팩스 릴레이를 수행하는 라우터가 전용 인코딩을 구현하려고 시도하는 팩스 머신의 설정을 재정의할 수 있습니다. fax NSF 명령을 사용할 수 있기 전에 이러한 브랜드의 팩스 머신에 대해 팩스 릴레이가 실패합니다. 일반적으로 fax NSF 명령은 NSF 필드를 모든 0으로 설정하는 데 사용됩니다. 이 경우 양쪽에서 표준 팩스 협상이 강제로 이루어집니다. 이 명령은 Harris 및 Lanier와 같은 특정 브랜드에서 성공했으며 팩스 릴레이가 실패할 경우 권장됩니다.

vnt-3660-23(config-dial-peer)#fax NSF 000000

11. MGCP 게이트웨이가 FXR 패키지에 대해 구성되었는지 확인합니다

PSTN에서 팩스 서버로 T.38 팩스 호출이 실패하고 Cisco Unified Communications Manager 추적이 support_FXR=0인 경우 MGCP 게이트웨이에서 FXR 패키지 컨피그레이션이 누락될 수 있습니다. 이 경우 MGCP 게이트웨이에 다음 명령을 추가합니다.

no mgcp fax t38 inhibit
mgcp package-capability fxr-package
mgcp default-package fxr-package

그런 다음 게이트웨이를 재설정하고 팩스 통화가 작동하기 시작합니다.

12. 최종 결의 단계

이전 트러블슈팅 단계에서 팩스 릴레이 문제가 해결되지 않은 경우 이 문제에는 고급 트러블슈팅이 필요할 수 있습니다. Cisco TAC(Technical Assistance Center)에서 케이스를 열기 전에 시도할 수 있는 추가 단계입니다.

• 실패한 팩스 기기의 브랜드와 모델에 대해 알아보고 해당 브랜드와 모델에 대해 알려진 문제를 조사합니다.

  특정 브랜드의 팩스기에 대한 문제를 해결하는 CARE 케이스 또는 버그가 있는 경우도 있습니다. 예를 들어 Pitney Bowes 팩스에 대한 버그 검색 툴(등록된 고객만)을 검색하면 Pitney Bowes 팩스 기계 및 Cisco 팩스 릴레이(Cisco 버그 ID CSCdu78373(등록된 고객만))가 포함된 버그가 표시됩니다. 이 버그는 Cisco IOS Software에 없지만 연결의 양쪽에 있는 팩스 장치가 Pitney Bowes 9920 또는 9930인 경우 Pitney Bowes의 독점적인 팩스 신호 프로토콜과 호환되지 않습니다. 해결 방법은 팩스 시스템에서 전용 프로토콜을 비활성화하거나 팩스 릴레이를 비활성화하고 더 높은 대역폭 코덱을 사용하는 것입니다.

  알려진 주의 사항

  알려진 주의 사항은 제품에 대한 소프트웨어 릴리스에서 예기치 않은 동작 또는 결함입니다. 이 표에는 Cisco 음성 게이트웨이의 팩스 지원에 대한 알려진 문제에 대한 정보가 포함되어 있습니다.

  CCO 계정이 있는 경우 Cisco 버그 추적기 시스템 툴인 Bug Search Tool에서 알려진 문제를 검색할 수 있습니다. 버그 검색 도구에 액세스하려면 다음 작업 중 하나를 수행합니다.

  • 웹 브라우저에 https://bst.cloudapps.cisco.com/bugsearch/을 입력합니다.

  표 1 알려진 주의 사항

  버그 ID	요약	설명
  CSCdu 30250	VAD는 팩스 통과 모드에서 심각한 오류를 발생시킵니다.	Cisco 음성 게이트웨이가 팩스 통과 모드로 구성된 경우 팩스 통화와 연결된 모든 VoIP 다이얼 피어에서 VAD(Voice Activity Detection)를 비활성화합니다. VoIP 다이얼 피어에서 VAD를 비활성화하려면 다음 명령을 사용합니다. config terminal dial-peer voice XXX voip no vad
  CSCdu 62269	CSCdu 62269	게이트웨이 모드에서 WS-X4604-GW로의 팩스 릴레이 통화(페이로드 유형이 96인 RTP 패킷)를 시작하는 Cisco 게이트웨이 장치는 실패합니다. 이 문제는 12.1.5YF3에서 해결되었습니다. 게이트웨이 모드로 설정된 경우 소프트웨어는 이제 페이로드 유형 96을 식별하고 통과 모드를 시작합니다.
  CSCdv08143	게이트웨이 모드에서 VG248에서 WS-X4604-GW로의 팩스 통과 모드에서는 5-30페이지의 팩스 전송이 실패합니다.	이 오류는 WS-X4604-GW의 소프트웨어 이미지 12.1.5YF2에서만 발생합니다. 이 오류를 방지하려면 12.1.5YF1, 12.1.5YF3 이상을 사용합니다.
  CSCdv83401	Cisco Catalyst 6000 스위치에서 팩스 또는 모뎀 신호음이 감지되면 통화가 10ms(134바이트) 패킷을 사용하는 팩스 통과 모드로 전환됩니다.	팩스 통과 모드의 프레임 크기는 214바이트입니다. 패킷 크기가 정확하지 않아도 팩스는 실패하지 않습니다.
  CSCdv83337
  CSCdw07735	Cisco CallManager 3-1-2c_spA 로드 A00203010026을 사용하는 WS-X4604/VIC-2FXS(전용)에서 WS-X6624-FXS 게이트웨이로의 팩스 패스스루 모드에서는 팩스 전송이 실패합니다. WS-X4604/VIC-2FXS는 게이트웨이 모드와 통행료 부과 모드에서 모두 이를 나타냅니다.	이 오류는 WS-X4604-GW의 소프트웨어 이미지 12.1.5YF2 및 12.1.5YF3에서 발생하며 12.2(7)X 소프트웨어에서 고정됩니다.
  CSCdw07804	Cisco CallManager 3-1-2c_spA 로드 A00203010026을 사용하는 WS-C4224V/VIC-2FXS(전용)에서 WS-X6624-FXS 게이트웨이로의 팩스 패스스루 모드에서는 팩스 전송이 실패합니다.	이 오류는 WS-C4224V의 소프트웨어 이미지 12.1.5YE2 및 12.1.5YE4에서 발생하며 12.2(7)X 소프트웨어에서 수정됩니다.

• 검색 툴을 사용하여 문제가 발생한 Cisco IOS Software 릴리스에서 알려진 팩스 문제를 확인합니다.

  이전 단계에서는 특정 팩스 브랜드와 Cisco 팩스 릴레이 코드 간의 알려진 문제를 식별하기 위해 특정 팩스 브랜드를 검색했습니다. 다음 단계는 설치된 Cisco IOS Software 릴리스에 팩스 릴레이 버그가 있을 수 있으므로 일반 검색을 수행하는 것입니다.

  예를 들어, VoFR을 사용하는 팩스 릴레이가 Cisco IOS Software Release 12.1(2)T에서 작동하지 않을 경우 CCO의 버그 툴킷으로 버그를 검색할 수 있습니다. 이 예에서는 다음 값을 사용합니다.

  • 주 버전: 12.1

  • 개정: 2

  • 기능/구성 요소: VoFR

  • 키워드: fax

  버그 중 하나는 Cisco 버그 ID CSCdr65984(등록된 고객만 해당)이며, "fax dosent work for vofr"이라는 제목이 있습니다. 이 버그로 인해 VoFR에 대한 모든 팩스 릴레이가 실패했으며 이 버그가 더 이상 존재하지 않는 Cisco IOS Software 릴리스로 업그레이드해야 합니다.

• 하드웨어 오류를 제거합니다.

  잠재적 문제 원인을 하나씩 제외할 경우 문제를 더 쉽게 격리할 수 있습니다. 다른 하드웨어 부품을 교체하고 게이트웨이 간에 대체 IP 연결을 사용합니다. 추가 하드웨어를 사용할 수 있는 경우 다음 단계를 수행하면 도움이 됩니다.

  • 라우터에서 서로 다른 포트를 사용합니다.

    컨피그레이션에 E1 또는 T1을 사용하는 PBX 또는 PSTN에 연결된 두 개의 게이트웨이가 포함되어 있는 경우 FXS 포트를 사용할 수 있는 경우 팩스 시스템을 음성 게이트웨이의 FXS 포트에 직접 연결하십시오. 이 절차를 수행하면 E1 카드 장애, 텔레포니 측 문제, E1 동기화 또는 케이블 문제 등의 가능성이 제외될 경우 문제를 더 격리할 수 있습니다.

  • 다른 하드웨어를 사용해 보십시오.

    FXS 포트를 사용할 수 있는 다른 음성 게이트웨이가 있는 경우 각 음성 게이트웨이에 이더넷 크로스오버 케이블로 직접 연결하고 FXS 포트에 연결된 팩스 시스템으로 팩스를 보냅니다. 이 절차는 VoX 네트워크에 대기열, 단편화 또는 우선 순위 지정과 같은 문제가 있는지 확인하는 데 도움이 됩니다.

• 라우터에서 debug 명령을 사용하여 문제를 확인합니다.

  팩스 릴레이 문제를 해결하는 데 유용한 디버그 명령에 대한 자세한 내용은 "디버깅" 섹션을 참조하십시오.

디버깅

T.30 메시지

일반적인 팩스 전송 내에서 발생하는 메시지에 익숙하지 않으면 디버그를 이해하기 어려울 수 있습니다. 단일 페이지 팩스 전송에 대해 발생하는 기본 T.30 트랜잭션을 그래픽으로 나타낸 것입니다.

이러한 트랜잭션의 세부사항에 대한 설명은 이 문서의 범위를 벗어나지만 팩스 릴레이 내에 표시되는 기본 트랜잭션에 대한 정의입니다. 목록은 빠른 참조를 위해 알파벳순으로 표시되며 Cisco 팩스 릴레이를 디버깅할 때 일반적으로 나타나는 메시지를 포함합니다. 이 메시징에 대한 자세한 정보 또는 여기에 나열되지 않은 메시지에 대한 자세한 내용은 T.30 사양을 참조하십시오.

• CED(Called Terminal Identification) - 팩스 호출에 응답할 때 종단 팩스 장치에서 전송하는 2100Hz 신호. 이 신호는 데이터 전송을 위한 회선을 준비하기 위해 연결에 있는 에코 취소를 일시적으로 비활성화합니다.

• CFR(Confirmation To Receive) - 이전 메시징 및 교육이 완료되었으며 팩스 페이지 전송이 시작됨을 확인하는 응답입니다.

• CNG(발신음) - 30초 동안 켜졌다가 3초 동안 꺼지는 1100Hz 신호음입니다. 이 신호는 팩스 단말기를 비음성 장치로 식별합니다. 신호는 또한 개시 팩스 단말기가 종료 팩스 단말기로부터의 DIS 신호를 대기하고 있음을 나타낸다.

• CRP(Command Repeat) - 이전 명령이 오류로 수신되어 반복해야 함을 나타내는 응답입니다. (선택 사항)

• CSI(Called Subscriber Identification) - 국제 전화 번호를 통해 호출된 팩스 터미널의 특정 ID를 제공하는 데 사용됩니다. (선택 사항)

• DCN(연결 끊기) - 팩스 호출을 종료하고 응답이 필요하지 않습니다.

• DIS(Digital Identification Signal) - 호출된 팩스 터미널의 기능을 식별합니다.

• DTC(Digital Transmit Command) - DIS 신호로 확인된 기능에 대한 응답입니다. 여기서 발신 팩스 터미널은 해당 기능을 수신 팩스 터미널의 DIS 메시지에 제공된 기능과 일치시킵니다.

• EOM(End Of Message) - 팩스 정보의 전체 페이지 끝을 나타냅니다.

• EOP(절차 종료) - 팩스 정보의 전체 페이지 끝을 나타내며 더 이상 보낼 페이지가 없습니다. 팩스 호출의 연결 끊기 단계로 진행합니다.

• FTT(Failure To Train) - 교육 신호를 거부하고 재교육을 요청하는 데 사용됩니다(재교육은 일반적으로 낮은 변조 속도로 발생함).

• MCF(Message Confirmation) - 메시지가 정상적으로 수신되었음을 나타냅니다.

• MPS(MultiPage Signal) - 팩스 정보의 전체 페이지가 끝나고 수신자가 추가 페이지를 사용할 준비가 되었음을 나타냅니다.

• NSF(Non-Standard Facilities) - T 시리즈 사양이 적용되지 않는 특정 기능 또는 요구 사항을 식별하는 데 사용됩니다. (선택 사항)

• RTN(Retrain Negative) - 이전 메시지가 제대로 수신되지 않았음을 나타냅니다. 재훈련은 (일반적으로 낮은 변조 속도로) 진행하기 위해 필요하다.

• RTP(Retrain Positive)(RTP(재교육 양성)) - 전체 메시지가 수신되었으며 재교육 이후에 가능한 추가 메시지가 발생함을 나타냅니다.

• TCF(Training Check) - 이전 T.30 시그널링에 사용된 300kbps V.21 변조와 비교하여 고속 T.4 변조 시스템을 통해 전송되어 교육을 확인하고 이 전송 속도로 전송된 팩스 페이지를 수락할 수 있음을 나타냅니다.

• TSI(Transmitting Subscriber Identification) - 전송(발신) 팩스 터미널의 ID를 나타냅니다. (선택 사항)

팩스 릴레이 디버그 명령

유용한 팩스 릴레이 디버그 명령입니다.

• debug fax relay t30 all

• vtsp 모두 디버그

• vtsp vofr 서브프레임 3 디버그

debug fax relay t30 all

Cisco 팩스 릴레이의 debug는 debug fax relay t30 all 명령으로 활성화됩니다.

vnt-3660-23c#debug fax relay t30 all
Debugging fax relay t30

실패한 팩스 릴레이 세션의 디버그 복사본입니다. Cisco IOS Software Release 12.2(7a)를 실행하는 발신 팩스 게이트웨이의 디버그입니다.

vdtl-3810-3b#
Dec 5 07:49:13.073: 1/2:62 1281347052 fr-entered (10ms)
Dec 5 07:49:17.985: 1/2:62 1281351950 fr-msg-det CRP
Dec 5 07:49:20.105: 1/2:62 1281354070 Fr-MSG-TX NSF
Dec 5 07:49:20.655: 1/2:62 1281354620 Fr-MSG-TX good crc,
 19 bytes
Dec 5 07:49:20.720: 1/2:62 1281354680 Fr-MSG-TX DIS
DEC 5 07:49:22.350: 1/2:62 1281356310 fr-msg-det TSI
DEC 5 07:49:23.045: 1/2:62 1281357000 fr-msg-det DCS
DEC 5 07:49:27.346: 1/2:62 1281361290 Fr-MSG-TX FTT
DEC 5 07:49:28.836: 1/2:62 1281362780 fr-msg-det TSI
DEC 5 07:49:29.531: 1/2:62 1281363470 fr-msg-det DCS
DEC 5 07:49:29.740: 1/2:62 1281363680 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:30.362: 1/2:62 1281364300 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:30.804: 1/2:62 1281364740 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:30.852: 1/2:62 1281364790 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:33.868: 1/2:62 1281367800 Fr-MSG-TX FTT
DEC 5 07:49:35.414: 1/2:62 1281369340 fr-msg-det TSI
DEC 5 07:49:36.113: 1/2:62 1281370040 fr-msg-det DCS
DEC 5 07:49:36.515: 1/2:62 1281370440 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:36.908: 1/2:62 1281370830 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:37.559: 1/2:62 1281371480 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:37.784: 1/2:62 1281371700 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:37.900: 1/2:62 1281371820 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:40.133: 1/2:62 1281374050 Fr-MSG-TX FTT
DEC 5 07:49:41.888: 1/2:62 1281375800 fr-msg-det TSI
DEC 5 07:49:42.583: 1/2:62 1281376490 fr-msg-det DCS
DEC 5 07:49:43.173: 1/2:62 1281377080 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:44.937: 1/2:62 1281378840 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:45.386: 1/2:62 1281379290 fr-msg-det bad crc,
 0 bytes
DEC 5 07:49:46.941: 1/2:62 1281380840 Fr-MSG-TX FTT
DEC 5 07:49:48.503: 1/2:62 1281382400 fr-msg-det DCN
DEC 5 07:49:50.631: 1/2:62 1281384520 fr-end-dcn

이 디버그는 팩스 릴레이 내의 DSP에서 발생하는 T.30 이벤트를 표시합니다. DSP의 관점에서 발생하는 디버그는 팩스 장치와 상호 작용하므로 "Fr-MSG-TX" 또는 전송 메시지는 DSP에서 연결된 팩스 장치로 전송됩니다. DSP에서 탐지했다고 하는 모든 메시지 또는 "fr-msg-det" 메시지는 연결된 팩스 디바이스에서 수신한 메시지입니다. 이 그래픽은 debug fax relay t30 all 명령이 실행될 때 DSP 메시지의 방향 흐름을 보여줍니다.

디버깅의 실패한 팩스 트랜잭션에서 여러 "잘못된 crc" 메시지 다음에 먼 쪽의 FTT(Failure To Train) 메시지를 볼 수 있습니다. 디버그에서 마치 문제가 훈련 신호와 관련이 있는 것처럼 보입니다. 잘못된 crc 오류와 반대쪽에서 반환된 FTT(Failure To Train) 메시지는 신호가 손상되었거나 Cisco 팩스 릴레이 프로토콜과 호환되지 않음을 나타냅니다. 이 디버깅은 Lexmark Optra 팩스 시스템에서 발생하는 팩스 릴레이 문제에서 가져옵니다. Lexmark는 V.34를 사용할 수 있으며 V.34 속도로 연결을 시도합니다. V.34는 Cisco 팩스 릴레이에서 지원되지 않으며 교육 오류가 발생합니다. 자세한 내용은 Cisco 버그 ID CSCdv89496(등록된 고객만 해당)을 참조하십시오.

T.30 디버그의 작업 예 페이지에서는 이러한 디버그를 읽는 방법에 대한 자세한 정보와 성공적인 디버그 및 ECM 모드 팩스 분석기 추적의 예를 제공합니다.

vtsp 모두 디버그

팩스 릴레이 문제를 해결하는 데 유용한 다른 debug 명령도 있습니다. 이러한 디버그는 T.30 디버그만큼 읽거나 많은 정보를 제공하는 것은 쉽지 않지만 여전히 유용할 수 있습니다.

VTSP(Voice Telephony Service Provider)는 아날로그 또는 디지털 인터페이스를 통해 PBX, 팩스 또는 중앙 사무소와 같은 표준 텔레포니 장비에 연결된 DSP 엔드포인트와 Cisco IOS 통화 컨트롤 간의 인터페이스를 정의하는 아키텍처입니다.

VoIP T.38 또는 팩스 릴레이의 경우, 모든 디버그 vtsp는 라우터에서 유용한 상태 정보를 제공할 수 있습니다. 트러블슈팅 섹션에서 설명한 대로 이 debug 명령을 사용하여 음성 전화 통신 서비스 공급자 디버깅 페이지에 표시된 대로 팩스 코덱이 DSP에 다운로드되었는지 확인할 수 있습니다.

vtsp vofr 서브프레임 3 디버그

VoFR 및 VoATM을 사용하는 팩스에 유용한 다른 팩스 릴레이 디버그 명령은 debug vtsp vofr subframe 3입니다. 이 명령은 Annex D 팩스 릴레이 페이로드 유형이 있는 FRF11 프레임을 출력합니다. 팩스 릴레이 호출이 하나뿐인 경우에도 이 명령의 상당한 출력이 출력되며, 16진수를 디코딩해야 합니다(FRF11 사양은 16진 디코딩에 유용합니다).

추가 디버그 명령

1. T.38 기능 교환 문제를 디버깅하려면 debug cch323 h245 명령을 사용합니다.

2. 애플리케이션과 DSP 간의 DSP 메시지 교환을 디버깅하려면 다음 debug 명령을 사용합니다.

   • vtsp 모두 디버그

   • voip ccapi inout 디버그

   • debug hpi all(Cisco 5300/2600/3600 및 TI c54x DSP를 사용하는 기타 모든 음성 플랫폼)

   • debug nextport vsmgr detail(NextPort DSP 플랫폼(Cisco 5400, 5850))

팩스 분석기

팩스 릴레이 문제를 해결하려면 Cisco 음성 게이트웨이의 디버깅 기능에 머무르지 않는 것이 필요할 때도 있습니다. 프로토콜 분석기 및 팩스 분석기 등의 도구를 사용하여 팩스 릴레이 작업에서 발생하는 사항을 확인합니다. Genoa ChannelProbe/FaxProbe by QualityLogic 또는 HP Telegra와 같은 팩스 분석기는 팩스 장치와 Cisco 게이트웨이 사이에 위치하여 상황을 파악할 수 있습니다. 라우터 간에 교환되는 팩스 릴레이 패킷을 확인해야 하는 경우 Sniffer 및 Domino와 같은 프로토콜 분석기가 도움이 될 수 있습니다.

복잡한 문제를 해결하기 위해서는 각 팩스 시스템에서 팩스 트래픽을 캡처할 수 있는 분석기와 팩스 릴레이 패킷을 캡처할 수 있는 프로토콜 분석기와 같은 장비가 함께 필요합니다. 문제를 재현하기 위해 단일 팩스 통화를 발신한 다음 분석을 위해 연결된 디바이스에서 정보를 캡처합니다. 이 다이어그램은 네트워크에서 이 테스트 장비가 배치되는 위치를 보여줍니다.

대부분의 팩스 분석기에는 상황을 파악하는 데 도움이 되는 적절한 도움말 화면과 설명서가 있습니다. T.30 사양도 큰 도움이 됩니다. 프로토콜 분석기의 경우, 인코딩이 독점적이거나 분석기 소프트웨어에 필요한 특정 디코딩이 없기 때문에 디코딩이 어려울 수 있습니다. VoFR 및 VoATM을 사용하는 팩스 릴레이의 경우 Cisco 게이트웨이는 FRF11 사양의 표준 기반 Annex D를 사용합니다. 프로토콜 분석기가 프레임을 디코딩할 수 없는 경우, 프레임은 본 명세서를 사용하여 수동으로 디코딩될 수 있다. 팩스 릴레이 및 VoIP에서는 팩스 릴레이 패킷에 Cisco 전용 형식이 사용됩니다.

팩스 분석기 및 프로토콜 분석기 정보를 사용하여 팩스 릴레이 문제를 해결할 수 있습니다. 이 지점에 도달하는 팩스 릴레이 문제는 거의 없으며, 문제가 발생할 경우 추가 지원을 위해 에스컬레이션 및 DE 리소스를 포함해야 합니다.

또한, 문제와 관련된 다른 모든 정보를 제공합니다.

TAC 케이스 열기

이 문서에서 문제를 격리하고 해결할 수 없는 경우 Cisco TAC(Technical Assistance Center)에 케이스를 열고 다음 정보를 제공합니다.

• 네트워크 토폴로지 설명(PDF, Visio 또는 Microsoft PowerPoint 형식)

• 사용된 팩스 기계로, 공급업체 및 모델 정보가 포함됩니다.

• 문제의 역사.

  구축이 새로운 것인지, 잘 작동했다가 실패한 기존 네트워크인지를 포함하여 유용한 정보를 제공합니다. 네트워크가 구축된 경우, 문제가 발생하기 전에 변경된 사항은 무엇입니까? 문제가 간헐적으로 발생합니까? 문제를 재현할 수 있으며, 만약 그렇다면 문제를 재현하기 위해 필요한 단계는 무엇인가?

• 팩스 게이트웨이와 IP 경로의 모든 라우터의 show tech 명령 출력 및 활성 타사 네트워크 장비에 대한 관련 정보.

• 다음 디버그 플래그가 활성화된 통화 추적 쌍입니다.

  • voip ccapi inout 디버그

  • vtsp 모두 디버그

  • isdn q931 디버그(ISDN 또는 Q.Sig가 포함된 경우)

• show voice call 및 show voice dsp 출력의 쌍입니다.

• 사용 가능한 경우 한 쌍의 팩스 분석기가 모니터 모드에서 시작 및 종료 팩스 장치에 연결된 추적을 추적합니다.

• 가능한 경우 수행된 트러블슈팅 및 디버깅 결과.

관련 정보

원래 https://www.cisco.com/c/en/us/support/docs/voice/fax-modem-over-ip/20227-faxrelay-tsguide.html에 게시됨

원래 MDF 태그는 다음과 같습니다. 기술:음성:팩스/IP를 통한 모뎀
문서 ID가 20227입니다. 

문서 ID 또는 URL이 일치하지 않으면 tz-writers@cisco.com으로 문의하십시오.

• Cisco Voice over IP 솔루션 - 팩스 서비스
• 통화 관리자 및 음성 게이트웨이를 사용하여 VoIP 팩스 릴레이 구성
• Cisco IOS Fax and Modem Services over IP 애플리케이션 가이드
• Catalyst 6608 및 VG248을 사용하여 IP를 통해 팩스 전송
• H.323 T.38 팩스 릴레이 문제
• Cisco AVVID Gateway Support for Fax Relay and Fax Pass-Through
• 음성 - VoIP를 사용하여 팩스 릴레이 구성(T.38)
• 음성 기술 지원
• 통합 커뮤니케이션 제품 지원
• 권장 자료: Cisco IP 텔레포니 문제 해결
• 기술 지원 및 문서 − Cisco Systems