On Tue, Dec 23, 2008 at 2:59 PM, Mindaugas Kezys <mke...@gmail.com> wrote: > > Looks very interesting. After reading all available info I have two > questions before testing: > > 1. Who/what answers the calls at the other end? I guess real live traffic > should be sent through this Asterisk server? > 2. How many calls you had made to to diagnose your problems? > > Thank you. > > Regards, > Mindaugas Kezys > http://www.kolmisoft.com > VoIP Billing and Routing Solutions >
Mindaugas, Thanks. 1) The same Asterisk system places the call and answers the call. You can use one technology to place the call and another to answer (but you don't have to). One connection is the control, the other is the variable. For instance, in my experiments I was testing SIP providers against one another and each other. I placed outbound calls to the SIP provider to a DID I had on a local PRI that came back into the same system running recqual. Recqual then (as designed) played audio in both directions while recording, like this: outbound call (to SIP provider, dialing DID on PRI below): <----- (audio in from inbound leg) ------> (audio out to outbound leg - not recorded, should always be perfect) Inbound call (from PRI): <----- (audio in from outbound leg) ------> (audio out to inbound leg - not recorded, should always be perfect) I know what the audio on both legs should look like so all I need to do is analyze it once it is returned to me. That way I can see how it changed from what Asterisk was supposed to be generating in the first place. This is how recqual is able to detect such a wide range of quality problems. 2) Depends on what you are testing for. For example, if you know you have a bad pair in a bundle of analog lines, you could just call all of the numbers a couple of times. Whichever number/pair has the worst audio (fails the test or looks the worst) is the bad pair. In the case of my SIP provider, they used outbound load balancing to send traffic to multiple media gateways and multiple trunk groups all over the country. Because we had no control over these routing decisions we had to make periodic calls for at least a day to detect the majority of the bad hosts/trunks/etc. -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
