I have an new inbound number added to the system and it’s set to hit a new IVR setup then a user chooses the department (Extension) to call by selecting the number option. When the extension rings, it rings on the desk phone properly. When the Follow Me kicks in, it never rings the external cell phone and times out then goes back to the IVR as it’s set to do. I have set this up the same way my other IVR/extensions are done and they work fine. They ring the cell phone when Follow Me is used. This new number fails to do this. I add my working extension to a usable number on the new IVR and the extension rings but my cell phone doesn’t ring. When i call my main number to my extension the cell rings fine. any help would be greatly appreciated.
If i call the extension internally from another phone, the Follow Me cell forwarding works fine. It fails when a call comes from the outside to this new SIP # and forwarded to the extension from the IVR.
Make a failing cal. Go to Reports → Asterisk Logfiles (install that module if you don’t have it). If the log is long, paste it to http://pastebin.freepbx.org/ and post the link here.
Just guessing, the new number is with a new provider or in a new country and the caller ID is in a format that your outbound trunk provider doesn’t accept. See what appears on the desk phone when calling the new number. Or, in the Follow Me settings, use Change External CID Configuration to force a caller ID in a format that you know is good.
It shouldn’t be more than 30-40 lines. We don’t need everything in the log - just the stuff during the duration of the associated PID (the part in parenthesis) for the failed call.
here is the log info from when i made the call to the 800 #, i picked option 5 to ring extension 2230 then it should have called my cell using follow-me. thank you all for the help with this. All #'s i have come from Bandwidth across the same SIP trunk.
I took only a brief look at the log. It appears that you are calling from XXX9285 through the system to XXX9285. Your cell carrier probably interprets that as you trying to retrieve your own voicemail and therefore doesn’t ring the phone. This may not be your issue, but please make the test call from a different number and (if there is still trouble) repost the log.
I can see the trouble, but don’t know the cause. Line 404 of your log shows [2018-03-12 11:56:06] VERBOSE[17387][C-000000bc] pbx.c: Executing [s@macro-dialout-trunk:5] Set("Local/XXXXXXX9285@from-internal-000000b2;2", "DIAL_NUMBER=+1XXXXXXX9285") in new stack
So it’s trying to prepend +1 to a number which already has an initial 1.
Possibly you can work around this by putting your cell number in the follow-me as 10 digits (without the initial 1).
Otherwise, try to track down where / why the number is being incorrectly rewritten.
If you still have trouble I’ll try to take a closer look. Please post what number rewriting you are doing in the Outbound Route, the manipulation rules for the trunk and in any custom contexts.
BTW, if you post another log, please make the call from another number. People looking at it won’t actually read 500+ lines, we search for what seems relevant. Having the same number for caller and callee makes that tougher.
If you don’t have anything better, use Skype or Viber on your cell to call your 800 number (both are free to US toll-free and don’t require credit).
trunk - no. they are from the Outbound Routes section
Yes, the outbound route changes the number to be an 11-digit with a + at the beginning as listed above
followme is a 10-digit with a hash (#) at the end
I’m very puzzled. Line 287 of your new paste shows: [2018-03-12 12:35:57] VERBOSE[22876][C-000000bf] pbx.c: Executing [2230@followme-sub:38] Macro("SIP/from-trunk-sip-bandwidth-com-00000171", "dial,30,HhTtrI,XXXXXXX9285#") in new stack
I would have thought that the value ending in # would have been been directly copied from the follow-me settings. Does the unredacted log indeed show 1+ areacode + number + #? And does the follow-me setting have areacode + number + #?
I’m not sure that I understand. Are you saying that the log had e.g. dial,30,HhTtrI,2123459285# but you replaced it with dial,30,HhTtrI,XXXXXXX9285# , i.e. you replaced six digits with 7 X’s ? If so, then my analysis was wrong and I’ll look further. Please fix the log so redacted information preserves the character count.
Did you try pointing the ‘new’ number to the ‘old’ IVR to confirm that the problem is related to the DID?
correct. i replaced the numbers with 7 X’s to mask the numbers in the log which shows the real #'s on my side. and the number on my side is a 10-digit in the log.
This is mostly a guess, because I don’t have a SIP trace, don’t have a working case for comparison and don’t trust the redaction:
I suspect that the new number is delivering a 10-digit caller ID (I have a toll-free from Vitelity that does that) and either Bandwidth or their upstream is rejecting the call. Take a look at your CDRs and see whether the CallerID field looks different for calls to the new incoming number vs calls from the same source to an old incoming number.
If that’s not it, we’ll need some SIP traces to investigate further.