I am using FreePBX 12.0.76.6 and am unable to dial 0800 (tollfree) numbers in Sao Paulo Brazil without first dialing ‘11’ which is the area code for Sao Paulo where I live.
I think this is a simple fix using a dial plan, so that whenever anyone dials 0800, the system automatically prefixes the 11 for me. However, when I tried this in the Outbound route, by adding 11 into the prepend field, and 0800 into the Match Pattern field.
As I understand it, anyone dialing 0800 would then automatically have 11 added to the call, which would then work. However, this does not seem to be working.
Any ideas what I am doing wrong, or what extra information I can provide to help get this troubleshooted?
If your route contains another Match Pattern that would match 0800 XXX XXXX (without a prepend), that may be taking priority. Create a separate Outbound Route with Match Pattern 0800X. and Prepend 11, using the same trunk sequence as the ‘regular’ route, then drag the new route so it comes before the conflicting on.
Also, if you are using Extension Routes or Class of Service, confirm that you aren’t blocking the new route.
If you still have trouble, post a log of an attempted toll-free call.
Many thanks @Stewart1 - I think I was doing the Dial Pattern incorrectly. I have now set it up as follows on the outbound route for the local provider, with the 0800X as the dial pattern to prepend to.
I have nothing setup on the trunk for this provider (Life Sip) but I don’t think I need anything on the Trunk.
So - having made the change, it was adding the 11 correctly, but the provider is saying it is not needed. I have now created a new Outbound Route with match pattern of 0800X. without the prepend and will test again. I then placed this as the first of the 3 outbound routes and only using the Trunk for Life-Sip who is the local provider.
As I’m not very familiar with Brazil numbering and know nothing about Life-Sip, here are some general comments; you’ll have to research the details.
When you are using failover (you show routing to Skype if Life-Sip fails to respond or rejects the call), you may need to do some rewriting in the trunk instead of the route, for example if Skype does not accept the 110800 format and wants something different.
If you permit access to 3-digit short codes, note that Z matches 1-9, so e.g. 100 (Human Rights Secretariat) would not be accepted.
If you want to allow international calling, you’ll need a separate pattern for that.
Likewise for non-geographic 0300 numbers (though you probably want to block premium rate calls).
On incoming calls, you may need to rewrite the format of some numbers to be the same as what users would dial, so that redialing from history and saving contacts works properly.
Thanks - that makes sense. I could see in the logs that the Life-Sip provider was busy, and it was then trying Skype Sip, which I use for international calls mostly.
I then did what you suggested and created the new Outbound Route just for 0800 calls, and put this at the top of the list, so it will not even try to failover.
Hopefully I should now see more clearly in the logs what is happening, and will post them here as soon as someone has tested.
So this is the log for a test call, and if I am reading this correctly, the provider is not passing the call on because they are congested?
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
-- Called SIP/Life-Sip/08000102570
-- SIP/Life-Sip-0000010c redirecting info has changed, passing it to SIP/209-0000010b
-- Got SIP response 486 "Busy Here" back from 104.131.39.137:5060
-- SIP/Life-Sip-0000010c is busy
== Everyone is busy/congested at this time (1:1/0/0)
-- Executing [s@macro-dialout-trunk:23] NoOp("SIP/209-0000010b", "Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 17") in new stack
-- Executing [s@macro-dialout-trunk:24] GotoIf("SIP/209-0000010b", "1?continue,1:s-BUSY,1") in new stack
-- Goto (macro-dialout-trunk,continue,1)
-- Executing [continue@macro-dialout-trunk:1] NoOp("SIP/209-0000010b", "TRUNK Dial failed due to BUSY HANGUPCAUSE: 17 - failing through to other trunks") in new stack
-- Executing [continue@macro-dialout-trunk:2] Set("SIP/209-0000010b", "CALLERID(number)=209") in new stack
-- Executing [08000102570@from-internal:7] Macro("SIP/209-0000010b", "outisbusy,") in new stack
-- Executing [s@macro-outisbusy:1] Progress("SIP/209-0000010b", "") in new stack
-- Executing [s@macro-outisbusy:2] GotoIf("SIP/209-0000010b", "0?emergency,1") in new stack
-- Executing [s@macro-outisbusy:3] GotoIf("SIP/209-0000010b", "0?intracompany,1") in new stack
-- Executing [s@macro-outisbusy:4] Playback("SIP/209-0000010b", "all-circuits-busy-now&pls-try-call-later, noanswer") in new stack
-- <SIP/209-0000010b> Playing 'all-circuits-busy-now.ulaw' (language 'cambuipbx')
> 0x7fb3487d9e70 -- Probation passed - setting RTP source address to 10.10.5.12:5004
-- <SIP/209-0000010b> Playing 'pls-try-call-later.ulaw' (language 'cambuipbx')
-- Executing [s@macro-outisbusy:5] Congestion("SIP/209-0000010b", "20") in new stack
[2018-12-05 15:39:22] WARNING[5418][C-00019e27]: channel.c:4861 ast_prod: Prodding channel 'SIP/209-0000010b' failed
== Spawn extension (macro-outisbusy, s, 5) exited non-zero on 'SIP/209-0000010b' in macro 'outisbusy'
== Spawn extension (from-internal, 08000102570, 7) exited non-zero on 'SIP/209-0000010b'
-- Executing [h@from-internal:1] Hangup("SIP/209-0000010b", "") in new stack
== Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/209-0000010b'
The line -- Called SIP/Life-Sip/08000102570
shows what was actually sent to the trunk and it appears that the 11 prepend was not added.
Recheck all your Outbound Routes to see why this didn’t happen. If you can’t spot the trouble, enable (in Advanced Settings) NoOp Traces in Dialplan and the log will then show what route was selected for the call.
Thanks - the prepending of 11 to the 0800 number was apparently a red-herring, and provider is now saying I do not have to do this, hence I removed it.
So, it looks like the number is being dialed correctly, and is being passed to the provider, but the provider is giving a busy response rather than processing the call?
-- Got SIP response 486 "Busy Here" back from 104.131.39.137:5060
-- SIP/Life-Sip-0000010c is busy
Anyway - this really looks like the issue is with the provider. The IP giving the SIP response of ‘Busy Here’ is Digital Ocean, and the provider confirmed that is where they host their services. It looks like the 0800 is being passed correctly, but the SIP provider is the issue.
Many thanks for your support on this @Stewart1 - I will update this once the provider gets back to me.
Issue was confirmed as being with the provider - 0800 is now working correctly, and I am using a new dia pattern just for 0800 that prepends 55 when someone dials 0800, as requested by the provider.
