Ticket #5774 (new Bugs)

Opened 1 year ago

Last modified 1 year ago

connectedline() sending the word "device" when an extension answers a Ring Group

Reported by: AdHominem Assigned to: p_lindheimer
Priority: minor Milestone: 2.11
Component: Ring Groups Version: 2.9-branch
Keywords: Cc:
Confirmation: Unreviewed Distro:
Backend Engine: All Distro Ver:
Backend Ver: SVN Revision (if applicable):

Description

I'm running the FreePBX Distro (2.9 with Asterisk 1.8.6). All FreePBX modules were updated today. I use Aastra 6757i phones. I have enabled Send RPID (PAI) in the extension settings and the CONNECTEDLINE() feature seems to work in most instances.

However, if I call a Ring Group, when a phone in the Ring Group finally answers, I see the extension # of the phone that answered, but the name assigned to it is "device." If I call the same extension directly, then I see the extension # and the name assigned to that extension in FreePBX. In addition, if I pick-up a parked call, I DO NOT see device.

I know that you were working on getting all the "device" names out of the system and at one point, you believed you'd gotten this corrected with respect to Ring Groups. Somehow, the name has been lost with respect to the device answering a Ring Group.

Change History

04/16/12 23:54:23 changed by p_lindheimer

  • confirmation changed from Unreviewed to Need Feedback.

please provide a trace of the call to the ringgroup .

04/17/12 00:24:52 changed by AdHominem

Here's the relevant log portions.

I've compared this log with another log where the CONNECTEDLINE() feature worked and I am GUESSING that you need to change CONNECTEDLINE(name) to CONNECTEDLINE(name,i):

[2012-04-16 21:17:55] VERBOSE[10794] app_dial.c: -- SIP/46-000006d2 is ringing [2012-04-16 21:17:55] VERBOSE[10794] app_dial.c: -- SIP/47-000006d3 is ringing [2012-04-16 21:17:55] VERBOSE[10794] app_dial.c: -- SIP/46-000006d2 is ringing [2012-04-16 21:17:55] VERBOSE[10794] app_dial.c: -- SIP/47-000006d3 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/44-000006d1 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/40-000006d0 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/44-000006d1 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/48-000006d4 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/44-000006d1 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/40-000006d0 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/40-000006d0 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/48-000006d4 is ringing [2012-04-16 21:17:56] VERBOSE[10794] app_dial.c: -- SIP/48-000006d4 is ringing [2012-04-16 21:17:58] VERBOSE[10794] app_dial.c: -- SIP/50-000006d5 connected line has changed. Saving it until answer for SIP/48-000006cf [2012-04-16 21:17:58] VERBOSE[10794] app_dial.c: -- SIP/50-000006d5 answered SIP/48-000006cf [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-auto-blkvm:1] Set("SIP/50-000006d5", "MACRO_RESULT=") in new stack [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-auto-blkvm:2] Macro("SIP/50-000006d5", "blkvm-clr,") in new stack [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-blkvm-clr:1] Set("SIP/50-000006d5", "SHARED(BLKVM,SIP/48-000006cf)=") in new stack [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-blkvm-clr:2] Set("SIP/50-000006d5", "GOSUB_RETVAL=") in new stack [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-blkvm-clr:3] MacroExit?("SIP/50-000006d5", "") in new stack [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-auto-blkvm:3] ExecIf?("SIP/50-000006d5", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=50)") in new st$ [2012-04-16 21:17:58] VERBOSE[10794] pbx.c: -- Executing [s@macro-auto-blkvm:4] ExecIf?("SIP/50-000006d5", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=Panasonic Cordless)") in new stack [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 47 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 42 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 46 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 40 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 41 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 44 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 43 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 50[ext-local] new state InUse? for Notify User 48 [2012-04-16 21:17:58] VERBOSE[14157] chan_sip.c: == Extension Changed 48[ext-local] new state InUse? for Notify User 47

04/17/12 00:57:40 changed by AdHominem

I've done more research.

Where it works correctly, you set the name first and then the num. You use the ,i flag after the name, but not the num.

i.e.

CONNECTEDLINE(name,i) CONNECTEDLINE(num)

However, in the case of Ring Groups, you reverse the order and don't use the ,i flag at all.

Since you do the (num) first when ring groups are answered, you may need the ,i in the CONNECTEDLINE(num) setting, i.e. CONNECTEDLINE(num,i). Otherwise, you may want to set the name first (with ,i) and then do num, as you do with regular calls.

Again, I'm just guessing here, as I am not a programmer. However, in instances where it works, the first one you update is updated with the ,i setting and the second one you update does not have the ,i setting.

05/01/12 20:17:29 changed by AdHominem

I see that this ticket still shows "needs feedback." I've provided the feedback. Should I change it back to unreviewed?

05/08/12 00:49:56 changed by AdHominem

  • confirmation changed from Need Feedback to Unreviewed.

06/04/12 21:35:26 changed by AdHominem

I've confirmed that this bug only affects FreePBX 2.9, and not 2.10.

06/05/12 18:34:41 changed by p_lindheimer

  • component changed from Core to Ring Groups.

if it's easy to provide a CLI trace of equivalent calls on 2.9 and 2.10 to try and quickly pinpoint the difference between the two it would be of help.

06/05/12 22:27:23 changed by AdHominem

If you can tell me how to do a CLI Trace, I'll be happy to do it.

06/06/12 11:05:16 changed by p_lindheimer

you simply set verbosity to about 5 and then copy the output of the CLI. You can probably get what is needed out of the log as well.

06/12/12 12:21:44 changed by AdHominem

Okay, so here are the log entries for a call to a Ring Group. The primary difference that I can see is that, with a Ring Group, you are failing to set the first connectedline with the ,i flag, but you are using the ,i flag with calls to an extension.

Just a reminder: When I call a Ring Group, the word "device appears" after a Ring Group member answers, but the extension # also appears correctly.

Here's the log for the Ring Group Calls:

-- SIP/50-000002eb connected line has changed. Saving it until answer for SIP/40-000002e3

-- SIP/50-000002eb answered SIP/40-000002e3

-- Executing [s@macro-auto-blkvm:1] Set("SIP/50-000002eb", "MACRO_RESULT=") in new stack

-- Executing [s@macro-auto-blkvm:2] Macro("SIP/50-000002eb", "blkvm-clr,") in new stack

-- Executing [s@macro-blkvm-clr:1] Set("SIP/50-000002eb", "SHARED(BLKVM,SIP/40-000002e3)=") in new stack

-- Executing [s@macro-blkvm-clr:2] Set("SIP/50-000002eb", "GOSUB_RETVAL=") in new stack

-- Executing [s@macro-blkvm-clr:3] MacroExit?("SIP/50-000002eb", "") in new stack

-- Executing [s@macro-auto-blkvm:3] ExecIf?("SIP/50-000002eb", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=50)") in new stack

-- Executing [s@macro-auto-blkvm:4] ExecIf?("SIP/50-000002eb", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=Panasonic Cordless)") in new stack

NOTE: Take note of the fact that CONNECTEDLINE(num) DOES NOT have the ,i flag, even though it appears first!

Here is the output if I call the extension directly. In this case, the connectedline name appears properly when the phone is ringing. Note that in this case, the first CONNECTEDLINE instruction DOES have the ,i flag:

-- Executing [s@macro-dial-one:39] Set("SIP/40-000002f1", "CONNECTEDLINE(name,i)=Panasonic Cordless") in new stack

-- Executing [s@macro-dial-one:40] Set("SIP/40-000002f1", "CONNECTEDLINE(num)=50") in new stack

-- Executing [s@macro-dial-one:41] Set("SIP/40-000002f1", "D_OPTIONS=wrI") in new stack

-- Executing [s@macro-dial-one:42] Dial("SIP/40-000002f1", "SIP/50wrI") in new stack

Interestingly, a few seconds later, I see this in the log:

-- Called SIP/50

-- Connected line update to SIP/40-000002f4 prevented.

-- SIP/50-000002f5 is ringing

However, this particular error does not seem to affect functionality in any way...

I should add that I'm using an Aastra 6757i. I have SendRPID set to PAI in the Extension settings and I have "sip pai: 1" and "sip update callerid: 1" set in my aastr.cfg file.

06/12/12 12:30:23 changed by AdHominem

Just to summarize, the difference between the logs when it works and when it doesn't is that, when it works, you set the name FIRST and you use the ,i flag on the name. When it doesn't work, you set the number first, and you don't use the ,i flag at all.

Works (correct name and number appears):

-- Executing [s@macro-dial-one:39] Set("SIP/40-000002f1", "CONNECTEDLINE(name,i)=Panasonic Cordless") in new stack

-- Executing [s@macro-dial-one:40] Set("SIP/40-000002f1", "CONNECTEDLINE(num)=50") in new stack

Does not work (correct number and word "device" appears):

-- Executing [s@macro-auto-blkvm:3] ExecIf??("SIP/50-000002eb", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(num))=50)") in new stack

-- Executing [s@macro-auto-blkvm:4] ExecIf??("SIP/50-000002eb", "0?Set(MASTER_CHANNEL(CONNECTEDLINE(name))=Panasonic Cordless)") in new stack

06/15/12 14:50:14 changed by AdHominem

I just did some manual editing of my extensions*.conf files and found that adding the ,i flag didn't change anything. So, I assume the bug is somewhere in the setting of the variable.