Ring group max extensions? - Dial argument takes format (technology/resource)


(Mvogel4949) #1

I had a system calling large number of extensions and all of a sudden it just stopped. I follow the call in the logfiles and this seems to be where the call dies. With more testing I see that over 36 extensions I see the dial argument takes format message and then the call dies.

[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] pbx.c: Executing [s@macro-dial:31] ExecIf("SIP/wiresip1-000002be", "0?Set(ds=PJSIP/2010/sip:2010@10.101.0.73:65060&Local/902010@zulu-call&PJSIP/2011/sip:2011@10.101.0.50:65060&PJSIP/2009/sip:2009@10.101.0.70:65060&Local/902009@zulu-call&PJSIP/2001/sip:2001@10.101.0.116:65060&Local/902001@zulu-call&PJSIP/2003/sip:2003@10.101.0.52:5060&Local/902003@zulu-call&PJSIP/2005/sip:2005@10.101.0.71:65060&Local/902005@zulu-call&PJSIP/2004/sip:2004@10.101.0.63:65060&Local/902004@zulu-call&PJSIP/2007/sip:2007@10.101.0.92:5060&Local/902007@zulu-call&PJSIP/2006/sip:2006@10.101.0.69:65060&Local/902006@zulu-call&PJSIP/2012/sip:2012@10.101.0.67:65060&Local/902012@zulu-call&PJSIP/2013/sip:2013@10.101.0.59:65060&Local/902013@zulu-call&Local/904010@zulu-call&PJSIP/4045/sip:4045@10.20.20.47:65060&Local/904045@zulu-call&PJSIP/4027/sip:4027@10.20.17.31:65060&Local/904027@zulu-call&Local/904167@zulu-call&PJSIP/4116/sip:4116@10.20.16.10:65060&Local/904116@zulu-call&Local/904028@zulu-call&PJSIP/4008/sip:4008@10.20.20.106:65060&Local/904008@zulu-call&PJSIP/4086/sip:4086@10.20.20.188:65060&Local/904086@zulu-call&PJSIP/4108/sip:4108@10.20.20.109:65060&Local/904108@zulu-call&PJSIP/4029/sip:4029@10.20.20.110:65060&Local/904029@zulu-call&PJSIP/4021/sip:4021@10.20.16.151:65060&Local/904021@zulu-call&PJSIP/4173/sip:4173@10.20.20.176:65060&Local/904173@zulu-call&PJSIP/4022/sip:4022@10.20.16.213:65060&Local/904022@zulu-call&PJSIP/4053/sip:4053@10.20.16.202:65060&Local/904053@zulu-call&PJSIP/4478/sip:4478@10.20.16.197:65060&Local/904478@zulu-call&PJSIP/4848/sip:4848@10.20.16.203:65060&Local/904848@zulu-call&PJSIP/4148/sip:4148@10.20.20.90:65060&PJSIP/4160/sip:4160@10.20.20.97:65060&Local/904160@zulu-call&PJSIP/4087/sip:4087@10.20.16.144:65060&PJSIP/4427/sip:4427@10.20.20.185:65060&Local/904427@zulu-call&PJSIP/4473/sip:4473@10.20.16.212:65060&Local/904473@zulu-call&PJSIP/4112/sip:4112@10.20.20.87:65060&Local/904112@zulu-call&PJSIP/4124/sip:4124@10.20.16.207:65060&Local/904124@zulu-call&PJSIP/4157/sip:4157@10.20.16.137:65060&Local/904157@zulu-call&PJSIP/4049/sip:4049@10.20.20.94:65060&Local/904049@zulu-call&PJSg)") in new stack
[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] pbx.c: Executing [s@macro-dial:32] Dial("SIP/wiresip1-000002be", "PJSIP/2010/sip:2010@10.101.0.73:65060&Local/902010@zulu-call&PJSIP/2011/sip:2011@10.101.0.50:65060&PJSIP/2009/sip:2009@10.101.0.70:65060&Local/902009@zulu-call&PJSIP/2001/sip:2001@10.101.0.116:65060&Local/902001@zulu-call&PJSIP/2003/sip:2003@10.101.0.52:5060&Local/902003@zulu-call&PJSIP/2005/sip:2005@10.101.0.71:65060&Local/902005@zulu-call&PJSIP/2004/sip:2004@10.101.0.63:65060&Local/902004@zulu-call&PJSIP/2007/sip:2007@10.101.0.92:5060&Local/902007@zulu-call&PJSIP/2006/sip:2006@10.101.0.69:65060&Local/902006@zulu-call&PJSIP/2012/sip:2012@10.101.0.67:65060&Local/902012@zulu-call&PJSIP/2013/sip:2013@10.101.0.59:65060&Local/902013@zulu-call&Local/904010@zulu-call&PJSIP/4045/sip:4045@10.20.20.47:65060&Local/904045@zulu-call&PJSIP/4027/sip:4027@10.20.17.31:65060&Local/904027@zulu-call&Local/904167@zulu-call&PJSIP/4116/sip:4116@10.20.16.10:65060&Local/904116@zulu-call&Local/904028@zulu-call&PJSIP/4008/sip:4008@10.20.20.106:65060&Local/904008@zulu-call&PJSIP/4086/sip:4086@10.20.20.188:65060&Local/904086@zulu-call&PJSIP/4108/sip:4108@10.20.20.109:65060&Local/904108@zulu-call&PJSIP/4029/sip:4029@10.20.20.110:65060&Local/904029@zulu-call&PJSIP/4021/sip:4021@10.20.16.151:65060&Local/904021@zulu-call&PJSIP/4173/sip:4173@10.20.20.176:65060&Local/904173@zulu-call&PJSIP/4022/sip:4022@10.20.16.213:65060&Local/904022@zulu-call&PJSIP/4053/sip:4053@10.20.16.202:65060&Local/904053@zulu-call&PJSIP/4478/sip:4478@10.20.16.197:65060&Local/904478@zulu-call&PJSIP/4848/sip:4848@10.20.16.203:65060&Local/904848@zulu-call&PJSIP/4148/sip:4148@10.20.20.90:65060&PJSIP/4160/sip:4160@10.20.20.97:65060&Local/904160@zulu-call&PJSIP/4087/sip:4087@10.20.16.144:65060&PJSIP/4427/sip:4427@10.20.20.185:65060&Local/904427@zulu-call&PJSIP/4473/sip:4473@10.20.16.212:65060&Local/904473@zulu-call&PJSIP/4112/sip:4112@10.20.20.87:65060&Local/904112@zulu-call&PJSIP/4124/sip:4124@10.20.16.207:65060&Local/904124@zulu-call&PJSIP/4157/sip:4157@10.20.16.137:65060&Local/904157@zulu-call&PJSIP/4049/sip:4049@10.20.20.94:65060&Local/904049@zulu-call&PJSb(func-apply-sipheaders^s^1),") in new stack
[2020-09-05 22:26:03] WARNING[8551][C-00000316] app_dial.c: Dial argument takes format (technology/resource)
[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] app_macro.c: Spawn extension (macro-dial, s, 32) exited non-zero on 'SIP/wiresip1-000002be' in macro 'dial'
[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] pbx.c: Spawn extension (ext-group, 528, 20) exited non-zero on 'SIP/wiresip1-000002be'
[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] pbx.c: Executing [h@ext-group:1] Macro("SIP/wiresip1-000002be", "hangupcall,") in new stack
[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] pbx.c: Executing [s@macro-hangupcall:1] GotoIf("SIP/wiresip1-000002be", "1?theend") in new stack
[2020-09-05 22:26:03] VERBOSE[8551][C-00000316] pbx_builtins.c: Goto (macro-hangupcall,s,3)

(Itzik) #2

It means that the Dial arguments doesn’t contain the correct technology, resources and/or options. So it cannot execute the Dial()

Is this a custom dialplan? Can you give us a little more details of how the calls are placed, routed etc?


(Mvogel4949) #3

That’s the crazy part. No custom dialplan. Just a call to a RG comprised of local extensions. If I trim the list back to around 36 it works. Any more than 36 in the RG and I see the Dial argument message and the call fails.


#4

I don’t know where the limit is, but there are (at least) two workarounds: Have multiple devices register to the same extension in pjsip, and/or use cascaded Ring Groups.

However, IMO disturbing dozens of people for one phone call is not a good idea. Some of them will start to answer, only to discover that someone else already got the call. Better to initially present the call to two or three ‘receptionists’; if unanswered within e.g. ten seconds, continue to ring them but start ringing some others, perhaps playing an announcement to the caller that an agent will be with them shortly.

If this is for ‘night’ service, ring a few phones such that one can be heard everywhere in the office. A user at a non-ringing phone can answer using his ‘group pickup’ key or code.


(Mvogel4949) #5

I think you might be right here. The system also has 160 zulu licenses to a call to an extension is really 3 calls. It starts to multiple and a RG of 30 becomes a RG of 90


(Lorne Gaetz) #6

Hi Mark

There are line length limits for Asterisk conf files that you are hitting with such a large ring group. If you can’t reduce the number of devices (which seems like the right approach here), try using a queue instead.


(Mvogel4949) #7

HI Lorne, always appreciate your help. I’ll test that. The system also has around 160 zulu licenses so a call to 30 extensions is actually 90 calls once you factor in desk phone, zulu desktop and zulu mobile. I doubt that is helping but it’s a large business that handles a lot of calls. They don’t use zulu mobile so I was hoping to turn those “calls” off but I’m not sure if you can turn just the Zulu mobile calls off.


(system) closed #8

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.