Problems with Asterisk 1.4.17 and VoicePulse
ALL,
Just spoke with VoicePulse - they are having an issue with Asterisks 1.4.17 in particular.
The situation occurs only on outbound calls. If the called party (the callee) generates a DTMF code of any sort, it results in a long continuous beep of that particularly DTMF. I have tried this on our corporate conference calling line as well as on a simple cell phone. If the DTMF tone changes, the long continuous beep tone changes to match.
VoicePulse is hoping that 1.4.18 will resolve this issue.
ben
bwoo, i replied to the Incident E-mail I received as well.
rrichiez, Voice Pulse doesnt give g729, are you using g729 on the extension? Either way, no matter what codec, the problem will still happen. I'm using ulaw. I tried testing with g726 but actually- g726 doesnt work for me no matter what servers I use, for some reason.
Regarding the never-ending DTMF tones in asterisk 1.4, as a temporary workaround you can add the line, rfc2833compensate=yes to the peer details section of your VoicePulse trunk. This will prevent never-ending tones, but the tones may still not work 100% correctly. Our engineers are still working on a more permanent solution. I will update you with any additional information I come up with.
OK, after being away on business for a few days, I came back and tried out the rfc2833compensate=yes parameter. Like the engineer said, it doesn't always work 100%. Well, for me, it worked 0%. In fact, the tones were so whacky that the conference call provider (Intercall) didn't even realize that I pressed ANYthing!
I've run several trace routes, and it is returning the same thing ... looks like something is going wrong at opks.datacenter.fullcontrol.net!
traceroute to 204.9.78.182 (204.9.78.182), 30 hops max, 40 byte packets
1 h-68-167-44-129.nycmny83.covad.net (aaa.bbb.ccc.ddd) 1.180 ms 1.160 ms 1.287 ms
2 172.31.255.253 (172.31.255.253) 17.174 ms 20.563 ms 21.035 ms
3 192.168.31.57 (192.168.31.57) 19.801 ms 21.500 ms 23.688 ms
4 192.168.253.53 (192.168.253.53) 25.170 ms 27.114 ms 29.045 ms
5 unknown.Level3.net (63.209.170.233) 30.982 ms 32.680 ms 34.611 ms
6 ge-1-3-0-79.bbr1.NewYork1.Level3.net (4.68.16.65) 36.839 ms 16.585 ms 14.976 ms
7 so-0-0-0.mpls2.StLouis1.Level3.net (64.159.0.57) 41.780 ms 43.744 ms so-3-0-0.mpls1.StLouis1.Level3.net (64.159.0.49) 46.912 ms
8 ge-10-0.hsa2.StLouis1.Level3.net (64.159.0.66) 47.119 ms 48.856 ms 50.297 ms
9 AMERICAN-FIB.hsa2.Level3.net (4.79.252.2) 58.158 ms 60.095 ms 61.334 ms
10 afs.opks.fullcontrol.net (206.165.102.18) 63.789 ms 66.210 ms 67.910 ms
11 opks.datacenter.fullcontrol.net (204.9.72.166) 78.737 ms 79.457 ms 79.916 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
I had an issue with not being able to see the nyc. and sfo. voicepulse servers as well. For me, it was because I had my DNS set to the IP address of my router. This has always worked in the past with voicepulse, but with the newer VoicePulse modules I had to use OpenDNS - look for the option in the network settings in Trixbox. When using the IP address of my router for the DNS server, I could get to every other site I tried, but not the VP servers.
It is something to do with SRV records and DNS that my pea-sized brain cannot comprehend. But using the OpenDNS option worked for me.
Yes try using that. Looks like the problem starts here:
9 AMERICAN-FIB.hsa2.Level3.net (4.79.252.2) 58.158 ms 60.095 ms 61.334 ms
I don't know why it's doing that on Level3 though. Level3 is #1.
Heres my traceroutes from one of my clients using Covad:
traceroute to nyc.voicepulse.com.makari.com (204.9.78.182), 30 hops max, 38 byte packets
1 10.10.174.1 (10.10.174.1) 1.677 ms 1.724 ms 1.706 ms
2 (filtered for security reasons).nyc1.dsl.speakeasy.net (filtered) 2.270 ms 2.543 ms 2.498 ms
3 er1.nyc1.speakeasy.net (64.81.134.1) 11.367 ms 93.951 ms 9.753 ms
4 220.ge-0-1-0.cr2.nyc1.speakeasy.net (69.17.83.201) 9.387 ms 9.745 ms 8.510 ms
5 166.90.136.33 (166.90.136.33) 9.460 ms 8.600 ms 9.334 ms
6 vlan51.csw1.NewYork1.Level3.net (4.68.97.30) 19.134 ms 20.104 ms 18.046 ms
7 ae-62-62.ebr2.NewYork1.Level3.net (4.69.134.81) 10.433 ms 10.078 ms 18.406 ms
8 ae-2.ebr1.Chicago1.Level3.net (4.69.132.65) 39.318 ms 38.897 ms 36.016 ms
9 ae-1-55.bbr1.Chicago1.Level3.net (4.68.101.129) 30.331 ms ae-1-51.bbr1.Chicago1.Level3.net (4.68.101.1) 30.360 ms ae-1-53.bbr1.Chicago1.Level3.net (4.68.101.65) 30.274 ms
10 so-3-0-0.mpls1.StLouis1.Level3.net (64.159.0.49) 35.797 ms 37.029 ms so-0-0-0.mpls2.StLouis1.Level3.net (64.159.0.57) 34.934 ms
11 ge-10-0.hsa2.StLouis1.Level3.net (64.159.0.66) 35.593 ms ge-7-1.hsa2.StLouis1.Level3.net (64.159.4.130) 35.592 ms ge-10-0.hsa2.StLouis1.Level3.net (64.159.0.66) 35.565 ms
12 AMERICAN-FIB.hsa2.Level3.net (4.79.252.2) 40.473 ms 41.014 ms 40.271 ms
13 afs.opks.fullcontrol.net (206.165.102.18) 42.061 ms 42.693 ms 41.233 ms
14 opks.datacenter.fullcontrol.net (204.9.72.166) 41.964 ms 42.334 ms 41.565 ms
15 *
this is where it stops responding due to firewalls on their end, which is not a problem
No latency issues whatsover- no voice delay when we talk. No DTMF issues.
Here's from my house, same story:
1 ipcop (10.10.173.1) 1.429 ms 1.725 ms 1.799 ms
2 10.35.128.1 (10.35.128.1) 7.777 ms 13.167 ms 13.364 ms
3 dstswr2-vlan2.rh.nyk2ny.cv.net (67.83.220.162) 13.450 ms 13.577 ms 13.516 ms
4 r4-ge1-1-2.mhe.hcvlny.cv.net (67.83.220.133) 15.151 ms 15.431 ms 15.380 ms
5 rtr4-tg11-3.wan.hcvlny.cv.net (64.15.4.37) 30.640 ms 30.932 ms 30.879 ms
6 rtr4-tg10-1.in.nycmny83.cv.net (64.15.0.17) 16.482 ms 16.649 ms 16.473 ms
7 * * *
8 ge-2-1-0-89.bbr1.NewYork1.Level3.net (4.68.16.129) 59.373 ms ge-0-3-0-69.bbr1.NewYork1.Level3.net (4.68.16.1) 16.851 ms ge-2-1-0-89.bbr2.NewYork1.Level3.net (4.68.16.130) 42.419 ms
9 so-3-0-0.mpls1.StLouis1.Level3.net (64.159.0.49) 42.761 ms 42.754 ms so-0-0-0.mpls2.StLouis1.Level3.net (64.159.0.57) 42.164 ms
10 ge-10-0.hsa2.StLouis1.Level3.net (64.159.0.66) 41.790 ms 41.788 ms 41.429 ms
11 AMERICAN-FIB.hsa2.Level3.net (4.79.252.2) 56.740 ms 56.637 ms 56.260 ms
12 afs.opks.fullcontrol.net (206.165.102.18) 58.477 ms 54.688 ms 52.310 ms
13 opks.datacenter.fullcontrol.net (204.9.72.166) 61.400 ms 58.582 ms 59.398 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 *
Ignore hop #8 though- any traceroute we do from Cablevision always gets a delay right after we leave their servers, but causes NO issues to us, whether it's a ping, etc.
See if you can get close to these 2 traceroutes
What state are you located in?
I'm actually in NYC using Covad! So far, I'm not having an issue with voice. The only two probs that I'm experiencing is that (a) when my Lotus Notes does it replication, I get voice issues for about 10 secs. This is because my laptop is being plugged into my SPA-942 but I have not QoS set; and (b) when using Intercall, it won't accept my dtmf. It's not really a problem, I have a back up Trunk via Vitelity, and since the Intercall # is an 800 number, it doesn't cost me anything.
ben
I think you should just try using OpenDNS though if you want to get it fixed. Because Vitelity is worse when your a customer on the eastern coast. I am in the middle of dropping them. My numbers are waiting to be ported, see http://www.trixbox.org/forums/trixbox-forums/open-discussion/voip...
Also, what happens if one day you call a non toll free number and it requires you to enter DTMF digits?
If OpenDNS doesn't help, contact Voice Pulse. They have awesome customer service and can SSH into your system and try to fix it for you.
Hi All,
I have asked VoicePulse what servers they are recommending for use with their SIP service.
In the meantime, I recommend sticking to using "connect02.voicepulse.com" (or 03) unless there is a definitive answer from VoicePulse stating that a different server should be used.
I am aware that there have been recommendations to use "sip.voicepulse.com", but to the best of my knowledge, no one has yet gotten this to work.
When lookup up the SRV records for sip.voicepulse.com, I get the following:
;; ANSWER SECTION:
sip.voicepulse.com. 237 IN SRV 1 1 5060 calcium.voicepulse.com.
sip.voicepulse.com. 237 IN SRV 0 1 5060 niobium.voicepulse.com.
But I am unable to ping their corresponding IP addresses.
Hopefully, I'll hear back from VoicePulse soon and let you all know.
Back to the original poster:
I had the continuous DMTF problem you described with Asterisk 1.4.18, but not with 1.2.10, but only with a particular provider. This was using dmtfmode=inband on the trunk. Using dtmfmode=rfc2833 (which was my preference) on SIP trunk would not allow me to break DTMF on remote IVR's. Using 711 codec.
Resolution: If my Aastra 9133i phone was set to SIP Info, the problem occurred. Changed it to RTP (in the 9133i itself) and the problem was completely resolved. Did not need to use rfc2833compensate=yes.
Hope this helps if you are still having the problem.


Member Since:
2007-04-25