Hi list! I'm using Asterisk 13.14.1 from Debian 9 repositories. The provider is Deutsche Telekom und Messagenet (just for receive). I can call and receive calls, but I have a little problem: there is a "delay" of about 1-1,5 seconds between the time the voice is sent and the time when the voice is received, so that it happens very often that the peer does not get my voice and try to repeat the question, then it get my voice, and breaks the question, and so on... This delay happens on every peer, Deutsche Telekom and Messagenet, so I think the problem is NOT by the Provider, but in my configuration... Can someone suggest me where can I search the problem? Thanks Luca Bertoncello (lucabert at lucabert.de)
On Tuesday 03 December 2019 at 19:28:19, Luca Bertoncello wrote:> Hi list! > > I'm using Asterisk 13.14.1 from Debian 9 repositories. > The provider is Deutsche Telekom und Messagenet (just for receive). > > I can call and receive calls, but I have a little problem: there is a > "delay" of about 1-1,5 seconds between the time the voice is sent and > the time when the voice is received, so that it happens very often that > the peer does not get my voice and try to repeat the question, then it > get my voice, and breaks the question, and so on... > > This delay happens on every peer, Deutsche Telekom and Messagenet, so I > think the problem is NOT by the Provider, but in my configuration... > > Can someone suggest me where can I search the problem?I would firstly look at whether your Asterisk box is doing transcoding - converting from oe codec (supported by your phones) and another codec (supported by the provider) because no codec can be found in common between the two. Secondly I would put a full packet sniffer (by which I mean collect all the RTP data as well as SIP) on each of your interfaces (internal and external) to see whether the delay really is happening inside your Asterisk server - if you see RTP data on your internal interface, then appearing 1-1.5 seconds later on the external interface, and vice versa, then you know the delay is inside your system. No point in making such an assumption only to find out it's someone else doing the transcoding and introducing the delay there :) Hope that helps, Antony. -- Tinned food was developed for the British Navy in 1813. The tin opener was not invented until 1858. Please reply to the list; please *don't* CC me.
Am 03.12.2019 um 19:57 schrieb Antony Stone: Hi Antony, thank you for your answer.> I would firstly look at whether your Asterisk box is doing transcoding - > converting from oe codec (supported by your phones) and another codec > (supported by the provider) because no codec can be found in common between > the two. > > Secondly I would put a full packet sniffer (by which I mean collect all the RTP > data as well as SIP) on each of your interfaces (internal and external) to see > whether the delay really is happening inside your Asterisk server - if you see > RTP data on your internal interface, then appearing 1-1.5 seconds later on the > external interface, and vice versa, then you know the delay is inside your > system.I'm really not an expert on Asterisk... Could you please say me HOW can I check the codecs? I tried to get the information of the channel: bpi*CLI> sip show channel p65551t1575398506m6025c4749452s2 * SIP Call Curr. trans. direction: Incoming Call-ID: p65551t1575398506m6025c4749452s2 Owner channel ID: SIP/pbxanika-0000021e Our Codec Capability: (alaw) Non-Codec Capability (DTMF): 1 Their Codec Capability: (ulaw|gsm|alaw|amr) Joint Codec Capability: (alaw) Format: (alaw) T.38 support No Video support No MaxCallBR: 384 kbps Theoretical Address: 217.x.x.x:5060 Received Address: 217.x.x.x:5060 SIP Transfer mode: open Force rport: Auto (No) Audio IP: 217.y.y.y (local) Our Tag: as45e11359 Their Tag: h7g4Esbg_p65551t1575398506m6025c4749452s1_206873930-910452977 SIP User agent: Username: 550293777072-0001 Peername: pbxanika Original uri: sip:sgc_c at 217.x.y.z Caller-ID: +4917711111111 Need Destroy: No Last Message: Rx: ACK Promiscuous Redir: No Route: <sip:217.x.y.z;transport=udp;lr> DTMF Mode: rfc2833 SIP Options: timer Session-Timer: Inactive Transport: UDP Media: RTP Maybe it helps to find the problem? Thanks Luca Bertoncello (lucabert at lucabert.de)
Am 03.12.2019 um 19:28 schrieb Luca Bertoncello: Hi again> This delay happens on every peer, Deutsche Telekom and Messagenet, so I > think the problem is NOT by the Provider, but in my configuration...Maybe I got the solution... I see, that I had the jitter buffer active. As I deactivated it, I have no delay anymore. Unfortunately is the audio quality now a little bad than with the jitter buffer... Any suggestion how can I improve the audio quality without add the delay? Thanks Luca Bertoncello (lucabert at lucabert.de)
On Wednesday 04 December 2019 at 07:37:51, Luca Bertoncello wrote:> Am 03.12.2019 um 19:28 schrieb Luca Bertoncello: > > Hi again > > > This delay happens on every peer, Deutsche Telekom and Messagenet, so I > > think the problem is NOT by the Provider, but in my configuration... > > Maybe I got the solution... > I see, that I had the jitter buffer active. As I deactivated it, I have > no delay anymore. > Unfortunately is the audio quality now a little bad than with the jitter > buffer... > > Any suggestion how can I improve the audio quality without add the delay?1. Try using codec GSM (which is pretty good quality but lower bandwidth than alaw, which is currently the only one you are offering). 2. What is the bandwidth (upstream is more important than downstream) of your Internet connection? Antony. -- Why is "dylexia" so difficult to spell, and why can I never remember "aphasia" when I want to? Please reply to the list; please *don't* CC me.