Hi, the payload with PCM is 64 kbit/s, but you have to add RTP/UDP/IP header which is 40 Bytes for each frame. With ordinary PCM you have 50 frames per second so the real bit rate is 50*40*8=16 kbit/s. so in total you will get 80 kbit/s = 10Kbytes/s On top if this you have some additional info SIP+RTCP which is usually ?2 kbit/s. I?m not sure why you get 20Kbytes/s this seems very high. What you can to is use a low bit rate codec G729 is ~8kbit/s, send more then one frame/packed (ptime in PJSIP) this will however increase your delay. You could try do setup a sendonly in SDP , see what happens if you have a call on hold. BR/Olle _____ From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Nguyen Van Minh Danh Sent: den 21 juni 2009 09:28 To: pjsip at lists.pjsip.org Subject: optimizing bandwidth usage for IVR applications writtenusing PJSIP I am using PJSIP 1.2 to write an IVR application capable of handling high cal volume. With PCMU codecs I observe the following bandwidth usage for an individual call: + Download bandwidth: ~20 KBytes/s for every call. This is assuming to be the incoming audio. + Upload bandwidth: very low (~300 bytes/s) when no IVR playback (e.g. wave file playback) is done AND ~20KBytes/s when IVR is playing back. I am running with null audio device so there should be no outgoing audio unless during IVR playback. With the above my code can only handle up to 20 calls on a 8Mbps (down)/1Mbps (up) connection. With higher number of calls the download bandwidth is pushed to its limit, affecting the upload bandwidth and the IVR will be unable to playback. A lot of "timed out trying to acquire PJSUA mutex...." error messages are displayed. I use pjsua_codec_set_priority to force the media stack to use GSM codec (my provider only supports PCMA, PCMU, GSM and G729). The bandwidth is reduced as follows: + Download: ~7KBytes/s. + Upload: ~300bytes/sec with no IVR playback and ~7KBytes/s during IVR Playback With this codecs my code can run up to 40 concurrent calls. Messages "timed out trying to acquire PJSUA mutex...." are displayed occasionally but the errors are non-fatal. My questions are as follows: (1) Why does the actual bandwidth differs too much from the theoretical bandwidth? What overheads are there in the actual bandwidth consumption? According to most websites, PCMU is said to have a bit rate of 64kbps (e.g. 8KBytes/sec), yet my testing yields ~20KB/s. GSM is said to have 13kbps but my testing yields ~8KB/s. (2) What other codecs can I try to save as much bandwidth as possible? I am looking at 100 concurrent calls on a connection of 8Mbps (down)/1Mbps (up), or even better, 2Mbps down/512kbps (up). (3) Since I am writing an IVR application, I don't care much about the incoming audio stream, e.g. I don't need to hear the voice from the remote end, be it ringing tone or a human voice. I only need to play back audio to the remote end (e.g. outgoing audio) and detect when DTMF is pressed. Are there any commands that I can use to tell PJSIP not to download the incoming audio stream while still informing me about the incoming DTMF? If possible, this will save a lot of download bandwidth. Or is it that the on_dtmf_digit is done on the client side by PJSIP and the incoming audio stream has to be downloaded in full before any DTMF can be detected? Any help is appreciated. Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090621/67354038/attachment-0001.html>
