[asterisk-users] Unique call ID's across several systems

[Steve Totaro]

Matt Florell wrote:
> On 10/24/06, Steve Edwards <asterisk.org at sedwards.com> wrote:
>> On Sat, 21 Oct 2006, Jeremy McNamara wrote:
>>
>> > Steve Edwards wrote:
>> >> I have a farm of 7 1u's) with te410p's. When a call comes in, I 
>> call an AGI
>> >> that creates a channel variable named GLOBALID. The GLOBALID is 2 
>> digits
>> >> for the host number, 2 digits for the channel number, and 8 
>> characters for
>> >> the UNIQUEID encoded in hex.
>> >>
>> >> Then, I stuff it into CALLERID(name) so it will be available as 
>> the call is
>> >> sent (using dial()) to the application servers.
>> >
>> > AGI is not going to scale.  Why not do it all with dial plan logic? 
>> Store a
>> > global system id for each system and concat it onto the uniqueid 
>> CDR value.
>>
>> Our need for a globalid (in addition to our needs) was mandated by our
>> credit card processor. They also limited us to length, upper case 
>> letters
>> and digits -- not even a lowly period was acceptable to them :)
>>
>> To fit the host, channel, and unique id in I decided to encode the 
>> unique
>> as hex. This system was designed before dialplan functions and I didn't
>> see an easy "dialplan way" to encode to hex, so I cranked out an AGI.
>>
>> I don't know how fast a dialplan implementation would be (if a hex
>> function was available), but I benched the AGI approach and the server
>> does 1,000 in about 4 seconds.
>>
>> I'm sure your knowledge of telephony far exceeds mine, Jeremy. For a
>> system with only 92 channels can the telco deliver more than 92 calls in
>> 0.4 seconds over PRI?
>>
>> The average call duration for this system is about 10 minutes, so the
>> probability of all 92 channels being free at the same time is rather
>> small.
>>
>> I always wondered how much overhead invoking an AGI incurred. Setting up
>> the AGI environment, spawning a new process, parsing the AGI 
>> environment,
>> doing something useful, terminating the AGI process -- it sounds like it
>> would take forever. Now I know it only takes about 40 msec.
>
> Have you tried using a FastAGI server script instead of a stand-alone
> AGI script?
>
> We saw dramatic improvement in speed and performance when we switched
> our logging functions to FastAGI from AGI.
>
> MATT---

We did as well.  The performance of a local standard AGI decreased over 
time.  I didn't have the time to figure out why so we just switched to 
fastagi on a remote host (Windows Service) and applied the patch that 
allows for n + 101 priority jumping in case of fastagi failure.  HUGE 
improvement.

Since then, I have had the opportunity to get root on a commercial 
asterisk "black box solution" and they also use fastagi but it is 
running on the localhost (127.0.0.1).  I have not looked at the agi yet 
but assume that running it locally is even smarter.

Thanks,
Steve Totaro