Wow. What a wonderful response! Andrew Radke Yuruga Nursery Pty Ltd Clonal Solutions Australia Pty Ltd PO Box 220 Walkamin Qld 4872 Phone: (07) 4093 3826 Fax: (07) 4093 3869 Email: andrew.radke at yuruga.com.au Web: www.yuruga.com.au On 23/09/2008, at 8:56 PM, Benny Prijono wrote: > On Tue, Sep 23, 2008 at 8:08 AM, Andrew Radke <andrew.radke at yuruga.com.au > > wrote: > Hi, > > I hope this is a relatively simple question but I seem to be chasing > my tail around the Internet looking for a solution. > > > The question is always simple (but the answer most likely is not). :) Yes, I always want to run in the other direction when someone wants to ask me a simple or quick question for that exact reason! > > I need a music on hold service that supports G711 and G729 at a > minimum. I have converted the wav file to ulaw using sox and then to > G729 using this tool: http://www.asteriskguru.com/tools/audio_conversion.php > > The theory is that having it pre-encoded removes any requirement to > actually understand the codec you are streaming and reduces the > resource requirements to a minimum. > > > So if I read this correctly, you wanted to stream encoded audio from > a file to remote calls. Exactly. > > I'm hoping that this would be a very simple thing to do with PJSIP/ > PJMEDIA since it already has support for dealing with RTP whereas > most other frameworks I've found only do SIP, or where they do the > audio too they need to understand or transcode it. I would also hope > to end up with a simple set of files that can be copied onto a > target system without a huge range of libraries, etc being required > which also makes PJSIP look promising. > > If this isn't something that can be done with PJSIP a pointer in > right direction would also be heartily appreciated. > > > Of course it can be done. Do you not think PJSIP as a magic library > that can do everything? ;-) > > On a more serious note, pjmedia as a media library works mostly with > PCM frames and not encoded frames, for obvious reason. The RTP > streaming is done only at the edge of the processing where the > frames are sent/received to/from the transport/network, and this is > done by an object called stream (stream.c), where it does the > conversion between PCM frames and RTP packets. This includes > encoding/decoding the audio, managing the RTP/RTCP session, and de- > jitter-buffering on the RX side. Since this is only a transmitted stream could the de-jitter-buffering be ignored or is there something that needs to be done with regards to this on outbound traffic as well? Also, is there much that needs to be done to take the encoded data and convert into RTP packets? I assumed just a header or the like but I have no real knowledge of RTP just very rusty SIP. > So if you were to stream PCM WAV files, then it would have been > trivial to do, even the sample pjsua application can do this out of > the box. But of course the implication on the resources used and > codec licensing (for g729) would not be so trivial. > > Having said that, it should be possible to stream an encoded file to > the network; all one has to do is to create something like stream, > but instead of taking PCM audio as the input, it takes encoded audio > instead. And the rest such as the RTP/RTCP session management and de- > jitter-buffering would need to be reimplemented on this object in > similar ways like it's done in stream.c or siprtp.c from the sample. > This might sound like a daunting task, but actually it shouldn't be > that difficult, since all the lower level components are there > already, so it's just a matter of integrating them into a new higher- > level object. And it has been done by other people too. This makes sense to me (in the context of my above comment) and I'd be very happy to have a go at it except that I am not a programmer. As a sysadmin I'd knock this up in perl in short work if there was some sort of interface to it though. ;-) > Or alternatively, you can also hack stream.c so that it works with > encoded audio. We might do this sometime in the future since some > audio devices (such as APS on Symbian) are capable of doing hardware > encoding, but considering other stuffs that we need to do we don't > have concrete plan to do this yet. It sounds like it might be easier implemented as a separate set of function(s) since it would probably only use a very small amount of the stream.c code. > So there you go, the options are yours. :) At least I now have options. Thank you! Is there anyone else out there that would be interested in this functionality? > Cheers > Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080924/f004d688/attachment.html
