Queue Callee and Caller identification

Hello I’m trying to find a way to log the callee and the caller number when a call is answered from queue. I tried as much variables as I was able to find… Here is my dialplan:

exten => 1006,1,Verbose(2,${CALLERID(all)} entering the support queue)
same => n,Queue(support,c,,,,,,sub-answer)
same = n,Verbose(2,CALLID 1: ${UNIQUEID} GOSUB: ${GOSUB_RETVAL})
same => n,Set(CALLID=${GOSUB_RETVAL})
same => n,Hangup()
exten = s,1,NoOp()
same = n,Set(EXTENSION=${CUT(CUT(CHANNEL,-,1),/,2)})
same => n,Return(${UNIQUEID})


     == Setting global variable 'SIPDOMAIN' to ''
    -- Executing [1006@gateway:1] Verbose("PJSIP/18015577-00000016", "2,"Teste" <18015577> entering the support queue") in new stack
  == "Teste" <18015577> entering the support queue
    -- Executing [1006@gateway:2] Queue("PJSIP/18015577-00000016", "support,c,,,,,,sub-answer") in new stack
    -- Music class  requested but no musiconhold loaded.
    -- Called PJSIP/1001
    -- PJSIP/1001-00000017 is ringing
    -- PJSIP/1001-00000017 is ringing
       > 0x7f9e1004ab20 -- Strict RTP learning after remote address set to:
    -- PJSIP/1001-00000017 answered PJSIP/18015577-00000016
    -- PJSIP/1001-00000017 Internal Gosub(sub-answer,s,1) start
    -- Executing [s@sub-answer:1] NoOp("PJSIP/1001-00000017", "") in new stack
    -- Executing [s@sub-answer:2] Set("PJSIP/1001-00000017", "EXTENSION=1001") in new stack
    -- Executing [s@sub-answer:3] Verbose("PJSIP/1001-00000017", "2,CALLID 2: 1552343877.37 NUM:1001 BridgePeer:    1001 0 "Customer" <1001>  Customer 1001  0 0 0 0 ") in new stack
  == CALLID 2: 1552343877.37 NUM:1001 BridgePeer:    1001 0 "Customer" <1001>  Customer 1001  0 0 0 0
    -- Executing [s@sub-answer:4] Return("PJSIP/1001-00000017", "1552343877.37") in new stack
  == Spawn extension (gateway, 1006, 1) exited non-zero on 'PJSIP/1001-00000017'
    -- PJSIP/1001-00000017 Internal Gosub(sub-answer,s,1) complete GOSUB_RETVAL=1552343877.37
       > 0x7f9e1001a380 -- Strict RTP learning after remote address set to:
    -- Channel PJSIP/1001-00000017 joined 'simple_bridge' basic-bridge <4b011c8a-642b-45a7-968c-6329af96a4d2>
    -- Channel PJSIP/18015577-00000016 joined 'simple_bridge' basic-bridge <4b011c8a-642b-45a7-968c-6329af96a4d2>
       > Bridge 4b011c8a-642b-45a7-968c-6329af96a4d2: switching from simple_bridge technology to native_rtp
       > Locally RTP bridged 'PJSIP/18015577-00000016' and 'PJSIP/1001-00000017' in stack
       > 0x7f9e1001a380 -- Strict RTP switching to RTP target address as source
       > 0x7f9e1004ab20 -- Strict RTP switching to RTP target address as source
    -- Channel PJSIP/1001-00000017 left 'native_rtp' basic-bridge <4b011c8a-642b-45a7-968c-6329af96a4d2>
    -- Channel PJSIP/18015577-00000016 left 'native_rtp' basic-bridge <4b011c8a-642b-45a7-968c-6329af96a4d2>
    -- Executing [1006@gateway:3] Set("PJSIP/18015577-00000016", "CALLID=") in new stack
    -- Executing [1006@gateway:4] Hangup("PJSIP/18015577-00000016", "") in new stack
  == Spawn extension (gateway, 1006, 4) exited non-zero on 'PJSIP/18015577-00000016'

I need these numbers: 1001 answered 18015577 … I also tried to link both calls using UNIQUEID so I can retrieve the number however my GOSUB_RETVAL=1552343877.37 it is not working with Set(CALLID=${GOSUB_RETVAL})

Thanks !

What’s wrong with CDRs?

1 Like

I need to know these numbers when the call is answered. If GOSUB_RETVAL works I can link both calls them I’m able to know both numbers…other ways is if exits any variables to check it… If you have other suggestion to do it please let me know ! Thanks !

If you need real-time data Can you use AMI? There are manager events for queues.

I’m going to check the possibility but for me it is a very simple feature to know the extension and the customer number who are connected.

Thanks for helping !

No extensions are involved.

I’m fairly sure that the queue log contains the required information, although you might need to map a channel unique ID to a a channel name.

Have you tried looking at the work in progress values for the CDR?

Knowing how you are going to use the information may help. You can reasonably assume that there are easy ways of getting the information that people normally want to get, although a little bit of research may be needed.

Note that most people doing complex things with queues will be using AMI and looking at AMI events.

Dont know why this variable is empty, try adding __

sub-answer is run on the Callee channel, via the queue app and has no access to anything from the calling channel. I don’t think you can return values back from it. You might be able to use Shared vairables and pass the channel id in when calling sub-answer, but not something I’ve tried.

Something like

same => n,Queue(support,c,,,,,,sub-answer(${CHANNEL})

Which should be available as ${ARG1} in the sub-answer channel.

Also you can access the PJSIP variables via the Channel App

same => n,Log(NOTICE, ${CHANNEL(pjsip,call-id)})
1 Like

Hello techman83 thanks for your opinion… I’m not able to pass arg by Queue goto as you mentioned I seems that is no a syntax error some hardcore restriction. Anyway I used CHANNEL(pjsip,…) options and find a way to link all calls… Thanks ! xD

Glad you found a way! Just checked and it looks like you can’t. The documentation subtly suggests that is the case, it’s not incredibly clear that you can’t.

gosub - Will run a gosub on the called party’s channel (the queue member) once the parties are connected. The subroutine execution starts in the named context at the s exten and priority 1.

@techman83 thanks for the documentation , I just reviewed and see the reason why variable was empty, was available only on the on the called party’s channel (the queue member), also this variable could be accesible on the calling channel using import()

1 Like

@techman83 and @ambiorixg12 Thank you both !

1 Like