Summary:	ASTERISK-06380: [patch] app_trunkisavail.c - load balancing between mulitple trunks
Reporter:	Edwin Groothuis (mavetju)	Labels:
Date Opened:	2006-02-20 19:48:45.000-0600	Date Closed:	2011-06-07 14:02:37
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Applications/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) patch-loadbalancing-1
Description:	This application is similar to ChanIsAvail(), except that it returns trunks instead of channels. The reason for this is that that ChanIsAvail() isn't atomic enough for our PABX which often gets two calls at nearly the same time, and letting ChanIsAvail return the same channel. TrunkIsAvail has two parameters: trunks and options. Trunks can be "Zap/g1" and "Zap/g1&Zap/g2&Zap/g3" or "g1" and "g1&g2&g3". Options can be "f", for "get the first one which is free, or "l" which returns the least busy trunk. For "l", if g1 has 30 channels and 12 channels in use, and g2 has 30 channels and 2 channels in use, it will return g2 because it has the most free channels (28). On the other hand, if g1 has 30 channels and 12 channels in use, and g2 has 20 channels and 4 channels in use, it will return g1 because it has the most free channels (18). At this moment the application is its own file, but due to the requirement of being able to access the information in channels/chan_zap.c, the long term solution would be to move it to chan_zap.c. The short term solution is to add "chan_zap.so => yes" to the [global] section of modules.conf.
Comments:	By: puzzled (puzzled) 2006-02-21 05:24:28.000-0600 Nice patch. Unfortunately I couldn't make it compile on 1.2. Any chance a 1.2 compatible version is made available too? By: Edwin Groothuis (mavetju) 2006-02-21 05:33:26.000-0600 What didn't work on 1.2 for you? I admit my chan_zap.c is pretty polluted with "improvements", but I didn't think it would be that bad. Let me know and I'll fix it in the morning. By: puzzled (puzzled) 2006-02-22 07:11:57.000-0600 The compilation failure below is on 1.2 svn rev 10707. If you need more info please let me know. Thanks. gcc -c  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -DZAPTEL_OPTIMIZATIONS          -m64 -fomit-frame-pointer  -DT38_SUPPORT -Wno-missing-prototypes -Wno-missing-declarations -DIAX_TRUNKING -DCRYPTO -fPIC  -o chan_zap.o chan_zap.c chan_zap.c: In function 'zap_channel_count': chan_zap.c:9597: error: 'pris' undeclared (first use in this function) chan_zap.c:9597: error: (Each undeclared identifier is reported only once chan_zap.c:9597: error: for each function it appears in.) chan_zap.c:9598: error: dereferencing pointer to incomplete type chan_zap.c:9606: error: dereferencing pointer to incomplete type chan_zap.c:9608: error: dereferencing pointer to incomplete type chan_zap.c: In function 'setup_zap': chan_zap.c:10426: warning: ignoring return value of 'sscanf', declared with attribute warn_unused_result chan_zap.c:10429: warning: ignoring return value of 'sscanf', declared with attribute warn_unused_result chan_zap.c:10432: warning: ignoring return value of 'sscanf', declared with attribute warn_unused_result make[1]: *** [chan_zap.o] Error 1 By: Edwin Groothuis (mavetju) 2006-02-23 17:00:55.000-0600 gcc -c  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE   -march=i686 -DZAPTEL_OPTIMIZATIONS         -Wno-missing-prototypes -Wno-missing-declarations -DZAPATA_PRI -DIAX_TRUNKING -DLINUX -DCRYPTO -fPIC  -o chan_zap.o chan_zap.c gcc -shared -Xlinker -x -o chan_zap.so chan_zap.o  -lpri  -ltonezone It comes because you don't have ZAPATA_PRI defined. That one is defined when libpri is installed (channels/Makefile:95). Do you have libpri installed, or do you have (no offense intended) some strange PRI card? By: puzzled (puzzled) 2006-02-24 04:00:20.000-0600 Thanks for pointing out that define. I checked channels/Makefile and it seems /usr/lib/ is hardcoded. Since I have 64bit libpri stuff in /usr/lib64 it could obviously not find them. Patched it and all is well now. By: puzzled (puzzled) 2006-02-24 07:09:41.000-0600 Unfortunately I spoke too soon. It compiles fine but when I start asterisk with $ asterisk -c -g -vvvv -dddd -U asterisk -G asterisk I get: [app_trunkisavail.so]Feb 24 15:06:44 WARNING[17400]: loader.c:325 __load_resource: //usr/lib64/asterisk/modules/app_trunkisavail.so: undefined symbol: zap_channel_count Any ideas? Thanks. By: Edwin Groothuis (mavetju) 2006-02-24 14:40:04.000-0600 See last paragraph: The short term solution is to add "chan_zap.so => yes" to the [global] section of modules.conf. By: Olle Johansson (oej) 2006-03-09 14:50:46.000-0600 I think this should be named with "zap" in it because it is not generic to trunks, it's only for zap trunks. By: Olle Johansson (oej) 2006-04-07 02:14:50 Comment? By: Kevin P. Fleming (kpfleming) 2006-04-11 17:22:06 I'm not sure I agree with the idea here... you understand that none of this is 'atomic' at all, and that just because your app returns that a 'trunk' is available is no guarantee that it will be when the next dialplan step is executed? Besides that... how is this better than just extending ChanIsAvail() to accept Zap group designations? By: Serge Vecher (serge-v) 2006-05-05 15:23:32 mavetju: are you able to extending ChanIsAvail() as per Kevin? By: Serge Vecher (serge-v) 2006-05-12 12:33:09 mavetju: please feel free to reopen when an updated patch is available. Thanks.