* You are viewing the archive for May 20th, 2011

looking for testers for app_meetme AMI patch


I’ve created a patch to correct error responses for the MeetMeList manager action. Currently MeetMeList produces an error if no conferences are active, success if any conferences are open. Requesting a conference that is not active while other conferences are active does not produce an error.


With the patch (app_meetme-r319651-meetmelist_error_reporting.diff):
If Conference is not specified then it’s no longer an error if no conferences are active.
If Conference is specified that is not active it is an error.

Please leave any notes on the issue tracker, if you respond to this mailing list please CC my email address or I might not see the message.

Thank you,

AstLinux 0.7.8 Release

The AstLinux Team would like to announce the immediate availability of
the 0.7.8 release. This release includes either Asterisk 1.4.41 or
Asterisk 1.8.4. All current users are encouraged to upgrade to this
release to take advantage of bug fixes and other updates to Asterisk.

Please note that there is a bug in Asterisk 1.8.4 that will prevent
Cisco 79xx phones from registering.

A full changelog is available at http://www.astlinux.org

Current users can upgrade from the web interface or from the commandline.

From the CLI:

(Asterisk 1.4)
upgrade-run-image check http://mirror.astlinux.org/firmware

Restart asterisk destroy all registered SIP peers

Hi Guys!

This is strange issue with 1.8 I have restarted my asterisk and it destroy all registered SIP peers now only solution is i manually reboot all phones to get them register back. I have never seen issue like this before. Any idea what would be the issue ?


SIP Diversion RDNIS – how to get reason parameter?

Hi Olivier

> Are those PBXs directly connected to each other through a SIP trunk ?

Yes, and the reason is definitely transmitted in the SIP header and also
parsed by asterisk and displayed in debug output.

After reading a bit more in chan_sip.c (I’m not a coder) I fear the result is
just put in a temporary variable __SIPDIVERSIONREASON but not in a variable
useable in the dialplan.



Do many people use this?
Is it reliable and safe?



Hints custom:abcdef

Hello list,

I want certain devices to monitor certain extensions/SIPaccounts and
other devices to monitor other extensions/SIPaccounts.

Therefore I do the following :


include => test1-blf


include => test2-blf

exten => 10,hint,SIP/testcorp1
exten => 20,hint,SIP/testcorp2

exten => 10,hint,SIP/testcorp110
exten => 20,hint,SIP/testcorp120

SIPaccounts with a context definition of “from-TEST1″ can not monitor
the extensions of test2-blf.
SIPaccounts with a context definition of “from-TEST2″ can not monitor
the extensions of test1-blf.

This works great. But now I have a problem with custom hints.

When I do the following :

exten => 10,hint,SIP/testcorp1
exten => 20,hint,SIP/testcorp2
exten => 80,hint,custom:light1

I see that SIPaccounts which enter the dialplan in context [from-TEST2]
also see the state (Green/Red) of hints defined in test1-blf.

So how can I make a difference between custom hints in one context and
custom hints in another context ??

Is there something like :
Set(DEVSTATE(*Custom:light1@test1-blf*)=INUSE)* * ??

Or can there be only one custom:light1 label ??