music on hold server using pre-encoded audio
Hi,
I hope this is a relatively simple question but I seem to be chasing
my tail around the Internet looking for a solution.
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.
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.
Regards,
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@yuruga.com.au
Web: www.yuruga.com.au
On Tue, Sep 23, 2008 at 8:08 AM, Andrew Radke andrew.radke@yuruga.com.auwrote:
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). :)
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.
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.
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.
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.
So there you go, the options are yours. :)
Cheers
Benny
Regards,
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@yuruga.com.au
Web: www.yuruga.com.au
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
On Tue, Sep 23, 2008 at 8:08 AM, Andrew Radke andrew.radke@yuruga.com.auwrote:
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). :)
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.
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.
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.
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.
So there you go, the options are yours. :)
Cheers
Benny
Regards,
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@yuruga.com.au
Web: www.yuruga.com.au
Visit our blog: http://blog.pjsip.org
pjsip mailing list
pjsip@lists.pjsip.org
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
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@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@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
On Wed, Sep 24, 2008 at 2:44 AM, Andrew Radke andrew.radke@yuruga.com.auwrote:
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?
Yeah, you don't need the jitter buffer then.
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.
Have a look at siprtp.c sample for a starting point. Currently it only put
PCMU in SDP, and it generates a silent PCMU frames in the outgoing RTP
packets. I think it shouldn't be too difficult to modify it to send g.729
instead in the SDP, and to generate the frame by reading from (encoded g729)
file instead.
Cheers
Benny