[asterisk-bugs] [Asterisk 0015182]: [patch] T.38 invite does not always comply with RFC 2327

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15182 
====================================================================== 
Reported By:                CGMChris
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   15182
Category:                   Channels/chan_sip/T.38
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     closed
Target Version:             1.4.27
Asterisk Version:           1.4.25 
Regression:                 No 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 fixed
Fixed in Version:           
====================================================================== 
Date Submitted:             2009-05-22 09:31 CDT
Last Modified:              2009-07-27 12:52 CDT
====================================================================== 
Summary:                    [patch] T.38 invite does not always comply with RFC
2327
Description: 
See http://www.faqs.org/rfcs/rfc2327.html, section 6:

"Note: For transports based on UDP, the value should be in the range 1024
to 65535 inclusive.  For RTP compliance it should be an even number."

My SIP provider drops the call when my signaling specifies an odd numbered
media port for T.38 (per RFC 2327).

In most of my tests, the media port in the T.38 invite is even:
1. From my provider to Asterisk
2. From Asterisk to my ATA
3. From my ATA back to Asterisk

At this point, (step 4) Asterisk seems to be prone to generating an odd
numbered port for signaling to my provider.

I *think* this issue has not been noticed widespread because ALG on most
routers corrects this behavior.  I do NOT have a problem using T.38 with a
cheap $60 Linksys router, however, using an off-brand router from Hong Kong
with no ALG support, I cannot get T.38 to work at all.
====================================================================== 

---------------------------------------------------------------------- 
 (0108270) svnbot (reporter) - 2009-07-27 12:52
 https://issues.asterisk.org/view.php?id=15182#c108270 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 209133

_U  branches/1.6.0/
U   branches/1.6.0/configs/udptl.conf.sample
U   branches/1.6.0/main/udptl.c

------------------------------------------------------------------------
r209133 | mmichelson | 2009-07-27 12:52:45 -0500 (Mon, 27 Jul 2009) | 31
lines

Merged revisions 209132 via svnmerge from 
https://origsvn.digium.com/svn/asterisk/trunk

................
  r209132 | mmichelson | 2009-07-27 12:50:04 -0500 (Mon, 27 Jul 2009) | 24
lines
  
  Merged revisions 209131 via svnmerge from 
  https://origsvn.digium.com/svn/asterisk/branches/1.4
  
  ........
    r209131 | mmichelson | 2009-07-27 12:44:06 -0500 (Mon, 27 Jul 2009) |
18 lines
    
    Allow for UDPTL to use only even-numbered ports if desired.
    
    There are some VoIP providers out there that will not accept SDP
    offers with odd numbered UDPTL ports. While it is my personal opinion
    that these VoIP providers are misinterpreting RFC 2327, it really is
    not a big deal to play along with their silly little games. Of course,
    since restricting UDPTL ports to only even numbers reduces the range
    of available ports by half, so the option to use only even port
numbers
    is off by default. A user can enable the behavior by setting
    use_even_ports=yes in udptl.conf.
    
    (closes issue https://issues.asterisk.org/view.php?id=15182)
    Reported by: CGMChris
    Patches:
          15182.patch uploaded by mmichelson (license 60)
    Tested by: CGMChris
  ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=209133 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-07-27 12:52 svnbot         Checkin                                      
2009-07-27 12:52 svnbot         Note Added: 0108270                          
======================================================================