similar to: NATted phones transferring calls - BUG0003710

I made the post below earlier today. I'v since removed all NAT from the equation and the problem still persists. Basically I am trying to transfer a call. The transferring phone sends a REFER message to asterisk with a call id that Asterisk doesn't know about. Surely, surely.... someone else must have seen this? hermes*CLI> sip show channels Peer User/ANR Call ID

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;branch=z9hG4bKba3b074892377BD1. From:

I just realised my problem seems to be related to bug 0003710 - "0003710: [patch] Consultative transfers between asterisk servers". It's unclear from the bug info if this problem has been 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

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-c28be02e-64b73be7@172.31.16.67'. Both legs must reside on Asterisk box

Hi, colleagues, I'm running samba3 Using OID (Oracle Internet Directory) as backend, almost works ok, but the final trick that doesn't work is the change of the passwords from windows dialog box, this change the samba passwords but don't change the userpassword, i have found this line on samba logs files: ldap password change requested, but LDAP server does not support it --

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 --

Can 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

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

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

Hmmm. Not having much luck with this. I'm trying 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

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

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

Ugh. I have voicemail set up for realtime... mysql> SELECT * FROM ast_vm_users; +----------+-------------+-----------+---------+----------+----------+-------+-------+---------------------+ | uniqueid | customer_id | context | mailbox | password | fullname | email | pager | stamp |

I hope I have this wrong, but when I have a bunch of priority 1 NoOp's created from regexten in sip.conf, and I do an 'extensions reload', I lose all the priority 1 NoOps! This can't be right... this means that in a production environment, if you make a change to your dialplan and do an 'extensions reload', you lose your ability to terminate calls to phones on this system.

Folks, When I have a dial string like this: Dial(SIP/3254101&SIP/3254102,20,tr) and I want to check the ${DIALSTATUS} variable after the dial, how do I know which number I am getting the variable for? And, what about this? Dial(SIP/3254101&SIP/3254102@proxy1,20,tr) What happens in that case? How can I get the ${DIALSTATUS} variable for EACH NUMBER dialled? Thanks, Doug.

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

I'm wondering if moh is still broken in Asterisk 1.4 beta3. In Asterisk 1.2, when a callee put a caller on hold, the musiconhold class that was played was not the one the callee wanted the caller to hear, but something else. Even after using mohsuggest in Asterisk 1.4, it still appears that this is not working correctly. Here's the results of a simple test: CASE CALLER CALLEE

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.

Ok, here's a weird one. I have an AGI script where one user calls another. The call is answered. Everything is peachy. If the call is terminated by the CALLEE hanging up the call, then Asterisk returns control back to where the Dial() command left off, and I can check the return code of Dial(), ${DIALSTATUS} etc. That's all great. HOWEVER, if the CALLER hangs up the call, it seems as if

I have a tricky situation. I have a polycom phone with number 3254103. I have configured the phone to 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