Thanks, Benny. The main issue is that our poor IP stack has trouble handling the UDP packet rate. The underpowered CPU needs to be relieved from the many interrupts and protocol processing tasks. It copes very well with the relatively simple audio level processing. We do have some influence on both sides of the line so we may be able to convince the peer that the ptime is no wish but a demand. Open to any other suggestions, Hoppie From: pjsip [mailto:pjsip-bounces@xxxxxxxxxxxxxxx] On Behalf Of Benny Prijono Sent: Monday, March 10, 2014 4:19 AM To: pjsip list Subject: Re: Where to start: reduce network packet rate Hi, There is a SDP "ptime" attribute that you can add to your SDP, but AFAIK this is just merely an indication to peer about our preference ptime. The peer may or may not adhere to this. Can't you buffer the packets and process them at reduced rate? Best regards, Benny On Wed, Mar 5, 2014 at 8:54 PM, Jeroen Hoppenbrouwers <jHoppenbrouwers at avionica.com<mailto:jHoppenbrouwers at avionica.com>> wrote: Hi all, For an embedded project using uClinux on a virtual CPU at 80 MHz, we deploy PJLIB/PJSIP as the audio transport. It sits in between our codec hardware (16-bit 8000 Hz no frills) and a standards-compliant SIP/RTP network link over Ethernet. The SIP link may go directly to the peer (the same software on another box) or be routed through Asterisk for conferencing. Three of these bi-directional audio links can be active at the same time on the box. It all works, but we have issues with the many Ethernet/UDP/RTP packets that flow around. Our minimal hardware has trouble coping with the sirq and CPU load. A very crude hack suggested that halving the RTP packet rate by doubling the content significantly reduced the problem. However I have trouble cleanly setting up the SDP negotiation to ask the peer for double-content/half-rate. I can fix myself, but not the other side, so to say. Current packet length (ptime?) is 20ms, 320 bytes (160 samples of 16 bits). I'd like to get to 640 or 1280 bytes instead (MTU is 1500 bytes). Latency is less of a problem in our application. Q: where do I need to start looking in the PJLIB stack for this setting, and what am I actually looking for exactly? Is this done at the codec layer, at the pjmedia layer, at the SIP toplevel layer? Etc. Best regards, Jeroen Hoppenbrouwers _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip at lists.pjsip.org<mailto:pjsip at lists.pjsip.org> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20140310/288a3069/attachment-0001.html>
