similar to: Asterisk Sends 180-RINGINGto UAeven withprogressinband=yes

> -----Original Message----- > From: Eric "ManxPower" Wieling [mailto:eric@fnords.org] > Sent: Monday, December 11, 2006 5:11 PM > To: Asterisk Users Mailing List - Non-Commercial Discussion > Subject: Re: [asterisk-users] Asterisk Sends 180-RINGING to UAeven > withprogressinband=yes > > > Douglas Garstang wrote: > > > > > > Andrew, >

Andrew, I don't think it's a Polycom issue. We took Asterisk out of the picture and had our Polycom phones communicate directly with an Audiocodes PSTN gateway. Unlike Asterisk, the audiocodes do not send 180 Ringing before sending 183 Session Progress, and the polycom's play the correct tones in this case. We WANT Asterisk to send progress tones in band. In our case it IS needed.

I don't follow. Are you saying there's a limit of 10 contexts within extensions.conf? If, on the other hand, your saying that each context can only have 10 #include statements, I tried that too. See below. I put 12 #include's across two contexts, and still got the same error, I not sure that goto's are much of a solution, but I'll have to proof it. And that's my

Oh Nooooooo! It looks as if there is a limit of 9 (not 10) maximum #include statments that you can have in extensions.conf. For example, the following extensions.conf causes the error to appear.. [user_3250071] #include "inc/wildwildwest/features.conf" #include "inc/wildwildwest/features.conf" #include "inc/wildwildwest/features.conf" #include

Can someone tell me why the following from extensions.conf generates this error on asterisk load? Jan 13 09:27:24 WARNING[31701]: config.c:938 ast_config_internal_load: Maximum Include level (10) exceeded As far as I can tell I don't have a DEPTH of 10 includes. I certainly have more than 10 include statements, but I don't have them drilled down to a depth of 10. I'm thinking the

Hi, Does anyone know if Asterisk is a good tool to be used for a large quantity of g711 and g729 transcoding? What is the best alternative for that? -- Woody Dickson woodydickson at gmail.com <woody.dickson at gmail.com> US and Worldwide Termination ============ Contact me for the following offering ============ USA Onnet - 0.0049/min USA Offnet - 0.011/min USA Mobile starting

I have progressinband=yes in sip.conf, but Asterisk sends a 180-Ringing to my polycom phones and then it also sends 183-Session Progress. That doesn't seem to make sense. Shouldn't Asterisk NOT send 180-Ringing if progressinband=yes ? Doug.

I don't expect my SIP provider to provide useful "Remote-Party-ID" information. Therefore, I am using "CONNECTEDLINE(num)=xxx" AND "CONNECTEDLINE(name)=yyy" to populate remote party information from a local database. I am also using the "I" (upper case "i") option for Dial. Generally I like to see to see the remote party name appear on the

Hmm. if you put it *after* the ldap userdb, it should not have prevented users from logging in. What happens if you do userdb { ? driver = passwd-file ? args = .... ? skip = notfound ? result_failure = continue-ok } Aki On 07.08.2018 12:58, Simeon Ott wrote: > Now the attributes are correctly read for the user test at onnet.ch > <mailto:test at onnet.ch>, but other users are not

Ah. You probably need to change ldap userdb so that you add userdb { driver = ldap ? args = /etc/dovecot/dovecot-ldap.conf result_success = continue-ok } so that the next one is processed. you can use 'doveadm user test at onnet.ch' to verify that the attributes are read for this user, and with another username that they are not. Aki On 07.08.2018 12:23, Simeon Ott wrote: > ?

Now the attributes are correctly read for the user test at onnet.ch <mailto:test at onnet.ch>, but other users are not able to authenticate anymore. root at buserver:/var/spool/postfix/virtual/onnet.ch/test/Maildir/.super# doveadm user test at onnet.ch field value uid 5000 gid 5000 home /var/spool/postfix/virtual/onnet.ch/test/ mail maildir:~/Maildir quota_rule *:bytes=1073741824 acl

? attached the dovecot -n, linked files, debug log lines during a standard client login root at buserver:/etc/dovecot/conf.d# doveconf -n # 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 3.16.0-6-amd64 x86_64 Debian 8.11 auth_debug = yes auth_debug_passwords = yes auth_mechanisms = plain login auth_verbose = yes auth_verbose_passwords = plain debug_log_path = syslog disable_plaintext_auth = no

http://repo.dovecot.org/ <http://repo.dovecot.org/> Sami > On 8 Aug 2018, at 10.27, Simeon Ott <simeon.ott at onnet.ch> wrote: > > Okay, this seems to be due to the fact that the option ?use_globals_only" is supported only in v2.2.31+ > We are on Debian jessie with dovecot v2.2.13 ? even an upgrade to current stable stretch won?t help (dovecot v2.2.27). So we will

Okay, this seems to be due to the fact that the option ?use_globals_only" is supported only in v2.2.31+ We are on Debian jessie with dovecot v2.2.13 ? even an upgrade to current stable stretch won?t help (dovecot v2.2.27). So we will wait until the packages find their way into the repository. thanks anyway > On 7 Aug 2018, at 13:00, Simeon Ott <simeon.ott at onnet.ch> wrote: >

Chris Abel writes: >Hello everyone! > >I've had this problem for a while and cant figure it out. When an outside >caller calls an extension on my asterisk system, they do not hear any >sort of ringing. Inside extensions calling other extensions do hear >ringing. We have 3 other asterisk systems that are configured the same >way, but do not have this problem. We think it

still the same? root at buserver:/etc/dovecot# doveadm user test2 at onnet.ch field valueuserdb lookup: user test2 at onnet.ch doesn't exist relevant config output from doveconf -n userdb { args = /etc/dovecot/dovecot-ldap.conf driver = ldap result_success = continue-ok } userdb { args = username_format=%Lu /etc/dovecot/share.passwd driver = passwd-file result_failure =

You could do userdb { ?? driver = username_format=%Lu passwd-file ?? args = /etc/dovecot/share.passwd } #? /etc/dovecot/share.passwd test at onnet.ch::::::: userdb_acl=vfile:/etc/dovecot/dovecot-acl userdb_acl_globals_only = yes should prevent the user from modifying any ACL files. Aki On 05.08.2018 17:04, Simeon Ott wrote: > Hello > > Is it possible to limit the ability of sharing

Hello Is it possible to limit the ability of sharing it?s own mailboxes to only a few users? We have a few sensitive mailboxes of users where the ability to share via IMAP SETACL should be prevented. I tried the following so far? doveadm acl remove -u test at onnet.ch <mailto:test at onnet.ch> INBOX user=test at onnet.ch <mailto:user=test at onnet.ch> admin but when doing this the

Thanks Sami, thanks Aki I just updated the packages on our testing server and now it works like expected. There are some LDAP tests to come. Are there many productive server out there using this repository? Simeon > On 8 Aug 2018, at 09:41, Sami Ketola <sami.ketola at dovecot.fi> wrote: > > > http://repo.dovecot.org/ <http://repo.dovecot.org/> > > Sami >

Hello Is it possible to limit the ability of sharing it?s own mailboxes to only a few users? We have a few sensitive mailboxes of users where the ability to share via IMAP SETACL should be prevented. I tried the following so far? doveadm acl remove -u test at onnet.ch INBOX user=test at onnet.ch admin but when doing this the admin rights are still there doveadm acl rights -u test at