Summary:ASTERISK-17576: issue with Asterisk 1.4.30 and T38 passthrough
Reporter:michel (michel)Labels:
Date Opened:2011-03-18 07:37:52Date Closed:2011-04-19 09:55:08
Versions:1.8.4 Frequency of
Description:This is my set up:

analog fax machine (fax #:224176701) <> Avaya IP office 500 PBX <> Asterisk <> VOIP provider (netia).

We are trying to set up fax pass-through for Asterisk. There is an analog fax machine attached to the Avaya PBX ( which in turn is communicating with Asterisk. All the in/out communication goes through the Asterisk ( Avaya is et up to support G.711 (ulaw,alaw) and G.729 if this matters in any way.

extensions.conf is correctly configured.

This is sip.conf for Avaya:
type            = friend
host            =
qualify         = no
context         = from-avaya
canreinvite     = no
disallow        = all
allow           = alaw
; added
allow           = g729
t38udptlsupport = yes
t38pt_udptl = yes
t38pt_rtp = no
t38pt_tcp = no

This is udptl.conf:
; UDPTL Configuration (UDPTL is one of the transports for T.38)
; UDPTL start and UDPTL end configure start and end addresses
; Whether to enable or disable UDP checksums on UDPTL traffic
; The error correction type to be sent
; T38FaxUdpEC = t38UDPFEC
T38FaxUdpEC = t38UDPRedundancy
; The maximum length of a UDPTL packet
T38FaxMaxDatagram = 400
; The number of error correction entries in a UDPTL packet
;udptlfecentries = 3
udptlfecentries = 1

; The span over which parity is calculated for FEC in a UDPTL packet
udptlfecspan = 3
; Some VoIP providers will only accept an offer with an even-numbered
; UDPTL port. Set this option so that Asterisk will only attempt to use
; even-numbered ports when negotiating T.38. Default is no.

use_even_ports = yes

When we try to send a fax (fax number 224176701), we hear the typical "fax beeping", but then we get a "communication error".

I have gathered few logs, here they are:

- tshark on asterisk (

1: 264.945761 -> SIP/SDP Request: INVITE sip:224176701@, with session description
2: 264.951583 -> SIP Status: 100 Trying
3: 264.962531 -> SIP Status: 180 Ringing
4: 266.119080 -> SIP/SDP Status: 200 Ok, with session description
5: 266.119326 -> SIP Request: ACK sip:224176701@;transport=udp
6: 272.880566 -> SIP Request: OPTIONS sip:Unknown@
7: 272.880830 -> SIP Status: 404 Not Found
8: 273.640571 -> SIP/SDP Request: INVITE sip:225401522@, with session description
9: 273.640996 -> SIP Status: 488 Not acceptable here
10: 273.644819 -> SIP Request: ACK sip:225401522@
11: 273.647558 -> SIP Request: BYE sip:225401522@
12: 273.647716 -> SIP Status: 200 OK

Request from asterisk to Avaya seems fine, but then in line 9, it looks like asterisk is not accepting the Request from Avaya (FYI: 225401522 is the callee).
Line 6 and 7 I think are irrelevant for our case.

- Asterisk in command line shows when trying to send a fax to the fax machine (#224176701):

   -- Executing [224176701@from-pstn:1] NoOp("SIP/netia-00000d74", "Inbound DDI 224176701 - Forwarding to avaya") in new stack
   -- Executing [224176701@from-pstn:2] Dial("SIP/netia-00000d74", "SIP/avaya/224176701") in new stack
   -- Called avaya/224176701
   -- SIP/avaya-00000d75 is ringing
   -- SIP/avaya-00000d75 answered SIP/netia-00000d74
   -- Packet2Packet bridging SIP/netia-00000d74 and SIP/avaya-00000d75
[Mar 15 11:41:45] NOTICE[591]: chan_sip.c:5632 process_sdp: No compatible codecs, not accepting this offer!
 == Spawn extension (from-pstn, 224176701, 2) exited non-zero on 'SIP/netia-00000d74'

Looking at the last two lines, It seems like Avaya and Asterisk do not agree on which codec to use!

Thanks for any help on this subject.


Comments:By: Leif Madsen (lmadsen) 2011-04-01 12:55:27

You will need to provide a SIP trace from the Asterisk console per the issue reporting guidelines. It is impossible to see which codec is negotiated and what is going on based on the data provided.

By: Leif Madsen (lmadsen) 2011-04-01 12:58:48

We'll need to see a SIP trace from the Asterisk console along with DEBUG level logging. Please provide this information so we can move the issue forward.


By: Leif Madsen (lmadsen) 2011-04-01 12:59:04

Oops, apologies, I double triaged this issue :)

By: Leif Madsen (lmadsen) 2011-04-19 09:55:08

No response from reporter.