방폭 SIP 전화기는 등록됨 상태를 표시해도 호출음이 울리지 않거나 무음으로 연결되거나 응답 후 끊길 수 있습니다. 등록, 통화 설정, 미디어 전송, 물리적 오디오 경로는 각각 별도로 점검해야 합니다. 설정을 변경하거나 전화기를 교체하기 전에 처음 실패하는 단계를 찾으십시오.
원격 로그와 승인된 시험 통화부터 시작하십시오. 위험장소의 물리적 점검에는 적격 인력, 현장 작업 허가, 에너지원 격리, 장비 지침 준수가 필요합니다. 필요한 통제 없이 전원이 인가된 외함을 열거나 위험장소에서 일반 노트북이나 시험 기기를 연결하지 마십시오. 네트워크 진단으로 방폭 보호의 건전성이 입증되지는 않습니다.
등록으로 입증되는 사항과 시험되지 않는 사항
성공한 REGISTER 트랜잭션은 등록 서버가 등록 요청을 수락했음을 확인합니다. 결과를 이해하려면 Contact 바인딩과 만료 시간을 확인하십시오. 인증은 흔히 사용되지만 200 OK만으로 인증이 수행되었음을 입증할 수 없습니다. 표시 상태가 현재 도달성이 아니라 이전 갱신을 반영할 수 있습니다.
통화에는 여전히 올바른 목적지에 도달하는 INVITE, 수락 가능한 세션 설명, 작동하는 오디오 경로가 필요합니다. 단말기의 Contact, PBX 라우팅, 게이트웨이나 SBC, 미디어 목적지는 서로 다른 주소와 정책을 수반할 수 있습니다. FXS 게이트웨이로 연결된 아날로그 방폭 전화기는 그 게이트웨이를 통해 진단해야 하며 전화기 자체는 네이티브 SIP 단말기가 아닙니다.
설정 변경 전에 증상을 분류하십시오
| 관찰된 증상 | 먼저 수집할 증거 |
|---|---|
| 호출음이 없거나 즉시 오류 발생 | 발신 INVITE, 목적지, 최종 응답, PBX 경로. |
| 연결되지만 무음이거나 단방향 음성 | SDP 주소와 포트, 이어서 각 방향의 미디어 도착 여부. |
| 응답 후 통화 끊김 | ACK 전달, BYE 발신 주체, 트랜잭션 타이머, 플랫폼 로그. |
| 음성이 끊기거나 간헐적으로 들림 | RTP 시퀀스 누락, 지터, 링크 부하, 로컬 오디오 동작. |
시각, 발신·착신 번호, 방향, 펌웨어, 토폴로지, 최근 변경 사항을 기록하십시오. 내선, 외선, 관제, 방송 목적지가 같은 방식으로 실패하는지 확인하십시오. 특정 경로의 장애는 모든 통화에 영향을 주는 장애와 다릅니다. 재부팅하거나 설정을 편집하기 전에 실패한 통화의 추적 자료를 보존하십시오.
1단계: 첫 장애까지 시그널링을 추적하십시오
실제 Request-URI 및 PBX 다이얼 플랜과 발신 번호를 대조하십시오. 접두번호, 번호 변환, 발신 권한, 목표 내선이나 트렁크 경로를 확인하십시오. 착신 장애에서는 현재 등록된 Contact와 착신 INVITE가 전화기에 도달하는지 확인하십시오.
응답 코드는 완전한 진단이 아니라 증거로 다루십시오. 첫 401 또는 407은 정상적인 인증 챌린지일 수 있으므로 반복 루프나 인증된 재시도의 거부를 조사하십시오. 403은 거부, 404는 대상 사용자 또는 도메인을 찾지 못함, 408은 시간 초과, 480은 일시적 이용 불가를 뜻합니다. 488은 단순한 코덱 불일치 이외의 세션 특성도 거부할 수 있습니다. 응답 세부 정보와 생성 시스템의 로그를 읽으십시오.
PBX가 INVITE를 전혀 받지 못하면 DNS 결과, VLAN, 게이트웨이, 전송 방식, 목적지 포트, 접근 규칙을 비교하십시오. 요청을 받지만 전달하지 않으면 플랫폼 라우팅과 정책을 살펴보십시오. 응답된 INVITE에 대해서는 해당 통화 구간의 200 OK와 ACK를 확인하십시오. 연결 표시는 모든 교환이 완료되었다는 증거가 아닙니다.
SIP는 흔히 포트 5060을 사용하고 TLS에서는 5061을 사용하지만 다른 포트도 쓸 수 있습니다. 추정한 포트 범위를 여는 대신 설정된 전송 방식과 수신 대기 서비스를 확인하십시오. TLS에서는 일반 네트워크 캡처로 암호화된 SIP 내용을 볼 수 없으므로 승인된 단말기 또는 서버 진단을 사용하십시오.
2단계: SDP와 실제 미디어 경로를 비교하십시오
협상된 SDP의 c=, m=, a=rtpmap과 a=sendrecv 같은 방향 속성을 살펴보십시오. 세션 수준과 미디어 수준 연결 정보, 수락된 형식, 거부되거나 비활성화된 스트림을 확인하십시오. 제안/응답은 서로 다른 SIP 메시지에서 이루어질 수 있으므로 INVITE와 200 OK에 항상 전체 협상이 포함된다고 가정하지 마십시오.
광고된 각 미디어 주소와 포트가 실제 토폴로지를 통해 도달 가능한지 확인하십시오. 사설 주소는 상대가 그 주소로 라우팅할 수 없을 때 문제가 되는 것이지 사설 주소라는 사실 자체가 문제는 아닙니다. 방화벽이나 NAT 경계 양쪽에서 패킷을 비교하여 어느 지점에서 한 방향이 멈추는지 확인하십시오. 설정된 미디어 흐름을 허용하십시오. 모든 전화기에 공통인 RTP 포트 범위는 없습니다.
SBC는 그렇게 설정되어 있을 때 미디어를 중계 지점에 고정할 수 있습니다. STUN, TURN, ICE는 역할이 다르며 호환되는 단말기와 플랫폼 지원이 필요합니다. 어느 것도 NAT를 해결하는 만능 설정 항목은 아닙니다. SIP ALG나 방화벽 동작을 바꾸기 전에 설계를 확인하고 복구 경로를 유지하십시오.
각 통화 구간에서 수락된 페이로드 유형, 코덱 매개변수, 패킷화, RTP/SRTP 요구사항을 비교하십시오. 게이트웨이나 PBX의 트랜스코딩은 해당 기능이 지원되고 활성화되어야 가능합니다. SDP 응답은 여러 형식을 수락할 수 있으므로 모든 응답이 정확히 하나의 코덱만 선택한다고 보는 것은 부정확합니다. 방폭 외함이나 다른 모델을 보고 지원 코덱을 추정하지 마십시오.
보류, 호전환 또는 re-INVITE 후 미디어가 멈추면 새 SDP 주소, 포트, 방향을 원래 세션과 비교하십시오. 일정 시간 후 끊긴다면 세션 타이머나 NAT 시간 초과를 탓하기 전에 해제 메시지와 로그를 살펴보십시오. RTP 손실과 지터는 전송 동작을 나타낼 뿐 마이크가 유효한 음성을 생성한다는 증거는 아닙니다.
3단계: 로컬 오디오 체인과 필요한 서비스를 확인하십시오
미디어가 올바른 단말기에 도달하면 승인된 절차로 음소거, 게인, 수화기, 마이크, 스피커, 선택된 오디오 출력을 확인하십시오. 양방향 패킷도 무음이나 디코딩할 수 없는 데이터를 담을 수 있습니다. 정상 동작이 확인된 통화 및 단말기와 비교하되 교체 결과만으로 하드웨어 결함이 입증된다고 가정하지 마십시오. 자격 증명, 펌웨어, 스위치 포트, 네트워크 설정도 다를 수 있습니다.
장착된 경우 수화기, 핸즈프리, 외부 방송 출력을 각각 시험하십시오. 수화기가 작동한다고 외부 증폭기, 혼 회로 또는 방송 릴레이도 작동한다는 뜻은 아닙니다. 관제 위치 표시, 녹음, 우선순위, 경보 연동은 해당 단말기가 명시적으로 구현하지 않는 한 플랫폼 또는 통합 기능입니다.
단말기 진단, 미러링된 스위치 포트, PBX, SBC 등 적절하고 승인된 지점에서 동기화된 캡처를 사용하십시오. SIP Call-ID와 타임스탬프를 대조하되 SBC가 서로 다른 통화 구간을 만들 수 있음을 유의하십시오. 필요한 트래픽만 수집하고 로그와 녹음을 보호하십시오. 암호화된 SRTP는 승인된 키 자료와 적절한 분석 방법 없이 일반 캡처만으로 들을 수 없습니다.
한 번의 통제된 변경 후 실패했던 경로와 양방향 오디오를 다시 시험한 다음, 영향을 받는 방송·관제 기능과 계획된 장애 전환 후 복구를 확인하십시오. 최종 설정, 추적 자료 참조, 결과를 저장하십시오. 장기적인 모니터링 및 설정 관행은 방폭 방송 전화기의 원격 유지보수를 참조하십시오.
자주 묻는 질문
내선 통화는 되는데 외선 통화가 실패하는 이유는 무엇입니까?
외선 통화에는 트렁크 라우팅, 권한, 번호 변환, 상위망 정책이 추가됩니다. 등록으로 트렁크까지 시험된다고 가정하지 말고, 성공한 내부 경로와 실패한 트렁크 통화를 반환 시그널링 및 미디어 구간까지 비교하십시오.
모든 무음 장애를 코덱 문제로 다뤄야 합니까?
아니요. 먼저 협상된 세션과 각 단말기로의 미디어 도착을 확인하십시오. 라우팅, NAT, 접근 규칙, SRTP 호환성, 로컬 오디오 모두 무음의 원인이 될 수 있습니다. 웹 페이지의 코덱 설정은 통화에서 실제로 협상한 내용을 입증하지 않습니다.
재부팅은 수리입니까?
재부팅은 프로세스를 복원하거나 매핑을 갱신할 수 있지만 원인을 식별하지는 못합니다. 가능하면 먼저 증거를 보존한 다음 재현 가능한 복구를 확인하십시오. 서비스 중단을 기록하고 유지보수 중 현장의 대체 통신 수단을 마련하십시오.
기술 참고자료
프로토콜 근거: IETF RFC 3261, SIP 및 IETF RFC 3264, SDP 제안/응답. 위험장소 유지보수 배경: 잠재적 폭발성 분위기의 전기에 관한 HSE 지침.
