Technical support 3CX responds: seizure of SIP-traffic on the PBX server
In this article we will talk about the basics of capturing and analyzing SIP-traffic generated by the 3CX PBX. The article is addressed to novice system administrators or regular users, whose duties include telephony service. For in-depth study of the topic, we recommend you to take the Advanced 3CX Training Course .
3CX V16 allows you to capture SIP traffic directly through the server’s web interface and save it in standard Wireshark PCAP format. You can attach a capture file when contacting technical support or download for independent analysis.
If 3CX runs on Windows, you must install Wireshark yourself on the 3CX server. Otherwise, the following message will appear when attempting to capture.
')
On Linux systems, the tcpdump utility is installed automatically when installing or updating 3CX.
To start the capture, go to the interface section Home> SIP Events and select the interface on which you want to capture. You can also capture traffic on all interfaces at the same time, except for IPv6 tunneling interfaces.
In 3CX for Linux, you can capture traffic for a local host (lo). This capture is used to analyze SIP client connections using 3CX Tunnel and Session Border Controller technology.
The Traffic Capture button launches Wireshark on Windows or tcpdump on Linux. At this point, you need to quickly reproduce the problem, because Capture loads the processor and takes up enough disk space.
Pay attention to the following call options:
Try not to click anywhere else in the interface, except for the “Stop” button. Also, do not follow other links in this browser window. Otherwise, traffic capture will continue in the background and will cause additional load on the server.
The Stop button stops capturing and saves the capture file. You can download the file to your computer for analysis in the Wireshark utility or generate a special technical support file that will include this capture and other debug information. Once downloaded or included in a technical support package, the capture file is automatically deleted from the 3CX server for security reasons.
On the server, the 3CX file is located in the following location:
To avoid increased server load or packet loss during capture, the capture period is limited to 2 million packets. After that, the seizure automatically stops. If you need a longer capture, use the separate Wireshark utility, as described below.
If you are interested in a deeper analysis of network traffic, capture it manually. Download Wireshark Utility for your OS from here . After installing the utility on the 3CX server, go to Capture> Interfaces. All OS network interfaces will be shown here. Interface IP addresses can be shown in IPv6 standard. To see the IPv4 address, click on the IPv6 address.
Select the interface to capture and click the Options button. Uncheck Capture Traffic in promiscuous mode and leave the other settings unchanged.
Now you should reproduce the problem. When the problem is reproduced, stop the capture (menu Capture> Stop). You can select SIP messages in the menu Telephony> SIP Flows.
Consider the main fields of the SIP INVITE message that is sent to establish a VoIP call, i.e. is the starting point for analysis. Usually SIP INVITE includes from 4 to 6 fields with information that is used by SIP end devices (phones, gateways) and telecom operators. Understanding the contents of the INVITE and the messages that follow it often helps determine the source of the problem. In addition, knowledge of the INVITE fields helps in connecting SIP operators to 3CX or combining 3CX with other SIP PBXs.
In an INVITE message, users (or SIP devices) are identified by a URI. Typically, the SIP URI is the user's phone number + SIP server address. A SIP URI is very similar to an e-mail address and is written as sip: x @ y: Port.
Request-Line-URI - the field contains the call recipient. It contains the same information as the To field, but without the display name of the user (Display Name).
Via — each SIP server (proxy) through which an INVITE request passes, adds its IP address and port to which the message was received at the top of the Via list. Then the message is passed on along the way. When the final recipient responds to the INVITE request, all transit nodes “look through” the Via header and return the message to the sender along the same route. In this case, the transit SIP proxy removes its data from the header.
From - the header indicates the initiator of the request from the point of view of the SIP server. The header is formed in the same way as the e-mail address (user @ domain, where user is the extension number of the 3CX user, and domain is the local IP address or the SIP domain of the 3CX server). Like the To header, the From header contains the URI and, optionally, the display name of the user Display Name. From the From header you can understand exactly how this SIP request should be processed.
The SIP RFC 3261 standard provides that if the display name of the Display Name is not transmitted, the IP phone or VoIP gateway (UAC) should use the Display Name "Anonymous", for example, From: "Anonymous" <sip: 10000@10.172.0.2>.
To - this header indicates the recipient of the request. This can be either the final recipient of the call or an intermediate. Typically, the header contains a SIP URI, but other schemes are possible (see RFC 2806 [9]). However, the SIP URI must be supported in all implementations of the SIP protocol, regardless of the manufacturer of the equipment. The To header may also contain a display name Display Name, for example, To: "First Name Last Name" <sip: 101@10.172.0.2>).
Typically, the To field contains a SIP URI indicating the first (next) SIP proxy that will handle the request. This does not have to be the final recipient of the request.
Contact - the header contains the SIP URI, by which you can contact the sender of the INVITE request. This is a required header that should contain only one SIP URI. It is part of two-way communication corresponding to the original SIP INVITE request. It is very important that the Contact header contains correct information (including an IP address) that the sender of the request is waiting for a response to. URI Contact is also used in further communications, after the establishment of a communication session.
Allow - the field contains a list of parameters (SIP-methods), separated by a comma. They describe which SIP capabilities this particular sender (device) supports. Complete list of methods: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE. More SIP methods are described here .
3CX V16 allows you to capture SIP traffic directly through the server’s web interface and save it in standard Wireshark PCAP format. You can attach a capture file when contacting technical support or download for independent analysis.
If 3CX runs on Windows, you must install Wireshark yourself on the 3CX server. Otherwise, the following message will appear when attempting to capture.
')
On Linux systems, the tcpdump utility is installed automatically when installing or updating 3CX.
Traffic capture
To start the capture, go to the interface section Home> SIP Events and select the interface on which you want to capture. You can also capture traffic on all interfaces at the same time, except for IPv6 tunneling interfaces.
In 3CX for Linux, you can capture traffic for a local host (lo). This capture is used to analyze SIP client connections using 3CX Tunnel and Session Border Controller technology.
The Traffic Capture button launches Wireshark on Windows or tcpdump on Linux. At this point, you need to quickly reproduce the problem, because Capture loads the processor and takes up enough disk space.
Pay attention to the following call options:
- The number from which they called, the other numbers / participants of the call also called.
- The exact time of the problem on the clock server 3CX.
- The route of the call.
Try not to click anywhere else in the interface, except for the “Stop” button. Also, do not follow other links in this browser window. Otherwise, traffic capture will continue in the background and will cause additional load on the server.
Getting the capture file
The Stop button stops capturing and saves the capture file. You can download the file to your computer for analysis in the Wireshark utility or generate a special technical support file that will include this capture and other debug information. Once downloaded or included in a technical support package, the capture file is automatically deleted from the 3CX server for security reasons.
On the server, the 3CX file is located in the following location:
- Windows: C: \ ProgramData \ 3CX \ Instance1 \ Data \ Logs \ dump.pcap
- Linux: /var/lib/3cxpbx/Instance/Data/Logs/dump.pcap
To avoid increased server load or packet loss during capture, the capture period is limited to 2 million packets. After that, the seizure automatically stops. If you need a longer capture, use the separate Wireshark utility, as described below.
Traffic capture utility Wireshark
If you are interested in a deeper analysis of network traffic, capture it manually. Download Wireshark Utility for your OS from here . After installing the utility on the 3CX server, go to Capture> Interfaces. All OS network interfaces will be shown here. Interface IP addresses can be shown in IPv6 standard. To see the IPv4 address, click on the IPv6 address.
Select the interface to capture and click the Options button. Uncheck Capture Traffic in promiscuous mode and leave the other settings unchanged.
Now you should reproduce the problem. When the problem is reproduced, stop the capture (menu Capture> Stop). You can select SIP messages in the menu Telephony> SIP Flows.
Traffic Analysis Basics - SIP INVITE Message
Consider the main fields of the SIP INVITE message that is sent to establish a VoIP call, i.e. is the starting point for analysis. Usually SIP INVITE includes from 4 to 6 fields with information that is used by SIP end devices (phones, gateways) and telecom operators. Understanding the contents of the INVITE and the messages that follow it often helps determine the source of the problem. In addition, knowledge of the INVITE fields helps in connecting SIP operators to 3CX or combining 3CX with other SIP PBXs.
In an INVITE message, users (or SIP devices) are identified by a URI. Typically, the SIP URI is the user's phone number + SIP server address. A SIP URI is very similar to an e-mail address and is written as sip: x @ y: Port.
Request-Line-URI:
Request-Line-URI - the field contains the call recipient. It contains the same information as the To field, but without the display name of the user (Display Name).
Via:
Via — each SIP server (proxy) through which an INVITE request passes, adds its IP address and port to which the message was received at the top of the Via list. Then the message is passed on along the way. When the final recipient responds to the INVITE request, all transit nodes “look through” the Via header and return the message to the sender along the same route. In this case, the transit SIP proxy removes its data from the header.
From:
From - the header indicates the initiator of the request from the point of view of the SIP server. The header is formed in the same way as the e-mail address (user @ domain, where user is the extension number of the 3CX user, and domain is the local IP address or the SIP domain of the 3CX server). Like the To header, the From header contains the URI and, optionally, the display name of the user Display Name. From the From header you can understand exactly how this SIP request should be processed.
The SIP RFC 3261 standard provides that if the display name of the Display Name is not transmitted, the IP phone or VoIP gateway (UAC) should use the Display Name "Anonymous", for example, From: "Anonymous" <sip: 10000@10.172.0.2>.
To:
To - this header indicates the recipient of the request. This can be either the final recipient of the call or an intermediate. Typically, the header contains a SIP URI, but other schemes are possible (see RFC 2806 [9]). However, the SIP URI must be supported in all implementations of the SIP protocol, regardless of the manufacturer of the equipment. The To header may also contain a display name Display Name, for example, To: "First Name Last Name" <sip: 101@10.172.0.2>).
Typically, the To field contains a SIP URI indicating the first (next) SIP proxy that will handle the request. This does not have to be the final recipient of the request.
Contact:
Contact - the header contains the SIP URI, by which you can contact the sender of the INVITE request. This is a required header that should contain only one SIP URI. It is part of two-way communication corresponding to the original SIP INVITE request. It is very important that the Contact header contains correct information (including an IP address) that the sender of the request is waiting for a response to. URI Contact is also used in further communications, after the establishment of a communication session.
Allow:
Allow - the field contains a list of parameters (SIP-methods), separated by a comma. They describe which SIP capabilities this particular sender (device) supports. Complete list of methods: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE. More SIP methods are described here .
Source: https://habr.com/ru/post/455381/
All Articles