[asterisk-bugs] [Asterisk 0011995]: T.38 Re-Invite header replaced by audio header when SIP asks for authorization

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11995 
====================================================================== 
Reported By:                fall
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11995
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-14-2008 11:46 CST
Last Modified:              02-14-2008 12:10 CST
====================================================================== 
Summary:                    T.38 Re-Invite header replaced by audio header when
SIP asks for authorization
Description: 
When trying to receive fax from SIP vendor thru Asterisk to SPA3102 with
T.38 service, it fails to receive always.
Further analyse found the sip header got replaced with audio codec header
in MD5 response in session decription protocol field when SIP vendor
replied with 401 unauthorized and asterisk reply with MD5 response.
The packet sequense is like this,
0. channel built by initially invite from SIP to local asterisk with ulaw
pcm.
0.5 SPA3102 accept invite and detected fax, reinvite T.38.
1. asterisk reinvite with T.38 to sip vendor in session description
protocol
2. sip vendor replied with 401 unauthorized.
3. asterisk replied with ACK.
4. astertisk resend invite with secret MD5 reponse, but with header field
replaced with ulaw PCM codec.
5. 200 OK from sip vedor for invite with header ulaw PCM. asterisk reply
with ACK.
6. SPA3000 resend T.38 invite to asterisk.
7. asterisk forward T.38 invite to sip vendor again.
8. repeat step 2.
9. repeast step 3
10. repeat step 4
11. repeat step 5

...
repeat step 6-11 until fax machine timeout and reported error.
====================================================================== 

---------------------------------------------------------------------- 
 fall - 02-14-08 12:10  
---------------------------------------------------------------------- 
events continued as
n. sip vendor detected fax signaling and reinvite T.38 because all
asterisk initiated invite with qualified MD5 response are all telephone
event with ulaw PCM codec. (all invite from * with T.38 didn't have MD5.)
n+1. asterisk ACK and forward to SPA3102.
n+2. SPA3102 will reply with 486 busy here, because T.38 invite from
SPA3102 sent at step 0.5 has not responded by proxy asterisk. (because all
invite went to sip vendor had T.38 header didn't have MD5 repsonse. All MD5
responded invite from asterisk header were all replaced by telephone event
ulaw pcm) 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-14-08 12:10  fall           Note Added: 0082254                          
======================================================================