[asterisk-dev] SIPP Testing

[Dan Austin]

The internal timing patch on Mantis might help, as that decouples
the outbound RTP from the inbound.

Dan

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Greg
Boehnlein
Sent: Wednesday, June 07, 2006 5:13 PM
To: asterisk-dev at lists.digium.com
Subject: [asterisk-dev] SIPP Testing

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



_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev