search for: 2944093

I'm having some issues with Background() and Read() commands. See the example below. This is when I wait for Background to finish playing the sound file, before entering '12345#'. All works fine. hestia*CLI> -- Executing Answer("SIP/2944093-3366", "") in new stack -- Executing Wait("SIP/2944093-3366", "1") in new stack -- Executing BackGround("SIP/2944093-3366", "if-u-know-ext-dial") in new stack -- Playing 'if-u-know-ext-dial' (language 'en') -- Ex...

...someone recommend the best way to view current calls in progress on the Asterisk console? Neither the 'show channels' or 'sip show channels' commands are easy to read. hestia*CLI> show channels Channel Location State Application(Data) SIP/2944093-f9e2 (None) Up Bridged Call(SIP/2944079-e7f2) SIP/2944079-e7f2 <mailto:2944093@one_start:2> 2944093@one_start:2 Up Dial(SIP/2944093|36|tr) 2 active channels 1 active call hestia*CLI> hestia*CLI> sip show channels Peer User/ANR Ca...

Before I play around with this again in 1.2.1, regexten is still essentially broken, correct? The misconception seems to be that it allows you to execute a command upon registration from a SIP UA. Even the O'Reilly TFOT book erroneously states that this is what it is for. After reading the developer discussion though, it definitely seems to be broken. Is it fixed yet? Doug.

...to call the DUNDILOOKUP function and assign it to a variable in an AGI script. I've tried setting with EXEC CMD and with SET VARIABLE. In both cases, it's treating DUNDILOOKUP literally, rather than calling a funciton. I've tried this: EXEC "Set" "DIALPATH=${DUNDILOOKUP(2944093|180net)}" and also: SET VARIABLE DIALPATH ${DUNDILOOKUP(2944093|180net)} in both cases, DIALPATH is set to a literal "${DUNDILOOKUP2944093|180net}" What am I doing wrong here? Doug.

I'm using Asterisk 1.2.7.1. Has the callerid number matching functionality in extensions.conf changed recently? exten => 5555,1,NoOp(${CALLERID}) hestia*CLI> -- Executing NoOp("SIP/2944093-d24d", ""Cletus the Slaw Jawed Yokel" <2944093>") in new stack == Auto fallthrough, channel 'SIP/2944093-d24d' status is 'UNKNOWN' This does not match... exten => 2944093/5555,1,NoOp(${CALLERID}) Can't figure out why.... It used to work. Do...

I made a call from 3254102 to 2944093. I then tried to do a transfer to 3254107. IP addresses have been changed to protect the innocent. It appears this related to bug 3710. It's unclear from the bug if the problem has been fixed or not. If it hasn't, then this seems pretty serious and would I guess affect any NAT-ted phones...

Trying to get SIP realtime working here... I'm connected to the database... *CLI> realtime mysql status Connected to vox180internal@db1.ipt.XXX.com, port 3306 with username voxadmin for 6 seconds. I can get information for the extension in question... *CLI> realtime load sipusers name 2944093 Column Name Column Value -------------------- -------------------- id 1 name 2944093 accountcode 2944093...

I have a SIP user, 2944093 that dialled 3254102. I'm trying to transfer the call from 3254102 to 3254104. When I try and transfer the call, I get the following on the Asterisk console. Mar 3 15:14:18 NOTICE[23124]: chan_sip.c:6731 get_refer_info: Supervised transfer requested, but unable to find callid '16749440-c2...

Arrgh. I just made a call with Asterisk to extension 2944093. That extension exists in astdb and I have rtcachefriends=yes in sip.conf. Asterisk did a database query... SELECT * FROM ast_sip_users WHERE name = '2944093' Uhm... Why? Doug

I made a call from 3254102 to 2944093. I then tried to do a transfer to 3254107. IP addresses have been changed to protect the innocent. Here's the REFER that the phone at 2944093 sends directly to Asterisk: U 216.186.128.68:5060 -> 216.186.142.203:5060 REFER sip:3254102@216.186.142.203 SIP/2.0. Via: SIP/2.0/UDP 216.186.128.68...

...en resolved yet. Anyone know? Doug. > -----Original Message----- > From: Douglas Garstang > Sent: Monday, March 27, 2006 4:41 PM > To: 'Asterisk Users Mailing List - Non-Commercial Discussion' > Subject: Transfer Calls - REFER > > > I made a call from 3254102 to 2944093. I then tried to do a > transfer to 3254107. > IP addresses have been changed to protect the innocent. > Here's the REFER that the phone at 2944093 sends directly to Asterisk: > > U 216.186.128.68:5060 -> 216.186.142.203:5060 > REFER sip:3254102@216.186.142.203 SIP/2.0....

Oh heck. It really looks like realtime has been seriously screwed up. When a call comes in to Asterisk, I can see asterisk executing these queries. SELECT * FROM ast_sip_peers WHERE host = '2XX.YYY.142.205' SELECT * FROM ast_sip_peers WHERE name = '2944093' SELECT * FROM ast_sip_peers WHERE name = '2944093' So, the first thing it does is check and see if there are any records in sip_peers where the IP address of the message matches. What happens if this user may make calls from multiple IP addresses? Will I need one entry for each IP add...

...2944078) [SIP] '2944079' => 1. Noop(2944079) [SIP] '2944086' => 1. Noop(2944086) [SIP] '2944090' => 1. Noop(2944090) [SIP] '2944093' => 2. Dial(SIP/2944093|20|tr) [pbx_config] '2944171' => 1. Noop(2944171) [SIP] '3254101' => 1. Noop(3254101) [SIP] 2. (AGI(ipt/iptrouter2.py))...

...not? Doug. > -----Original Message----- > From: Douglas Garstang > Sent: Tuesday, March 28, 2006 8:30 AM > To: 'Asterisk Users Mailing List - Non-Commercial Discussion' > Subject: NATted phones transferring calls - BUG0003710 > > > I made a call from 3254102 to 2944093. I then tried to do a > transfer to 3254107. > IP addresses have been changed to protect the innocent. > > It appears this related to bug 3710. It's unclear from the > bug if the problem has been fixed or not. If it hasn't, then > this seems pretty serious and would I...

...forward to a new number, 18059999999. Here's my dialplan: exten => 3254103,1,Dial(SIP/3254103,10,tr) exten => 18059999999,1,Dial(SIP/11101553818059999999@proxy2,40,tr) When Asterisk dials 3254103, here's what comes up on the console: hestia*CLI> -- Executing Dial("SIP/2944093-6935", "SIP/3254103|10|tr") in new stack -- Called 3254103 -- Got SIP response 302 "Moved Temporarily" back from xxx.187.128.19 -- Now forwarding SIP/2944093-6935 to 'Local/18059999999@betty_start' (thanks to SIP/3254103-47ab) -- Executing Dial(&quot...

The Asterisk Manager Interface is driving me nuts. Whoever wrote it should be drawn and quartered. Sometimes the data comes back separated by \r\n, and sometimes it's separated by \n. The whole thing is completely inconsistent, and trying to write any kind of API for it is -GHASTLY- Doug.

Here's an interesting question: If I transfer a call from Asterisk system to another with IAX, is there any way I can get control back on the original system? Or.. do I lose control, and the dialplan has to continue on the new system? Scenario is we transfer calls to an Asterisk system that handles ACD queues. If the ACD queue times out, we want to send the caller to voicemail on another

I just upgraded to Asterisk 1.2.7 from 1.2.5. Page() is behaving differently. I'm getting an error - Incomplete destination '' supplied. -- Executing Page("SIP/2944093-5999", "SIP/3254107&SIP/3254105|") in new stack Apr 13 11:06:11 WARNING[9294]: app_page.c:193 page_exec: Incomplete destination '' supplied. -- Playing 'beep' (language 'en') -- Created MeetMe conference 1023 for conference '1592290043d'...

...; Subject: RE: [asterisk-users] What's up with the Manager Interface?!?! >> >> >> On Wed, 29 Nov 2006, Douglas Garstang wrote: >> >> >>> Grrrr. Here's another example... >>> >>> Action: Command >>> Command: sip show peer 2944093 >>> >>> Response: Follows >>> Privilege: Command >>> >>> >>> * Name : 2944093 >>> Secret : <Set> >>> MD5Secret : <Not set> >>> Context : 180o_CallStart >>> Subscr.Cont. : 1...

Just spent hours dicking around with SIP Realtime. Every time a phone came up and sent a registration to Asterisk, Asterisk would simply NOT query the database. I had sipusers in extconfig, but added sippeers as well. NOW I can see Asterisk doing a 'SELECT * FROM sippeers WHERE name = '2944093''. Huh??? Uhm, why? It's not a peer! It's a bloody phone, and in my mind should be a user or a friend! It should be looking in sippeers! How does it decide which table to use? Has anyone made sense of this mess? Doug.