Summary:ASTERISK-07638: [patch] t.38 passthrough not working when endpoints are behind a NAT
Reporter:Marek Cervenka (cervajs)Labels:
Date Opened:2006-08-31 09:58:38Date Closed:2007-02-05 10:26:15.000-0600
Versions:Frequency of
Environment:Attachments:( 0) boat.tif
( 1) boat-t38.tif
( 2) chan_sip.c-svn-47446
( 3) chan_sip-t38-fix.diff
( 4) kapanga-t38-no-nat.txt.log
( 5) kapanga-vp100.txt
( 6) log_t38.txt
( 7) t38_log_1.log
( 8) t38.log
( 9) T38-01Dec06-001.log
(10) t38-11132006.log.log
(11) t38-2kapanga.txt
(12) T-38-fail-over-ipsec-fail
(13) t38-is-sip-only.txt
(14) t38-kapanga-both-behind-nat
(15) t38-kapanga-with_nat.log
(16) t38Log-Nov21-001.txt
(17) T-38-working.tif
(18) vdebug_01Dec06.txt
(19) vdebug_04Dec06.log
(20) working-T-38-kapanga-with-nat
Description:i have this topology (ATA - 2x grandstream ht496 fw, t.38 on)

trying t.38 passthrough

in sip.conf per phone
t38pt_udptl = yes

i have this problem
chan_sip.c:4586 process_sdp: Unsupported SDP media type in offer: image 10912 udptl t38

do you want SIP traffic dump or i have problem in config/hw/sw/mind?
Comments:By: Serge Vecher (serge-v) 2006-08-31 10:25:59

AFAIK, canreinvite must be on for T.38 passthrough to work. Since your endpoints behind a NAT, canreinvite will not work. So, you are looking at a currently unsupported network configuration.

Let's see a SIP Debug trace though:
1) Prepare test environment (reduce the ammount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterik.
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Save complete console log to file and _attach_ said file to the bug.

By: Marek Cervenka (cervajs) 2006-09-13 15:49:25

working on test lab

meantime ... i set up http://www.voip-info.org/tiki-index.php?page=Asterisk%20T.38

By: Marek Cervenka (cervajs) 2006-09-13 18:49:18

ok, topology changed => simple scenario
one subnet 2 kapanga softphone, one asterisk svn trunk - Asterisk SVN-trunk-r42893 (no NATs!)
uploaded sip debug t38-2kapanga.txt

same problem as with grandstreams
WARNING[18321]: chan_sip.c:4633 process_sdp: Unsupported SDP media type in offer: image 5124 UDPTL t38

By: Leonardo Gomes Figueira (sabbathbh) 2006-09-29 14:53:08

I'm trying with 2 UTStarcom IAN-02EX ATAs and 1.4 branch and got the same problem:

[Sep 29 16:39:19] WARNING[30981]: chan_sip.c:4643 process_sdp: Unsupported SDP media type in offer: image 4504 udptl t38

Asterisk and ATAs on the same LAN with canreinvite working between then. No NAT.

I don't know if the T.38 implementation on this ATAs really work since I didn't find on google anyone that already tested this but I would like to help solving this issue anyway (and find out if this ATAs work with T.38).

Do you want debug/sip debug ?

Connected to Asterisk SVN-branch-1.4-r43997 currently running on pfdesenv (pid = 30932)

By: jmls (jmls) 2006-11-02 12:20:19.000-0600

I think any debugs / logs you can provide will be helpful for the developers. Thanks.

By: Leonardo Gomes Figueira (sabbathbh) 2006-11-06 08:38:37.000-0600

Unfortunately I don't have any T.38 capable ATAs available anymore so I can't really help right now. Maybe someone else could provide this debug info ? Sorry.

By: Ahsan Masood (ahsan) 2006-11-08 11:39:46.000-0600


I have installed a latest asterisk trunk version (SVN-trunk-r47321)and configured two grandstream ATAs (496 and 386). Both ATA's are using a same fimware verson

Both ATA are registed to asterisk on local network without NAT and I am unable to send faxes between them. Please find the attached log file (t38.log) for aerisk cli debug report.

I have different kind of ATAs over here and will be happy to help in testing this feature.

Ahsan Masood
Telappliant Ltd.

By: dea (dea) 2006-11-08 16:15:51.000-0600

  Do you have 't38pt_udptl = yes' set for the ata peers?  Your log
clearly shows the t38 offer in the SDP, but the log also claims it
was not found.

By: Ahsan Masood (ahsan) 2006-11-09 09:34:42.000-0600

Yes, I have set t38pt_udptl = yes. My sip.conf entries for both ATA looks like

t38pt_udptl = yes

t38pt_udptl = yes

By: Leonardo Gomes Figueira (sabbathbh) 2006-11-09 10:32:50.000-0600

Is there an "t38pt_udptl = yes" on [general] section of sip.conf ? It must be there too.

By: Ahsan Masood (ahsan) 2006-11-09 11:14:48.000-0600

I got t38pt_udptl=yes in  general section, run the test again and T.38 failed and fax worked on alaw.

still reciving debug message

[Nov  9 18:19:20] DEBUG[20548]: chan_sip.c:4889 process_sdp: Peer doesn't provide T.38 UDPTL

By: dea (dea) 2006-11-09 12:32:31.000-0600

I believe that is progress, but a new debug log will be required to
confirm that.

It now appears that the SDP is properly parsed and the T38 capabilities
identified, but for some reason the udptl port number is not recorded.

Can you attach another log?

By: Ahsan Masood (ahsan) 2006-11-09 12:40:42.000-0600

Please find latest logs (t38_log_1.log)

By: dea (dea) 2006-11-09 15:46:45.000-0600

Did you have 'core set debug 4' for this log?  There are messages
I would expect to see that are not present.

The interesting bit is that Asterisk appears to complete the T38
negotiation, ACK'ing the 200 OK responses from the ATAs after the
T38 re-invite, but immediately sends another invite to use RTP.

I think I see a possible cause, but will need a log with the logging
levels mentioned by serge-v in the first post.

By: dea (dea) 2006-11-09 18:31:30.000-0600

Here is a super small patch that checks to see if we have completed
T38 negotiation inside of sip_set_rtp_peer()

Looking over the logs on this bug and 7679, it looks like the callback
to sip_set_rtp_peer is triggered when the T38 code re-assigns the port
number, which then triggers a re-invite for RTP.

Consider the patch a proof of concept only at this point, there may be
a better way, but I would be interested to see a log after this patch is
applied (sip debug; core set verbose 4; core set debug 4)

By: dario (dario) 2006-11-10 06:40:15.000-0600

Please find latest logs from my configuration: SPA-9000 and cisco router (log_t38.txt)


By: Ahsan Masood (ahsan) 2006-11-10 08:53:57.000-0600

After patching, I am getting these errors.

[CC] chan_sip.c -> chan_sip.o
chan_sip.c: In function `sip_set_rtp_peer':
chan_sip.c:16703: error: structure has no member named `lock'
chan_sip.c:16709: error: structure has no member named `lock'
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2

By: dario (dario) 2006-11-10 08:57:51.000-0600

I have patched chan_sip.c and now T.38 is working (SVN-branch-1.4-r47405M)


By: Ronald Chan (loloski) 2006-11-10 09:08:23.000-0600


  is this environment applicable for you ? ATA -NAT- ASTERISK(public ip) -ANOTHER NAT- ATA just like the original reporter? if this t38 pass thru is working in this environment. it's great we have it now :)


By: dario (dario) 2006-11-10 09:26:18.000-0600

Sorry, it is without NAT :(, I will check it on Monaday with NAT

By: Ronald Chan (loloski) 2006-11-10 10:17:05.000-0600


  ok i'll try to test this functionality also using kapanga softphone on both ends. using a both with nated and a non-nat environment, hoping we get this in.
also i will try both SVN-trunk and 1.4-beta3 with above patch by DEA... thanks

i will get back into this asap


By: dea (dea) 2006-11-10 10:41:25.000-0600

ahsan, you line numbers are nowhere near close to what I have.  I do
have another small patch in my tree, but it would not explain the huge
difference.  Can you post the SVN number you have?

How did you apply the patch and did it generate any errors other than

One point to clear up about this bug, while it was reported against
NAT, the issue was not about NAT.  The bug would trigger on any call
that started by using RTP and then attempted to switch to udptl.

By: Ronald Chan (loloski) 2006-11-10 11:09:34.000-0600

DEA: same error encounter with ahsan it applies cleanly but failed to build

patch -p0 < ../../1.4/patch/t38.diff

patching file channels/chan_sip.c
Hunk #1 succeeded at 16705 (offset 224 lines).

chan_sip.c: In function ?sip_set_rtp_peer?:
chan_sip.c:16707: error: ?struct sip_pvt? has no member named ?lock?
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2

Path: .
URL: http://svn.digium.com/svn/asterisk/trunk
Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision: 47438
Node Kind: directory
Schedule: normal
Last Changed Author: file
Last Changed Rev: 47438
Last Changed Date: 2006-11-11 00:55:13 +0800 (Sat, 11 Nov 2006)
Properties Last Updated: 2006-11-11 01:06:45 +0800 (Sat, 11 Nov 2006)

hope this help

By: dea (dea) 2006-11-10 11:19:13.000-0600

I'm checking out a fresh copy and will check the patch against it.

The only reference to lock in the patch is a copy and paste from
a similar test in sip_set_rtp_peer.  Perhaps locking rules changed
between 47337 and 47438

By: Ahsan Masood (ahsan) 2006-11-10 11:21:40.000-0600

DEA:   Asterisk Version. SVN-trunk-r47321

Patched as
patch -p0 < ../../1.4/patch/t38.diff

Got succeeded message but got errors on make install.

By: Ronald Chan (loloski) 2006-11-10 11:39:04.000-0600

DEA: i was able to patch and build it cleanly on branch 1.4 inline with your. in this release

Path: .
URL: http://svn.digium.com/svn/asterisk/branches/1.4
Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision: 47444
Node Kind: directory
Schedule: normal
Last Changed Author: rizzo
Last Changed Rev: 47444
Last Changed Date: 2006-11-11 01:13:34 +0800 (Sat, 11 Nov 2006)
Properties Last Updated: 2006-11-11 01:28:22 +0800 (Sat, 11 Nov 2006)

maybe i should start testing it here on svn-branch-1.4beta first before jumping the gun on my head in trunk nah maybe i can do both for sure :)

By: dea (dea) 2006-11-10 11:42:19.000-0600

SVN 47444 takes the patch with a little fuzz, compiles and installs.

The error is odd, as sip_pvt most definately has a member named lock.
I suspect an issue with the patch(ing)

Can either of you paste a few lines of code before and after the
line identified in the make error into a txt and attach it?

By: Ronald Chan (loloski) 2006-11-10 12:04:08.000-0600

Before the patch applies it's on line 16706 on SVN

Last Changed Author: russell
Last Changed Rev: 47446
Last Changed Date: 2006-11-11 01:53:46 +0800 (Sat, 11 Nov 2006)
Properties Last Updated: 2006-11-11 02:06:49 +0800 (Sat, 11 Nov 2006)

i will apply it manually and create a svn diff format

By: Ronald Chan (loloski) 2006-11-10 12:12:54.000-0600

DEA: still the same error even applied it by hand.

chan_sip.c: In function ?sip_set_rtp_peer?:
chan_sip.c:16707: error: ?struct sip_pvt? has no member named ?lock?
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2

Path: .
URL: http://svn.digium.com/svn/asterisk/trunk
Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision: 47448
Node Kind: directory
Schedule: normal
Last Changed Author: russell
Last Changed Rev: 47446
Last Changed Date: 2006-11-11 01:53:46 +0800 (Sat, 11 Nov 2006)
Properties Last Updated: 2006-11-11 02:06:49 +0800 (Sat, 11 Nov 2006)

i'm just wondering what really happen i will try to look also on the code if there's really change between the lines.


By: Ronald Chan (loloski) 2006-11-10 12:20:22.000-0600

DEA: please take a look at this http://pastebin.ca/245191 for more information

By: dea (dea) 2006-11-10 12:46:11.000-0600

Thanks.  The problem is obvious now.

My patch is against SVN ./branches/1.4 since this is a bug there.
It looks you and ashan are running Trunk which has changes to the locking rules.

Change this in my patch:

to this:

And you'll be able to test.  

Also the log_t38.txt posted today does show progress.  Asterisk is
no longer triggering the re-invite, but the Cisco router is.  Now
to find why.  The log claims that NAT is off for both peers, on the
RTP and T38 stacks.  This might be a config issue, and it might be a
code issue.  I'll need to see the relevant sections of the sip.conf
that was used to generate log_t38.txt

By: Ronald Chan (loloski) 2006-11-10 13:59:05.000-0600

   I will attach the the log here kapanga-t38-no-nat.txt regarding the udptl negotiation, the fax went thru on both softphone but the problem is, it's corrupted. it might be the softphone issue as well, i will mail kapanga mailing list about this :)


WinXP->Kapanga --> * <-- Kapanga>WinXP


By: Ronald Chan (loloski) 2006-11-11 00:11:17.000-0600

Beta Tester/Developer

  Whatever configuration i check/uncheck with these T38 capable softphone, the closes thing i get is this it's no longer corrupted but still crappy :)

 i will attach both the original boat.tiff file and the received boat-t38.tiff file using ulaw as a codec i also check with alaw but it's the same thing.

please confirm if someone has successfully sending T38 fax over different T38 capable device, this will elimate my doubt that the culprit is *.

By: Olle Johansson (oej) 2006-11-12 09:42:24.000-0600

I've committed some T.38 related patches - please retest with latest 1.4 and svn trunk. Thanks for all kinds of feedback.

By: Ronald Chan (loloski) 2006-11-12 11:01:17.000-0600

Oej: here's my latest test from SVN Trunk
still the same image i get after the T38 negotiation has take place please see t38-11132006.log

URL: http://svn.digium.com/svn/asterisk/trunk
Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision: 47514
Node Kind: directory
Schedule: normal
Last Changed Author: oej
Last Changed Rev: 47514
Last Changed Date: 2006-11-13 00:15:49 +0800 (Mon, 13 Nov 2006)
Properties Last Updated: 2006-11-13 00:36:24 +0800 (Mon, 13 Nov 2006)

By: Olle Johansson (oej) 2006-11-12 11:09:26.000-0600

Thanks for fast feedback!

By: Olle Johansson (oej) 2006-11-15 15:40:44.000-0600

Can't do much in Asterisk about the image, it's up to the endpoints. We just need to make sure that the passthrough works.

Any open unresolved issues with latest svn trunk 1.4?

By: Ronald Chan (loloski) 2006-11-16 04:46:12.000-0600

oej: since, i don't really know rfc3261 in general, base on the log i post t38-11132006.log.log, could you or someone verify if T38-pass thru thing has been done in this case??? if yes, maybe you can close this for now until someone request to re-open this ticket

Many thanks !!!


By: Ronald Chan (loloski) 2006-11-16 05:08:53.000-0600

To cervajs:

when i'm doing this test my sip configuration doesn't match to your topology as you describe above there's no NAT involve in my setup with canreinvite set to yes. T38 settings was on for both peers. i hope i made myself clear on this.

since there's no clear direction wethere this stuff was really working on both nated and non-nated environment i decided to choose non NAT since it's very easy to setup, could someone lift a hand on this, and check also if this pass thru thing applicable as per original report?.


By: Marek Cervenka (cervajs) 2006-11-16 05:09:42.000-0600

same topology as note from 09-13-06 18:49
call from kapanga -> asus vp100
asterisk SVN-branch-1.4-r47712

[Nov 16 11:44:34] WARNING[3749] chan_sip.c: Unsupported SDP media type in offer: image 10014 UDPTL t38

dump i attach kapanga-vp100.txt (maybe t.38 in vp100 is bad, look at dump please)

By: Ronald Chan (loloski) 2006-11-16 05:21:45.000-0600

cervajs: ok i will produce this with NAT also with both kapanga softphone, aiming for other developers to think of this, since my C and asterisk internals is very very limited, what we can do for now is to test this and aid them for some insight produce by our log

Best regards,


By: dea (dea) 2006-11-16 11:16:46.000-0600

cervajs, are you sure that 't38pt_udptl = yes' is set on the vp100?

The Unsupported SDP message can be triggered if the peer does not have
t38 support turned on.  The SVN rev you have does have support for both
'udptl' and 'UDPTL' in the SDP, so this is not the case sensitivity bug
that popped up in another report.

OEJ, is the test for p->udtpl needed when scanning the SDP?  If it was
removed, we would always detect the T38 offer, and later in the code,
say near where we setup the udptl port, warn if we have a t38 offer, but
the user/peer does not have support turned on?  It might make it clearer
why a failure to negotiate t38 occured.

By: Ronald Chan (loloski) 2006-11-16 17:55:03.000-0600

To ALL: i think this is not the case for kapanga softphone with phone behind a nat with canreinvite set to no. please check my new debug trace

By: dea (dea) 2006-11-16 18:52:40.000-0600

loloski, did the session work or fail?  The log looks like the Asterisk
server properly relayed the udptl packets between the endpoints until
the kapanga endpoint sent the 'Bye'.

The only other issue that stands out in the logs is that the Linksys
PAP2 insists on sending keep-alive notifies, which Asterisk doesn't
care for and replies with 489 'Bad Event'

By: Ronald Chan (loloski) 2006-11-16 19:44:38.000-0600

DEA: Please disregard The linksys PAP2 on the picture sorry. i will retest this again. with both kapanga soft phone on the network with both nat=yes and canreinvite=no.

By: Ronald Chan (loloski) 2006-11-16 20:12:40.000-0600

DEA: please check this recent logs, both peer is set to nat=yes canreinvite=no
on my perspective, the call is said to be complete. but i can't produce now the crappy image i produce on my previous test with nat=no and canreinvite=yes. i hope this may help you and other developers along the way :)

Thank you!!

By: Ronald Chan (loloski) 2006-11-16 21:17:24.000-0600

TO ALL: yes, good news after downloading recent kapanga softphone 1.00.2152 build
i was able to send and receive fax perfectly using with nat=yes and canreinvite=no
please check the recent logs and sample image


By: Ronald Chan (loloski) 2006-11-17 04:57:22.000-0600

DEA & others: guys, when i'm writing this i'm very hesistant simply because the topology i'm using slightly modified against the original report, but here it is this time T-38 pass through failed to finish the transmission.

T-38 Softphone 1 -> IPSEC/l2tpd -> * -> T-38 Softphone 2

T-38 Sofphone 1 =    
IPSEC/l2tpd GW =
* =
T-34 Softphone 2 =

 As you can see this is same NAT -> NAT scenario the only thing that's being add here is the IPSEC/l2tpd which i know it's very heavy. it can cause a lot of network jitters which i think this is the main cause this test to fail. do we need to  pursue in this setup? or shall we go back on the test case with the original reporter? _NO_FLAME_WAR_PLS i just want to help :)


Sorry for my horrible english since i'm not a native english speaker :)
i hope i made my self clear on this.


By: Marek Cervenka (cervajs) 2006-11-17 05:18:11.000-0600

to DEA:
i'm pretty sure to have t38pt_udptl = yes

sip show peer 200
T38 pt UDPTL : Yes
sip show peer 201
T38 pt UDPTL : Yes

By: Ronald Chan (loloski) 2006-11-17 05:49:54.000-0600

cervajs: i'm using SVN-branch-1.4-r47751M ? and yours ?

how about in [general] section of sip.conf ? did you add this t38pt_udptl = yes ?

By: dea (dea) 2006-11-17 11:43:16.000-0600

   Your English is fine.  I am pretty sure I don't speak your native
language, so I appreciate your efforts.  Your ipsec-fail log actually
looks good, maybe the udptl packets are a little smaller than they
should be (I don't know what size is healthy), but the communications
setup seems to complete.

  There are only 2 reasons to get this:
     Unsupported SDP media type in offer: image 10912 udptl t38

  1.  The 't38pt_udptl = yes' options is not set
  2.  The SDP offer is not a perfect match.
     A.  The code to find the image offer is/was case sensitive.
      'image 12345 udptl t38' would match
      'image 12345 UDPTL t38' would not

The case sensitivity issue was had a fix implimented before the
version you last reported to be testing (branches-1.4-47712), but it might
not be working as expected.  I'll take a look.

The Kapanga-vp100 log shows that the VP100 offered T38 with UDPTL,
and Asterisk rejected it.  Loloski has reported success with the
Kapanga softphone.  So if the option is turned on, then issue is
likely back on the upper case UDPTL.

By: Ronald Chan (loloski) 2006-11-17 12:00:20.000-0600


 Thanks a lot, well as far as i can say maybe it could be MTU issue's since ipsec/l2tpd was set to 1452 wherein you can set this to low or even higher i'll check later on if setting MTU to 1492 will solve this, well i'll handle this and report asap, to others please help us to test this in order for us to move forward without your help this issue will rest in this bug tracker forever :) peace ^_^

By: Ronald Chan (loloski) 2006-11-20 18:52:46.000-0600

DEA: this is reproducible in in IPSEC/l2tpd scenario maybe it's not related to MTU. setting MTU to 1492/1400 doesn't make sense at all.

cervajs: did you make any progress on your testing environment???


By: Marek Cervenka (cervajs) 2006-11-21 03:21:17.000-0600

waiting for second licence for kapanga (donated by kapanga for asterisk testing)
i'm ordered grandstream ht496

i will edit this note asap

loloski: can we make interoperability tests together? my mail cervajs at freevoice.cz

By: Ahsan Masood (ahsan) 2006-11-21 03:52:58.000-0600

Hi All,

I am using asterisk verion SVN-trunk-r47790 and tested the T.38 feature between two local HT-496 (using latest beta firmware and fax failed.

My extensions looks like

t38pt_udptl = yes

t38pt_udptl = yes

and t38pt_udptl = yes in general section. Logs are attached as t38_ht496.log.

Please let me know if any change or further testing required.

By: Marek Cervenka (cervajs) 2006-11-21 04:16:57.000-0600

to ahsan:
"Peer doesn't provide T.38 UDPTL"
looks like

you have "fax mode: passthrough" in ht496. can you check? you must have T.38

By: Alex lake (alexlake) 2006-11-21 04:44:08.000-0600

Hello there, loloski asked me to "help out" here and I'm certainly willing to put a bit of time in....

I have a very similar problem, but it's got nothing to do with NAT.

SVN r47866 on Ubuntu 5.10

Essentially I'm getting the "Unsupported SDP media type in offer: image 47174 udptl t38" problem leading to a SIP 488 (Not acceptable here)

I do have "canreinvite = yes" and "t38pt_udptl = yes" in sip.conf for appropriate peers

ASIDE: Do these both need to be in both inbound AND outbound peer configuration sections, or is it controlled by just one?

My setup involves no NAT at all. We have a carrier who operates a Cisco box (5400 on SW v12.3) clever enough to invoke t38 on the fly. The call flow is:


When PSTN_B is a fax machine, the fax answer tone is recognised by the Cisco which sends us a new invitation (see below) which results in the warning shown above.

Is this any use? Do you need any more files/traces/etc? Should I stay here? Cancel my own bug report?

No.     Time        Source                Destination           Protocol Info
     6 5.999566         SIP/SDP  Request: INVITE sip:442070173460@, with session description

Frame 6 (923 bytes on wire, 923 bytes captured)
Ethernet II, Src: ZyxelCom_53:59:ce (00:a0:c5:53:59:ce), Dst: Dell_22:69:48 (00:13:72:22:69:48)
Internet Protocol, Src: (, Dst: (
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol
   Request-Line: INVITE sip:442070173460@ SIP/2.0
   Message Header
   Message body
       Session Description Protocol
           Session Description Protocol Version (v): 0
           Owner/Creator, Session Id (o): msw 6754 2344 IN IP4
           Session Name (s): sip call
           Connection Information (c): IN IP4
           Time Description, active time (t): 0 0
           Media Description, name and address (m): image 47174 udptl t38
           Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy
           Media Attribute (a): T38FaxMaxDatagram:72
           Media Attribute (a): T38FaxMaxBuffer:200
           Media Attribute (a): T38FaxRateManagement:transferredTCF
           Media Attribute (a): T38FaxTranscodingJBIG:0
           Media Attribute (a): T38FaxTranscodingMMR:0
           Media Attribute (a): T38FaxFillBitRemoval:0
           Media Attribute (a): T38MaxBitRate:14400
           Media Attribute (a): T38FaxVersion:0

By: Ahsan Masood (ahsan) 2006-11-21 04:58:22.000-0600


Fax mode is set to T.38 as default. (Fax Mode:  T.38 (Auto Detect))

Not sure why its doing like that.

I have also reported this to grandstream and wiating for thier response.

By: Alex lake (alexlake) 2006-11-21 05:02:20.000-0600

ahsan - I'd have thought the reason is that most IP networks are not good enough for fax over the audio channel - even sending uncompressed (64kbps) can have problems with latency. Thus the best chances for success are to use T38 while in the VOIP domain and hope that PSTN gateways can do the conversion!

By: Ahsan Masood (ahsan) 2006-11-21 06:22:39.000-0600


I am using both HT-496 on the same network and I don't think its a network issue.

By: Ronald Chan (loloski) 2006-11-21 07:40:32.000-0600

cervajs: did you get my e-mail?? please reply about the arrangements of the testing,

alexkake: could you please provide, the sip debug and udptl debug logs on your end, hoping for some developers to pick this up, whethere here or on your own bug report.

core set verbose 3
sip set debug
udptl debug

Bug Marshall:

Please inform me if this is not the right thing to do, since there's a lot of T-38 passthrough related issue, i think it's best if we can consolidate it here first, then inform everyone if they are really need to file their own bug report. Thank you!!


By: Alex lake (alexlake) 2006-11-21 09:11:06.000-0600

See t38Log-Nov21-001.txt for console trace of call that attempts to transfer to T.38

By: Ahsan Masood (ahsan) 2006-11-21 10:36:51.000-0600

I have two HT-496 and two Sipura 2100 and Asterisk box wih external IP.

Please let me know if I can help with any further testing.


By: Ronald Chan (loloski) 2006-11-21 11:05:52.000-0600

ahsan & others: for those people interested on doing interoperability testing please e-mail me the details. my * is on dynamic ip with public address. i have kapanga softphones to be used in T-38 nego. my e-mail is loloski at yahoo dot com

definetly this will be on NAT to NAT scenario just in case there are people interested just jump in. you can add me to YM too.

though i have linksys PAP2-NA adapter claim to be a T38 capable device but i haven't tried it yet because i don't have a fax machine to plug in there.


By: dea (dea) 2006-11-21 11:06:44.000-0600

 442070173450 is setup as a peer, does it have 't38_udptl = yes' set?
It looks like you are using the same peer to setup both legs of this call,
hair-pinning though a proxy.  

Can we see the section of sip.conf related to Gamma-OUT?

By: Alex lake (alexlake) 2006-11-21 11:41:06.000-0600

type            = peer
context         = from-gamma
host            =
allow           = alaw
t38pt_udptl     = yes
canreinvite     = yes

(I tried your implicit suggestion of "t38_udptl = yes" and it didn't help)

BTW - You are right about the "hairpinning" (a kind of local tromboning)

By: Marek Cervenka (cervajs) 2006-11-22 12:28:11.000-0600

i have found why some users report
[Nov 22 19:20:10] WARNING[14396]: chan_sip.c:4756 process_sdp: Unsupported SDP media type in offer: image 5120 UDPTL t38

this is because without t38pt_udptl = yes in [general] section T.38 DONT WORK!

BUT in example config we have
;----------------------------------------- T.38 FAX PASSTHROUGH SUPPORT -----------------------
; This setting is available in the [general] section as well as in device configurations.
; Setting this to yes, enables T.38 fax (UDPTL) passthrough on SIP to SIP calls, provided
; both parties have T38 support enabled in their Asterisk configuration (either general or
; peer/user/friend sections)
; t38pt_udptl = yes            ; Default false

(either general or peer/user/friend sections)

this is NOT true

By: Marek Cervenka (cervajs) 2006-11-22 12:43:26.000-0600

same topology as note from 09-13-06 18:49
asterisk  SVN-branch-1.4-r47911
kapanga 2152b build

t38pt_udptl = yes added to [general]

t.38 fax works (but receiving kapanga crash after fax transmission(this is kapanga bug, not bug in asterisk. i'm in contact with kapanga support)

to loloski: i sent email to you

By: dea (dea) 2006-11-22 13:08:34.000-0600

  Great catch.  I intended to look at that, and well, work got in the way.

To summerize your findings:
           General             User/Peer         Result
    1.     No(default)           No(default)       No
    2.     No                    Yes               No
    3.     Yes                   No                No
    4.     Yes                   Yes               Yes

So 1, 3 and 4 work as expected, but 2 is inconsistent.  That
should be an easy fix.

By: Ronald Chan (loloski) 2006-11-22 13:39:30.000-0600

DEA: I colloborate with ahsan today, using his grandstream ATA adapter we found out that even his ata is on the same network. it doesn't work in some cases.

with canreinvite=no, nat=yes one time we got a complete T38 transmission and fax. in this setting most of the time there's an exchange of UDPTL packet's going on but failed to complete the fax.

with canreinvite=yes, nat=no           doesn't work
with canreinvite=yes, nat=never        doesn't work
with canreinvite=no,  nat=no           doesn't work
with canreinvite=yes, nat=nonat        doesn't work either.

but on my testing at home, with kapanga canreinvite=no,nat=yes works 100% all the time. nat=no, canreinvite=yes it work's but sometimes it failed.

cervajs: your are right some time kapanga crash after fax transmission. but it's kapanga issue anymore.

ahsan: if you have time, could you sent here the sip debug so that they can see it. i forgot to log those traces on my putty.

By: dea (dea) 2006-11-22 15:02:23.000-0600

Looking deeper at the t38 support code, I think the only sip.conf
setting that matters right now is t38pt_udptl in the [general]
section.  Settings per peer/user just do not seem to be

Can someone test with the option turned on in [general] and
  Explicitly off (t38pt_udptl=no) on a user/peer
  Not present on a user/peer

I think we will find that the user/peer setting does not matter,
and it is not as trivial a fix as I first thought.  If I am right,
we can get past the negotiation issues with a work-around and move
on to why is seems to fail after negotiation.

By: Alex lake (alexlake) 2006-11-23 03:52:06.000-0600

Good spot on the [General] section

It looks like you can turn it OFF on the Peer.

My tests show:

[General] [Peer]
yes       yes       It works
yes       -         It works
yes       no        It fails
-         yes       It fails
-         no        It fails
-         -         It fails

- = Node not specified

When I say "It works" I mean you don't get the "Unsupported SDP media type" warning. I've still got trouble (i.e. Asterisk is still sending a 488) but it's progress!

By: Alex lake (alexlake) 2006-11-23 04:00:41.000-0600

I think I may be having trouble with the media types I allow through my Asterisk. I've uploaded t38_day2.txt

My sip.conf is now:

context         = default
port            = 5060
bindaddr        =
nat             = no
reinvite        = no
canreinvite     = yes
disallow        = all
allow           = alaw
trustrpid       = yes
sendrpid        = yes
t38pt_udptl     = yes

type            = peer
context         = from-gamma
host            =
allow           = alaw
t38pt_udptl     = yes
canreinvite     = yes

By: Marek Cervenka (cervajs) 2006-11-27 16:12:09.000-0600

same topology as note from 09-13-06 18:49
Asterisk SVN-branch-1.4-r48054
kapanga 2152b build
grandstream ht496

kapanga->ht496 works ok!
ht496->kapanga (1/3 is ok, 2/3 black - this is not related to the bug, it's kapanga/ht496 problem!)

this note is only for testers -> info about working configuration
please add working configurations to the wiki at http://www.voip-info.org/tiki-index.php?page=Asterisk%20T.38

By: Alex lake (alexlake) 2006-11-29 04:57:17.000-0600

I think I'm going to give up on this as a way of allowing fax to transit our network.

I did wonder if it was possible from within a dialplan or AGI session to get a call reinvited, but I've heard from someone who knows about this kind of thing that it isn't. I know this is drifting from the topic, but if any kind soul can suggest how I might manage to do a reinvite (i.e. cut out the "hairpin"), that would be mucho appreciated!

Good luck, chaps!

By: Alex lake (alexlake) 2006-11-29 10:07:30.000-0600

I presume that someone has got T.38 passthru working. I wonder if it might be possible to see the .conf files and SIP/debug logs for a successful call?


By: dea (dea) 2006-11-29 11:16:04.000-0600

Alex, you posted on 11/23 that you uploaded a new log name
t38_day2.txt, but it is not attached to this bug.  Did it get
added to the wrong bug?

From the other reports, I think we have made good progress, and
I'd like to see if we can figure out your '488' issue.


By: Alex lake (alexlake) 2006-12-01 03:29:56.000-0600

Sorry - I could have sworn that I did, but must be deluded.
I'll arrange a fresh one....

By: Alex lake (alexlake) 2006-12-01 03:54:37.000-0600

T38-01Dec06-001.log now uploaded.

It would appear that the Cisco is issuing the INVITE but without a media stream that Asterisk can do anything with. Perhaps I need to add something to the "allow" bit of sip.conf or else get the carrier to modify the way in which the Cisco is configured?

Either way, a log (and sip.conf) from a good T38 reinvitation (SOMEONE must have one!!!) would be a very useful point for comparison.

By: Alex lake (alexlake) 2006-12-01 03:56:46.000-0600

BTW - where is the best documentation for T.38 in Asterisk?

By: Serge Vecher (serge-v) 2006-12-01 10:20:51.000-0600

alexlake: it's useful to see what asterisk is "thinking" with debug log enabled. Please reproduce per the following instructions:

1) Prepare test environment (reduce the amount of unrelated traffic on the server);
2) Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3) restart Asterisk with the following command:
  'asterisk -Tvvvvvdddddgc | tee /tmp/verbosedebug.txt'
4) Enable SIP transaction logging with the following CLI commands:
set debug 4
set verbose 4
sip debug
5) Attach verbosedebug.txt to the issue.

By: Alex lake (alexlake) 2006-12-01 10:57:28.000-0600

OK, although I note for reference that I had to use

core set debug 4
core set verbose 4
sip set debug gamma-OUT

File uploaded: vdebug_01Dec06.txt

By: dea (dea) 2006-12-01 12:34:27.000-0600

I think this is related to your use of the Local channel.

Following the log flow, the '488' error follows 'This Call is UP' in
handle_request_invite().  We send a '488' in a number of situations,
but the log flow points to a test to see if the target peer (bridgepeer)
is using SIP for it's channel tech.

At the point of the failure, I think that 442070605610 is set to Local
and will fail.

I think I can get you a small patch to test this, but if you can modify
your dialplan to not use the Local channel for calls to/from 442070605610
we can prove or disprove this theory.  This is not suggested as a
perminant change, just a debugging step, and will provide the same validation
as a patch.

By: Alex lake (alexlake) 2006-12-04 03:31:59.000-0600

OK -  vdebug_04Dec06.log now uploaded which shouldn't be using the local channel.

ATTENTION!!! It would appear that this log is unreliable. I'm going to do another one...

By: Alex lake (alexlake) 2006-12-04 04:06:12.000-0600

Just an interim progress report - it does get further with the non-local dial. There is still a problem but it looks like it might not be anything to do with Asterisk. Will report more progress later.

By: Serge Vecher (serge-v) 2006-12-04 09:30:54.000-0600

Dan: do you want to attach the small patch you've mentioned for testing purposes?

By: dea (dea) 2006-12-04 11:11:56.000-0600

   The small patch would be just to add new LOG_DEBUG statements
where I think the code is triggering the '488', and would not change
the behaviour, which is why I suggested that Alexlake try without using
the Local channel (either would confirm the location of the failure).

I'm going to look a little deeper at the current logging in chan_sip
with regards to T38.  There are a number of conditions that trigger
the same log/warning/error message which makes finding the exact location
of the problem difficult.

On a housekeeping note, Alex's issue is not NAT, and not really related
to the Cisco endpoints like his original bug-report.  This bug and 7679
appear to be resolved with OEJ's recent fixes in branches/1.4 and Trunk.

By: Alex lake (alexlake) 2006-12-04 11:17:06.000-0600

Not going through the Local channel does resolve my issue.

I have a slight problem that I'm trying to keep both tickets updated and this one is not really relevant. So I'm going to focus on my own issue 8387!

By: Serge Vecher (serge-v) 2006-12-04 11:23:56.000-0600

DEA: thanks for the update. Can we please get a confirmation that oej's fixes 1.4 svn r > 48199 have fixed the original issue?

By: dea (dea) 2006-12-04 11:58:43.000-0600

I'll try to summerize the status from the three related t38 bugs (7844, 7679 and 8387)

Issue 1-
  SDP case sensitivity.  Some endpoints put UDPTL instead of udptl in the SDP offer (fixed)

Issue 2-
  RTP timeouts.  A re-invite to t38 after RTP was negotiated would cause the call to drop after the rtp timeout period (fixed)

Issue 3-
  Global T38 configuration inheritance.  T38 will only work if it is enabled in the [general] section of the config (not really fixed, but at least the requirement is documented)

Issue 4-
  T38 is only supported on SIP.  Use of other channels, including local, would trigger a 488 Unsupported.  I've attached a small patch to make it clear why the T38 setup was rejected.

Reporters Cervajs(7844), Alexlake (8387), Loloski, Ivoc, Coppens_b. Marcelbarbulescu and Andrew all report success with recent code and the [general] section requirement.

Reporter Ahsan(7679) has not confirmed success in his ticket or in 7844, but the other reporters have covered the same test case.

By: Serge Vecher (serge-v) 2006-12-04 13:01:59.000-0600

excellent summary, DEA. Let's commit the little patch and close the reports ...

By: Marek Cervenka (cervajs) 2006-12-04 18:08:15.000-0600

DEA: can you please sumarize which scenario is supported with current t.38 passthrough code a configuration?

1) ata1 - nat -asterisk- SAMEnat* - ata2   (*same subnet as ata1)
2) ata1 - nat -asterisk- ANOTHERnat - ata2  
3) ata1 - nat -asterisk- NOnat - ata2
4) ata1 - NOnat -asterisk- NOnat - ata2

from my testing
ad 1) (both canreinvite=no) - works ok
ad 3) fail (sip channels are packet2packet bridged)
ad 4) (both canreinvite=yes) - works ok

By: dea (dea) 2006-12-04 19:55:50.000-0600

   Unfortunatly I cannot.  I don't have any T38 gear, so I have
based all of my efforts on the posted logs and code review.

   Your summary is about what I would expect, with case 3 being
an unknown.  If you can post a log for such a session, I can review
it.  I would hazard a guess that the packet2packet bridge does not
work with udptl sessions, but that is a wild guess without looking
at the code.  OEJ might have a couple thoughts on this point as I
believe that he has had other problems with the packet2packet feature

By: Olle Johansson (oej) 2007-01-26 02:34:24.000-0600

...busy actually testing t.38 stuff...

By: Olle Johansson (oej) 2007-01-26 05:27:58.000-0600

Asterisk t.38 passthrough and NAT is severly broken, or I must be missing something critical. I get incoming UDPTL packets, but Asterisk does not send anything anywhere, just swallows them. I've spent many hours trying to figure this out now...

I suspected the RTP bridge and disabled that to get the generic bridge going, but then I got channel locks when I had incoming RTP packets at the same time as chan_sip was trying to lock the channel for T.38 re-invite. Asterisk gave up with a "503 server error".

This is bad. Who tested this before commit?

By: hristo (hristo) 2007-01-27 12:11:19.000-0600

T.38 was working around 16-Nov-2006 (refer to note 54736 in issue 7679).  I'm pretty sure NAT tests were also ok at that time. A little bit later, after adding functionality to disable RTP timers with T.38 the swallow behavior appeared (as mentioned in note 55871/issue 7679). I don't know if RTP timers themselves introduced the swallow bug (I think it was present before that???) or if it was introduced by some other change at about the same time, but hopefully this will give you a clue where to look for the problem...

By: ivoc (ivoc) 2007-01-29 11:58:10.000-0600

Tested using revisions in the range 47584-48215.

UDPTL packet forwarding works fine up to revision 47625 /inclusive/.
Seems the update after that caused the problem:

r47628 | file | 2006-11-15 00:05:03 +0200 (Wed, 15 Nov 2006) | 2 lines

Only keep the video RTP structure around if 1. Video support is enabled and 2. A video codec is enabled on the dialog


By: dea (dea) 2007-01-29 13:13:32.000-0600

This code in sip_write() ~line 3504 looks fishy:

    if (p->udptl && ast->_state != AST_STATE_UP)
        res = ast_udptl_write(p->udptl, frame);

The vrtp changes do not make sense as a cause, but the above test
seems backwards....

By: Olle Johansson (oej) 2007-01-30 11:18:37.000-0600

DEA: yes, I spotted that part but when I labbed, we never used that part of the code. Thanks for all research, I'll try to look further into this during this week.

By: dea (dea) 2007-01-30 12:50:11.000-0600

verbose_debug_no_UDPTL_r51360_wDEBUG.txt attached to 7679 provides a hint
near the end of the log.  At timestamp Jan 24 10:36:59 we get an entry
showing that we've returned from p2p bridging through ast_channel_bridge.

And further examination shows we are going into p2p mode.  So what we
need to do is when we get into a T38 re-invite we need to tear down
the p2p and route the packets back through sip_read/sip_write

Not that I know where or how to do that...

By: Olle Johansson (oej) 2007-02-01 12:03:18.000-0600

- T.38 passthrough without re-invites, without NAT now works
- T.38 passthrough with re-invites works, T.38 goes directly between two devices

Tested with SIPura SPA 2100, latest 1.4 from svn. Please test with NAT.

By: dea (dea) 2007-02-01 12:30:19.000-0600

Just a quick question, the only change in svn is the one I pointed out in
post 0058432, are we sure that is enough?

The reason I ask is that in sip_rtp_read() we return a NULL frame if the
channel does not have RTP, but what if the call never negotiated RTP and
went straight to UDPTL?

Should the:
  if (!p->rtp)
be changed to:
  if (!p-rtp && !p->udptl)

By: Olle Johansson (oej) 2007-02-01 15:18:58.000-0600

- tested with NAT and it works.

By: Olle Johansson (oej) 2007-02-01 15:19:53.000-0600

DEA: THe main changes was in rtp.c

By: dea (dea) 2007-02-01 15:36:25.000-0600

Ah.  I see the addition frametypes added to the p2p and native bridge loops.
That still leaves the question about the case where there is no RTP, and
at a different level (philosophical, I guess) does it make sense to handle
udptl bridging in rtp.c?

These maybe questions better suited to the -dev list, so if a discussion is
worthwhile I canask over there...

By: ivoc (ivoc) 2007-02-05 02:43:42.000-0600

Works fine now.

By: Joshua C. Colp (jcolp) 2007-02-05 10:26:08.000-0600

I'm comfortably that this issue has been fixed now, but if this is not the case please reopen. Thanks! DEA - I would take that to -dev, it's a larger issue then just T38.