search for: callington

...changed: unknown callerID changed: unknown callerID changed: unknown callerID changed: unknown callerID changed: unknown callerID changed: unknown AGI Environment Dump: -- accountcode = -- callerid = unknown -- calleridname = unknown -- callingani2 = 0 -- callingpres = 0 -- callingtns = 0 -- callington = 0 -- channel = IAX2/u32218094-1 -- context = default -- dnid = unknown -- enhanced = 0.0 -- extension = 8365 -- language = en -- priority = 3 -- rdnis = unknown -- request = agi-VDADtransfer.agi -- type = IAX2 -- uniqueid = 1139506471.2 AGI Environment Dump: |1139506471.2|IAX2/u3221809...

Hi, whatever dialplan I'm using for outgoing calls via PRI (Digium card, chan_zap), the callerid when receiving calls has no leading zeros, which are normally used to distinguish local, national and international calls in Europe. The number has always the area code in front, but the country code only for foreign calls. Now I'm looking for any mean to decide, whether the received

...agi-bin/dialparties.agi -- dialparties.agi: priority = 4 -- dialparties.agi: callingani2 = 0 -- dialparties.agi: accountcode = -- dialparties.agi: channel = Zap/1-1 -- dialparties.agi: callerid = unknown -- dialparties.agi: context = macro-dial -- dialparties.agi: callington = 0 -- dialparties.agi: dnid = unknown -- dialparties.agi: request = dialparties.agi -- dialparties.agi: calleridname = unknown -- dialparties.agi: extension = s -- dialparties.agi: language = en -- dialparties.agi: uniqueid = 1141046151.2 -- dialparties.agi: call...

...bin/dialparties.agi -- dialparties.agi: priority = 4 -- dialparties.agi: callingani2 = 0 -- dialparties.agi: accountcode = -- dialparties.agi: channel = Zap/1-1 -- dialparties.agi: callerid = 5122311245 -- dialparties.agi: context = macro-dial -- dialparties.agi: callington = 33 -- dialparties.agi: dnid = 5126873305 -- dialparties.agi: request = dialparties.agi -- dialparties.agi: calleridname = AIRLINK SYSTEMS -- dialparties.agi: extension = s -- dialparties.agi: language = en -- dialparties.agi: uniqueid = 1125593688.105 -- dialpar...

Hello, i've recently switched over from 1.0.9 to 1.2.3. I've experienced some (to me) weird behaviour. This is the config for an example queue.conf: [654] wrapuptime=30 timeout=20 strategy=ringall retry=5 queue-youarenext=queue-youarenext queue-thereare=queue-thereare queue-thankyou=queue-thankyou queue-callswaiting=queue-callswaiting music=default monitor-join=yes monitor-format=

hi, on our incoming E1-PRI from german telco Arcor the leading 0 for the (area access code in europe) and the 00 (country accescode in europe) are missing on incoming callerids. only prepending a single 0 is not the solution as suggested by some writers on this list, because there is no way to differ between national and international callerids and it's not possible to make the decission

...MisterHouse.agi,"CallerID": -- calleridname = UNAVAILABLE MisterHouse.agi,"CallerID": -- callingani2 = 0 MisterHouse.agi,"CallerID": -- callingpres = 0 MisterHouse.agi,"CallerID": -- callingtns = 0 MisterHouse.agi,"CallerID": -- callington = 0 MisterHouse.agi,"CallerID": -- channel = Zap/4-1 MisterHouse.agi,"CallerID": -- context = incoming-dial MisterHouse.agi,"CallerID": -- dnid = unknown MisterHouse.agi,"CallerID": -- enhanced = 0.0 MisterHouse.agi,"CallerID": -...

Hi, i have a HT 488 and I want using this like an FXO for Asterisk. I have find some configuration in the list archive & google but my HT with these config not work. my sip.conf [HT-488] username=400 type=peer secret=wowowow qualify=yes port=5062 nat=no host=192.168.1.157 fromuser=400 disallow=all context=from-pstn allow=g711u allow=ulaw allow=alaw my sip debug:

Hi to all I've mada up my mind and i tried to change from i4l to chan_capi, following some councelling from the gurus. I compiled it up, and when i try to load it in modules.conf, i get that wonderful message and Asterisk does not start: [chan_capi.so]Feb 17 09:21:40 WARNING[16384]: loader.c:239 ast_load_resource: /usr/lib/asterisk/modules/chan_capi.so: undefined symbol: ast_get_group Feb

Hi, maybe a dumb question, but it seems that some calls are directed to our central dial in number despite the extensions the callers say they dialled. E.g. they dial 1234-567, asterisk recognizes 12345, it says this is an unknown extension, where it is right, and redirects the call to the central dial in extension 1234-0. This only seems to happen when the numbers are dialled manually. When