[asterisk-bugs] [Asterisk 0012074]: Do not process the UDPTL proxy under two sip channel (like in 1.4.18.x)

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12074 
====================================================================== 
Reported By:                Ivan
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12074
Category:                   Channels/chan_sip/T.38
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 104125 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             02-26-2008 07:39 CST
Last Modified:              02-26-2008 18:23 CST
====================================================================== 
Summary:                    Do not process the UDPTL proxy under two sip channel
(like in 1.4.18.x)
Description: 
Test system:
2 SIP Gateway with support t38 re-invate (for example, SPA2102 with 5.3.2
firmware)
Description:
The confirmation under SIP UDPTL sessions heppends successfully but
detection of fax signal do not process.
====================================================================== 

---------------------------------------------------------------------- 
 dimas - 02-26-08 18:23  
---------------------------------------------------------------------- 
Hmmm. I found your patch after posting mine (
http://bugs.digium.com/view.php?id=12078 ). I believe we both fixing the
same issue. However, honestly I do not think your patch is the good
approach to fix the problem because it will make t38state inconsistent
again. Imagine followin scenario:

1. Peers A and B are bridged
2. A doest T38 reinvite. t38state for A becomes PEER_REINVITE
3. Asterisk passes reinvite to peer B and DOES NOT change B's t38state -
it remains T38_DISABLED. Which is not correct already.
4. When OK from B received B's state changes to T38_PEER_REINVITE and then
a bit later to T38_ENABLED

So duging steps 3 and 4 t38state for peer B contained inconsistent values.
My patch differs in items 3 and 4:
3. Asterisk passes reinvite to peer B and sets B's t38state to
T38_LOCAL_REINVITE
4. When Asterisk received OK from B it changes B's state from
T38_LOCAL_REINVITE to T38_ENABLED. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
02-26-08 18:23  dimas          Note Added: 0082994                          
======================================================================