Choppy sound on SIP channel, only when playing music on hold

Asterisk Asterisk Support
1

Hello people,
I setup an * box (brand new Dell Core 2 Duo server) for a call center and it is working well but there is still a problem and I would like to have your opinion about.
When a call comes in it goes to a queue and a music on hold is played until an agent answer, when the call comes in from a sip channel connected to an Audiocodes E1 gateway the music on hold is of good quality and when the agent answer the audio between the caller and the agent is good too; when the call comes in from a sip channel, connected to our ITSP, the quality of the music on hold is not good, the sound is choppy but the quality of the conversation between the caller and the agent is good.
I think this is caused by the more jittering present in the connection with the ITSP, when the call is bridged to the music on hold * does not use a jitter buffer but when the call is bridged with a sip phone the phone uses the jitter buffer, this could explain why there is a difference in the quality of the audio, so force the use of the jitter buffer in the sip channel, with the jbforce option of sip.conf, would be of help to have a better music on hold ?

Thanks.

Regards.

Marco Bruni

2

If you are using asterisk 1.4 I would recommend you taking a look at

[options]
internal_timing = yes

option in the /etc/asterisk/asterisk.conf

Otherwise jitter of outgoing RTP stream when playing MoH depends on jitter of incoming stream. Weird. More on this - bugs.digium.com/view.php?id=5374

3

Dimaz, your pointer to the bug was right, that’s the problem I’m having, the issue is not related to jittering, its related to the rtp timing, I don’t use any zaptel hardware, so do you think using the ztdummy and the parameter internal_timing will solve the problem ?
By the way I’ll try…

Thanks for the help :smile:

Regards.

Marco Bruni

4

Ztdummy loaded, internal_timing set to yes, asterisk restarted but no difference…choppy music on hold :frowning:

I’m using * 1.4.4 so the patch related to bug 5734 should be already in, right ?

5

Well, I had choppy MoH with remote clients (and good sound with local). After switching to internal_timing MoH for remote clients were fixed. So I think yes, it will help you too. I do not have hardware providing timing too.

PS: to me, internal_timing = yes must be default because “other” mode where outgoing RTP depends on presense of incoming is just very strange to me…

6

yes, 1.4.4 is patched already.

make sure you uncomment not only “internal_timing = yes” but also a “[options]” section header too. It was issue for me :smile:

7

You’re right, the first try I did it was commented, now it is working :smile: but I had to restart *, a reload was not enough.

Thanks again.

Regards.

Marco Bruni

8

Thanks for the above! I had Asterisk 1.4.7.1. This solution didn’t work. I downloaded 1.4.4 as you mentioned it worked, and voilá! It works now!

9

I have the same issue here!! I have the ZTDummy compiled
Will

[options]
internal_timing = yes

Will this works for Asterisk ABE-B.1-3 ?? I will try it anyway but won’t have a chance to test till a few hours later

I wish Digium support would know about this bug. I called them and had a rep that kept on spinning me in circles telling me either its a server performance or network performance issue when I told them it’s a duo core 3ghz with only 1 call on a completely private test network with no other traffic.

EDIT: I tried this and it did NOT work in ABE-B 1.3. The MOH sounds bad still.