3CX 기술 지원팀의 응답: PBX 서버에서 SIP 트래픽 캡처

이 기사에서는 3CX PBX에서 생성된 SIP 트래픽을 캡처하고 분석하는 기본 사항에 대해 설명합니다. 이 기사는 전화 통신 유지 관리를 담당하는 초보 시스템 관리자나 일반 사용자를 대상으로 작성되었습니다. 주제에 대한 심층적인 연구를 위해서는 다음을 수행하는 것이 좋습니다. 고급 3CX 교육 과정.

3CX V16을 사용하면 서버 웹 인터페이스를 통해 직접 SIP 트래픽을 캡처하고 이를 표준 Wireshark PCAP 형식으로 저장할 수 있습니다. 기술 지원에 문의할 때 캡처 파일을 첨부하거나 독립적인 분석을 위해 다운로드할 수 있습니다.

3CX가 Windows에서 실행되는 경우 3CX 서버에 Wireshark를 직접 설치해야 합니다. 그렇지 않으면 캡처를 시도할 때 다음 메시지가 나타납니다.


Linux 시스템에서는 3CX를 설치하거나 업데이트할 때 tcpdump 유틸리티가 자동으로 설치됩니다.

트래픽 캡처

캡처를 시작하려면 인터페이스 섹션 홈 > SIP 이벤트로 이동하여 캡처할 인터페이스를 선택합니다. IPv6 터널링 인터페이스를 제외한 모든 인터페이스에서 동시에 트래픽을 캡처할 수도 있습니다.

Linux용 3CX에서는 로컬 호스트(lo)에 대한 트래픽을 캡처할 수 있습니다. 이 캡처는 기술을 사용하여 SIP 클라이언트 연결을 분석하는 데 사용됩니다. 3CX 터널 및 세션 경계 컨트롤러.

트래픽 캡처 버튼은 Windows에서는 Wireshark를 시작하고 Linux에서는 tcpdump를 시작합니다. 이 시점에서는 신속하게 문제를 재현해야 합니다. 왜냐하면... 캡처는 CPU를 많이 사용하며 상당한 양의 디스크 공간을 차지합니다.  


다음 호출 매개변수에 주의하세요.

• 통화가 이루어진 번호로, 통화에 참여한 다른 번호/참가자도 이 번호로 전화를 걸었습니다.
• 3CX 서버 시계에 따른 문제가 발생한 정확한 시간입니다.
• 통화 경로.

"중지" 버튼을 제외한 인터페이스의 아무 곳도 클릭하지 마세요. 또한 이 브라우저 창에서 다른 링크를 클릭하지 마십시오. 그렇지 않으면 트래픽 캡처가 백그라운드에서 계속되어 서버에 추가 로드가 발생하게 됩니다.

캡처 파일 수신

중지 버튼은 캡처를 중지하고 캡처 파일을 저장합니다. Wireshark 유틸리티에서 분석하기 위해 파일을 컴퓨터에 다운로드하거나 특수 파일을 생성할 수 있습니다. 기술 지원, 여기에는 이 캡처 및 기타 디버깅 정보가 포함됩니다. 지원 패키지에 다운로드되거나 포함되면 캡처 파일은 보안을 위해 3CX 서버에서 자동으로 삭제됩니다.

3CX 서버에서 파일은 다음 위치에 있습니다.

• Windows: C:ProgramData3CXInstance1DataLogsdump.pcap
• 리눅스: /var/lib/3cxpbx/Instance/Data/Logs/dump.pcap

캡처 중 서버 로드 증가 또는 패킷 손실을 방지하기 위해 캡처 기간은 2만 패킷으로 제한됩니다. 그 후에는 캡처가 자동으로 중지됩니다. 더 긴 캡처가 필요한 경우 아래 설명된 대로 별도의 Wireshark 유틸리티를 사용하십시오.

Wireshark 유틸리티로 트래픽 캡처

네트워크 트래픽에 대한 심층 분석에 관심이 있는 경우 수동으로 캡처하십시오. 해당 OS에 맞는 Wireshark 유틸리티를 다운로드하세요. 따라서. 3CX 서버에 유틸리티를 설치한 후 캡처 > 인터페이스로 이동합니다. OS의 모든 네트워크 인터페이스가 여기에 표시됩니다. 인터페이스 IP 주소는 IPv6 표준으로 표시될 수 있습니다. IPv4 주소를 보려면 IPv6 주소를 클릭하세요.

캡처할 인터페이스를 선택하고 옵션 버튼을 클릭합니다. 무차별 모드에서 트래픽 캡처를 선택 취소하고 나머지 설정은 변경하지 않은 상태로 둡니다.

이제 문제를 재현해야 합니다. 문제가 재현되면 캡처를 중지하세요(메뉴 캡처 > 중지). 전화 통신 > SIP 흐름 메뉴에서 SIP 메시지를 선택할 수 있습니다.

트래픽 분석 기본 사항 - SIP INVITE 메시지

VoIP 통화를 설정하기 위해 전송되는 SIP INVITE 메시지의 주요 필드를 살펴보겠습니다. 분석의 출발점이다. 일반적으로 SIP INVITE에는 SIP 최종 장치(전화, 게이트웨이) 및 통신 사업자가 사용하는 정보가 포함된 4~6개의 필드가 포함됩니다. INVITE의 내용과 그에 따른 메시지를 이해하면 문제의 원인을 파악하는 데 도움이 될 수 있습니다. 또한 INVITE 필드에 대한 지식은 SIP 운영자를 3CX에 연결하거나 3CX를 다른 SIP PBX와 결합할 때 도움이 됩니다.

INVITE 메시지에서 사용자(또는 SIP 장치)는 URI로 식별됩니다. 일반적으로 SIP URI는 사용자의 전화번호 + SIP 서버 주소입니다. SIP URI는 이메일 주소와 매우 유사하며 sip:x@y:Port로 작성됩니다.

요청 라인 URI:

요청-라인-URI - 필드에는 통화 수신자가 포함됩니다. 여기에는 받는 사람 필드와 동일한 정보가 포함되어 있지만 사용자의 표시 이름은 없습니다.

비아 :

경유 - INVITE 요청이 통과하는 각 SIP 서버(프록시)는 해당 IP 주소와 메시지가 수신된 포트를 경유 목록의 맨 위에 추가합니다. 그런 다음 메시지는 경로를 따라 추가로 전송됩니다. 최종 수신자가 INVITE 요청에 응답하면 모든 전송 노드는 Via 헤더를 "조회"하고 동일한 경로를 따라 발신자에게 메시지를 반환합니다. 이 경우 전송 SIP 프록시는 헤더에서 해당 데이터를 제거합니다.

부터

From - 헤더는 SIP 서버의 관점에서 요청 개시자를 나타냅니다. 헤더는 이메일 주소와 동일한 방식으로 구성됩니다(user@domain, 여기서 user는 3CX 사용자의 내선 번호이고 domain은 3CX 서버의 로컬 IP 주소 또는 SIP 도메인입니다). To 헤더와 마찬가지로 From 헤더에는 URI와 선택적으로 사용자의 표시 이름이 포함됩니다. From 헤더를 보면 이 SIP 요청이 어떻게 처리되어야 하는지 정확하게 이해할 수 있습니다.

SIP 표준 RFC 3261에서는 표시 이름이 전송되지 않는 경우 IP 전화 또는 UAC(VoIP 게이트웨이)가 표시 이름 "Anonymous"를 사용해야 한다고 규정합니다(예: From: "Anonymous")[이메일 보호]>.

에:

To - 이 헤더는 요청 수신자를 나타냅니다. 이는 통화의 최종 수신자일 수도 있고 중간 링크일 수도 있습니다. 일반적으로 헤더에는 SIP URI가 포함되어 있지만 다른 방식도 가능합니다(RFC 2806 [9] 참조). 그러나 SIP URI는 하드웨어 제조업체에 관계없이 SIP 프로토콜의 모든 구현에서 지원되어야 합니다. 받는 사람 헤더에는 표시 이름도 포함될 수 있습니다(예: 받는 사람: "이름 성").[이메일 보호]>).

일반적으로 받는 사람 필드에는 요청을 처리할 첫 번째(다음) SIP 프록시를 가리키는 SIP URI가 포함되어 있습니다. 이 사람이 요청의 최종 수신자일 필요는 없습니다.

연락처 :

연락처 - 헤더에는 INVITE 요청의 발신자에게 연락할 수 있는 SIP URI가 포함되어 있습니다. 이는 필수 헤더이며 SIP URI를 하나만 포함해야 합니다. 이는 원래 SIP INVITE 요청에 해당하는 양방향 통신의 일부입니다. 요청을 보낸 사람이 응답을 기대하는 올바른 정보(IP 주소 포함)가 연락처 헤더에 포함되어 있는 것이 매우 중요합니다. URI 연락처는 통신 세션이 설정된 후 추가 통신에도 사용됩니다.

허용하다:

허용 - 필드에는 쉼표로 구분된 매개변수(SIP 방법) 목록이 포함되어 있습니다. 특정 발신자(장치)가 지원하는 SIP 프로토콜 기능을 설명합니다. 전체 메소드 목록: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE. SIP 방법에 대해 자세히 설명합니다. 여기에.

출처 : habr.com