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?
Данный сайт есть в английской версии. Желаете ли Вы перейти на английскую версию?
Device type: VP9650 & vPoint
Current firmware version: V200R001C30SPCd00.
What is the issue: Customer reported that has audio issue, encounter dead air, while he is dialing the MCU's IVR from a vPoint VOIP software, but if he make an Ad-hoc conference in the SMC 2.0 and call from vPoint directly the conference ID, he has audio in calls.
What I have done: Asked him for wireshark captured with full RTP and signaling streams onto the MCU and vPoint side to make a comparison and to see if the RTp packets are sent or not from the MCU's IVR towards vPoint.
After a comparison on the captures tooked onto the MCu leg and on the vPoint leg, an encryption method was discovered on the RTP level.
Below we can see the RTP strings filtered with: h225||h245 command in whireshark's filter area. Using this string you can see all the H.245 interogation when a device is dialed and with which audio codec capability.
Below is a message body were was identified that the RTP packet is encrypted. That means that this packet is not decoded and, in this scenario, the MCU sent it encrypted to the vPoint, thus the issue with no audio:
Below is a message body of an RTP packet which is not encrypted and was successfuly sent by the MCU to the vPoint and the MCU's IVR was heard without any problem:
We have found out that in the non-working capture, the MCU is actually sending the packets towards the vPoint as per below, which means that the packets are transmited:
But we have also found a slight difference between the working capture and the non-working one. We have found out that the MCU encrypts the RTP streams and this might be the issue, therefore the packets are not sent decoded towards vPoint and the vPoint cannot handle the decoding of the encrypted RTP packets and this is causing the “dead air” (no audio).
The solution is to access the web interface of the MCU and go to Settings -> Conference -> Policy for Scheduling and Controlling a Conference -> and make sure that the “Default encryption type” is set on No encryption instead of Auto encryption as per below: