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

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12437 
====================================================================== 
Reported By:                marsosa
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12437
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     confirmed
Asterisk Version:           1.4.18 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             04-14-2008 08:31 CDT
Last Modified:              06-16-2008 16:54 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.
====================================================================== 

---------------------------------------------------------------------- 
 samdell3 - 06-16-08 16:54  
---------------------------------------------------------------------- 
Exact same problem here with Patton SmartNode. They offer T.38 in the
initial invite (as well as audio codecs). Asterisk 'always' sets the call
up as T.38, even if its only voice call. 
Ideally, Asterisk should first setup as a vanilla audio call, and wait for
the re-invite to T.38 when fax is detected by the receiving endpoint.

I dont think anyone is at fault. The so called T.38 'standard' can be
interpreted many different ways.....

The most common standard is to *not* offer T.38 in the initial invite, and
for the receiving party to offer the T.38 re-invite upon fax detection.
However, it would be a great bonus to have Asterisk compatible with T.38
offering in the initial SDP 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-16-08 16:54  samdell3       Note Added: 0088779                          
======================================================================