다섯 팀, 음성 네트워크를 테스트하는 다섯 가지 이유.

수십 곳의 피어링 파트너를 통해 트래픽을 전달하고 있습니다. 그중 한 곳은 자사 쪽에는 문제가 없다고 주장하지만, 고객은 그렇지 않다고 말합니다. 어느 쪽도 통화의 나머지 절반을 볼 수 없습니다.

CDR만으로 하는 사후 디버깅으로는 codec 재협상, 트랜스코딩 아티팩트, 실제 packet loss를 구분할 수 없습니다. 수동으로 pcap을 캡처할 즈음에는 대개 문제 상태가 이미 사라져 있습니다.

1. 01고객님 네트워크의 에이전트 노드에서 모든 피어링 라우트를 대상으로 예약 캠페인을 지속적으로 실행합니다.
2. 02응답 여부, PDD, 양방향으로 오디오가 흘렀는지를 기준으로 각 통화를 판정합니다. 코드별 판정 정책을 두어, 통화 중 신호음 테스트에서 486은 성공으로, 404는 실패로 처리할 수 있습니다.
3. 03라우트 품질이 저하되면, 문제가 된 바로 그 통화의 SIP ladder와 패킷 캡처가 이미 준비되어 있습니다.

새 SBC, 새 통신사, 또는 UCaaS 전환입니다. 설정은 올바르게 보이고 수동 테스트 통화 몇 건도 성공합니다.

수동 테스트는 단말 한 대에서 정상 경로만 확인합니다. 오퍼의 두 번째 codec, 보류 시의 re-INVITE, 새 SBC가 요구하는 PRACK, 동시 통화 2건이 아닌 200건에서 일어나는 상황은 확인하지 못합니다.

1. 01Test Console에서 기능 테스트 통화를 걸고, 인증 챌린지와 re-INVITE를 포함한 모든 트랜잭션을 타이밍과 함께 담은 전체 SIP ladder를 확인합니다.
2. 02해당 거점이 실제로 도달하는 동시 통화 수에 맞춰 초당 통화 수를 점진적으로 늘리며 부하 실행을 진행하고, 장애 지점을 추측하는 대신 직접 관찰합니다.
3. 03전환 기간 내내 예약 캠페인을 계속 실행해, 회귀가 발생하면 바로 드러나게 합니다.

PBX, SBC, 게이트웨이 또는 소프트폰을 개발합니다. 매 릴리스는 고객이 이미 의존하는 codec, 전송 방식, call flow와 계속 호환되어야 합니다.

수작업 회귀 테스트나 한 명의 엔지니어만 이해하는 스크립트로는 누군가 기억해서 건 흐름만 다루게 됩니다. TLS 위의 두 번째 codec이나 형식이 올바르지 않은 헤더에 대한 응답은 테스트되지 않고 넘어가기 쉽습니다.

1. 01통화 테스트를 codec 및 전송 방식 매트릭스를 갖춘 YAML 스위트로 기술하고, 제품 옆에서 버전 관리합니다.
2. 02모든 빌드마다 CI에서 스위트를 실행하고, 단위 테스트처럼 JUnit 결과를 기준으로 릴리스를 승인합니다.
3. 03부정 사례에는 Signalling Lab을 사용합니다. 직접 작성한 의도적으로 잘못된 SIP를 보내, 새 빌드가 어떻게 응답하는지 확인합니다.

아웃바운드 통화의 오디오 품질은 하루 대부분 양호합니다. 불만은 오후에 몰리는데, 아무도 재현하지 못합니다.

trunk가 살아 있는지만 보는 모니터링으로는 간헐적인 품질 저하가 보이지 않습니다. 통화가 200 OK로 완료되어도 사용할 수 없는 경우가 있습니다. 버스트로 도착하는 jitter, 한쪽 방향으로만 들리는 오디오, 협대역으로 되돌아간 codec 등이 그렇습니다.

1. 01중요한 라우트 전반에서 합성 통화를 스케줄에 따라 24시간 실행하고, 각 통화에서 응답 여부뿐 아니라 양방향 오디오와 협상된 codec도 확인합니다.
2. 02특정 라우트에 불만이 몰리면 해당 라우트에서 음성 품질 테스트를 실행합니다. 기준 오디오를 보내 도착한 오디오와 비교하므로, 패킷 통계가 정상으로 보여도 손상을 확인할 수 있습니다.
3. 03jitter 히스토그램과 프레임별 상세 분석으로 버스트 손실과 지속적인 품질 저하를 구분합니다.

여러 고객사의 음성 서비스를 관리하고 있습니다. 고객마다 네트워크가 정상인지 알고 싶어 하며, 요청하는 형식도 제각각입니다.

리포트를 서로 다른 도구에서 수작업으로 취합하느라 느려서, 많아야 월 1회 작성됩니다. 월간 리포트는 고객이 이미 겪은 문제를 요약한 것에 불과합니다.

1. 01각 고객을 별도의 테넌트로 분리하고, 고객별 계정, 에이전트 노드, 팀을 둡니다.
2. 02통화 기록, SLA 결과, 부하 실행 결과로 리포트를 한 번 구성한 뒤, 자동으로 발송되도록 예약합니다.
3. 03고객이 자체 도구에서 사용하길 원하면 API로 전체를 연동하고, CI를 운영하는 고객에게는 JUnit 출력을 제공합니다.

예약된 테스트가 밤사이 실패했습니다. 당직 엔지니어에게는 통화 기록과 응답 코드가 있고 기다리는 고객도 있지만, SIP ladder, SDP, 미디어 결과를 읽을 시간이 없습니다.

응답 코드는 원인이 아니라 증상을 나타냅니다. 같은 488이라도 codec 불일치일 수도, 상대측이 거부하는 SRTP 오퍼일 수도, SBC의 정책일 수도 있으며, 증거는 여러 화면에 흩어져 있습니다.

1. 01통화 기록에서 Ask AI를 누르거나, 어시스턴트에게 통화가 실패한 이유를 물어보세요.
2. 02어시스턴트는 VoiceLab 자체 기록에서 해당 통화와 SIP ladder, 미디어 결과를 읽고, 그 통화의 맥락에서 응답을 설명합니다.
3. 03모든 주장에는 Observed, Likely, Unknown 표시가 붙어, 데이터가 보여 주는 내용과 어시스턴트의 추정이 구분됩니다.
4. 04관련된 두 계정을 비교하게 하거나, 전주 같은 시간대와 비교해 SLA 인시던트를 조사하게 할 수 있습니다.

새 trunk에도 기존과 같은 점검이 필요합니다. 계정을 등록하고, 지정한 codec으로 번호에 전화를 걸고, 오디오를 확인하고, 매일 밤 반복합니다.

각각이 여러 페이지에 걸쳐 열두 개쯤의 필드가 있는 양식이며, codec 이름이나 번호에 오타가 있으면 실행이 실패하고 결과도 혼란스러워집니다.

1. 01이렇게 설명하세요. “6001에서 6002로 PCMA로 전화를 걸어 오디오를 확인해 줘”.
2. 02어시스턴트가 정확한 번호로 계정을 찾고, 테스트 초안을 작성한 뒤, API가 적용하는 것과 동일한 규칙으로 검증합니다.
3. 03무엇이 전송되거나 변경될지 제안 내용을 그대로 검토하고 확인을 누릅니다. 그 전에는 아무것도 실행되지 않습니다.
4. 04결과는 다른 테스트와 마찬가지로 Call Records에 표시되며, 어시스턴트가 결과를 설명합니다.