Here is the problem:
So I creating a new feature code to Transfer to Voicemail: _7XX
So when I have Inbound Route set to Hunt List instead of IVR I can't forward incoming call to VM. However, when the call reaches IVR (either no one answers in the specified time and it fails over to IVR or I remove the Hunt List) then goes to an extension I can then answer the call and forward to VM using the feature code above. Why this works only when a call goes thru the IVR is nonsense.
THIS DOESN'T WORK
Incoming Call -> Hunt List (Ext 11 and 14) -> Ext 11 Answers and tries to send to Ext 12 VM (Transfer Blind 712 Transfer)-> call goes silent
THIS WORKS
Incoming Call -> IVR -> Select Ext 11 -> Ext 11 Answers and tries to send to Ext 12 VM (Transfer Blind 712 Transfer) -> this works
On the call that works:
-- Executing [s@macro-tl-transfer-to-voicemail:3] VoiceMail("SIP/4.68.250.148-00000924", "12@default-FluentStream,") in new stack
On the one that doesn't:
-- Executing [s@macro-tl-transfer-to-voicemail:3] VoiceMail("Local/11@from-inside-FluentStream-e846;2", "12@default-FluentStream,") in new stack
The problem in the code is here in channel being transferred to macro tl-transfer-to-voicemail:
The macro is trying to transfer the local channel to voicemail, when it should be transferring the SIP/4.68.250.148-0000092b channel.
Has anyone resolved the bug issue regarding the macro transfer-to-voicemail?
Thanks,
Doug Aumont
As exciting as Asterisk 1.0
As exciting as Asterisk 1.0 would be ;), it's Asterisk 1.6.2.6 on the latest TL MTE 6.0.1.80.
As for the name, our SIP provider uses a SBC media gateway model for PSTN termination that happens from multiple locations. Changing configuration to address this doesn't seem to change the above issue.
Anyone run into this before, by chance?
Doug
its yet another chan_local
its yet another chan_local bug which seems to have cropped in yet again. Most likely because of the /n switch that is happening in macro-ringgroup-base. Why dont you re-create your huntlist using device based ring groups and give that a try. There was another previous chan_local bug around 6.0.1.73 from calls transferred to an extension but not timing out to VM because ARG2 went from the extension # of the mailbox to the RINGGROUP_TIMEOUT value instead which was failing on invalid mailbox number. Using deviced based ring groups will turn a dialplan that looks like...
macro(huntlist) -> macro(tl-ringgroup-base) -> dial(local/ext) --fork--> dial(sip/ext)
to
macro(huntlist) -> dial(sip/ext)
Once again excellent work
Once again excellent work Erik. Just to close the loop for everyone, switching to a device-based ring group solved the issue. That may have some other implications for us, but we haven't run into anything yet.
Thanks again. I appreciate it.
i dont know doug.. are you running a 10yr old version of pbx manager on asterisk 1.0? how are we supposed to know?
also your sip trunk is setup wrong.. showing an ip instead of a name is clear indication that your inbound settings dont get parsed.