SOLVED Help with Anveo Direct outbound trunk.

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
I am new to PIAF and this forum. I have a trunk setup for outbound calls through Anveo Direct. It is working good except when I call certain numbers. It gives me a message saying "The number you have dialed has not been recognized. Please try again." I also have a Voipo.me trunk for backup. If I put the Voipo.ms trunk in my outbound route instead of the Anveo route I can call the same numbers just fine.
Any ideas what could be wrong?
Thanks
 

atsak

Guru
Joined
Sep 7, 2009
Messages
2,381
Reaction score
436
They're particular about caller ID. Make sure you're sending something valid (configure it on the trunk and force it to be sure). You can also look at the sip trace in their portal to see why they rejected the call.
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
They're particular about caller ID. Make sure you're sending something valid (configure it on the trunk and force it to be sure). You can also look at the sip trace in their portal to see why they rejected the call.

Thanks for the quick reply. I am sending a valid CID. I forgot to mention that the trouble calls do not show up in CDR on Anveo Direct. So I can't check sip trace. All my other call are showing up in Anveo Direct CDR.
 

atsak

Guru
Joined
Sep 7, 2009
Messages
2,381
Reaction score
436
Well that's weird. Post your trunk settings I guess. Trust you're using a static IP?
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
Yes it is weird. It has been doing this for a few days and now I just tested it several times again on one of the trouble numbers and it gives about 7-10 seconds of dead silence and then the call connects.o_O I do not have a static IP. My trunk settings are below. The first one is the one in my outbound route. The second I added to make it so my calls would not drop at 15 minutes.
Anveo trouble.pngAnveo trouble2.png
 

atsak

Guru
Joined
Sep 7, 2009
Messages
2,381
Reaction score
436
I guess the other thing to look at is the /var/asterisk/full log at one of the calls with the delay. You may need to turn on sip debug to capture what might be wrong.

I thought anveo direct required a static IP?
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
I guess the other thing to look at is the /var/asterisk/full log at one of the calls with the delay. You may need to turn on sip debug to capture what might be wrong.
How do I turn on sip debug? Like I said earlier I am new to PIAF. I have been playing with it for about a week. I was not sure about how to go about finding /var/asterisk/full log, but I found something in the GUI under reports/asterick logfiles. Is that what you are talking about or is the something different? I pasted some of it that did not seem right to me below.

Note the time it is taking on the last three lines in this section.
Code:
[2015-07-07 06:57:36] VERBOSE[25751][C-0000293a] pbx.c: -- Executing [s@macro-dialout-trunk:29] Set("SIP/111-00002985", "the_num=13152749050") in new stack
[2015-07-07 06:57:36] VERBOSE[25751][C-0000293a] pbx.c: -- Executing [s@macro-dialout-trunk:30] Dial("SIP/111-00002985", "SIP/[email protected],300,Tt") in new stack
[2015-07-07 06:57:36] VERBOSE[25751][C-0000293a] netsock2.c: == Using SIP RTP TOS bits 184
[2015-07-07 06:57:36] VERBOSE[25751][C-0000293a] netsock2.c: == Using SIP RTP CoS mark 5
[2015-07-07 06:57:36] VERBOSE[25751][C-0000293a] app_dial.c: -- Called SIP/[email protected]
[2015-07-07 06:57:49] VERBOSE[25751][C-0000293a] app_dial.c: -- SIP/sbc.anveo.com-00002986 is making progress passing it to SIP/111-00002985
[2015-07-07 06:57:51] VERBOSE[25751][C-0000293a] app_dial.c: -- SIP/sbc.anveo.com-00002986 answered SIP/111-00002985

Could it be that I have some codec settings wrong?
Code:
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] channel.c: Codec mismatch on channel SIP/111-0000298c setting write format to g729 from ulaw native formats (ulaw)
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] channel.c: Unable to find a codec translation path from (ulaw) to (g729)
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] chan_sip.c: Asked to transmit frame type g729, while native formats is (ulaw) read/write = ulaw/ulaw
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] chan_sip.c: Asked to transmit frame type ulaw, while native formats is (g729) read/write = ulaw/ulaw
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] channel.c: Codec mismatch on channel SIP/111-0000298c setting write format to g729 from ulaw native formats (ulaw)
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] channel.c: Unable to find a codec translation path from (ulaw) to (g729)
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] chan_sip.c: Asked to transmit frame type g729, while native formats is (ulaw) read/write = ulaw/ulaw
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] chan_sip.c: Asked to transmit frame type ulaw, while native formats is (g729) read/write = ulaw/ulaw
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] channel.c: Codec mismatch on channel SIP/111-0000298c setting write format to g729 from ulaw native formats (ulaw)
[2015-07-07 07:13:00] WARNING[25954][C-0000293e] channel.c: Unable to find a codec translation path from (ulaw) to (g729)

My IP is not static but it changes very infrequent. If or when it does change I will need to update it on the trunk in Anveo Direct for it to continue to work.
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
This is all you should need....

type=peer
host=sbc.anveo.com
port=5060
insecure=port,invite
canreinvite=yes
disallow=all
allow=ulaw

because Anveo doesn't proxy its audio stream you are being connected directly to the carriers. Different ones are chosen, based on your rules, for different numbers.

Without the last two lines:

disallow=all
allow=ulaw

you appear to be running into codec issues depending on where you call.
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
This is all you should need....

type=peer
host=sbc.anveo.com
port=5060
insecure=port,invite
canreinvite=yes
disallow=all
allow=ulaw

because Anveo doesn't proxy its audio stream you are being connected directly to the carriers. Different ones are chosen, based on your rules, for different numbers.

Without the last two lines:

disallow=all
allow=ulaw

you appear to be running into codec issues depending on where you call.


Thanks for the reply. I copied your code and replaced what I had with it. I did a test call to one of the trouble numbers and this time I got message and the call did not go through. Below is part of the log for that call. I do not know what it means though.
Code:
[2015-07-07 08:46:29] VERBOSE[27323][C-00002943] netsock2.c: == Using SIP RTP TOS bits 184
[2015-07-07 08:46:29] VERBOSE[27323][C-00002943] netsock2.c: == Using SIP RTP CoS mark 5
[2015-07-07 08:46:29] VERBOSE[27323][C-00002943] app_dial.c: -- Called SIP/[email protected]
[2015-07-07 08:46:30] VERBOSE[27323][C-00002943] app_dial.c: -- SIP/sbc.anveo.com-00002996 is making progress passing it to SIP/111-00002995
[2015-07-07 08:46:39] VERBOSE[27323][C-00002943] app_macro.c: == Spawn extension (macro-dialout-trunk, s, 30) exited non-zero on 'SIP/111-00002995' in macro 'dialout-trunk'
[2015-07-07 08:46:39] VERBOSE[27323][C-00002943] pbx.c: == Spawn extension (from-internal, 13152680870, 5) exited non-zero on 'SIP/111-00002995'
[2015-07-07 08:46:39] VERBOSE[27323][C-00002943] pbx.c: -- Executing [h@from-internal:1] Hangup("SIP/111-00002995", "") in new stack
[2015-07-07 08:46:39] VERBOSE[27323][C-00002943] pbx.c: == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/111-00002995'
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
The trace looks fine. Do some more testing. There may be an Anveo Sip Trace for the call since its going further then it was before.
Also go onto the Anveo site and do a call simulation (Outbound Serve->Configure outbound service->Call simulation) to make sure that you have possible alternative routes to a given number. The one it's choosing could be bad for that number.

PM me the number if you want me to try it
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
The trace looks fine. Do some more testing. There may be an Anveo Sip Trace for the call since its going further then it was before.
Also go onto the Anveo site and do a call simulation (Outbound Serve->Configure outbound service->Call simulation) to make sure that you have possible alternative routes to a given number. The one it's choosing could be bad for that number.

PM me the number if you want me to try it
The one trouble number is for our ISP Slic Network Solutions. I can give that one out. It is 1315 274 9050. When it works at night you get a recording saying they are closed. In the day time one of their reps answer. Most of the time I get the number not recognized message. Last night for a little it was connecting but with a big delay.

This afternoon I got an idea. All the trouble numbers have fiber optic phone through Slic Network Solutions. They are also our ISP. Could that have something to do with this strange problem? I have my PBX hosted here on site on a dedicated machine.

If I send the same number to the same Anveo Direct trunk from Anveo Retail's outbound call route feature the call goes through fine. So I do not think it is a route problem on Anveo Direct. But who knows maybe I should try blocking some routes on Anveo Direct.
 

atsak

Guru
Joined
Sep 7, 2009
Messages
2,381
Reaction score
436
Yes, that's likely it. They probably haven't got good interconnect arrangements (or whatever) and Anveo has problems delivering to them. Anveo direct is pretty cheap, so if Slic charges a lot to terminate the call Anveo Direct might not find a carrier for it.
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
I get the same "not recognized" result when the call go's out on Level 3 (15) but if I eliminate Level 3 as an option or put in a block for that number the call will go out on Verizon (12) without issue. The CDR lists which carrier number was used.

These kinds of things are not unusual. It could be pursued with Level 3 if you had a reason to do so otherwise it's easier to just use one of the other route choices. At least on Anveo you can isolate the issue and fix it. On other carriers you call them, they make a "change" that may fix that issue and then create another some some other number.
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
I get the same "not recognized" result when the call go's out on Level 3 (15) but if I eliminate Level 3 as an option or put in a block for that number the call will go out on Verizon (12) without issue. The CDR lists which carrier number was used.

These kinds of things are not unusual. It could be pursued with Level 3 if you had a reason to do so otherwise it's easier to just use one of the other route choices. At least on Anveo you can isolate the issue and fix it. On other carriers you call them, they make a "change" that may fix that issue and then create another some some other number.

It looks like it maybe is a route problem. I figured out for me it was trying to use routes 24 and 26. I blocked them and now it connects through route 3. I'll have to test the other trouble numbers latter and see if it fixed them to. I assumed it was not a route problem because it was connecting fine on routes 24 and 26 when I send the same number to the same Anveo Direct trunk from Anveo Retail's outbound call route feature.
 

marlur6

Member
Joined
Jun 28, 2015
Messages
33
Reaction score
0
They all work now.:) Apparently PIAF needs different routes for those numbers than Anveo Retail's outbound call route feature. Thanks everyone for your help.
 

Members online

No members online now.

Forum statistics

Threads
25,782
Messages
167,509
Members
19,203
Latest member
frapu
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top