[asterisk-dev] SIPP Testing

Greg Boehnlein damin at nacs.net
Wed Jun 7 17:13:24 MST 2006


Hello,
	I am working on a bunch of issues, one of which is trying to track 
down proof that using CONFIG_ZAPTEL_MMX w/ a Centos 4.3 2.6.9-34.0.1 
kernel causes FPU errors w/ various codecs. This requires me to have a 
high volume of SIP calls doing lots of Ulaw to G729 transcoding over a 
period of time, using a modified g729 binary from Digium that logs when 
the errors occur.
	In doing this testing, I have setup a box w/ the latest SIPP 
traffic generator (http://sipp.sourceforge.net) to make boatloads of 120 
second calls to a Music On Hold extension that simply plays Ulaw based 
MOH to the caller.

I'm accomplishing this w/ the following command;

./sipp -sn uac -d 120000 -s 451 gw4.n2net.net -l 300 -mp 5606 -i 207.166.192.254

Now.. from all the reading that I've done, what this should do is place a 
call to the Asterisk server (extenion 451). That part works.

I can see that the calls are coming in:

gw4*CLI> show channels 
[deleted]
300 active channels
300 active calls

And.. I see that they are g729:

gw4*CLI> sip show channels 
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message   
[deleted]
207.166.192.254  sipp        2-16898 at 207  00101/00001  g729  No       Rx: ACK        
207.166.192.254  sipp        1-16898 at 207  00101/00001  g729  No       Rx: ACK        
300 active SIP channels
	
However, it does not appear as if any RTP is actually being send back to 
the SIPP server. An RTP debug shows no RTP packets between the boxes.

Examining the SIP headers, I see the following:

--- (11 headers 7 lines)---
Using INVITE request as basis request - 1-16858 at 207.166.192.254
Sending to 207.166.192.254 : 5060 (non-NAT)
Found user 'sipp'
Found RTP audio format 0
Peer audio RTP is at port 207.166.192.254:5606
Found description format G729
Capabilities: us - 0x100 (g729), peer - audio=0x104 (ulaw|g729)/video=0x0 (nothing), combined - 0x100 (g729)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)

Looks good to me. We should send g729 media to 207.166.192.254:5606 (The 
SIPP RTP Media Echo port)

Anyways.. I fear that because no RTP packets are actually being 
transmitted there is no actual transcoding going on. With 300 channels of 
g729, the load should be a lot higher than "0.01".

Anyone have any suggestions?

-- 
    Vice President of N2Net, a New Age Consulting Service, Inc. Company
         http://www.n2net.net Where everything clicks into place!
                             KP-216-121-ST






More information about the asterisk-dev mailing list