Queue parameters in realtime not applied

Hi,

I’m using Asterisk 13.6 realtime in pjsip and I am having a hardtime with new created queue in my DB.
Is there any kind of reload that is needed in order to apply new parameters made in the queues table?
Some parameters like queue-thankyou are still playing to the agents even though I have removed the parameter.
I did a test by duplicating a problematic queue with a new name and the queue-thankyou message is not played to the agent. It’s almost like some parameters are stucked to whatever I have set and cannot be undone.

My extconfig.conf :

queues => odbc,asterisk
queue_members => odbc,asterisk
queue_log => odbc,asterisk,Queue_log

Can you post the output from the CLI when you use the Queue app?

Here it is: I have set queue-thankyou in the announce column and even after removing it you can see the message played at the end:

[Aug 24 06:53:47] Connected to Asterisk 13.6.0 currently running on dti-asterisk (pid = 2061)
[Aug 24 06:54:10] – Channel PJSIP/U_2434-000ece0d left ‘native_rtp’ basic-bridge
[Aug 24 06:54:10] – Channel PJSIP/ATA-LINE-040-000ece0c left ‘native_rtp’ basic-bridge
[Aug 24 06:54:10] == Spawn extension (garneau-interne, 2233, 7) exited non-zero on ‘PJSIP/ATA-LINE-040-000ece0c’
[Aug 24 06:54:40] == Using SIP RTP Audio TOS bits 184
[Aug 24 06:54:40] == Using SIP RTP Audio CoS mark 6
[Aug 24 06:54:40] – Executing [2313@garneau-interne:1] NoOp(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] – Executing [2313@garneau-interne:2] Goto(“PJSIP/U_6995-000ece0e”, “Lunetterie,2313,1”) in new stack
[Aug 24 06:54:40] – Goto (Lunetterie,2313,1)
[Aug 24 06:54:40] – Executing [2313@Lunetterie:1] NoOp(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] – Executing [2313@Lunetterie:2] Set(“PJSIP/U_6995-000ece0e”, “CDR(garneau_dst)=Lunetterie 2313”) in new stack
[Aug 24 06:54:40] – Executing [2313@Lunetterie:3] Set(“PJSIP/U_6995-000ece0e”, “CDR(garneau_userfield)=Carl Fortin 2674”) in new stack
[Aug 24 06:54:40] – Executing [2313@Lunetterie:4] Gosub(“PJSIP/U_6995-000ece0e”, “Sub_Set_Caller_ID,start,1()”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:1] NoOp(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:2] Set(“PJSIP/U_6995-000ece0e”, “CID_Trunk=PJSIP/U_6995-000ece0e”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:3] Set(“PJSIP/U_6995-000ece0e”, “CID_Trunk=U_6995-000ece0e”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:4] Set(“PJSIP/U_6995-000ece0e”, “CID_Trunk=U_6995”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:5] ExecIf(“PJSIP/U_6995-000ece0e”, “0?Set(FLAG=PRI)”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:6] ExecIf(“PJSIP/U_6995-000ece0e”, “0?Set(FLAG=PRI)”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:7] GotoIf(“PJSIP/U_6995-000ece0e”, “0?CID_PRI:CID_Interne”) in new stack
[Aug 24 06:54:40] – Goto (Sub_Set_Caller_ID,start,8)
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:8] NoOp(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:9] Set(“PJSIP/U_6995-000ece0e”, “CALLERID(num)=2674+A-0025-01”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:10] Goto(“PJSIP/U_6995-000ece0e”, “Fin”) in new stack
[Aug 24 06:54:40] – Goto (Sub_Set_Caller_ID,start,15)
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:15] NoOp(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Set_Caller_ID:16] Return(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] – Executing [2313@Lunetterie:5] Gosub(“PJSIP/U_6995-000ece0e”, “Sub_Lunetterie,start,1()”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Lunetterie:1] NoOp(“PJSIP/U_6995-000ece0e”, “Appel a la Lunetterie”) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Lunetterie:2] Set(“PJSIP/U_6995-000ece0e”, “CONNECTEDLINE(all,i)=“Lunetterie <2831>””) in new stack
[Aug 24 06:54:40] – Executing [start@Sub_Lunetterie:3] Answer(“PJSIP/U_6995-000ece0e”, “”) in new stack
[Aug 24 06:54:40] > 0x7fb066729810 – Probation passed - setting RTP source address to 10.188.4.31:16504
[Aug 24 06:54:40] – Executing [start@Sub_Lunetterie:4] Queue(“PJSIP/U_6995-000ece0e”, “lunetterie,R,300,”) in new stack
[Aug 24 06:54:40] – Started music on hold, class ‘Lunetterie’, on channel ‘PJSIP/U_6995-000ece0e’
[Aug 24 06:54:40] – Called PJSIP/01-A-A4934CFE2736
[Aug 24 06:54:40] == Using SIP RTP Audio TOS bits 184
[Aug 24 06:54:40] == Using SIP RTP Audio CoS mark 6
[Aug 24 06:54:40] – PJSIP/01-A-A4934CFE2736-000ece0f connected line has changed. Saving it until answer for PJSIP/U_6995-000ece0e
[Aug 24 06:54:40] – PJSIP/01-A-A4934CFE2736-000ece0f is ringing
[Aug 24 06:54:40] – Stopped music on hold on PJSIP/U_6995-000ece0e
[Aug 24 06:54:42] – PJSIP/01-A-A4934CFE2736-000ece0f answered PJSIP/U_6995-000ece0e
[Aug 24 06:54:42] – <PJSIP/01-A-A4934CFE2736-000ece0f> Playing ‘queue-thankyou.ulaw’ (language ‘fr’)
[Aug 24 06:54:42] > 0x7fb066729810 – Probation passed - setting RTP source address to 10.188.4.31:16504
[Aug 24 06:54:42] > 0x7fb065b96070 – Probation passed - setting RTP source address to 10.188.4.39:16484
[Aug 24 06:54:44] – Channel PJSIP/01-A-A4934CFE2736-000ece0f joined ‘simple_bridge’ basic-bridge <972defeb-bcde-409d-b087-c8e2a3dffc27>
[Aug 24 06:54:44] – Channel PJSIP/U_6995-000ece0e joined ‘simple_bridge’ basic-bridge <972defeb-bcde-409d-b087-c8e2a3dffc27>
[Aug 24 06:54:44] > Bridge 972defeb-bcde-409d-b087-c8e2a3dffc27: switching from simple_bridge technology to native_rtp
[Aug 24 06:54:44] > Remotely bridged ‘PJSIP/U_6995-000ece0e’ and ‘PJSIP/01-A-A4934CFE2736-000ece0f’ - media will flow directly between them
[Aug 24 06:54:44] > Remotely bridged ‘PJSIP/U_6995-000ece0e’ and ‘PJSIP/01-A-A4934CFE2736-000ece0f’ - media will flow directly between them

Is that set in periodic_announce or just queue_thankyou?
What happens when you run ‘queue reload all’ from the CLI?

It was set in the column called announce .I have a NULL value in periodic_announce.

Here is what I get from the cli:

queue reload all
[Aug 24 08:28:11] NOTICE[16067]: app_queue.c:8551 reload_queue_rules: queuerules.conf has not changed since it was last loaded. Not taking any action.

It still playing the queue-thankyou after reloading.

Try setting announce to no.

That fixed the problem. Does asterisk see NULL value as a No or a yes then?

Not sure, but if I had to guess, I’d say that the NULL just doesn’t replace what’s stored in the AstDB for that queue.

I do not see anything about queue in the astdb database.

It may only show if persistentmembers = yes. I don’t use it that way either.

Ok, thanks a lot for your help.