Summary:ASTERISK-01524: [patch] a new channel group for calls aggregation
Reporter:cybershield (cybershield)Labels:
Date Opened:2004-05-03 10:45:11Date Closed:2004-09-25 02:48:25
Versions:Frequency of
Description:This patch adds an identifier to individual calls allowing them to be grouped. This feature then permit counting of calls sent to each destination resource. This patch extent the capability till now available only on CHAN_SIP module with INCOMINGLIMIT static option to any kind of chan tecnology. If you need to limit the maximum number of calls permitted towards a resource, you can set it dynamically.
The group identifier and any related operation is executed in extension.conf (es: counting call of one group).
The groups identifiers does not need to be defined before use them.

Extension command:
SetGroupId(<idgroup>) -> set <idgroup> to active channel.

Extension variable:
${GROUPID} -> return a group id of active channel
${GROUPIDCOUNT(<idgroup>)} -> return the number of channels having group <idgroup>.

CLI command:
show groups -> shows all assigned groups information
show group <idgroup> -> shows all channels grouped into <idgroup>

AGI command:
set groupid <idgroup>


exten => 3X.,1,SetGroupId(gsm)
exten => 3X.,2,GotoIf(${GROUPIDCOUNT(gsm)}>5?3:4)
exten => 3X.,3,Congestion()
exten => 3X.,4,Dial(Zap/g1/${EXTEN})

This example shows how to limit bridging to only 5 gsm calls. Each call could income independently from any chan technology (Zap/Sip/Iax/...).
Comments:By: zoa (zoa) 2004-05-03 12:33:14

This looks quite useful to me, although it would probably more appropriate to link a call to an group using the sip.conf & iax.conf etc and have a config file to set the limits for the groups.

For example, lets say i have 100 clients, and they all need a limit of 1 connection, then i'd need 100 new extension to create 100 different groups.

But if you just want to limit the resources for sip or zap, this is a usefull patch.

Any comments if this could break something ?

By: Brian West (bkw918) 2004-05-03 12:33:24

diff -u please... and BRAVO good work.


By: Brian West (bkw918) 2004-05-03 12:36:52

zoa his idea works better than the per chan_* drama.

I like this.


By: zoa (zoa) 2004-05-03 12:41:08

yeah, i also like it, it has a lot of possibilities, just not for per user limits... (at least i think).

By: Brian West (bkw918) 2004-05-03 12:44:46

exten => _X.,1,SetGroupId(${EXTEN})
exten => _X.,2,GotoIf(${GROUPIDCOUNT(${EXTEN})}>5?3:4)
exten => _X.,3,Congestion()
exten => _X.,4,Dial(Zap/g1/${EXTEN})

Now toss some dgget's in that mess and you can limit an inbound DID to X channels.

PS: not sure if ${EXTEN} would get substituted or not. If not it SHOULD!

By: Brian West (bkw918) 2004-05-03 12:48:23

on that note you could use account code to limit also :P

By: cybershield (cybershield) 2004-05-03 13:55:02

for bkw918:

if i well understand your example allows a customer ( a phone-number) to receive a maximum of 5 contemporary call.

The argument of SetGroupId is a string, then you can use whatever you want.

for zoa:

how do you intend idendify in the extension.conf the 100 clients? ..using the calling-id? In this case you can use as group-id the calling-id.

By: cybershield (cybershield) 2004-05-03 15:06:48

for bkw918:

Add cvs diff -u version !!! Sorry ;)
how do cancels the old diff file (groupchannel.diff (7,501 bytes) 05-03-04 10:45) ?

for zoa:

exten => _X.,1,SetGroupId(${CALLERIDNUM})
exten => _X.,2,GotoIf(${GROUPIDCOUNT(${CALLERIDNUM})} > 1 ? 3 : 4)
exten => _X.,3,Congestion()
exten => _X.,4,Dial(Zap/g1/${EXTEN})

This example permit to any clients only one contemporary call...for every number of client ... 1 ... 10 ... 100 ... 1000 !!!

By: Mark Spencer (markster) 2004-05-03 16:57:09

Why don't we just use the existing variable construct to do this?  In otherwords, I don't see why group ID should be a new field in a channel vs. just a variable.  I'll be happy to implement it if it's done with a channel variable instead of a field in the channel structure itself.

By: cybershield (cybershield) 2004-05-04 04:19:27

Which is the problem to add a field in the channel structure ?

By: zoa (zoa) 2004-05-04 05:42:46

cybershield: darn you are right ! :)


By: Mark Spencer (markster) 2004-05-04 10:17:31

The channel structure should only contain things which are used in virtually every call, or which are accessed with great frequency when they are used.  Remember that when you add something to the channel structure, *every* channel in the whole system has to add that feature and if, perchance, anyone has an application that isn't compiled with asterisk, it would have to be recompiled.

It's not that the channel structure is killer, but should be avoided if reasonable, and in this case, I see absolutely no reason why this couldn't be done with just a channel variable -- do you?

By: cybershield (cybershield) 2004-05-04 11:11:21

Ok mark.
Rewrite the patch with channel variable.

By: alric (alric) 2004-05-04 11:18:34

Deleted old diffs, per cybershield's request.

By: Mark Spencer (markster) 2004-05-04 12:03:03

Okay, it's in CVS.

Check out app_groupcount.  It supplies the following functions:

SetGroup(group) -- sets the group name on the channel
GetGroupCount([group]) -- gets the group count for the specified group or the
  one the channel is in, if not specified
CheckGroup(max) -- checks whether the total number of channels exceeds max and
               return -1 (or skips to n+101) if it does, or continues if not.

By: Mark Spencer (markster) 2004-05-04 12:03:22

Equivalent functionality added to CVS.