8018 phone audio problem in Connect 2.X

Post Reply
Euti
Member
Posts: 7
Joined: 12 Mar 2018 08:18

8018 phone audio problem in Connect 2.X

Post by Euti »

Good morning, I am writing to you in the forum because we are having audio loss problems in 8018 telephones. The telephones are connected to a dedicated switch and the switch directly connected to a FTTO also dedicated only to voice. The problem happens to us since we passed the client of an R8 to a connect with the 8018 telephones from the first day. We have already changed the switch for a new one and we have separated the voice and data network. In the traces that we are taking from the operator of the SIP trunk and the input of the connect we see that there are some RTP packages marked as "WRONG TIMESTAMP", in the trace if you hear in the whireshark almost no loss of audio is appreciated but when reaches 8018 makes the loss of audio is very large. This problem of loss of audio if the client we put a 4029 does not happen and we have had to replace them provisionally. Has any of you happened or do you know what it could be?
The problem is being reproduced in another client with the same scenario for what we suspect is a problem with the 8018 telephones or the CONNECT version. I would appreciate any help. Thank you very much.
Euti
Member
Posts: 7
Joined: 12 Mar 2018 08:18

Re: 8018 phone audio problem in Connect 2.X

Post by Euti »

Good afternoon, I've been drawing traces and I've seen that the loss of audio occurs when the 8018 phone makes a request for RTCP protocol, just after a ping request error occurs and at that moment the voice is being lost in the phone. The RTCP attribute parameter in SDP is disabled, so it is the phone that is sending it. We have confirmed that the same failure is reproduced in a model with R10 and 2.2 so everything points to an internal configuration problem of the 8018 phone.
User avatar
KoenC
Member
Posts: 48
Joined: 18 Feb 2015 10:38
Location: Belgium

Re: 8018 phone audio problem in Connect 2.X

Post by KoenC »

Which release are you running on the OXO? Only R2.2 supports 8018 (also see release note: TC2308).
Can you add the traces?

Good luck !
If I'm ever on life support, unplug me. Then plug me back in, see if that works...
Euti
Member
Posts: 7
Joined: 12 Mar 2018 08:18

Re: 8018 phone audio problem in Connect 2.X

Post by Euti »

Good morning, the bug is reproduced in all the versions of oxo connect, the tests are done in OXO Connect R2.2 / 023.001 and it happens in two clients that we have with these versions and it also happens in a model that we have mounted empty in our workshop. KoenC you are absolutely right terminals only work in connect 2.2 but it is also true that they work from R9 detected with 8028. This test in older versions we have done to see if the phone behaves in the same way and I can tell you that too loses in audio. I save or copy the traces so you can see it. Thank you.
Euti
Member
Posts: 7
Joined: 12 Mar 2018 08:18

Re: 8018 phone audio problem in Connect 2.X

Post by Euti »

Good morning again, so you can see when the audio is lost I copy the lines of the trace. I clarify that this only happens with the 8018 model connect it in any version 2.2 that is.

13967 65.698421 185.190.101.103 212.34.139.3 RTCP 234 Extended report (RFC 3611) Sender Report Source description
13968 65.698479 212.34.139.3 185.190.101.103 ICMP 262 Destination unreachable (Port unreachable)
User avatar
KoenC
Member
Posts: 48
Joined: 18 Feb 2015 10:38
Location: Belgium

Re: 8018 phone audio problem in Connect 2.X

Post by KoenC »

Hi Euti,

Did you connect the 8018 phones NOE IP or SIP to your telephone system? Following to that (if connected by SIP); PBX is configured for SIP or H.323?

The Extended report (XR) blocks are TCP packets being used by many applications, and often by voice applications that use RTP and RTCP.
These packets contain reporting, testing and netwerk information about the packets themselves.
These packets can cause ports on the firewall to open or close (therefore they can block RTP and RTCP streams).

For this, it would be easier if you provided the whole trace (pcap) or tcp dump...
It can be easier to check the ports / packet types used during the signalling.
Not only for me, but for the whole community to help you...
Good Luck.
Greets
If I'm ever on life support, unplug me. Then plug me back in, see if that works...
Post Reply

Return to “MAIN”