[Home]

Summary:ASTERISK-10317: [patch] [depend:codec expansion] AMR NB pass-through
Reporter:klaus3000 (klaus3000)Labels:
Date Opened:2007-09-17 08:30:40Date Closed:2011-06-07 14:02:38
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Codecs/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) amr-passthrough-trunk-r82546M.txt
( 1) amr-passthrough-trunk-r82546M-fixed.txt
( 2) amr-passthrough-trunk-r82546M-fixed.txt
Description:This adds pass-through of AMR narrow band to Asterisk's core, chan_sip and rtp.

Further, a format_amrnb.c was added which should store in RFC conform AMR files.

****** ADDITIONAL INFORMATION ******

I could not test the format_amrnb as I do not know how to force asterisk to store a file using format_amrnb. I tried app_record but it always wants to convert to SLIN first.
Comments:By: Jason Parker (jparker) 2007-09-17 14:20:35

You should be able to just use Record(myfile.amr), and as long as the channel is in amr, it should be fine.
By: Jason Parker (jparker) 2007-09-17 14:53:43

note: RFC 3267 describes how much of this must be handled.

edit: Actually, RFC 4867 obsoletes 3267


By: Jason Parker (jparker) 2007-09-17 15:29:20

I talked to Kevin about this, and we read the RFC, and we came to a conclusion...  If these can be solved reasonably, we'd be more than happy to include this.

There are several optional SDP parameters that if set, would make us unable to accept the call.  The main one would be mode-set.  If mode-set is set, it would require that we have the ability to transcode between the various modes.  Example: We setup a call between two endpoints.  One side uses mode-set=5, and the other end does not have mode-set set (which makes it default to allowing any of 0-7).  The second endpoint can at any time during the call decide that they want to switch to mode 4.  If we sent mode 4 audio to the first endpoint, we would be violating the RFC.

Since we're a B2BUA and not a proxy, it doesn't make much sense for us to tell the second leg to only send mode 5 audio (maybe?).

Per Kevin: "but we can't say 'we support AMR' if we would deny most of the calls".  Of course, it would really depend on how many endpoints would actually set these parameters.


Thoughts?
By: klaus3000 (klaus3000) 2007-09-17 16:27:35

This is a pass-through patch - thus transcoding is not support. We also have a working AMR codec for Asterisk http://sip.fontventa.com/trac/asterisk/browser/amr but:
1. Including a codec would require paying license fees
2. The code is GPL and not disclaimed

These are the main reasons that I have submitted a pass through patch to avoid the legal issus (pretty the same as G.729).

Recording: I tried Record(myfile.amr,10) but it did not worked. It tried to convert to slinear. Maybe it was due to the silence option (which is mandatory according to the documentation). I will try again tomorrow.

SDP options: The mode set is not only requested withthe SDP, but also with the CMR (codec mode request) byte in the RTP packet (the first byte of the payload).   Why not just forward the mode-set too (if the SDP was not already sent back)?

Nevertheless I would prefer starting with AMR pass through with all the SDP options support and add them when we encounter problems.

It think the octed-aligned mode option is more important to handle then the mode-set. Currently the patch only handles octed-aligned mode. This is also what is used by rtsp streaming servers and 3gp files. Thus, we used the RTP octed-aligned format in ast_frames. To support other modes too (and for reencdoing) we would either need a second frame format or ast_frame->subsubtype.

Conclusion: This is pass-through patch and thus can not handle transcoding issues (just like g729 or video pass through)
By: klaus3000 (klaus3000) 2007-09-18 02:25:55

Hi again!

I've just read the RFC again to find out how to announce multiple AMR capabilities. For example, if Asterisk supports AMR octet-aligned AND AMR bandwidth efficient mode it has to add 2 entries to the SDP, eg:

m=audio 49120 RTP/AVP 97 98
a=rtpmap:97 AMR/8000
a=rtpmap:98 AMR/8000
a=fmtp:98 octed-aligned=1

Thus, we have 2 possibilities:
1. Make different AST_FORMATs for the different AMR variants
2. Add a subsubtype (or a void *priv) member to ast_frame which can be used by codecs to store private/internal data

Solution 2 would be more flexible but does not allow transcoding from one AMR mode to another AMR mode as Asterisk sees only a single codec.
By: klaus3000 (klaus3000) 2007-10-01 01:11:19

hi! any comments ?
By: Matti Z (mattiz) 2007-10-10 05:32:22

Hi.

I'm new to Asterisk and I'm trying to add other codecs in pass-trough mode.
Are there any other files not decribed in this patch that must be configured to enable pass-through for a "new" codec in Asterisk?

Thanks in advance,
Matti Zemack
BBC R&I


By: klaus3000 (klaus3000) 2007-10-10 05:34:19

I guess "no" because my patch is working.
By: Matti Z (mattiz) 2007-10-10 05:51:31

Thanks.
By: klaus3000 (klaus3000) 2007-10-18 08:06:59

I fixed a small bug in the patch.
By: Tilghman Lesher (tilghman) 2008-10-09 19:06:36

Unassigning, as the codec_bits branch has been abandoned in favor of the media negotiation plans, as of AstriDevCon 2008.
By: klaus3000 (klaus3000) 2008-10-10 05:08:20

Sorry - what does this mean now?
By: Joshua C. Colp (jcolp) 2009-04-27 14:41:44

I am suspending this issue until such time as our new media architecture is complete. Once this is done this issue will be revisited, updated, and added. I urge you to participate in the media architecture discussion once it is brought to the development list so that you can help it become the best architecture it can be.

Thank you for your contribution.