Skip to main content

Voicemail not really in disabled state

Posted by duc on Mon, 01/07/2008

Hi Thirdlane users,

I use thirdlane to create and manage my Asterisk users. By default I not use the voicemail. After the creation of the users, I go to the thirdlane user interface and desactivate the voicemail.

Sometimes, my customers receive voicemail even when the status of the voicemail is on disabled. I wonder how I can fix this or if I can delete the voicemail as a workaround., Will it compromise the Thirdlane integrity ? Any idea how to have a better comportement ?

Thanks in advance, Cheers, Duc.


Submitted by eeman on Wed, 01/09/2008 Permalink

generally speaking having no entry in voicemail.conf will not cause problems for stdexten macros that send to a non-existent voicemail box. But i have not specifically tested this with thirdlane.

Submitted by mattdarnell on Tue, 01/15/2008 Permalink

Duc,

In the old days, we would record re-order tone for the users greeting.

No one will stay on the line & listen to 2 minutes of re-order tone.

With Asterisk you can copy the file into the user's directory.

-Matt

Submitted by eeman on Wed, 01/16/2008 Permalink

thats precisely what he is suggesting. He is suggesting that if you upload a 2min reorder (fast busy?) tone as the busy and unavailable messages that no one in a sane mind would wait around to see if they get a beep to begin recording.

As far as i can tell, the only time the enable/disable option is checked is when the userextension script is called. If, for some reason, they are arriving to the voicemail box as a result of another script or application such as a queue, hunt group, etc; the value could go ignored.

have you considered changing the email account to something mapped to /dev/null and enable delete=1 so that the recording is deleted after the email is sent to a recipient that never exists?

In an /etc/aliases sendmail world you could just create an alias to /dev/null .. such as

testuser: /dev/null

then run 'newaliases' to rehash the table.

any mail sent to testuser@localhost or testuser@localhost.localdomain would go into a bit bucket.

In reply to by duc

Submitted by duc on Thu, 01/24/2008 Permalink

Thanks eeman and mattdarnell,

I like the idea of the fake tone. I think it's better than destroy voicemail for my customers. But this two answers is not reals solutions. I think there is a issue in the Thirdlane base script. I've tested that eeman mention and that's right, the voicemail statuts is only checked in userexten. I think that the userexten must be called from the other macro that dial an extension.

Any options on this ?

Cheers, Duc

Submitted by gelo on Wed, 02/13/2008 Permalink

I'm experiencing this same issue. I'm using multitenant, and when the call enters into userexten-base it tries to get the values of some variables from the database. But these values are always empty, although I know they were set as I can see it with 'database show'. So I think the way userexten script is getting these values is wrong, as it does not have in account the different tenants.

Do you know how I can modify this to work? Thanks

Submitted by gelo on Wed, 02/13/2008 Permalink

Take a look at this

-- Executing Goto("IAX2/ceilugo-11", "from-outside-redir|0250020|1") in

new stack

-- Goto (from-outside-redir,0250020,1)

-- Executing Set("IAX2/ceilugo-11", "DIALED_PUBLIC_NUMBER=0250020")

in new stack

-- Executing Set("IAX2/ceilugo-11", "DIALED_NUMBER=0250020") in new

stack

-- Executing Set("IAX2/ceilugo-11", "status=1") in new stack

-- Executing GotoIf("IAX2/ceilugo-11", "1?7") in new stack

-- Goto (from-outside-redir,0250020,7)

-- Executing GotoIfTime("IAX2/ceilugo-11",

"*|*|*|*?from-outside-0250020-tl-allhours-500|s|1") in new stack

-- Goto (from-outside-0250020-tl-allhours-500,s,1)

-- Executing Set("IAX2/ceilugo-11", "tenant=500") in new stack

-- Executing Set("IAX2/ceilugo-11", "CDR(userfield)=500") in new stack

-- Executing Set("IAX2/ceilugo-11", "MOH=default-500") in new stack

-- Executing GotoIf("IAX2/ceilugo-11", "0?nomoh") in new stack

-- Executing SetMusicOnHold("IAX2/ceilugo-11", "default-500") in new

stack

-- Executing Macro("IAX2/ceilugo-11", "tl-userexten|SIP/200-500||")

in new stack

-- Executing Set("IAX2/ceilugo-11", "DIALED_NUMBER=s") in new stack

-- Executing Macro("IAX2/ceilugo-11",

"tl-userexten-base|SIP/200-500||") in new stack

-- Executing GotoIf("IAX2/ceilugo-11", "1?set_options") in new stack

-- Goto (macro-tl-userexten-base,s,7)

-- Executing Set("IAX2/ceilugo-11", "OPTIONS=rtT") in new stack

-- Executing Set("IAX2/ceilugo-11", "THISEXT=TL/500-s") in new stack

I call from outside. The 0250020 is redirected to user extension 200 from tenant 500. But the userexten script sets DIALED_NUMBER=s, so when it tries to get values from database they are wrong. Is there any non-intrusive fix, please?

Submitted by eeman on Wed, 02/13/2008 Permalink

I discovered this via a different problem by which if i redirected an inbound call to a specific DID directly to a analog Zap channel 's' would show up as the destination number in the CDR. Bear in mind that it is not CALLED_NUMBER that writes this value to the database but rather the value 'dst' that is written to CDR. This shows up as 's' because of the GotoIfTime rules in inbound.include. instead of maintaining the destination extension you are redirected to an s extension.

exten => 5025551212,7,GotoIfTime(*|*|*|*?from-outside-5025551212-tl-allhours-bgn|s|1)

rewrites the destination extension and sends it to inbound_actions.include as 's'

[from-outside-5025551212-tl-allhours-bgn]

exten => s,1,Set(tenant=bgn)

exten => s,2,Set(CDR(userfield)=bgn)

exten => s,3,Set(MOH=${DB(TL/MOH/default${TL_DASH}${tenant})})

exten => s,n,GotoIf($["${MOH}" = ""]?nomoh)

exten => s,n,SetMusicOnHold(${MOH})

exten => s,n(nomoh),Macro(tl-goto-userextension,512)

when really

exten => 5025551212,7,GotoIfTime(*|*|*|*?from-outside-5025551212-tl-allhours-bgn|${EXTEN}|1)

and

[from-outside-5025551212-tl-allhours-bgn]

exten => _.,1,Set(tenant=bgn)

exten => _.,2,Set(CDR(userfield)=bgn)

exten => _.,3,Set(MOH=${DB(TL/MOH/default${TL_DASH}${tenant})})

exten => _.,n,GotoIf($["${MOH}" = ""]?nomoh)

exten => _.,n,SetMusicOnHold(${MOH})

exten => _.,n(nomoh),Macro(tl-goto-userextension,512)

would retain the correct 'dst' in the CDR. Now asterisk is going to complain a little about matching _. because that matches against timeouts and fallthrough etc. That warning is valid in general contexts but not specific application-like contexts where the only possible way to get into the context is to be sent there as a result of another dialplan application (such as gotoiftime). But for the faint of heart..

[from-outside-5025551212-tl-allhours-bgn]

exten => _x.,1,Set(tenant=bgn)

exten => _x.,2,Set(CDR(userfield)=bgn)

exten => _x.,3,Set(MOH=${DB(TL/MOH/default${TL_DASH}${tenant})})

exten => _x.,n,GotoIf($["${MOH}" = ""]?nomoh)

exten => _x.,n,SetMusicOnHold(${MOH})

exten => _x.,n(nomoh),Macro(tl-goto-userextension,512)

exten => _+.,1,Set(tenant=bgn)

exten => _+.,2,Set(CDR(userfield)=bgn)

exten => _+.,3,Set(MOH=${DB(TL/MOH/default${TL_DASH}${tenant})})

exten => _+.,n,GotoIf($["${MOH}" = ""]?nomoh)

exten => _+.,n,SetMusicOnHold(${MOH})

exten => _+.,n(nomoh),Macro(tl-goto-userextension,512)

would also be valid albeit twice the amount of code. This represents a two pronged problem to fix.

  1. the inbound routes portion of the Thirdlane PBX application has to begin writing the rules out according to this standard
  2. the existing entries inside inbound.include and inbound_actions.include would have to be changed retroactively.
Submitted by thirdlane on Wed, 02/20/2008 Permalink

I just made voicemail optional for user extensions, so the overall behavior changed.

The new code is not yet publicly available. There is a ton of other bug fixes, enhancements and a good amount of new functionality, let me know if you want to get a prerelease version - send email to alex@thirdlane.com