The internal timing patch on Mantis might help, as that decouples the outbound RTP from the inbound.
Dan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Greg Boehnlein Sent: Wednesday, June 07, 2006 5:13 PM To: [email protected] 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 [EMAIL PROTECTED] 00101/00001 g729 No Rx: ACK 207.166.192.254 sipp [EMAIL PROTECTED] 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 - [EMAIL PROTECTED] 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 _______________________________________________ --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
