[asterisk-bugs] [Asterisk 0012437]: Asterisk negotiates only T.38 when answering even if the other end offers audio

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12437 
====================================================================== 
Reported By:                marsosa
Assigned To:                file
====================================================================== 
Project:                    Asterisk
Issue ID:                   12437
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     closed
Asterisk Version:           1.4.18 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2008-04-14 08:31 CDT
Last Modified:              2009-03-30 09:43 CDT
====================================================================== 
Summary:                    Asterisk negotiates only T.38 when answering even if
the other end offers audio
Description: 
One of our gateways (audiocodes mp-118) offers ulaw,g729 and t.38 when an
incoming call is sent to asterisk, and asterisk answer() with t.38 only,
instead of using ulaw. T.38 is enabled on the gateway because this is
needed for reinvites, if i disable it, the call works ok but fails later
when the ata wants to do reinvite for receiving faxes with t.38 '488 not
acceptable'.
The main problem here is that, after answering with t.38, asterisk sends
invites with t.38 only to the ip phones, and they rejected with not
acceptable.
====================================================================== 

---------------------------------------------------------------------- 
 (0102386) svnbot (reporter) - 2009-03-30 09:43
 http://bugs.digium.com/view.php?id=12437#c102386 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 184951

_U  branches/1.6.2/
U   branches/1.6.2/channels/chan_sip.c

------------------------------------------------------------------------
r184951 | file | 2009-03-30 09:43:12 -0500 (Mon, 30 Mar 2009) | 28 lines

Merged revisions 184948 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r184948 | file | 2009-03-30 11:37:47 -0300 (Mon, 30 Mar 2009) | 21 lines
  
  Merged revisions 184947 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14
lines
    
    Improve our handling of T38 in the initial INVITE from a device.
    
    We now answer with matching media streams to what is requested. If an
INVITE
    is received with both a T38 and RTP media stream this means we answer
with both.
    For any outgoing calls created as a result of this inbound one no T38
is requested
    in the initial INVITE. Instead if we start receiving udptl packets we
trigger a
    reinvite on the outbound side.
    
    (closes issue http://bugs.digium.com/view.php?id=12437)
    Reported by: marsosa
    Tested by: pinga-fogo, okrief, file, afu
    
    Review: http://reviewboard.digium.com/r/208/
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=184951 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-03-30 09:43 svnbot         Checkin                                      
2009-03-30 09:43 svnbot         Note Added: 0102386                          
======================================================================