[asterisk-bugs] [Asterisk 0016821]: SDP in a session refresh re-INVITE does not contain T.38 when it should

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=16821 
====================================================================== 
Reported By:                dop251
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   16821
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.6.2.2 
JIRA:                       SWP-914 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-02-12 16:22 CST
Last Modified:              2010-05-01 17:03 CDT
====================================================================== 
Summary:                    SDP in a session refresh re-INVITE does not contain
T.38 when it should
Description: 
I tried to send a rather long fax (58 pages) and found that the call is
dropped after a while. It looks like it's because the re-INVITE which is
sent to refresh the session contains usual audio codecs instead of T.38.

[Feb 13 01:02:09] DEBUG[25129] chan_sip.c: Session timer expired: 28 -
8F3E8D271
4B0D9E642B252115B48C3EA-6011229@***********                         
[Feb 13 01:02:09] DEBUG[25129] chan_sip.c: ** Our capability: 0xc
(ulaw|alaw) Vi
deo flag: True Text flag: True                                            
     
[Feb 13 01:02:09] DEBUG[25129] chan_sip.c: ** Our prefcodec: 0x0 (nothing)
     
[Feb 13 01:02:09] DEBUG[25129] chan_sip.c: -- Done with adding codecs to
SDP    
[Feb 13 01:02:09] DEBUG[25129] channel.c: Internal timing is disabled
(option_in
ternal_timing=0 chan->timingfd=35)                                        
     
[Feb 13 01:02:09] DEBUG[25129] chan_sip.c: Done building SDP. Settling
with this
 capability: 0xc (ulaw|alaw)           

After receiving this reinvite the other end (which in my case was the same
instance of asterisk -- the call was handled via an external SIP proxy, but
I don't think it matters) tore the call down:

[Feb 13 01:02:14] DEBUG[25292] app_fax.c: T38 down, finishing             
     
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: Loop finished, res=6            
     
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: Fax phase E handler. result=49  
     
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: FLOW T.30 Changing from state 12
to 32
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: FLOW T.30 Changing from phase
T30_PHAS
E_C_ECM_RX to T30_PHASE_CALL_FINISHED                                     
     
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: FLOW T.38T Set rx type 8        
     
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: FLOW T.38T Set tx type 8        
     
[Feb 13 01:02:14] DEBUG[25292] app_fax.c: FLOW T.38T FAX exchange complete
====================================================================== 

---------------------------------------------------------------------- 
 (0121275) Jamuel (reporter) - 2010-05-01 17:03
 https://issues.asterisk.org/view.php?id=16821#c121275 
---------------------------------------------------------------------- 
I see this same issue with a more "traditional" setup:

PSTN --> SIP Carrier/Acme Packets SBC --> Asterisk 1.6.1.19-rc3 -->
Receive Fax

The carrier is requiring sip session-timers (1800 sec) and at the 900-sec
refresh interval we see a RE-INVITE from the Acme then Asterisk replies 488
Not Acceptable.

Attaching SIP signaling. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-05-01 17:03 Jamuel         Note Added: 0121275                          
======================================================================