팩스 릴레이 문제 해결 가이드

소개

이 문서의 목적은 Cisco 팩스 릴레이 문제를 해결하고 해결할 수 있는 기본 가이드를 제공하는 것입니다.팩스 및 팩스 릴레이의 기술적 복잡성은 자세히 다루지는 않지만 일반적인 팩스 릴레이 문제의 대부분을 해결할 수 있어야 합니다.팩스 및 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 IOS Software Release 12.2(5)를 기반으로 합니다. 그러나 대부분의 정보는 다른 Cisco IOS Software 릴리스에도 유용합니다.

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

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.라이브 네트워크에서 작업하는 경우, 명령을 사용하기 전에 명령의 잠재적인 영향을 이해해야 합니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

팩스 및 팩스 릴레이 개요

대부분의 최신 팩스 장치는 그룹 3을 준수합니다.Fax Group 3은 주로 T.4 및 T.30 ITU 권장 사항으로 구성된 표준 기반 기술입니다.T.4는 팩스 장치가 팩스 이미지를 인코딩하는 방법과 관련이 있으며 T.30은 팩스 협상과 통신 프로토콜을 자세히 설명합니다.

그룹 3 팩스 장치는 PSTN(Public Switched Telephone Network)을 통해 사용하도록 설계되었습니다. PSTN은 사람의 음성을 위해 설계되었기 때문에 그룹 3은 아날로그 모뎀과 마찬가지로 아날로그 인코딩 또는 변조된 신호를 사용합니다.아날로그 모뎀과 팩스 기기는 모두 PSTN을 통해 디지털 정보를 전달하기 위해 모듈화된 아날로그 신호를 사용해야 하는 디지털 장치입니다.이 모듈화된 신호는 일반적으로 다른 오디오 신호음으로 들릴 수 있습니다.

VoX 네트워크의 게이트웨이는 처음에는 음성 및 팩스 통화를 동일하게 처리합니다.두 통화 유형 모두 게이트웨이가 DSP(디지털 신호 프로세서)에서 구성된 음성 압축 코덱을 로드하도록 합니다. DSP에 대한 자세한 내용은 음성 하드웨어:C542 및 C549 DSP(Digital Signal Processor).

음성 압축 코덱은 일반적으로 높은 압축 코덱으로, 각 음성 통화에 사용되는 대역폭이 줄어듭니다.G729 및 G723과 같은 고압축 코덱은 음성에 최적화되어 있으며 음성을 낮은 대역폭(8kbps, G.729의 오버헤드는 제외)으로 압축하지만 품질이 우수하지만 G.729 및 기타 고압축 코덱은 팩스에 최적화되지 않습니다.실제로, 팩스 전송의 변조된 신호는 일반적으로 이러한 코덱을 사용할 때 제대로 전달되지 않으며, 결과적으로 팩스 호출이 실패합니다.압축 코덱에 대한 자세한 내용은 Voice over IP - Per Call Bandwidth Consumption을 참조하십시오.

압축 비율이 낮거나 압축이 전혀 없는 코덱을 사용하는 경우(예: 에코 취소 또는 음성 활동 감지 기능이 없는 G.726 및 G.711) 팩스를 성공적으로 전송할 수 있습니다.음성 코덱을 통한 이 팩스 전송 방법을 인밴드 팩스 또는 팩스 패스스루라고 합니다.속도 향상이라고 알려진 기술을 사용하면 게이트웨이가 음성 통화를 위해 구성된 음성 압축 코덱을 DSP에 처음 로드하고 팩스 신호음이 감지될 경우 저압축 코덱으로 변경할 수 있습니다.

인밴드 팩싱의 경우 초기 모듈형 신호는 소스 라우터의 코덱에 의해 인코딩되어 압축되며 음성 샘플인 것처럼 VoX 네트워크를 통해 전달됩니다.그런 다음 종료 게이트웨이는 샘플을 압축 해제하고 디코딩한 다음 종료 팩스 장치로 재생합니다.팩스 릴레이는 다르게 작동합니다.이 프로토콜은 모듈화된 신호를 종료하고 디지털 정보를 추출한 다음 데이터 패킷으로 데이터 네트워크를 통해 디지털 정보를 릴레이하는 프로토콜입니다.종료 측면에서 디지털 정보는 패킷에서 추출되고, 모듈화되며, 재생됩니다.

팩스 기본 정보

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

반이중 팩스 협상은 팩스 통화를 시작할 때 발생합니다.V.21 모듈화된 HDLC(High-level Data Link Control) 데이터 프레임은 300bps 속도로 전달됩니다.이러한 데이터 프레임은 원본과 종료 팩스 장치 간에 표준 순서로 전송됩니다.이 교환에서 각 팩스 장치는 기능을 교환하며, 두 팩스 장치는 페이지 전송이 발생하기 전에 팩스 세션 특성에 동의합니다.이 그림은 PSTN을 통한 기존 팩스 호출을 보여줍니다.

교환 및 협상되는 일부 기능은 페이지 전송 속도, ECM(Error Correction Mode), 해결, 페이지 코딩, 스캔 시간입니다.페이지 전송 속도(교육)는 팩스가 정보를 보내는 속도를 결정하는 중요한 협상입니다.팩스는 처음에 교환된 매개변수에 따라 가능한 최고 변조 속도로 훈련을 시도합니다.더 빠른 속도의 교육에 실패할 경우 팩스 장치가 더 낮은 속도로 재교육됩니다.

페이지 전송은 팩스 협상 단계의 교육 부분이 이전에 합의된 매개변수를 사용하여 완료될 때 발생합니다.페이지 정보는 인치당 203H x 98V 도트의 표준 해상도로 스캔 선에 코딩됩니다.팩스 이미지는 일반적으로 압축되고 MH(Modified Huffman) 또는 MR(Modified Read) 인코딩으로 인코딩됩니다.MH는 보통 20:1 비율로 압축한다.MR 인코딩은 일반적으로 MH에 비해 20% 압축 개선을 제공하지만 오류 발생 시 복원력이 약간 떨어집니다.

페이지 전송이 발생하면 통화 설정 협상에 사용된 초기 300BPS보다 높은 비트 전송률이 사용됩니다.페이지 전송에 사용되는 비트 전송률은 교육 내에서 확인됩니다.다음은 팩스 페이지 전송에 사용되는 일반적인 요율입니다.

• V.27ter - 2400/4800BPS

• V.29 - 7200/9600BPS

• V.17 - 14,400BPS

참고: 페이지 전송(V.27ter, V.29, V.17) 및 팩스 협상(V.21)에 사용되는 이러한 V.XX 사양은 아날로그 전화 회선을 통해 디지털 데이터를 전송하는 방법을 정의하는 사양입니다.데이터 모뎀은 대부분의 데이터 모뎀이 훨씬 빠른 속도로 마이그레이션되었지만 이러한 사양을 사용할 수도 있습니다.

팩스 릴레이 기본 정보

팩스 릴레이는 이러한 코덱이 팩스 트래픽을 전달하려고 할 때 고압축 음성 코덱의 결함을 극복하는 데 사용되는 기술입니다.

팩스 통화는 일반 음성 통화인 것처럼 처리되므로 각 게이트웨이의 DSP는 음성 모드로 전환되며, 그 이후에는 사람의 음성이 수신 및 처리될 것으로 예상됩니다.통화 중에 CED(Fax Answer) 또는 통화(CNG) 신호음이 들리면 DSP는 음성 처리를 방해하지 않습니다.VoX 통화 레그를 통해 신호음이 계속 울립니다.

일반 팩스 기기는 CED를 생성하거나 CNG를 들은 후 팩스 핸드셰이크의 일부로 T.30 DIS 메시지를 전송합니다.이 프로세스는 일반적으로 종료 팩스 기기에서 발생합니다.그런 다음 종료 게이트웨이의 DSP는 DIS 메시지 시작 시 HDLC 플래그 시퀀스를 탐지하고 팩스 릴레이 전환을 시작합니다.즉, 음성 코덱을 언로드하고 팩스 코덱을 로드하여 발생하는 팩스 통화를 처리합니다.

또한 VoX 네트워크의 다른 쪽에 있는 DSP에 알림이 전송되므로 팩스 통화의 각 쪽에 있는 DSP에서 팩스 코덱을 사용하도록 합니다.사용된 팩스 릴레이 프로토콜에 따라 알림 메커니즘이 다릅니다.DSP는 로드된 팩스 코덱을 사용하여 T.30 HDLC 프레임을 테스트하고, 팩스 정보를 추출하여 다음 팩스 릴레이 프로토콜 중 하나를 사용하여 라우터 간에 전달합니다.

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

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

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

인밴드 팩스나 팩스 패스스루와는 달리, 팩스 릴레이는 T.30 팩스 신호음을 특정 HDLC 프레임(demostration)으로 분해하고, 팩스 릴레이 프로토콜을 사용하여 VoX 네트워크를 통해 정보를 전송한 다음, 이 비트를 원측(변조)의 음조로 다시 변환한다는 점을 이해하는 것이 중요합니다. 엔드 유저의 팩스 기기는 발신음 및 수신 신호음을 전송하며, 모조/변조 팩스 릴레이 프로세스를 인식하지 못합니다.

Cisco 팩스 릴레이와 T.38 팩스 릴레이는 T.37 팩스 매장 및 포워드와도 다릅니다.T.37은 VoIP 게이트웨이가 이를 수신할 수 있도록 표준 기반 방법을 제공합니다.

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

1. 팩스 통과 - 팩스 통과 모드에서 게이트웨이는 팩스 통화와 음성 통화를 구분하지 않습니다

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 플랫폼에서 팩스 릴레이가 기본적으로 활성화됩니다.두 라우터 간에 음성 통화가 성공적으로 완료되면 팩스 통화도 작동해야 하지만 팩스 릴레이가 작동하지 않거나 성능을 개선해야 할 경우, 문제를 해결하기 위해 사전 조치로 실행할 수 있는 몇 가지 팩스 릴레이 특정 명령이 있습니다.

• 팩스 속도

• fax-relay ECM 비활성화

• 팩스 NSF

• 팩스 프로토콜

팩스 속도 명령

팩스 속도 명령은 컨피그레이션 모드의 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와 같은 낮은 대역폭 코덱이 기본 팩스 속도 음성 설정으로 구성된 경우 이 동작이 필요합니다.팩스 속도 명령을 사용하면 코덱보다 큰 대역폭을 사용하도록 팩스 전송을 구성할 수 있습니다.명령 팩스 속도 14400을 사용하면 구성된 음성 코덱에 관계없이 팩스 호출이 최대 14400BPS까지 협상할 수 있습니다.이 컨피그레이션은 더 긴 완료 시간의 문제를 해결합니다.

VoX 네트워크 내에서 팩스 속도 명령이 제공하는 주요 용도는 통화당 확실한 대역폭 사용량을 제공하는 것입니다.팩스 속도 음성 설정은 음성 및 팩스 통화가 모두 VoX 네트워크 내에서 동일한 양의 대역폭을 사용하도록 하기 때문에 기본값입니다.이 고려 사항은 팩스 속도가 코덱의 대역폭보다 큰 것으로 변경될 때 이해해야 합니다.또한 일부 팩스 장치는 기본값과 다른 속도로 더욱 안정적으로 작동할 수 있습니다.이 경우 팩스 속도 명령을 사용하여 다른 속도로 작업을 테스트할 수 있습니다.

팩스 속도 명령을 실행하면 라우터 출력에 팩스 릴레이를 비활성화할 수도 있습니다.유효한 문제 해결 방법은 팩스 릴레이를 비활성화하고 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 Facility) 필드와 함께 이루어집니다.

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 옵션을 사용하면 다이얼 피어가 음성 서비스 voip 명령으로 전역으로 구성된 팩스 릴레이 프로토콜을 상속할 수 있습니다.voice service voip 명령에 아무것도 구성되지 않은 경우 기본값은 Cisco 팩스 릴레이입니다.

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 will use 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 since 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 및 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 다이얼 피어의 예입니다. 발신(outbound)을 생성합니다.

     시작 게이트웨이	종료 게이트웨이
     !--- 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:1.1.1.1 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 How Inbound and Outbound Dial Peers Matching on Cisco IOS Platforms에서 확인할 수 있습니다.

     다이얼 피어 일치를 확인하는 데 사용할 수 있는 또 다른 방법은 debug voip ccapi inout 명령을 실행하는 것입니다.이 명령의 디버그 출력에는 호출된 번호와 일치하는 모든 다이얼 피어를 나열하는 ssaSetupPeer 메시지가 표시됩니다.ccCallSetupRequest 메시지는 아웃바운드 VoIP 다이얼 피어가 선택되었음을 나타내는 아웃바운드 피어 옵션과 함께 나타납니다.동일한 대상에 대해 여러 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 capi 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을 다이얼하면) 컨피그레이션에서 다이얼 피어가 팩스에 대해 올바르게 구성되었는지 확인합니다.통화의 양쪽에서 확인할 수 있는 몇 가지 일반적인 오류는 다음과 같습니다.

     • 낮은 대역폭 코덱을 사용하는 동안 팩스 릴레이가 비활성화되었습니다(즉, 다이얼 피어에서 팩스 속도 비활성화 명령이 실행됨).

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

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

   • 잘못된 컴퓨터 형식

     미국 회사의 형태는 µ로 되어 있습니다.유럽과 아시아에 있어서 그것은 법입니다.show voice call 명령을 실행하여 현재 구성된 값을 확인할 수 있습니다.BRI 또는 E1 포트에서 라우터의 컴팬딩 유형이 연결된 디바이스의 유형과 일치하지 않고, 통화가 실패하여 때때로 연결되기도 하지만, 음성이 심하게 왜곡되어 사용자가 인식할 수 없게 되고 높은 낮은 피치 노이즈 수준이 나타납니다.

     Cisco IOS Software Release 12.2(3)에서 comand-type 명령은 BRI 포트에 있지 않으며 companing type이 기본값입니다.이 버그에 대한 자세한 내용은 Cisco 버그 ID CSCdv00152 및 CSCdv01861을 참조하십시오.

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

   • 게이트웨이 쌍의 Cisco IOS Software 비호환성

     Cisco IOS Software 릴리스가 항상 일치할 필요는 없지만 문제가 발생할 경우 릴리스를 확인하는 것이 좋습니다.

   • 압축된 실시간 전송 프로토콜(cRTP).

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

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

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

   음성 통화가 양방향으로 작동하지만 팩스 통화가 한 방향 이상 실패할 경우 이 두 컴퓨터 간의 일반 팩스가 PSTN에서 작동하는지 확인합니다.다시 말해, 팩스 장치가 VoX 네트워크를 통과하지 않고 PSTN을 사용하여 서로 팩스를 전송하는지 확인합니다.그렇지 않으면 팩스 장치에 문제가 발생할 수 있으며 팩스 릴레이 문제를 고려하기 전에 해결해야 합니다.

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

라우터에서 팩스 릴레이를 수행하는 T1 또는 E1 디지털 연결이 사용되는 경우 오류가 없는지 확인합니다.팩스 릴레이는 디지털 인터페이스의 오류에 매우 민감하며, 특히 실수도 많습니다.음성 통화에서는 오류가 나타나지 않지만 팩스가 실패할 수 있습니다.

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 문서는 동기 잠금에 대한 자세한 내용을 제공합니다.

26xx/366x 라우터에서 AIM VOICE 카드를 사용할 경우 network-clock-participate 및 network-clock-select 명령을 추가하지 않는 한 컨트롤러는 "제어된 슬립"을 표시합니다.

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

Cisco 7200VXR 플랫폼에서는 음성 카드에 frame-clock-select 명령이 필요합니다.이 명령은 7200VXR 음성 게이트웨이에서 특히 중요합니다. 기본적으로 내부 TDM 버스는 로컬 진동기에 의해 제어되지 않기 때문입니다.E1 트렁크는 일반적으로 텔레포니 네트워크에 동기화되므로 숨겨진 클록 오류 및 간헐적인 팩스 전송 문제가 발생합니다.자세한 내용은 Cisco 버그 ID CSCdv10359에서 확인할 수 있습니다.

C4224 MFT 카드에서 라인에서 시계를 수락할 때 컨트롤러 t1 x/y 아래에서 clock source loop-timed 명령을 실행해야 합니다.이 설정은 시스템 전체의 클럭에서 컨트롤러 시계를 분리합니다.그런 다음 network-clock-select 명령을 설정해야 합니다.이 경우 네트워크 클럭에서 1 t1 x/y 를 선택합니다.

4. 팩스 인터페이스 유형을 확인합니다.

Cisco 3660, 5300, 5350, 5400 및 5800을 포함하는 일부 플랫폼에서는 기본적으로 라우터가 팩스 인터페이스 유형 모뎀으로 설정됩니다.fax interface-type modem global configuration 명령은 DSP가 아닌 모뎀(일반적으로 T.37 저장소 및 팩스 착신 전환)에 팩스 호출을 강제로 적용합니다.Cisco 팩스 릴레이가 작동하려면 팩스 호출을 DSP로 전송해야 합니다. 즉 팩스 인터페이스 유형 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 capi 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이 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 명령을 실행하여 음성 통화에 할당된 포트(및 시간 슬롯(해당되는 경우)를 확인합니다.터미널 모니터를 입력한 다음 show voice call 명령을 음성 포트(및 해당되는 경우 시간 슬롯)와 함께 실행하여 자세한 DSP 통계를 가져옵니다.출력의 "***DSP VOICE VP_ERROR STATISTICS***" 섹션에서 카운터를 찾습니다.일반적으로 0 또는 20 미만입니다. 카운터가 20보다 크면 패킷 손실을 조사합니다.

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

8. 팩스 릴레이 ECM 사용 안 함(Cisco 전용 VoIP만 해당)

패킷 손실 및 지터가 많은 네트워크의 경우 ECM을 비활성화하여 팩스 릴레이 통화를 개선하십시오.팩스 릴레이 ECM 비활성화 명령(이 문서의 구성 섹션에서 자세히 설명)을 실행하여 ECM을 해제하면 더 많은 양의 지터와 패킷 손실이 허용됩니다.

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

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

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

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

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

T.38 팩스가 PSTN에서 팩스 서버로 전화를 걸 때 Cisco Unified Communications Manager 추적이 show 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 팩스에 대한 Bug Search Tool(등록된 고객만 해당)에서 검색하면 Pitney Bowes 팩스 장치와 Cisco 팩스 릴레이(CSCdu78373(등록된 고객만 해당)가 포함된 버그가 표시됩니다. 이 버그는 Cisco IOS Software에는 없지만 연결의 양쪽에 있는 팩스 장치가 Pitney Bowes 9920 또는 9930s인 경우 Pitney Bowes의 전용 팩스 신호 프로토콜과 호환되지 않습니다.해결 방법은 팩스 시스템에서 전용 프로토콜을 비활성화하거나 팩스 릴레이를 비활성화하고 더 높은 대역폭 코덱을 사용하는 것입니다.

  알려진 주의 사항

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

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

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

  표 1 알려진 주의 사항

  버그 ID	요약	설명
  CSCdu30250	VAD에서는 팩스 통과 모드에서 심각한 오류가 발생합니다.	Cisco 음성 게이트웨이가 팩스 통과 모드로 구성된 경우 팩스 통화에 연결된 모든 VoIP 다이얼 피어에서 VAD(Voice Activity Detection)를 비활성화해야 합니다.VoIP 다이얼 피어에서 VAD를 비활성화하려면 다음 명령을 사용합니다. config terminal dial-peer voice XXX voip no vad
  CSCdu62269	CSCdu62269	게이트웨이 모드에서 WS-X4604-GW에 대한 팩스 릴레이 통화(페이로드 유형이 96인 RTP 패킷 포함)를 시작하는 모든 Cisco 게이트웨이 디바이스에 장애가 발생합니다.이 문제는 12.1.5YF3에서 해결되었습니다. 게이트웨이 모드로 설정하면 이제 소프트웨어에서 페이로드 유형 96을 식별하고 패스스루 모드를 시작합니다.
  CSCdv08143	5-30페이지의 팩스 전송은 게이트웨이 모드에서 VG248에서 WS-X4604-GW로 팩스 통과 모드로 실패합니다.	이 오류는 WS-X4604-GW의 소프트웨어 이미지 12.1.5YF2에서만 발생합니다.이 오류를 방지하려면 12.1.5YF1, 12.1.5YF3 이상을 사용하십시오.
  CSCdv83401	Cisco Catalyst 6000 스위치에서 팩스 또는 모뎀 신호음이 감지되면 통화가 10ms(134바이트) 패킷이 포함된 팩스 통과 모드로 전환됩니다.	팩스 통과 모드의 프레임 크기는 214바이트여야 합니다.패킷 크기가 올바르지 않더라도 팩스는 실패하지 않습니다.
  CSCdv83337
  CSCdw07735	WS-X4604/VIC-2FXS(전용)에서 Cisco CallManager 3-1-2c_spA 로드 A00203010026의 WS-X6624-FXS 게이트웨이로 팩스 전송 실패. WS-X460/VIC460-2FXS는 게이트웨이 모드와 수신자 부담 모드에서 모두 이를 나타냅니다.	이 오류는 WS-X4604-GW의 소프트웨어 이미지 12.1.5YF2 및 12.1.5YF3에서 발생하며 12.2(7)X 소프트웨어에서 수정됩니다.
  CSCdw07804	Cisco CallManager 3-1-2c_spA 로드 A00203010026을 사용하는 WS-C424V/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의 Bug Toolkit을 사용하여 버그를 검색할 수 있습니다.이 예에서는 다음 값을 사용합니다.

  • 주 버전:12.1

  • 개정:2

  • 기능/구성 요소:VoFR

  • 키워드:팩스

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

• 하드웨어 결함을 제거합니다.

  경우에 따라 문제 소스를 하나씩 제외하면 문제를 쉽게 격리할 수 있습니다.다른 하드웨어 부품을 교체하고 게이트웨이 간 대체 IP 연결을 사용합니다.추가 하드웨어를 사용할 수 있는 경우 다음 단계를 통해 다음을 수행할 수 있습니다.

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

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

  • 다른 하드웨어를 테스트합니다.

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

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

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

디버깅

T.30 메시지

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

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

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

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

• CNG(Calling Tone) - 30초 동안 켜진 다음 3초 동안 꺼진 1100Hz 신호음.이 신호는 팩스 터미널을 음성이 아닌 장치로 식별합니다.또한 시작 팩스 터미널이 종료 팩스 터미널의 DIS 신호를 기다리고 있음을 나타냅니다.

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

• CSI(Called Subscriber Identification)(CSI(Called Subscriber Identification)) - 국제 전화 번호를 통해 전화기의 특정 ID를 제공하는 데 사용할 수 있습니다.(선택 사항)

• DCN(연결 끊기) - 팩스 통화를 종료하며 응답이 필요하지 않습니다.

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

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

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

• EOP(프로시저 종료) - 팩스 정보의 전체 페이지 끝을 나타내며 더 이상 전송할 페이지가 없습니다.팩스 통화의 연결 끊기 단계로 진행합니다.

• FTT(Failure To Training) - 교육 신호를 거부하고 재교육을 요청하는 데 사용됩니다(재열차는 일반적으로 변조 속도가 더 낮음).

• MCF (Message Confirmation) - 메시지가 만족스럽게 수신되었음을 나타냅니다.

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

• NSF(Non-Standard Facility) - T 시리즈 사양에 포함되지 않은 특정 기능 또는 요구 사항을 식별하는 데 사용할 수 있습니다.(선택 사항)

• RTN(Retrain Negative) - 이전 메시지를 제대로 수신하지 못했음을 나타냅니다.계속 진행하려면 재교육이 필요합니다(일반적으로 변조 속도가 낮음).

• RTP(Retrain Positive) - 전체 메시지가 수신되었으며 재교육 후 추가 메시지가 표시될 수 있음을 나타냅니다.

• TCF(Training Check) - 이전 T.30 시그널링에 사용된 300kbps V.21 변조 방식과 달리 고속 T.4 변조 시스템을 통해 전송되어 교육을 확인하고 이 전송 속도로 전송된 팩스 페이지의 적합성을 나타냅니다.

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

팩스 릴레이 디버그 명령

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

• 디버그 팩스 릴레이 t30 all

• vtsp 모두 디버그

• 디버그 vtsp vofr 하위 프레임 3

디버그 팩스 릴레이 t30 all

Cisco 팩스 릴레이의 디버그는 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 메시지의 방향 흐름을 보여 줍니다.

디버그의 실패한 팩스 트랜잭션에서 여러 개의 "bad 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 모두 디버그

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

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

VoIP T.38 또는 팩스 릴레이의 경우 디버그 vtsp 모두 라우터에서 유용한 상태 정보를 제공할 수 있습니다.문제 해결 섹션에서 설명한 대로 이 debug 명령을 사용하여 Voice Telephony Service Provider Debugging 페이지에 표시된 대로 팩스 코덱이 DSP에 다운로드되었는지 확인할 수 있습니다.

vtsp vofr 하위 프레임 3 디버그

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

추가 디버그 명령

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

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

   • vtsp 모두 디버그

   • 디버그 voip ccapi inout

      

   • 모두 디버그(Cisco 5300/2600/3600 및 TI c54x DSP를 사용하는 기타 모든 음성 플랫폼에서)

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

팩스 분석기

팩스 릴레이 문제를 해결하기 위해 Cisco 음성 게이트웨이의 디버깅 기능을 넘어서는 경우가 있습니다.프로토콜 분석기, 팩스 분석기 등의 도구를 사용하여 팩스 릴레이 작업에서 무엇이 발생하는지 확인합니다.QualityLogic의 제노바 ChannelProbe/FaxProbe나 HP Telegra와 같은 팩스 분석기는 팩스 장치와 Cisco 게이트웨이 사이에 배치하여 발생한 문제를 캡처할 수 있습니다.Sniffer 및 Domino와 같은 프로토콜 분석기는 라우터 간에 교환되는 팩스 릴레이 패킷을 확인해야 할 때 유용할 수 있습니다.

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

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

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

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

TAC 케이스 열기

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

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

• 공급업체 및 모델 정보가 포함된 사용된 팩스 장치입니다.

• 문제의 역사.

  유용한 정보에는 구현이 새로운 네트워크인지, 제대로 작동했다가 실패한 설정된 네트워크인지 등이 포함됩니다.네트워크가 설정된 경우 문제가 발생하기 전에 변경된 사항은 무엇입니까?문제가 간헐적으로 발생합니까?문제를 재현할 수 있습니까? 그렇다면 문제를 재현하는 데 필요한 단계는 무엇입니까?

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

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

  • 디버그 voip ccapi inout

  • vtsp 모두 디버그

  • debug isdn q931(ISDN 또는 Q.Sig가 관련된 경우)

• show voice call 및 show voice dsp 출력 쌍

• 모니터 모드에서 원본 및 종료 팩스 장치에 연결된 한 쌍의 팩스 분석기 추적(사용 가능한 경우).

• 문제 해결 및 디버깅 결과(가능한 경우)

관련 정보

• Cisco Voice over IP 솔루션 - 팩스 서비스
• 통화 관리자 및 음성 게이트웨이를 사용하여 VoIP 팩스 릴레이 구성
• Cisco IOS 팩스 및 모뎀 서비스 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