[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:                kpfleming
====================================================================== 
Project:                    Asterisk
Issue ID:                   16310
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     assigned
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:              2009-11-23 13:46 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 ?
====================================================================== 

---------------------------------------------------------------------- 
 (0114163) kpfleming (administrator) - 2009-11-23 13:46
 https://issues.asterisk.org/view.php?id=16310#c114163 
---------------------------------------------------------------------- 
It is highly unlikely that Asterisk is rejecting the re-INVITE solely on
the basis of the T38MaxBitRate field, but we'd only be guessing why
otherwise since you didn't provide any log information to see why Asterisk
responded the way it did.

Please run this test again, after setting 'core set debug 10', 'core set
verbose 10', 'sip set debug on' and ensuring that all five logger levels
are enabled for the 'full' log file. Once the test is complete, upload the
relevant part of the 'full' log file as an attachment to this issue.
Thanks. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-11-23 13:46 kpfleming      Note Added: 0114163                          
======================================================================