Questo sito utilizza cookie di profilazione (propri e di terze parti) per ottimizzare la tua esperienza online e per inviarti pubblicità in linea con le tue preferenze. Continuando a utilizzare questo sito senza modificare le tue preferenze acconsenti all’uso dei cookie. Se vuoi saperne di più o negare il consenso a tutti o ad alcuni cookie clicca qui>
The website that you are visiting also provides Arabian language. Do you wish to switch language version?
يوفر موقع الويب الذي تزوره المحتوى باللغة العربية أيضًا. هل ترغب في تبديل إصدار اللغة؟
The website that you are visiting also provides Russia language Do you wish to switch language version?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
Customer reported an issue where he has in his Video conference infrastructure an audio conference configured as a participant on the management SMC platform. When he adds this participant to a meeting and a SIP call is generated to customer's conference server running on FreePBX to enter the meeting into an audio conference it fails to connect. They have changed their system to support TLS transmission protocol.
In order to further investigate the reported issue we required from the customer the video conferencing solution which he is currently using and also network topology and firmware version for each element present in the network. Our VC solution can support the merge of UDP and TLS transport mode.
Customer provided the following network topology along with the requested firmware versions of each element.
A call comes into the conference server from the Provider over a SIP Trunk to the Cisco CUBE which then directs it to the FreePBX Host to enter it to the conference. At the same time the SMC/SC starts a meeting with the Audio Conference Participant added which generates a SIP call to the FreePBX host. It is this call leg that fails since they have changed their system to use TLS.
After we have clarified the scenario, network topology and firmware version of each network element present in the VC infrastructure we requested the following:
- On which equipment would like to configure the transport protocol from UDP to TLS?
- To which server does the audio participant register to; Cisco CUBE or our SC
- How does the audio participant join the call? Does he schedule the conference on the SMC or the audio participant calls the audio conference number? What is the audio participant’s number and IP address?
- First of all run the signaling diagnostics on the SC before reproducing the issue and after the issue has been reproduced ,export it; device and running logs from the SC after the issue has been reproduced; signaling capture from the MCU and capture from the PBX as well if possible
- IP address assignation included in the network capture (IP of the SC, MCU and PBX) to follow the communication
- The logs from the SMC (system logs and debug log)
- One Click diagnostics of the MCU
IP address assignation:
10.0.2.48 is their FreePBX Server that is hosting the Audio Conference. This does not register to any device it just receives SIP calls.
10.0.7.3 is their SC
10.0.7.4 is their MCU
After we have analyzed the provided logs we have noticed on the log on the SMC that the call failed because of the reason: "Failed to call participant Audio Conf 5148 to join conference Test Audio Conf. Reason: Failed to set up a TLS link and we scheduled a remote session to collect more information:
Operations performed during the remote session:
- Clarified the reported issue
- When there are two ongoing conferences, one on the SMC and one audio conference on the FreePBX. When the audio conference participant is added to the conference there is an error message displayed stating that: Failed to set up a TLS link when there is a SIP call sent to the freePBX host
- Checked the firmware version of the SMC
- Checked the MCU involved and the settings on the standalone SC
- Gathered the signaling diagnostics from the web interface of the VP9630 after the issue has been reproduced
- Gathered the signaling diagnostics from the standalone SC 10.0.7.3 after the issue has been reproduced
- Gathered operation logs for SC
- Gathered device logs for SC
- Gathered the SMC logs both system logs and debug logs
After we have analyzed the gathered data along our upper level of support we have found that the TSL connection cannot be established between the SC and the FreePBX (10.0.2.52) and the FreePBX sends an alert with the handshake failure after the key exchange and then restarts the connection as it can be seen below:
The root cause of this issue is because of the SIP transport layer protocol set to TLS instead of UDP on the SC when adding a zone configuration page:
After changing the SIP transport layer protocol form the zone adding configuration page of the SC the call worked.