[asterisk-bugs] [Asterisk 0016310]: 488 not acceptable when receiving T.38 at 14400 speed

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16310 
====================================================================== 
Reported By:                prandini
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16310
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0 
SVN Revision (number only!): 230766 
Request Review:              
====================================================================== 
Date Submitted:             2009-11-23 08:11 CST
Last Modified:              2011-01-27 01:29 CST
====================================================================== 
Summary:                    488 not acceptable when receiving T.38 at 14400
speed
Description: 
When I get a re-INVITE like this one:

INVITE sip:0119209223 at 91.112.73.125:5060 SIP/2.0^M
Max-Forwards: 19^M
f: <sip:0237009198 at 82.113.193.76>;tag=2F3F031C-231F^M
t: <sip:50119209223 at sip.twt.it>;tag=as7319a027^M
i: B8AC0C90-D5B411DE-AD06EC60-9C02B256 at 82.113.193.76^M
m: <sip:0237009198 at 82.113.193.76:5060>^M
CSeq: 102 INVITE^M
Expires: 180^M
User-Agent: Cisco-SIPGateway/IOS-12.x^M
Min-SE: 1800^M
l: 399^M
^M
v=0^M
o=CiscoSystemsSIP-GW-UserAgent 2486 1092 IN IP4 82.113.193.76^M
s=SIP Call^M
c=IN IP4 82.113.193.76^M
t=0 0^M
m=image 16808 udptl t38^M
c=IN IP4 82.113.193.76^M
a=T38FaxFillBitRemoval:0^M
a=T38FaxMaxBuffer:200^M
a=T38FaxMaxDatagram:72^M
a=T38FaxRateManagement:transferredTCF^M
a=T38FaxTranscodingJBIG:0^M
a=T38FaxTranscodingMMR:0^M
a=T38FaxUdpEC:t38UDPRedundancy^M
a=T38FaxVersion:0^M
a=T38MaxBitRate:14400^M

asterisk replies with

SIP/2.0 100 Trying^M
Via: SIP/2.0/UDP
82.113.194.190:5060;branch=z9hG4bK827014-kmbcnrv;cgp=twtmail.twt.it;upaddr=82.113.193.76;received=82.113.194.190;rport=5060^M
Via: SIP/2.0/UDP 
82.113.193.76:5060;x-route-tag="cid:3 at 82.113.193.76";branch=z9hG4bKD701F222C^M
From: <sip:0237009198 at 82.113.193.76>;tag=2F3F031C-231F^M
To: <sip:50119209223 at sip.twt.it>;tag=as7319a027^M
Call-ID: B8AC0C90-D5B411DE-AD06EC60-9C02B256 at 82.113.193.76^M
CSeq: 102 INVITE^M
User-Agent: Asterisk PBX 1.6.0.11^M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO^M
Supported: replaces, timer^M
Contact: <sip:0119209223 at 91.112.73.125>^M
Content-Length: 0^M

and then with

SIP/2.0 488 Not acceptable here^M
Via: SIP/2.0/UDP
82.113.194.190:5060;branch=z9hG4bK827014-kmbcnrv;cgp=twtmail.twt.it;upaddr=82.113.193.76;received=82.113.194.190;rport=5060^M
Via: SIP/2.0/UDP 
82.113.193.76:5060;x-route-tag="cid:3 at 82.113.193.76";branch=z9hG4bKD701F222C^M
From: <sip:0237009198 at 82.113.193.76>;tag=2F3F031C-231F^M
To: <sip:50119209223 at sip.twt.it>;tag=as7319a027^M
Call-ID: B8AC0C90-D5B411DE-AD06EC60-9C02B256 at 82.113.193.76^M
CSeq: 102 INVITE^M
User-Agent: Asterisk PBX 1.6.0.11^M
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO^M
Supported: replaces, timer^M
Content-Length: 0^M
^M

If I get a re-invite with 9600 speed, everything is ok.
Why on earth is it refusing 14400 ?
====================================================================== 

---------------------------------------------------------------------- 
 (0131094) prandini (reporter) - 2011-01-27 01:29
 https://issues.asterisk.org/view.php?id=16310#c131094 
---------------------------------------------------------------------- 
Hi Haggard, I didn't notice your note.
No, it is not done in such a way any more, if you have a look at
the sources in 1.6 there is no such block. I patches it in previous
versions like you suggest, and it worked, but now there is 14400
in the various switches in chan_sip.c but it doesn't work properly
anyway. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-01-27 01:29 prandini       Note Added: 0131094                          
======================================================================