[asterisk-bugs] [Asterisk 0010741]: [patch] AMR NB pass-through

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10741 
====================================================================== 
Reported By:                klaus3000
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10741
Category:                   Core-General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:            SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 82546 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             09-17-2007 08:30 CDT
Last Modified:              09-17-2007 15:29 CDT
====================================================================== 
Summary:                    [patch] AMR NB pass-through
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.
====================================================================== 

---------------------------------------------------------------------- 
 qwell - 09-17-07 15:29  
---------------------------------------------------------------------- 
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? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
09-17-07 15:29  qwell          Note Added: 0070699                          
======================================================================