[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