[Home]

Summary:ASTERISK-14191: [patch] T.38 invite does not always comply with RFC 2327
Reporter:Chris Alcorn (cgmchris)Labels:
Date Opened:2009-05-22 09:31:43Date Closed:2009-07-27 12:57:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 15182.patch
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.

****** ADDITIONAL INFORMATION ******

<--- SIP read from 64.158.162.75:5060 --->
INVITE sip:8124254246@74.143.228.142:5060 SIP/2.0
Via: SIP/2.0/UDP 64.158.162.75:5060;branch=z9hG4bK02Ba8e97c8f110989b5
From: <sip:18668566334@64.158.162.75>;tag=gK02845fe2
To: "Chelsea Luttrell" <sip:8124254246@74.143.228.142>;tag=as6d70ce8e
Call-ID: 6b24cac85ea42d771fdc129262207283@74.143.228.142
CSeq: 5433 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay,  multipart/mixed
Contact: <sip:18668566334@64.158.162.75:5060>
Supported: timer
Session-Expires: 1800;refresher=uac
Min-SE: 90
Content-Length:  305
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 25927 21077 IN IP4 64.158.162.75
s=SIP Media Capabilities
c=IN IP4 64.158.162.71
t=0 0
m=image 18746 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:262
a=T38FaxMaxDatagram:90
a=T38FaxUdpEC:t38UDPRedundancy
a=sendrecv

Reliably Transmitting (NAT) to 10.0.0.150:5060:
INVITE sip:Fax_Chelsea@10.0.0.150 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.12:5060;branch=z9hG4bK58cbf1d5;rport
From: <sip:8668566334@10.0.0.12>;tag=as276d7bc2
To: "Chelsea Luttrell" <sip:Fax_Chelsea@10.0.0.12>;tag=9b0094887ca83721
Contact: <sip:8668566334@10.0.0.12>
Call-ID: ecbfd5b866fa87da@10.0.0.150
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
X-asterisk-info: SIP re-invite (T38 switchover)
Content-Type: application/sdp
Content-Length: 262

v=0
o=root 15949 15951 IN IP4 10.0.0.12
s=session
c=IN IP4 10.0.0.12
t=0 0
m=image 4388 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:90
a=T38FaxMaxDatagram:90
a=T38FaxUdpEC:t38UDPRedundancy

<--- SIP read from 10.0.0.150:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.12:5060;branch=z9hG4bK58cbf1d5;rport
From: <sip:8668566334@10.0.0.12>;tag=as276d7bc2
To: "Chelsea Luttrell" <sip:Fax_Chelsea@10.0.0.12>;tag=9b0094887ca83721
Call-ID: ecbfd5b866fa87da@10.0.0.150
CSeq: 102 INVITE
User-Agent: Grandstream HT287 1.1.0.26
Contact: <sip:Fax_Chelsea@10.0.0.150>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE
Content-Type: application/sdp
Supported: replaces, timer
Content-Length: 351

v=0
o=Fax_Chelsea 8000 8002 IN IP4 10.0.0.150
s=SIP Call
c=IN IP4 10.0.0.150
t=0 0
m=image 5004 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy

<--- Reliably Transmitting (NAT) to 64.158.162.75:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 64.158.162.75:5060;branch=z9hG4bK02Ba8e97c8f110989b5;received=64.158.162.75
From: <sip:18668566334@64.158.162.75>;tag=gK02845fe2
To: "Chelsea Luttrell" <sip:8124254246@74.143.228.142>;tag=as6d70ce8e
Call-ID: 6b24cac85ea42d771fdc129262207283@74.143.228.142
CSeq: 5433 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:8124254246@74.143.228.142>
Content-Type: application/sdp
Content-Length: 274

v=0
o=root 15949 15950 IN IP4 74.143.228.142
s=session
c=IN IP4 74.143.228.142
t=0 0
m=image 4159 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:280
a=T38FaxMaxDatagram:280
a=T38FaxUdpEC:t38UDPRedundancy
Comments:By: Mark Michelson (mmichelson) 2009-06-12 13:15:45

I have a couple of problems with this issue report.

1) RFC 2327 is deprecated in favor of RFC 4566, which does not have any sort of restriction regarding the use of even numbered ports.

2) Even if you ignore the existence of RFC 4566 and follow RFC 2327, the passage you quoted says that RTP ports should have even numbers. It does not carry such a restriction for UDPTL. I'll admit though that the language used is a bit ambiguous and that I may be misinterpreting it.

So to me anyway, this seems like buggy behavior by your SIP provider, not Asterisk.

That being said, it wouldn't be all *that* difficult to make sure that the port selected is even. I can work up a patch for you to try.
By: Mark Michelson (mmichelson) 2009-06-12 13:47:13

I've uploaded a patch for testing. If you apply this patch and set use_even_ports = yes in udptl.conf, Asterisk should only designate even-numbered ports for T.38 offers. Let me know if it works out for you.
By: Leif Madsen (lmadsen) 2009-07-16 07:55:44

Pinging the reporter. You have opened an issue and a patch was made to resolve your issue. Can you please test the patch so that we can determine if it resolves the issue, and thus commit it to Asterisk?

Thanks!
By: Chris Alcorn (cgmchris) 2009-07-16 08:03:20

Sorry, it's been very busy in my office lately.  I will test this weekend or early next week and report back ASAP.  Thanks.
By: Chris Alcorn (cgmchris) 2009-07-21 10:44:20

Just installed the patch and it appears to be working.  I will contact my SIP provider for further testing and report back with any issues.
By: Scott Johnson (globalnetinc) 2009-07-23 09:08:40

Is there any way that this patch can be ported to 1.6.1?  Our SIP provider uses Sonus as well and we have been unable to get T.38 to work.  They always drop the call.
By: Mark Michelson (mmichelson) 2009-07-23 09:14:49

@globalnetinc: Yes, when the code gets committed, the change will be put in the 1.6.1 branch as well as all other current Asterisk branches since this is a bug fix. When I get confirmation from CGMChris that this has worked in his tests with his SIP provider, I'll get this merged in.
By: Mark Michelson (mmichelson) 2009-07-27 11:23:15

I think at this point it is safe to merge these changes. I will commit the changes as soon as I can.
By: Digium Subversion (svnbot) 2009-07-27 12:44:16

Repository: asterisk
Revision: 209131

U   branches/1.4/configs/udptl.conf.sample
U   branches/1.4/main/udptl.c

------------------------------------------------------------------------
r209131 | mmichelson | 2009-07-27 12:44:15 -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 ASTERISK-14191)
Reported by: CGMChris
Patches:
     15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris


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

http://svn.digium.com/view/asterisk?view=rev&revision=209131
By: Digium Subversion (svnbot) 2009-07-27 12:50:13

Repository: asterisk
Revision: 209132

_U  trunk/
U   trunk/configs/udptl.conf.sample
U   trunk/main/udptl.c

------------------------------------------------------------------------
r209132 | mmichelson | 2009-07-27 12:50:12 -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 ASTERISK-14191)
 Reported by: CGMChris
 Patches:
       15182.patch uploaded by mmichelson (license 60)
 Tested by: CGMChris
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=209132
By: Digium Subversion (svnbot) 2009-07-27 12:52:45

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 ASTERISK-14191)
   Reported by: CGMChris
   Patches:
         15182.patch uploaded by mmichelson (license 60)
   Tested by: CGMChris
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=209133
By: Digium Subversion (svnbot) 2009-07-27 12:57:30

Repository: asterisk
Revision: 209134

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

------------------------------------------------------------------------
r209134 | mmichelson | 2009-07-27 12:57:29 -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 ASTERISK-14191)
   Reported by: CGMChris
   Patches:
         15182.patch uploaded by mmichelson (license 60)
   Tested by: CGMChris
 ........
................

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

http://svn.digium.com/view/asterisk?view=rev&revision=209134
By: Digium Subversion (svnbot) 2009-07-27 12:57:49

Repository: asterisk
Revision: 209135

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

------------------------------------------------------------------------
r209135 | mmichelson | 2009-07-27 12:57:48 -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 ASTERISK-14191)
   Reported by: CGMChris
   Patches:
         15182.patch uploaded by mmichelson (license 60)
   Tested by: CGMChris
 ........
................

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

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