[Home]

Summary:ASTERISK-04957: [branch] It's time to start getting T.38 into *
Reporter:steveu (steveu)Labels:
Date Opened:2005-09-01 10:16:22Date Closed:2008-01-15 17:12:00.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/CodecInterface
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-1.2.4-t38-20060216.tar.bz2
( 1) asterisk-1.2.7.1-t38-20060423.tar.bz2
( 2) bad_capture_06_08_2006.txt
( 3) sip_conf.txt
Description:I'd like to start the ball rolling on integrating T.38 with *. The first step is to get a format assigned for it. Since formats are running short, it is not obvious that the following will be acceptable. I therefore submit it as a first step for discussion:

--- frame.h.orig        2005-09-01 23:10:43.000000000 +0800
+++ frame.h     2005-09-01 23:11:44.000000000 +0800
@@ -161,10 +161,12 @@
#define AST_FORMAT_H261                (1 << 18)
/*! H.263 Video */
#define AST_FORMAT_H263                (1 << 19)
/*! H.263+ Video */
#define AST_FORMAT_H263_PLUS   (1 << 20)
+/*! T.38 FAX */
+#define AST_FORMAT_T38                 (1 << 21)
/*! Max one */
#define AST_FORMAT_MAX_VIDEO   (1 << 24)
Comments:By: Kevin P. Fleming (kpfleming) 2005-09-01 18:37:01

Well, since the rest of the T.38 stuff obviously won't be going into 1.2, we can defer a decision on this one until the new development branch is open... but it appears that maybe we should either use the next 'audio' format number, or the next higher one after MAX_VIDEO, since this is not really audio or video.
By: Kevin P. Fleming (kpfleming) 2005-09-01 18:37:27

Care to comment on this one?
By: steveu (steveu) 2005-09-01 19:32:31

You seem to be missing the point. We need to add T.38. Someone else is adding G.722. The 32 bit mask for the type is a broken idea, which is about to break. I can't see why there is not at least 32 bits for audio + 32 bits for video + 32 bits for image, etc.
By: Kevin P. Fleming (kpfleming) 2005-09-02 15:46:09

No, I didn't miss the point, but we currently have 14 bits available in the 32-bit format word. Adding two more formats is not going to put us in serious danger of having to re-architect anything, since it's not likely that 12 more formats are going to show up in the next development cycle. If you want to propose a new architecture to be used for post-1.4, I'm all for it, but for now it appears that using a 32-bit word for format specification is adequate.
By: steveu (steveu) 2005-09-03 00:24:06

OK, then can we get and allocation for a T.38 type into CVS?

Next issue. When rtp.c is called to read a packet it is only seems able to return a single frame. I asked around, and I don't think I am missing something here. This is a broken design, as a single rceived RTP packet can produce multiple frames. Specifically for what I am doing now, FEC information can lead to one or more recovered frames, plus the information frame itself. My UDPTL code has the same problem. For T.38 testing I have been using a fudge, but we need a proper design.

Any suggestions for how this should be handled? Frames have pointers so they may be linked. Returning a chain of frames seems a reasonable approach.
By: steveu (steveu) 2005-09-04 10:06:28

chan_sip.patch is an incomplete patch for adding T.38 handling to chan_sip.c. I have been using a rather fudged approach for testing. Now its time to get something in shape to go into CVS. I'm looking for feedback at the moment. udptl.c/udptl.h and tpkt.c/tpkt.h are structural similar to rtp.c/rtp.h. They are mostly implemented, and waiting for agreement on how multiple frames per call should be handled. The transports should be ready to go into CVS pretty soon after that is agreed.

This code doesn't make UDPTL and TPKT optional compilation things. It should probably do that during the integration/stabilisation phase.
By: Olle Johansson (oej) 2005-09-05 03:57:15

Can you please provide the patch in "cvs diff -u" format?
By: Michael Jerris (mikej) 2005-09-05 08:15:56

Can we please try to answer the real questions on this bug on it's merits instead of formatting reviewing a much wanted feature to death.
By: steveu (steveu) 2005-09-05 08:56:06

Fair comment. Its a bit hard to follow the basic patch. chan_sip.patch2 was made with -U, and I added "#if defined(T38_SUPPORT)" around all the interesting bit. This patch should be harmless to add.
By: Olle Johansson (oej) 2005-09-05 09:17:05

Thank you, it's much easier to see what you're up to with "diff -u" format.

How far away is an implementation we can test? We are going to change chan_sip quite a lot as soon as we have the 1.3 development tree open, so we need to keep everything in synch.
By: steveu (steveu) 2005-09-05 09:22:59

If we can agree only how udptl.c and tpkt.c should return multiple frames things should start to move
By: Olle Johansson (oej) 2005-09-05 09:30:21

The packet issue is a bit above my head right now. I'll dig into the code and see if I can grasp that part... :-)
By: Kevin P. Fleming (kpfleming) 2005-09-07 23:26:14

Here are some answers:

Mark and I have decided that the proper thing for this is actually a frame type, not a codec, since it's not transcodable, it needs to bypass any jitter buffers, and it is neither 'audio' nor 'video', and existing applications that process frames have no way to deal with T.38 frames. I've added AST_FRAME_T38 to frame.h in CVS HEAD.

Second: We agree that the RTP/UDPTL/TPKT protocols should be able to return more than one frame in a single read() call, chained together with their next pointers. It seems that the most logical place to handle this will be in ast_read() itself, which can determine whether there are chained frames and queue them onto the channel for subsequent ast_read() calls to retrieve. If necessary, ast_read() could call ast_frisolate() to safely copy the frame contents, so that the lower level drivers could re-use the same frame structures to return data in.
By: steveu (steveu) 2005-09-08 10:37:01

I haven't checked this too carefully, yet. However, very simple changes to channel.c seem to allow the first frame of the returned list to be returned to the app, and the rest to be tacked on the queue. I don't think they need copying, as another call to tech->read won't occur until that queue has been flushed. It seems like all the current tech->read functions ensure the next field in NULL, so introducing tech->read functions that return a list of frames looks like it doesn't incur nasty rework.
By: Tilghman Lesher (tilghman) 2005-09-08 11:10:14

Out of curiosity, why is it necessary that a read to rtp.c produce more than one frame?  If all of our frames were exactly the same length, I could see where you'd need to break up a packet into multiple frames, but that isn't the case:  frames are variable length for precisely the reason that packets are also variable length.
By: Kevin P. Fleming (kpfleming) 2005-09-08 19:16:48

steveu: That is all correct, it is safe for a tech->read function to return a chain of frames. The frisolate() may not be necessary if the frames point to structures allocated specifically for that call; otherwise they may get reused for another call before they are de-queued from the current channel.

Corydon76: From my very brief reading of the T.38 documents I have been able to find, the 'multiple frame' result is necessary because we always want (need) to preserve the original frame boudaries. Passing along a larger size frame does not seem like it would be a good choice for interoperability, and it may not be possible to break a larger frame back into its components (but I could be wildly off base here). When a frame is lost, and a later frame is received containing the redundant copies of the missing frame(s), those frames all need to be returned as a result of the read() call... and it's simpler to do that than to work out rules for combining/splitting frames.
By: Kevin P. Fleming (kpfleming) 2005-09-08 19:19:09

Just some more random thoughts...

Using AST_FRAME_T38 (instead of a codec format) means that any future TDM<->T.38 bridging code would need to run as an Asterisk application that brigdes between two connected channels, rather than leveraging the existing bridging functionality. However, since these bridges would never be 'native', would never need to be DTMF-monitored, or any of the other stuff that voice bridges need, this seems to be logical. I was envisioning something like an app called TDMtoT38() that would be called on a TDM channel and would create an outbound T.38 channel to the requested destination and then do the conversion/forwarding.
By: Michael Jerris (mikej) 2005-09-25 15:50:45

steve-  Do you have any other outstanding questitons on how to proceded on this or is this just in process at this point?
By: steveu (steveu) 2005-09-26 22:01:46

Corydon76:

When FEC is used for RTP or UDPTL a read can result in either one frame (error correction did not occur) or multiple frames (error correction was able to recover one or more lost frames). Frames are variable length, but the frame system in * does not indicate frame boundaries. You can't just string them together. They need to be reported separately.

MikeJ:

I came back from a trip today, so I haven't been working on this for 2 weeks. I will get back to it now. I don't think I need anything from other people right now.
By: Tilghman Lesher (tilghman) 2005-09-27 09:06:30

I certainly understand error correction recovering a lost frame, but that sounds like we need a better queue in rtp.c.  So if we decode a packet, and that results in a recovered frame, as well as a new frame, then we queue the new frame, deliver the recovered frame, then wait for another read to deliver the next queued frame.

Is there a circumstance where we're going to stop reading queued frames, other than in a case of a hungup channel (prematurely aborted)?
By: steveu (steveu) 2005-10-02 01:39:54

A suggested change to frame.h. V.150 modem over IP is structurally similar to T.38, so to provide for that later on I suggest the T.38 frames are handled as follows:

/*! Modem-over-IP data streams */
#define AST_FRAME_MODEM     11

/* MODEM subclasses */
/*! T.38 Fax-over-IP */
#define AST_MODEM_T38       1
/*! V.150 Modem-over-IP */
#define AST_MODEM_V150      2

This is now what I am using in my development work.
By: steveu (steveu) 2005-10-02 06:52:45

chan_sip.c seems to have started massive changes. If I supply an up to date T.38 diff, can I get this in. I'd like to start changing along with chan_sip.c, rather than fighting to keep up. The alternative is I probably get pissed off and give up working on this.
By: Matt Riddell (zx81) 2005-10-04 00:55:34

Man this would be so great to get in.  A lot of people I know are running other software just to deal with the T.38 termination.

Even passthrough would be great!

I'm totally available if you need any testers for this one (and could potentially put quite a bit of load through it).

It seems Steve is going hard to get this into Asterisk rather than as a whole lot of patches and seperately maintained items.  Shouldn't someone be jumping at the opportunity?  I understand the timing is not ideal, but people have been begging for this for ages!

:)
By: Rosario Pingaro (rpingar) 2005-10-05 05:41:35

To compile the t.38-bits I had to remove the tpkt.o from Makefile, so everythink is compiling fine.

But I tested t.38 passthough with sipura spa-2100 and an italian provider supporting t.38.
And I still get: chan_sip.c:3464 process_sdp:  about unkwon SDP media type in offer: image 17196 UDP T38

so something is chan_sip is not completed about UDPTL
By: nenadr (nenadr) 2005-10-05 08:51:08

No it still don't work even if you exclude tpkt.o and everything that calls tpkt functions from chan_sip.c.patch and add this two small patches for asterisk.c and T38 PATCHED chan_sip.c:

--- asterisk.c.orig     2005-09-29 04:38:24.000000000 +0200
+++ asterisk.c  2005-10-05 14:00:05.000000000 +0200
@@ -65,6 +65,7 @@
#include "asterisk/pbx.h"
#include "asterisk/enum.h"
#include "asterisk/rtp.h"
+#include "asterisk/udptl.h"
#include "asterisk/app.h"
#include "asterisk/lock.h"
#include "asterisk/utils.h"
@@ -2153,6 +2154,7 @@
               exit(1);
       }
       ast_rtp_init();
+       ast_udptl_init();
       if (ast_image_init()) {
               printf(term_quit());
               exit(1);

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

--- chan_sip.c.orig     2005-10-05 15:35:26.713679192 +0200
+++ chan_sip.c  2005-10-05 15:49:50.218406520 +0200
@@ -2537,7 +2537,7 @@
                       ast_mutex_unlock(&p->lock);
               }
               break;
-       case AST_FRAME_IMAGE:
+       case AST_FRAME_MODEM:
#if defined(T38_SUPPORT)
               if (p) {
                       ast_mutex_lock(&p->lock);
@@ -3435,6 +3435,7 @@
               }
#if defined(T38_SUPPORT)
               if (p->udptl && (sscanf(m, "image %d udptl t38 %n", &x, &len) == 1)) {
+                       found = 1;
                       udptlportno = x;
                       if (debug)
                               ast_verbose("Found UDPTL T.38\n");
@@ -3463,7 +3464,7 @@
               if (!found )
                       ast_log(LOG_WARNING, "Unknown SDP media type in offer: %s\n", m);
       }
-       if (portno == -1 && vportno == -1 ) {
+       if (portno == -1 && vportno == -1 && udptlportno == -1) {
               /* No acceptable offer found in SDP */
               return -2;
       }

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

First patch enables updtl init on asterisk start (way like RTP is inited) and second one tries to solve "488 Not Accepted Here" problem when line "image XXXXX udptl t38" is found in SDP, and fixes a small overview in regards to steves bugnote ASTERISK-3353285.

Still even with all this, Asterisk and Grandstream 286 ATA don't try to talk UDPTL (judging by SIP debug on asterisk).


By: Rosario Pingaro (rpingar) 2005-10-05 12:05:12

for nendar

after I applied the patch about chan_sip.c I got an error about undeclared udptlportno function

how to fix it?
thanks


By: nenadr (nenadr) 2005-10-05 12:12:45

for rpingar:

Compile * (or at least chan_sip) with CFLAGS+=-DT38_SUPPORT in Makefile
Without that most of the chan_sip.c.patch doesn't get compiled at all.
By: Rosario Pingaro (rpingar) 2005-10-05 15:28:07

for nenadr

I made everything, from ereasing enything about tpkt in chan_sip.c to compiling with that flag. But I still don't get t.38 recognized as you mentioned.

So I would like to get some feedback from steveu about t38-bits.

Thanks about your support.
By: nenadr (nenadr) 2005-10-13 09:26:45

I have uploaded set of patches, that enables SIP T38 UDPTL pass-through faxing. I've tested it with 2 Gradnstream 286 ATAs and it is working. You need to set canreinvite=yes for peer with T38 capable ATA or it will not work. Treat this as extension to Steve's chan_sip.patch, since I'm not much of coder, nor I have some big knowledge of asterisk internals. I believe that it would be wise that someone with greater knowledge then mine, inspect this code. Also with this patches I didn't managed to neither receive nor send fax with app_txfax and app_rxfax, but it seems to me that SIP signaling and SDP processing part is OK in that case also.
By: Rosario Pingaro (rpingar) 2005-10-14 05:15:23

I used your file to patch plain chan_sip.c and it didn't give me an error.
I setted to reinvite the ata and the peer.

I didn't get the unkwon error into the console, but i see it into the messages log. The ata's log doesn't show any use of t.38

I compiled all asterisk with CFLAGS+=-DT38_SUPPORT and ereased all tpkt functions into chan_sip.c

So I think I got something wrong.
By: nenadr (nenadr) 2005-10-14 05:27:57

for rpingar: strange.... did you enabled t38support in sip.conf section [general] (t38udptlsupport=yes t38tcpsupport=no and t38rtpsupport=no settings) ? please enable verbose, debug, udptl and sip peers logging for peers with t38capable ATAs and send me log to email (nenadr (at) deltaplan.co.yu).
By: Rosario Pingaro (rpingar) 2005-10-14 07:09:07

Thanks NEnad,

now it seems to work.
By: steveu (steveu) 2005-10-16 00:11:14

Good work nenadr. That saved me filling in some holes in my patch :-).

I assume the only thing stopping this getting into CVS to provide at least basic passthrough operation is me donating the udptl transport. I just uploaded it, and I give permission for it to go into CVS. It should be complete for passthrough and delivering IFP packets to an application. It deals with all the error correction issues. I have a TPKT transport that is less ready to go into CVS, and I think it is less useful to people anyway.
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-10-18 06:48:54

with the attached patch, adding spandsp+t.38, I get the following compilation error:

gcc  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6 -march=k8 -DZAPTEL_OPTIMIZATIONS         -m64 -fomit-frame-pointer    -c -o tpkt.o tpkt.c
tpkt.c: In function `accept_thread':
tpkt.c:148: error: structure has no member named `sin'
tpkt.c:150: error: `block_sockets' undeclared (first use in this function)
tpkt.c:150: error: (Each undeclared identifier is reported only once
tpkt.c:150: error: for each function it appears in.)
tpkt.c:155: error: structure has no member named `lock'
tpkt.c:157: error: structure has no member named `send_events'
tpkt.c:158: error: `sessionlock' undeclared (first use in this function)
tpkt.c:159: error: structure has no member named `next'
tpkt.c:159: error: `sessions' undeclared (first use in this function)

...

same applies with the new udptl.[ch] files above
By: Roy Sigurd Karlsbakk (rkarlsba) 2005-10-18 07:34:37

hi

please remove that patch I uploaded

roy
By: Matt Riddell (zx81) 2005-10-18 07:54:19

Could all the files that are not needed for this to work be removed?
By: steveu (steveu) 2005-10-22 22:40:36

chan_sip.patch and chan_sip.patch2 are no longer needed. asterisk-t38.patch.txt is a more complete superset of those. Although I submitted them it seems I cannot delete them.
By: Matt O'Gorman (mogorman) 2005-10-23 00:33:32

there you go steve.
By: dlu (dlu) 2005-10-25 03:09:03

i miss a clear install base. if i checkout latest head and use spandsp-0.0.3pre4. Spandsp compiled correctly and then i copy all t38-bits into /usr/src/asterisk and patch all files without any error. Than i add ASTFLAGS+=T38_SUPPORT and add in frame.h  

/*! Modem-over-IP data streams */
#define AST_FRAME_MODEM 11

/* MODEM subclasses */
/*! T.38 Fax-over-IP */
#define AST_MODEM_T38 1
/*! V.150 Modem-over-IP */
#define AST_MODEM_V150 2

but errors still happen:
chan_sip.c: In function `sip_rtp_read':
chan_sip.c:3019: error: storage class specified for parameter `sip_rtp_read'
chan_sip.c:3019: error: syntax error before "struct"
chan_sip.c:3020: error: storage class specified for parameter `null_frame'
chan_sip.c:3020: error: parameter `null_frame' is initialized
chan_sip.c:3022: error: syntax error before "if"
........
and followerrors

@Steve please write a little install.txt from scratch to help users like me to can test the great extension.

Thanx all for your work.
By: Jason Sjöbeck (sjobeck) 2005-10-25 04:11:15

steveu: I know it is an annoying pain in the derrier, but, well, sorry, I am in the same place as 'dlu'.  I would hope that if you did write this, it would help more folks attempt the install, which means more folks testing, & more constructive feedback, & that might get us to where we all want to be. This really will be a big step for *. Thanks very much for your efforts. Everyone notices.


By: nenadr (nenadr) 2005-11-03 09:45:18.000-0600

Here is a bit improved version of T38 patch. You will need udptl.c/udptl.h from here or from t38-bits.tgz, tpkt.c/tpkt.h, sip.conf.sample.patch, udptl.conf.sample, tpkt.conf.sample from t38-bits.tgz (t38-bits should be from spandsp-0.0.3-pre4 on www.softswitch.org).

diff is made agains todays (11/03/2005) checkout of asterisk tree.

Improvements should be:

- processing of peers T38 SDP params and reacting upon them

- creation of T38 SDP based on real negotiated params (dropped hardcoded values)

- recognition of channel variable T38CALL for direct T38 INVITE (first invite with T38 SDP)

- recognition of T38 SDP in first invite and response with adequate SDP in it.

- attempt of "fax tone" detection (I say attempt, because according to specs. receiving fax should detect -optional- fax tone, and must detect fax preamble and I'm not sure can asterisk's dsp.c can detect fax preamble), and initiation of T38 re-invite on channel if channel is not bridged to another channel (last two option can be useful in future with spandsps app_rx/tx fax).

Fax pass-through functionality of patch is tested so far between Grandstream HT286 ATAs, Grandstream to Cisco 5350 Gateway and vice versa, and it worked fine.

Anyone who is going to test this patch should try to test it with both canreinvite=yes/no in peer/user section of sip.conf !!!

There are a two problems with this patch that I see:

1. Native UDPTL bridging with ast_udptl_bridge() never happens because I cannot find a way to tell asterisk to try native bridge again after T38 SDP is re-negotiated (if canreinvite is yes asterisk tries native RTP bridge only once and in a first phase of call while T38 switchover had happened (before first re-invite with T38 SDP)).

2. Native RTP bridging had to be disabled in order to T38 re-invite to happen :( . At the moment sip_bridge function disables RTP bridges if t38udptlsupport is enabled. This does the trick, but it is not good enough because it disables native RTP bridges on SIP-SIP calls. Alternative, that I can see, is to add per user/peer configuration option t38support which will do the trick regarding for whom to disable/enable native RTP bridge.

I kindly ask some of you guys with the better knowlage of asterisk (chan_sip) internals, to review the patch (it should be easy since everything is #ifdef-ed)
By: Kevin P. Fleming (kpfleming) 2005-11-07 23:39:50.000-0600

Sorry for being so not-present on this bug lately... I've been focusing on the stuff going into 1.2.

First: nenadr - do you have a disclaimer on file? It's somewhat difficult for us to track work in a single patch when multiple people work on it, but in this case I see no better alternative;

Second: steveu - what is holding this up going into CVS is the feature freeze. We haven't opened a post-1.2 CVS branch yet (since we will be converting to SVN at that time as well), so this will have to wait until 1.2 has been released before it can be merged. The current plan is release 1.2 early next week and get the new development tree open later that week.
By: nenadr (nenadr) 2005-11-08 00:44:13.000-0600

kpfleming - this is an extension of steveu's patch and as far as I know he has a disclaimer on file. If you think that you need my disclaimer on file I'll fax you one today. It would be really nice if you can find time to take a look at the patch, there is still a work to do regarding extending it for TPKT and RTP support, and I would realy like to know am I on the "right track" with stuff that is done so far.


By: Matt Riddell (zx81) 2005-11-08 12:37:17.000-0600

Hi, I'm getting the following in the console:

   -- Attempting native bridge of SIP/503-c41c and SIP/provider-88ce
Nov  8 13:35:43 WARNING[24744]: chan_sip.c:10083 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
Nov  8 13:35:44 WARNING[24744]: chan_sip.c:10083 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
Nov  8 13:35:49 WARNING[24744]: chan_sip.c:3709 process_sdp: Unknown SDP media type in offer: image 31472 udptl t38
 == Spawn extension (test, 1XXXXXXXXXX, 1) exited non-zero on 'SIP/503-c41c'
   -- Got SIP response 500 "Server Internal Error" back from XXX.XXX.XXX.XXX

<B>Update</B>: I forgot to enable the options in the top of the sip file.
<B>Update</B>: I'm now getting:

Nov  8 13:56:32 WARNING[24829]: chan_sip.c:3647 process_sdp: Unable to lookup host in c= line, 'IN IP4 22555'

Anyone able to help?


By: nenadr (nenadr) 2005-11-08 14:05:15.000-0600

ZX81: it is a very strange c= line indeed .... This looks to me like some issue with the ATA configuration, since the part of process_sdp function where that log line is, wasn't touched by this patch. I probably don't need to explain, but anyway :), log say is that your ATA reported its media IP address or a hostname as '22555', and that '22555' isn't resolvable to IP address.
By: Kevin P. Fleming (kpfleming) 2005-11-08 19:33:33.000-0600

Yes, we will need disclaimers from anyone who has copyright interest in this work... if you have contributed anything more than a few lines of trivial changes, then you qualify :-)
By: Matt Riddell (zx81) 2005-11-08 21:34:50.000-0600

Yeah I figured as much.  I had a look through the code and saw that message was coming from the hostname lookup.  Stupid Grandstream HT488 1.0.2.9.  I'll do another round of tests tonight and report on progress.
By: nenadr (nenadr) 2005-11-09 00:40:17.000-0600

kpfleming - OK I'll fax disclaimer today

ZX81 - Please try with newest Grandstream firmware (www.grandstream.com/BETATEST/) - Grandstream support recommended me that
By: Sergey Basmanov (sb) 2005-11-09 05:00:52.000-0600

How does it works?
I found some softphone that seems to support T.38
When I place a call, it generates CNG
but I don't see that asterisk detects this call as T38 call.
First, I see in logs:
Nov  9 13:53:12 DEBUG[28581]: chan_sip.c:3921 process_sdp: T38 state changed to 0 on channel <none>
before Dial() executed.
I set variable T38CALL to 'yes' and I see that T38 state on outgoing channel is still 0
Am I missing something? Who should initiate re-invite with T.38 ? Client or asterisk? How can I force a call to be T.38 call ?
And one more:
when remote fax answers, I see this in logs:
Nov  9 13:24:40 VERBOSE[28314] logger.c:     -- Attempting native bridge of SIP/140-20fb and SIP/voipexchange-4825
Nov  9 13:24:40 NOTICE[28314] chan_sip.c: T38 UDPTL support enabled so no native bridging
Nov  9 13:24:51 NOTICE[28314] rtp.c: Unknown RTP codec 100 received
Nov  9 13:24:51 NOTICE[28314] rtp.c: Unknown RTP codec 100 received


By: steveu (steveu) 2005-11-09 06:06:56.000-0600

sb: if you just see CNG data being sent, it sounds like you haven't started FAX transmission. If you had, there would be some audio and a re-invite to use T.38.
By: Sergey Basmanov (sb) 2005-11-09 06:34:39.000-0600

steveu: I'm not sure that softphone I found is really supporting T.38 (but they claims it does)
There is a button on panel 'Start FAX', when I press it while call, it writes on screen 'Sending CNG tones' and I hear fax guard tone in audio channel.
So, this is all I have. When remote fax answers, i see a message in logs about unknown codec 100, and nothing.. Calls made using g729.
By: steveu (steveu) 2005-11-09 07:05:04.000-0600

sb: ah, sorry. I am with you know. You mean it sends the CNG tone. I was thinking of comfort noise before. I wonder what codec 100 is set to in the SDP? Or whether it is set to anything at all? What is this soft-phone? Is it something we can all try?
By: Sergey Basmanov (sb) 2005-11-09 08:17:58.000-0600

steveu: softphone is at http://www.kapanga.net/ip/home.cfm
My setup is:
softphone->asterisk->provider->pstn->fax machine on my desk
softphone and provider claims t.38 support.
asterisk cvs 07-11-2005 with latest t.38 patch.
I can provide a debug output from my asterisk server if You give me email where to send it.
By: nenadr (nenadr) 2005-11-10 09:13:39.000-0600

I have uploaded V3 of patch. It is made against asterisk 1.2.0-RC1, and difference to a V2 is that couple of small issues are fixed. Same installation/testing instructions as for V2 still apply.

sb: I have tested Kapanga softphone with the T38 faxing and it worked fine with Cisco 5350 with both canreinvite=yes/no, and with Grandstream 286 (1.0.7.x firmware) with canreinvite=yes.

kpfleming: I have faxed disclaimer today.
By: Sergey Basmanov (sb) 2005-11-10 09:18:30.000-0600

nenadr: Thanks for lookin..
Can You please provide a call flow with T.38 ? I have no idea where to look. May be I missed something in configuration/source or in softphone setting.. Or my voip provider really doesn't support T.38.. So, in my setup, who must start re-invite with T.38 ? And when it must happen? When remote answers, or when I press 'Transmit Fax' button on softphone?
By: nenadr (nenadr) 2005-11-10 09:33:55.000-0600

sb: google for a "draft-ietf-sipping-realtimefax" - document has a couple of nice examples. Generally, if I have understood things, receiving side should issue re-invite when it detects fax CNG tone (which is optional) or fax preamble. So in your case providers equipment should issue a reinvite, after you have pressed start on the softphone (softphone starts to send CNG, and you are prompted for a tiff image to to send). Turn on debug logging and sip debug to a console, for a softphone's and provider's peers, you should be able to figure out from logs did re-invite happened and was the T38 negotiated.
By: steveu (steveu) 2005-11-10 09:41:27.000-0600

There are some example descriptions around, but actually the way the parties get into T.38 mode seems poorly defined. Something has got to trigger a re-invite, that is for sure. Exactly what stimulus does that is less sure.
By: Martin Vit (festr) 2005-11-10 09:46:24.000-0600

this patch isnt for doing conversion zaptel => sip of t.38? am I right? If yes, it is planning in the future? And what is already done for this?
thanks for any info.
By: Sergey Basmanov (sb) 2005-11-10 09:50:46.000-0600

I had sip debug turned on, and I seen that nor asterisk, nor voip provider seen cng tone. And even when remote fax answered, nothing changed.. Seems I really need to change voip provider to be sure that T.38 works for me.
Thank You all for help, I'll try to change provider and then post a report here.
By: Fabrizio Cuseo (fabry) 2005-11-11 05:41:37.000-0600

I'm trying with an Ata-286 Grandstream (with both 1.0.6.7 and last beta firmware), and an Italian VoIP provider supporting T.38 with Cisco Gateways (As53XX).
Sending fax works fine... but receiving fax causes this error:

 == Spawn extension (default, 0773XXXXXXXX, 1) exited non-zero on 'SIP/0773XXXXXXXXX-af08'
   -- Executing Dial("SIP/0773XXXXXXXXX-c35a", "SIP/fax") in new stack
   -- Called fax
   -- SIP/fax-6f35 is ringing
   -- SIP/fax-6f35 answered SIP/0773XXXXXXX-c35a
   -- Attempting native bridge of SIP/0773XXXXXXX-c35a and SIP/fax-6f35
Nov 11 13:36:45 NOTICE[8325]: chan_sip.c:2825 sip_bridge: T38 UDPTL support enabled native RTP bridging disabled
Nov 11 13:36:52 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:53 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
Nov 11 13:36:54 WARNING[8325]: rtp.c:460 ast_rtp_read: RTP Read too short
[skip......]

And the call hangs...

hcp5*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Form  Hold     Last Message  
XXX.XXX.XXX.XXX    fax         2cdeb77856d  00102/38938  ulaw  No       Rx: ACK        
XXX.XXX.XXX.XXX   0773XXXXXX  D14EE00E-51  00102/00101  ulaw  No       Tx: ACK        


Any idea ?
Thanks, Fabrizio Cuseo
By: Lee Howard (faxguy) 2005-11-11 10:22:13.000-0600

Steve,

I get a "unrecognized codec 100" message whenever I send a fax out from the FXS port on my Sipura SPA-2000.

Thanks,

Lee.
By: nenadr (nenadr) 2005-11-11 11:41:22.000-0600

fabry: dind't showed debug log, so my assumption is that for some reason your grandstream doesn't detect fax CNG or preamble in a call coming from your provider, and it doesn't issue a reinvite... it is quite possible that your provider is passing a call to your asterisk with some codec other than ulaw/alaw. turn on sip debuging on console and test again - you should be able to see did the T38 re-invite happened.

faxguy: codec with a payload type 100 on kapanga softphone is speex; I don't know is that a case with sipura but, anyway, looking at rtp.c I don't see that payload type 100 is defined at all (and speex is defined as type 110).


By: Fabrizio Cuseo (fabry) 2005-11-11 11:54:25.000-0600

nenadr: as you can see from my previous note, the call is established with ulaw codec... and i've tested my Grandstream ata directly with the VoIP provider; all works fine...
On monday i'll post a link with my debug log.
Have a nice week end.
Fabrizio
By: nenadr (nenadr) 2005-11-11 12:04:11.000-0600

fabry: sorry, didn't noticed sip show channels at the end of bugnote... looking forward to see that debug log since it will be done on equipment I have here (or similar), so I can try to reproduce it (I didn't had any problems in T38 communication between Cisco 5350 to HT 286).
By: dlu (dlu) 2005-11-12 14:24:14.000-0600

@steveu

got latest CVS head from today and add the

/*! Modem-over-IP data streams */
#define AST_FRAME_MODEM 11

/* MODEM subclasses */
/*! T.38 Fax-over-IP */
#define AST_MODEM_T38 1
/*! V.150 Modem-over-IP */
#define AST_MODEM_V150 2

to t38 pre4. Add all the patches but still cant compile chan_sip.c

make[1]: Leaving directory `/usr/src/asterisk/res'
make[1]: Entering directory `/usr/src/asterisk/channels'
gcc  -DT38_SUPPORT -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6 -march=i686 -DZAPTEL_OPTIMIZATIONS         -fomit-frame-pointer  -Wno-missing-prototypes -Wno-missing-declarations -DZAPATA_PRI -DIAX_TRUNKING -DCRYPTO -fPIC    -c -o chan_sip.o chan_sip.c
chan_sip.c:969: warning: initialization from incompatible pointer type
chan_sip.c: In function `sip_registry_destroy':
chan_sip.c:2121: error: `p' undeclared (first use in this function)
chan_sip.c:2121: error: (Each undeclared identifier is reported only once
chan_sip.c:2121: error: for each function it appears in.)
chan_sip.c: In function `sip_bridge':
chan_sip.c:2742: warning: comparison of distinct pointer types lacks a cast
chan_sip.c:2748: warning: comparison of distinct pointer types lacks a cast
chan_sip.c:2770: error: too few arguments to function `ast_rtp_bridge'
chan_sip.c:3005:2: #endif without #if
chan_sip.c: At top level:
.........

what went wrong?

Thanx
By: Fabrizio Cuseo (fabry) 2005-11-14 05:16:27.000-0600

nenadr: you can find my debug log (my problem is only in receive fax... sending is ok) at this address:

http://discovirtuale.panservice.it/fabry/t38/fax.txt

Thank's in advance for your support.
Fabrizio
By: nenadr (nenadr) 2005-11-14 05:40:41.000-0600

fabry: I think I know what is the problem and how to fix it, but for confirmation purposes, please send me your SIP peers configurations for both provider and grandstream to nenadr (at) deltaplan.co.yu. Thank you !

faxguy: Are you using sipura SPA 2000 or 2100 ? As far as I know only 2100 so far supports T38 faxing !

dlu: I have succesfully patched, compiled and tested this patch on 1.2.0-RC2 which has the same revision of chan_sip.c as a CVS from date you mentioned.
By: Lee Howard (faxguy) 2005-11-14 10:17:54.000-0600

nenadr, I'm using a SPA-2000.  Yes, I know that it doesn't support T.38.  I merely mentioned it so to perhaps shed some light on the "codec 100" issue.
By: dlu (dlu) 2005-11-14 10:44:52.000-0600

@nenadr

What patch you apply? The one from T38-bits (chan_sip.c.patch)or the  "asterisk-t38-patch3.diff (57,491 bytes) 11-10-05 09:03" from this page???? I always use T38-bits from steves site.
By: nenadr (nenadr) 2005-11-14 10:58:24.000-0600

dlu: asterisk-t38-patch3.diff - this is newer version of patch that steve included t38bits. It is also made against the asterisk 1.2.0-RC1 source and it compiles and works on RC2 also, and fixes couple of issues that steve's original patch had. Please read first couple of lines from bugnote 0035735, regarding installation.
By: dlu (dlu) 2005-11-15 03:52:10.000-0600

@nenadr

great now asterisk compile but we also use app_rxfax.c and after i add it from t38-bits it wont compile.

gcc  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6 -march=i686 -DZAPTEL_OPTIMIZATIONS         -fomit-frame-pointer  -DT38_SUPPORT -fPIC   -c -o app_rxfax.o app_rxfax.c
app_rxfax.c: In function `t38_tx_packet_handler':
app_rxfax.c:151: error: structure has no member named `ast_chan'
app_rxfax.c:162: error: structure has no member named `ast_chan'
app_rxfax.c: In function `rxfax_exec':
app_rxfax.c:358: error: structure has no member named `ast_chan'
app_rxfax.c: At top level:
app_rxfax.c:69: warning: `t30_flush' defined but not used
make[1]: *** [app_rxfax.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-1.2.0-rc2/apps'
make: *** [subdirs] Error 1
sip01:/usr/src/asterisk-1.2.0-rc2 #  

I guess there are some patches required.
By: nenadr (nenadr) 2005-11-15 04:04:13.000-0600

dlu: That happens to me also, and even if I add a missing member of t38_state struct, and get it compiled, I get a segfaults on app_rx/txfax execution ! Real fixing of this is a question for Steve :). Anyway you don't need app_tx/rxfax to test T38 pass-through operation.
By: Daniele Gallina (gallysoft) 2005-11-15 05:57:40.000-0600

Hi all. After patching asterisk-1.2.0-rc2 with asterisk-t38-patch3.diff on make it say:

udptl.c: In function `ast_udptl_read':
udptl.c:646: warning: `seqno' might be used uninitialized in this function
make: *** No rule to make target `tpkt.o', needed by `asterisk'.  Stop.

Where is the problem?
Thanks.
By: Matt Riddell (zx81) 2005-11-15 08:16:56.000-0600

Hi, I'm getting what seems like the same sequence number repeated over and over, any ideas?

Got UDPTL packet from xxx.xxx.xxx.xxx:38124 (type 0, seq 1081327328, len 172)
Got UDPTL packet from xxx.xxx.xxx.xxx:38124 (type 0, seq 1081327328, len 172)
Got UDPTL packet from xxx.xxx.xxx.xxx:38124 (type 0, seq 1081327328, len 172)
Got UDPTL packet from xxx.xxx.xxx.xxx:38124 (type 0, seq 1081327328, len 172)
Got UDPTL packet from xxx.xxx.xxx.xxx:38124 (type 0, seq 1081327328, len 172)
By: dlu (dlu) 2005-11-15 09:45:11.000-0600

@nenadr,steveu

for T38 passthru we didnt need app_rxfax but we need fax to email bad so we cant left this feature.
By: gnudialer gnudialer (gnudialer) 2005-11-17 11:08:35.000-0600

nenadr and dlu:

I get the same thing as nenadr and dlu..

I can get app_txfax.c and app_rxfax.c to compile by either adding the ast_chan var or by commenting the lines referring to it (since it doesn't seem that it is being used anywhere anyway).

Mine doesn't seg though, but the faxes don't go thru.  Could be an issue with our setup/provider though.

I don't remember anyone saying that either app works yet so we'll wait it out.  Either way they'll kick arse once they do.

For those who wanted instructions.. Here's how we got it to compile...

1. Download latest asterisk CVS Head, spandsp, t38-bits, and asterisk-t38-patch3.diff
2. Install spandsp
3. Remove "FORCE" from the version.h label in the Asterisk Makefile (or else it wants to do this crazy looping thing).
4. Copy tpkt.c and udptl.c from t38-bits to the main asterisk source directory.
5. Copy all files from t38-bits/include/asterisk/ to asterisk/include/asterisk/
6. Copy all files from t38-bits/configs to asterisk/configs
7. Apply the sip.conf.sample.patch in asterisk/configs
8. Copy all files from t38-bits/apps to asterisk/apps
9. Apply Makefile.patch in asterisk/apps (it will fail)
10. Copy the rejected chuck (the part with the pluses +++) from Makefile.rej to Makefile after the app_curl.so label
11. Make sure the tabs in the chunk don't get converted to spaces and don't forget to take out the pluses (yes I actually forgot to do that the first time).
12. From the line that says "APPS+=app_rxfax.so app_txfax.so app_udptl_test.so" remove app_udptl_test.so cuz it doesn't compile
13. mkdir asterisk/include/spandsp
14. Copy all files from spandsp-0.0.3/src/spandsp/ to asterisk/include/spandsp/
15. Copy spandsp.h from spandsp-0.0.3/src/ to asterisk/include/
16. Apply the asterisk-t38-patch3.diff in the main Asterisk source directory.  (be prepared to provide the full paths to some of the files, e.g. utils/frame.h channels/chan_sip.c include/asterisk/udptl.h (there might have been more i can't remember)) !!! The frame.h patch will fail! Don't worry about it...
17. Comment out the lines in app_txfax.c and app_rxfax.c that refer to t38.ast_chan (some of those lines will have corresponding "if" statements so don't forget to comment those out too)
18. make clean && make (will fail)
19. You'll get AST_MODEM undefined and some other stuff.. so add the frame.h chunk from the patch manually to each file that needs it (just adding it to frame.h didn't work for some reason.. even though it worked the first time i did it)
20. make install
By: gnudialer gnudialer (gnudialer) 2005-11-20 18:04:43.000-0600

realized that ast_channel ast_chan struct is actually being used so adding the member is indeed necessary... app_rxfax and app_txfax are clearly broken cuz we tried sending to a supporting provider with no luck (doesn't send any data; we watched with iptraf)

also tried setting up our own sip trunk between 2 servers (txfax on one, and rxfax on the other) with no luck.

i tried my own instructions and they do work for getting it to compile, but of course don't comment out lines that refer to ast_chan.

I think steve realized that there shouldn't be any reference to asterisk stuff in the spandsp includes so he must have taken out the ast_chan and forgot to find another solution or hasn't gotten around to it or something...

not too worried either way given the fast pace this is going


By: Anton (apt) 2005-11-22 05:54:44.000-0600

Hi all.
My configuration like this: Fax over T38+H323 ---> Asterisk 1.2 -->-SIP->Cisco 827(with t38 support) --->fax(brother).  Without Asterisk, Cisco827 fine work by h323 with my voip ISP. I have compile STEP-BY-STEP T38 into Asteris 1.2 like heath1444 provide to do.  But fax's  still not work. to both ways :(  

This is part of my cisco config:
voice service voip
fax protocol t38 ls-redundancy 5 hs-redundancy 2 fallback pass-through g711alaw
h323
sip
---
t38 setting in Sip.conf:
t38udptlsupport=yes
t38tcpsupport=no
t38rtpsupport=no

When incoming or outgoing fax  trying, i have this debug info:
Sorry for over-posting, help me please:
======================================================================
Transmitting (no NAT) to Cisco827-IP:5060:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP  Cisco827-IP:5060;received=Cisco827-IP
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact:
Content-Length: 0


---
We're at Asterisk-IP port 17304
Adding codec 0x2 (gsm) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x8 (alaw) to SDP
Reliably Transmitting (no NAT) to Cisco827-IP:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP  Cisco827-IP:5060;received=Cisco827-IP
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact:
Content-Type: application/sdp
Content-Length: 209

v=0
o=root 31549 31550 IN IP4 Asterisk-IP
s=session
c=IN IP4 Asterisk-IP
t=0 0
m=audio 17304 RTP/AVP 3 0 8
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=silenceSupp:off - - - -

---
nagios*CLI>
<-- SIP read from Cisco827-IP:55551:
ACK sip:94396445@Asterisk-IP:5060 SIP/2.0
Via: SIP/2.0/UDP  Cisco827-IP:5060
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Date: Wed, 10 Mar 1993 23:56:48 GMT
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK


--- (9 headers 0 lines)---
Nov 21 15:32:00 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 100 received
...
Nov 21 15:32:03 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 100 received
Nov 21 15:32:03 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
Nov 21 15:32:04 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
Nov 21 15:32:05 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 100 received
...
Nov 21 15:32:06 NOTICE[31556]: chan_sip.c:2844 sip_bridge: T38 UDPTL support enabled native RTP bridging disabled
Nov 21 15:32:10 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
Nov 21 15:32:12 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 100 received
...
nagios*CLI>
<-- SIP read from Cisco827-IP:50226:
INVITE sip:94396445@Asterisk-IP:5060 SIP/2.0
Via: SIP/2.0/UDP  Cisco827-IP:5060
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Date: Wed, 10 Mar 1993 23:57:32 GMT
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
Supported: timer,100rel
Min-SE:  1800
Cisco-Guid: 3114938287-482939340-2233247478-3172329006
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO
CSeq: 102 INVITE
Max-Forwards: 6
Remote-Party-ID: ;party=calling;screen=no;privacy=off
Timestamp: 731807852
Contact:
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 424

v=0
o=CiscoSystemsSIP-GW-UserAgent 6080 6422 IN IP4 Cisco827-IP
s=SIP Call
c=IN IP4 Cisco827-IP
t=0 0
m=image 17004 udptl t38
c=IN IP4 Cisco827-IP
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy
a=qos:optional sendrecv

--- (20 headers 17 lines)---
Using INVITE request as basis request - BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
Sending to Cisco827-IP : 5060 (non-NAT)
Got T.38 offer in SDP
Peer audio RTP is at port Cisco827-IP:65535
Peer T.38 UDPTL is at port Cisco827-IP:17004
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)
Reliably Transmitting (no NAT) to Cisco827-IP:5060:
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/UDP  Cisco827-IP:5060;received=Cisco827-IP
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Max-Forwards: 70
Contact:
Content-Length: 0


---
Nov 21 15:32:19 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
nagios*CLI>
<-- SIP read from Cisco827-IP:50226:
ACK sip:94396445@Asterisk-IP:5060 SIP/2.0
Via: SIP/2.0/UDP  Cisco827-IP:5060
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Date: Wed, 10 Mar 1993 23:57:32 GMT
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
Max-Forwards: 6
Content-Length: 0
CSeq: 102 ACK


--- (9 headers 0 lines)---
Nov 21 15:32:21 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
...&ASTERISK-1081;&ASTERISK-1080;&ASTERISK-1068;&ASTERISK-1084;&ASTERISK-1080;&ASTERISK-1082;&ASTERISK-1093;...
Nov 21 15:32:45 NOTICE[31549]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received

<-- SIP read from Cisco827-IP:57894:
BYE sip:94396445@Asterisk-IP:5060 SIP/2.0
Via: SIP/2.0/UDP  Cisco827-IP:5060
From: "0021" ;tag=337CAA68-21A3
To: ;tag=as124cac91
Date: Wed, 10 Mar 1993 23:57:32 GMT
Call-ID: BD82B07A-1CC911CC-851FA6F6-BD15E62E@Cisco827-IP
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 6
Timestamp: 731807879
CSeq: 103 BYE
Content-Length: 0
By: Marcello (hunters) 2005-11-28 03:02:23.000-0600

Hi heath1444,
i tryied to use your instructions to compile, all went ok during patching but it still doesn't compile app_rxfax.c on asterisk-1.2.0 stable release (spandsp-0.0.3pre6 and t38bits from that release)(chan_sip compiled ok).

Platform SLES9 x86_64

Here my output:

make[1]: Entering directory `/data/src/asterisk-1.2.0_t38tmp/apps'
gcc  -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6 -march=k8 -DZAPTEL_OPTIMIZATIONS         -m64 -fomit-frame-pointer  -DT38_SUPPORT -fPIC   -c -o app_rxfax.o app_rxfax.c
In file included from ../include/spandsp.h:47,
                from app_rxfax.c:23:
../include/spandsp/arctan2.h: In function `arctan2':
../include/spandsp/arctan2.h:51: warning: implicit declaration of function `fabs'
In file included from ../include/spandsp.h:54,
                from app_rxfax.c:23:
../include/spandsp/dc_restore.h: In function `fsaturate':
../include/spandsp/dc_restore.h:107: warning: implicit declaration of function `rint'
app_rxfax.c: In function `t38_tx_packet_handler':
app_rxfax.c:151: error: structure has no member named `ast_chan'
app_rxfax.c:162: error: structure has no member named `ast_chan'
app_rxfax.c: In function `rxfax_exec':
app_rxfax.c:358: error: structure has no member named `ast_chan'
app_rxfax.c: At top level:
app_rxfax.c:69: warning: `t30_flush' defined but not used
make[1]: *** [app_rxfax.o] Error 1
make[1]: Leaving directory `/data/src/asterisk-1.2.0_t38tmp/apps'
make: *** [subdirs] Error 1


Any ideas??
Thanks,
Bye,
Marcello
By: Matt Riddell (zx81) 2005-11-30 07:40:52.000-0600

Any way we can get a review and get the code into CVS?  That way we'll stop getting questions here and they'll end up on the users list :D

What needs to happen to move this forward?
By: Serge Vecher (serge-v) 2005-11-30 10:16:16.000-0600

One would think that an updated patch is in order, as well as a revised README file similar to what heath1444 wrote up on 11/17
By: deti (deti) 2005-12-01 04:26:22.000-0600

Isn't there any full patch that applies properly to the current asterisk tree (with real directory and file names)?
By: Denis Smirnov (mithraen) 2005-12-05 08:31:49.000-0600

When this patches would be in svn head?
By: Ezio Vernacotola (ezio) 2005-12-11 07:28:21.000-0600

In asterisk-t38-patch-all.diff there is the full patch against current asterisk svn 1.2.

I have followed the install instruction of heath1444 and generated the patch with "svn diff". To apply go into asterisk root dir and execute "patch -p0 < asterisk-t38-patch-all.diff".

To make it compile I have commented the code referencing t38.ast_chan in app_txfax.c and app_rxfax.c.

I have tested with success the t38 passthrough in a "follow me like" application in this manner: fax is sent to a my provider via pstn, the provider calls my asterisk via sip, if NVFaxDetect recognize the call as fax the call is redirected via the same provider to another pstn fax number.
By: steveu (steveu) 2005-12-11 07:49:08.000-0600

Wakey, wakey. Its post 1.2. It time to get this stuff into SVN so we can start moving beyond passthrough, and get the more interesting stuff going.
By: jkoko1 (jkoko1) 2005-12-13 09:39:24.000-0600

I am applied the patch asterisk-t38-patch-all.diff to Asterisk 1.2.1.
The patch applied clean, make run ok.
When I am starting asterisk I got following error.

[app_rxfax.so]Dec 13 17:22:17 WARNING[26752]: loader.c:325 __load_resource: /usr/lib/asterisk/modules/app_rxfax.so: undefined symbol: t30_get_far_ident
Dec 13 17:22:17 WARNING[26752]: loader.c:554 load_modules: Loading module app_rxfax.so failed!
Ouch ... error while writing audio data: : Broken pipe
By: Andrew Lindh (andrew) 2005-12-13 10:33:17.000-0600

I still get unknown media type on as pass thru....
Unknown RTP codec 100 received
Unknown SDP media type in offer: image 16816 udptl t38

Asterisk 1.2 (SVN), SpanDSP 3pre6, the last patch, sipura SPA-2100, cisco AS5300

If I try rxfax, it crashes astersik (has since 2pre21, even without t38).
By: Ezio Vernacotola (ezio) 2005-12-13 11:22:05.000-0600

I tested only passtrought (noload => app_txfax.so, noload => app_rxfax.so). Now I have removed the patch on my system because the call transfer with a grandstream bt100 (normal voice calls, no fax at all) don't worked anymore, ie the user press the flash key on the phone, the party goes on hold and after a while the call hangs up.

Andrew have you put t38udptlsupport=yes in sip.conf?
By: Andrew Lindh (andrew) 2005-12-13 13:14:50.000-0600

Forgot the sip.conf change. Passthru works now. But fails when I use the grandstream HT-286 ATA with 1.0.7.11 firmware. The call starts and when it switches to t38 all I get is "RTP Read too short" errors on the asterisk console. But it works with the Sipura.
By: Daniele Gallina (gallysoft) 2005-12-15 02:54:38.000-0600

Is the patch allready in cvs head? I can't patch 1.2 branch with asterisk-t38-patch-all.diff because it don't work.
By: steveu (steveu) 2005-12-29 05:56:05.000-0600

I have abandoned work on this. It seems FAX support for * is of no interest to anyone in a position to help move it forward. What a waste of time this was.
By: Fabrizio Cuseo (fabry) 2005-12-29 06:18:33.000-0600

steveu: i'm very interested in t.38 support for Asterisk... i've done test with sip providers and with different kind of equipments, but with some problem that i've posted here. The only problem is that i'm not a C coder, so all my work will be limited to test.

If i can be helpful in some way, let me know.
Fabrizio
By: Rosario Pingaro (rpingar) 2005-12-29 06:29:33.000-0600

I am interested too.

And I think also the your (Steave) and Nenad work has been great.
Hope that you and Nenad will not leave us without the t.38

Regards
Rosario
By: Martin Vit (festr) 2005-12-29 06:30:39.000-0600

i can also help testing with many devices
By: Marek Cervenka (cervajs) 2005-12-29 06:45:52.000-0600

there are many people with interest in t.38, but are not C programmers :(
i have grandstream, sipura, asus, .. hardware and can test too
By: Matthew Fredrickson (mattf) 2005-12-29 08:37:10.000-0600

Hey steve, sorry, it's just been pretty busy around here recently trying to keep on top of a lot of things.  I haven't been keeping up to date on this, but I'll talk to kpfleming or markster and see what's going on with it.
By: Denis Smirnov (mithraen) 2006-01-03 06:57:57.000-0600

T.38 support wants *all* my clients

How I can help with it?
By: Gerd Flaig (gefla) 2006-01-03 09:23:10.000-0600

Mithraen, I believe testing/debugging the T.38 code in OpenPBX.org would help most right now. Later, the Asterisk folks can merge that code back. Beware that any of the three t.38 options (Asterisk 1.0, Asterisk 1.2, OpenPBX.org) I am currently aware of needs some developer skills.
By: Tilghman Lesher (tilghman) 2006-01-03 10:37:30.000-0600

Patch updated to current trunk, disabled by default (which is how I think it's going to be merged eventually, anyway).
By: Matthew Fredrickson (mattf) 2006-01-03 10:50:06.000-0600

We can't do much with the big patch right now, AFAIK, spandsp isn't disclaimed (steveu, feel free to correct me if this is not so).  Right now, the only thing keeping the little patch from compiling is an implementation of tpkt.[c,h] that is disclaimed.  We'll have to see what steveu wants to do about it before it can be committed.
By: steveu (steveu) 2006-01-03 17:06:53.000-0600

spandsp is not disclaimed, and will never be. The current patches in the bug tracker add passthrough T.38 operation, and the infrastructure for other modes of T.38. These do not depend on spandsp. The patch should certainly be split back up, into the individual files it affects. udptl.c and updtl.h are new files, and adding those is completely independent of the other changes. The changes to chan_sip.c inevitably form one fairly large patch. Not a lot can be done about that.
By: Denis Smirnov (mithraen) 2006-01-04 04:19:24.000-0600

It add T.38 passthrow only for SIP?
Would it works with T.38-device<-SIP>Asterisk<-IAX2->Asterisk<-SIP->T.38 device?

Can spandsp with fax modules be added to asterisk-addons?
By: Roy Sigurd Karlsbakk (rkarlsba) 2006-01-04 04:25:51.000-0600

> It add T.38 passthrow only for SIP?
> Would it works with T.38-device<-SIP>Asterisk<-IAX2->Asterisk<-SIP->T.38 device?

AFAIK passthrought will require UDPTL which is not supported for IAX2.

> Can spandsp with fax modules be added to asterisk-addons?

I really don't see why not. Lots of GPLish stuff is in -addons already...

roy
By: Denis Smirnov (mithraen) 2006-01-04 09:30:08.000-0600

steveu, can you disclaim patches for chan_sip.c, needed to works with T.38 and app_rxfax/app_txfax?
By: Matthew Fredrickson (mattf) 2006-01-04 09:41:57.000-0600

Ok, here is the latest version of steve's t.38 pass through patch in preparation for committing.  It should apply against SVN-head cleanly.  I've looked through it, and it appears to be mostly ready. I just need to sit down with kpfleming to go through the chan_sip portions (since he's a bit more SIP savvy than I am).
By: Matthew Fredrickson (mattf) 2006-01-04 09:45:45.000-0600

Oh yeah, here's the post-patched versions of udptl.h and .c that are for this patch.
By: Serge Vecher (serge-v) 2006-01-04 11:40:21.000-0600

udptl.* have Steve's last name misspelled. Also, a comma needs to be placed in front of 'which' on the same line.
By: Tilghman Lesher (tilghman) 2006-01-04 16:31:16.000-0600

Apparently someone missed the memo.  DO NOT PASTE DEBUG OUTPUT INTO BUGNOTES.  Upload a file, instead.
By: gnudialer gnudialer (gnudialer) 2006-01-04 17:02:38.000-0600

Can anyone shed some light on the future of app_rxfax/txfax?

I spose it would be pointless to have them installed if a person doesn't have spandsp installed.

Then again, it would be a chore for people to have to 1. install spandsp 2. install asterisk 3. install the apps separately...

Perhaps the Makefile could install them if spandsp is installed?

It doesn't really matter to me cuz I can always hack it together; it is just that I think we can safely expect the apps' popularity to soar once this stuff gets really stable.


On another note.. There's a minor issue with the patch...

If you disable T38 support in the Makefile, udptl.c still compiles, but the parts of frame.h are undefined.  Should be easy for you guys to fix, just thought I'd point that out.


A couple of other semi-related points people should look out for...

1. The Makefile patch for app_rxfax and app_txfax is jacked, so expect to do some hacking (putting the spandsp headers in asterisk source dir/Manually adding the stuff from Makefile.rej) if you try to install them

2. The apps themselves still have the ast_chan struct problem, so you still have to mod t38.h.
By: Rosario Pingaro (rpingar) 2006-01-05 15:43:59.000-0600

I posted my log about asterisk patched by the latest one doing t38-udptl passthrough between cisco gateway and a kapanga softphone (t38 enabled).

Seems asterisk it is not able to start the udptl session and when it fall back to rtp it is not able to bridge.

regards
By: Matthew Fredrickson (mattf) 2006-01-06 13:08:10.000-0600

Could those of you that had this working previously (for pass through) try the latest patch to make sure I didn't break anything in up-porting it and taking out the tkpkt transport type?
By: Rosario Pingaro (rpingar) 2006-01-07 02:04:37.000-0600

Patch3 from Nenad was working with Kapanga and as you can see from the posted log something is not working about the latest one.

Rosario
By: mman (mman) 2006-01-10 09:24:38.000-0600

Will this patch work correctly even if there are proxy (Local) channels between the SIP end channels?
By: Matthew Fredrickson (mattf) 2006-01-12 10:22:29.000-0600

does this patch (20060103__t38.diff.txt) work too? If so, can you do a sip debug of a working t.38 call for me so I can compare the difference between the two and figure what I might have broken? thanks.
By: Mark Dickey (cyon) 2006-01-13 16:43:39.000-0600

I have been monitoring this thread for some time, but felt my skills were insufficient to provide any real value.  However, I am highly interested in having this functionality work, and now that I have T.38 Passthrough functioning using (*cough*) ser, I felt that my debugs from asterisk might be of some value.  Or at the least, if I'm doing something wrong, it could be pointed out.

My logs are:  http://pastebin.com/504563

I have ser and asterisk on the same box, would kill ser, start asterisk, and this happens.  Kill asterisk, start ser, and the fax goes through perfectly every time.  (Although outgoing only, as the PRI I'm testing over is an LD one, and my local has slipping and attenuation issues that are being worked on.)

Anyway, FreeBSD, * 1.2.1 with the  t38_pre1.diff applied and associated files.  If it would be of assistance, I can test with the svn version of *, as well as test with the 20060103__t38.diff.txt patch.

While I'm not a skilled coder, I will act as a very ready pair of hands for anything that needs to be done.
By: steveu (steveu) 2006-01-15 05:31:18.000-0600

Since the udptl stuff seems to have gone into SVN, I guess the config file ought to join it.
By: raiden (raiden) 2006-01-16 15:11:32.000-0600

Now that the udptl code for T.38 support has been added to SVN, Could someone please create an updated diff file for T.38 support based on the latest SVN?
By: Matthew Fredrickson (mattf) 2006-01-17 09:13:43.000-0600

Ooops, forgot about that.  I'll put that in.  The next step after this is to figure out what broke in my "backport" of chan_sip.c.
By: Andre Nazario (samoied) 2006-01-20 12:05:12.000-0600

Anyone have the BETATEST Firmware for grandstream HT488? The directory http://www.grandstream.com/BETATEST/HT488_496_386/ is empty!
I want this because my HT488 dont detect the FAX signal, and no send T.38 request...
By: raiden (raiden) 2006-01-20 15:53:37.000-0600

Could someone please make a new t.38 diff patch based on the latest svn trunk and upload it? Thanks
By: Matthew Fredrickson (mattf) 2006-01-20 16:04:23.000-0600

There, that's the latest one against trunk.  It needs testing.  Basically all that is left is to work out the kinks in the chan_sip patch.  We put all the udptl code in, as well as the framework modifications, so this is the last of it for getting passthrough.
By: Matthew Fredrickson (mattf) 2006-01-24 12:28:56.000-0600

Hrm... I can't really get anywhere with these logs.  If somebody with t.38 equipment and can get me login access to their machine, I'll take a look at it.  You can get ahold of me on IRC as Cresl1n.
By: deti (deti) 2006-01-24 13:23:48.000-0600

The latest spandsp version is 0.0.3pre6 from november 13th. Can anyone tell me which app_(r|t)xfax.c work with the current trunk-t38_pre2.diff patch?
By: acheck (acheck) 2006-01-24 23:39:54.000-0600

I have installed SVN with patch issued by mattf at 01-20-06 16:04 and made successfull testing of T.38 on SIP between Cisco AS5300 and AS5400 and between Cisco AS5300 and Addpac 2xFXS gateways - it works stable with RE-INVITE enabled. If any of developers would need SSH access to my * box I can provide it. I'm available on ICQ - UIN 61260294.

Unfortunatelly I can't compile app_rxfax from spandsp-0.0.3pre6.tar.gz and have no chance to test it.
By: raiden (raiden) 2006-01-27 02:17:30.000-0600

I applied the latest trunk-t38pre2.diff and with 2 Sipura 2100 (Latest 3.2.5d firmware) working with T.38. I had turned off ReInvite(in sip.conf) for my adapters but they were both behind the same network. The only concern was that I never saw any messages saying that a T.38 connection has been established on my cli.
By: Bryan Copleand (bcopeland) 2006-01-27 12:10:39.000-0600

I'm Including chan_sip.diff .. for patching the lastest trunk downloaded today 1/27
By: Bryan Copleand (bcopeland) 2006-01-27 12:17:51.000-0600

Ok.. I'm a retard.. excuse that last file please...

New Diff file : retard_chan_sip.diff
By: Pavel Siderov (psiderov) 2006-02-01 01:09:24.000-0600

I couldn't patch my chan_sip.c (Using latest SVN). Lots of hunks while patching and it failed at last:

20 out of 52 hunks FAILED -- saving rejects to file chan_sip.c.rej
By: Bryan Copleand (bcopeland) 2006-02-01 06:42:05.000-0600

Which patch were you using that failed?
By: Dirk Willbrandt (dirkw) 2006-02-02 03:11:35.000-0600

i have the same errors with all SVN versions and all Stable releases up from version 1.2.2 with all Patches. Also with the t38_bits.tgz from steveu i have some errors.

Yesterday i patched the chan_sip.c by hand, all works fine. I can compile asterisk but t38 won't work :(

Asterisk see that a fax is coming in on Channel A activates UDPTL and tries to "bridge" the Traffic to our Carrier (he has t38 Support) but the Fax Conversation breaks after some seconds and i don't know why.

Is there any idea?
By: Dirk Willbrandt (dirkw) 2006-02-02 05:02:29.000-0600

just as note:

in all patches that i tried to apply i had to move the function-prototyp for "sip_bridge" in chan_sip.c to the other declarations somewhere at the top of chan_sip.c. If not i got some compilier errors because he can't find the function.
By: Bryan Copleand (bcopeland) 2006-02-02 07:44:58.000-0600

Out of curiosity who is your t.38 provider and ata? ... I got udptl running pretty stable using svn trunk and sipura spa-2100 with latest firmware... and the patch I provided ... I am just having an issue with the ata having to re register... Which I hope to have resolved today...
By: jkoko1 (jkoko1) 2006-02-02 08:19:09.000-0600

To:bcopeland
I have the same error by patching. Asterisk 1.2.4 and retard_chan_sip.diff.
By: Dirk Willbrandt (dirkw) 2006-02-02 09:59:52.000-0600

It's a german telephone provider, he uses a SER-Proxy as Gateway and behind the Proxy is a Cisco PGW VoiceSwitch with t38 support.

for a few days there was a SVN Trunk from asterisk version 1.2.2 with, i think, t38 support enabled, because with that version Faxing works fine. But then the Timebomb goes up and then i've updated to another Asterisk version. After this fax won't working.
By: Matthew Fredrickson (mattf) 2006-02-02 11:39:15.000-0600

Here's the latest version, updated to trunk.
By: kent (kent) 2006-02-02 11:52:46.000-0600

nice patch but i can't see the function ast_udptl_proto_unregister :)))))
By: Dirk Willbrandt (dirkw) 2006-02-03 04:14:13.000-0600

i had downloaded the latest svn trunk and patched the sources. It went well.

Now i've just the problem with our carrier. Maybe the reason for the T.38 disconnects is a carrier fault.
By: Pavel Siderov (psiderov) 2006-02-03 05:31:40.000-0600

Downloaded the latest svn - asterisk, libpri, zaptel. The latest patch - trunk-t38_pre3.diff. Used the instructions given from health1444. But app_rxfax doesn't compile. Attached the errors. Any ideas?
Thanks in advance!
By: kent (kent) 2006-02-03 07:07:58.000-0600

to add in yr patch :))

 #if defined(T38_SUPPORT)
    /* Tell the UDPTL subdriver that we're here */
    ast_udptl_proto_unregister(&sip_udptl);
 #endif
By: Dirk Willbrandt (dirkw) 2006-02-03 07:25:10.000-0600

where is that to add ?
By: kent (kent) 2006-02-03 07:38:20.000-0600

are you not programmer ?

inside the function      int unload_module()
after or before
a function ast_rtp_proto_unregister(&sip_rtp);

#if defined(T38_SUPPORT)
/* Tell the UDPTL subdriver that we're here */
ast_udptl_proto_unregister(&sip_udptl);
#endif
By: Shawn Lawrence (radar) 2006-02-06 00:39:11.000-0600

I've done some testing on the latest version of the patch.  Our big concern is getting passthrough working at this point.  We are able to use a Sipura 2100 with the Fax Reinvite going to a Quintum gateway without any problems provided the unit is not behind a firewall.  To try and get the Sipura working behind a firewall, we set canreinvite=no.  When we did that, asterisk crashed.  I have put together a series of logs (backtrace, asterisk full log, and SIP debug) to see if this will shed some light on the problem.

I do have the programming skills to try and correct it, but am just starting to get into the code structure of asterisk and not sure what I should suggest to fix it at this point.

The trace files are attached and are prefixed with "radar".
By: Bradley Schatz (bradleeroy) 2006-02-08 00:26:37.000-0600

How can I configure this to send a fax received from a Sipura 2100 to the openh323 T38modem?
By: Rosario Pingaro (rpingar) 2006-02-08 21:37:27.000-0600

my asterisk box has one e1 connection.
Should I use this patch to allow my sip customers to send fax by t.38 to my box and then it through e1 in the standard way?
thanks
By: jkoko1 (jkoko1) 2006-02-15 23:28:25.000-0600

Some working patch again asterisk 1.2.4 ?
By: Adolfo R. Brandes (arbrandes) 2006-02-16 11:43:47.000-0600

I have a working patch for 1.2.4, based on the latest svn trunk, with very minor modifications to make it backward compatible.  I'll post it in a minute.
By: Adolfo R. Brandes (arbrandes) 2006-02-16 12:31:36.000-0600

Here it is: asterisk-1.2.4-t38-20060216.tar.bz2.  I'm not sure if it's against the rules to upload a tar, but I thought it would be more practical than sending the 4 files separately.  Furthermore, if you untar it inside your asterisk-1.2.4 source dir, the files already go in their right subdirectories.

In any case, putting the files in their right places, patch your out-of-the-box asterisk-1.2.4 release with:

$patch -p0 <asterisk-1.2.4-t38-20060216.diff

It should patch and compile cleanly, even on old gcc's.

To answer a common question in these notes: this patch does NOT provide anything other than passthrough functionality.  It works, and it works well; I tested thoroughly using the Kapanga softphone, with and without canreinvite, and had excellent results (no crashes or deadlocks).  However, don't expect it to translate to and from T.30.  You need both endpoints of the call to support T.38 for this to work.

On a more general T.38 note: it seems clear that the receiving end is the one responsible for issuing an SDP reINVITE containing the "image" and "udptl" media descriptions, once the fax tone is detected.  In other words, if the remote end doesn't do it, don't expect to see T.38 happening.  I'm not sure about this (so please somebody confirm it), but I don't think this patch includes working fax-detect functionality.

For an interesting technical article that analyzes the IP traffic between two T.38 endpoints using Ethereal (including an attached capture file so you can examine the data yourself), go here:

http://www.brooktrout.com/support/productinfo.cfm?frmProduct=TR1034&frmCategory=Knowledgebase&frmKnowBaseID=1983&Level=2

It has been very useful to me.
By: Rosario Pingaro (rpingar) 2006-02-16 14:08:32.000-0600

question for Setveu:
now that t.38 passthrough seems to works fine what is to be done to implement a t.30 t.38 conversion in the way tha how has a t1 or e1 could offer a t.38 service to its customers?

regards
By: rchen (rchen) 2006-02-21 00:37:26.000-0600

Dear Apt,

Are you able to fax to cisco using the new patch?  we tried the new patch and fax to cisco as5300, with same configuration as yours. still can't make the connection.   if you do, can you share your configuration?

Ray
By: steveu (steveu) 2006-02-21 07:40:13.000-0600

The latest spandsp code I have here seems to be doing some useful T.38 work, though it still has some quirks. Something that does T.38 termination properly should be available soon. This uses a patched *, with an entry in the frames for the packet sequence number. error control doesn't work properly without that. i still need to get T.38 gateway operation integrated. The stuff in spandsp seems to work, but its not yet integrated with any of the channels.
By: Denis Smirnov (mithraen) 2006-02-26 02:58:22.000-0600

I can't find t38-bits.tgz at http://www.soft-switch.org/downloads/spandsp/

How I can test app_rxfax/app_txfax with T.38?
By: DarekJ (darek) 2006-03-03 05:17:45.000-0600

There is still problem with sending mulitipage fax. Are you going to repair this? I talk about spandsp ver. up to spandsp-0.0.2pre25.
By: Ted Cabeen (secabeen) 2006-03-03 18:51:23.000-0600

I've been testing the asterisk-1.2.4-t38-20060216.tar.bz2 patch this week, and it seems to work pretty well.  However, I've been unable to get it working with an endpoint behind a NAT box using nat=yes and canreinvite=no.  Is there any support in the patch for this configuration?  If not, what would we need to do to get that working?
By: Olle Johansson (oej) 2006-03-04 08:52:05.000-0600

Opened a branch to maintain this patch for trunk

http://svn.digium.com/svn/team/oej/t38passthrough

kpfleming: Maybe you can move this to a group branch, so mattf can also check in to it.

Based the branch on mattf's latest patch. If changes are needed, please add patches for this branch in the future.
By: Olle Johansson (oej) 2006-03-04 08:57:24.000-0600

Correct URL:

http://svn.digium.com/svn/asterisk/team/oej/t38passthrough
By: Olle Johansson (oej) 2006-03-04 09:06:28.000-0600

nenadr: Since you added code to this patch, we need to get a confirmation that you have a disclaimer on file with Digium. Thanks.

The branch will automatically be kept up to date with SVN trunk chan_sip changes.
By: Olle Johansson (oej) 2006-03-04 09:19:26.000-0600

nenadr: Sorry, saw that you already confirmed it. This huge bug report is hard to get a grip on... :-)

Added a README and sip.conf settings to the branch. If anyone can contribute some documentation text I can add to these files, I would really appreciate it.

"Dressing up for making this possible to commit" - help me!
By: nenadr (nenadr) 2006-03-04 10:48:22.000-0600

oej: Yes, I have disclaimer on file. Looking forward to see T.38 in *.

Just a note: can anyone investigate putting SIP call on a hold (and getting it from a hold :) ) when t38 is enabled.... I think I have noticed, on one of mine installations, that there were some problems with that,  but unfotunatly I was not in a possition (and I'm still not :( ) to investigate it further.
By: Denis Smirnov (mithraen) 2006-03-04 12:00:28.000-0600

With this patch when I put caller on hold I can't get it back
By: Olle Johansson (oej) 2006-03-04 16:53:15.000-0600

Did some cleaning up on chan_sip in the branch. Please test.

We need to create peer/user settings so that enabling T38 does not disable RTP bridge for *all* devices.

(BTW, if you add a comment to this bug report PHP will time out. The comment will be stored in the bug tracker any way, so please do not resubmit. Digium staff is trying to fix this error in mantis.)
By: Paul Cadach (pcadach) 2006-03-04 22:27:06.000-0600

branch compilation problem:
chan_sip.c:1099: warning: `always_inline' attribute directive ignored
chan_sip.c: In function `process_sdp':
chan_sip.c:3993: parse error before `int'
chan_sip.c:4003: `found' undeclared (first use in this function)
chan_sip.c:4003: (Each undeclared identifier is reported only once
chan_sip.c:4003: for each function it appears in.)
By: Olle Johansson (oej) 2006-03-05 02:12:57.000-0600

PCadach: Good catch, I though I found all of those. Those are only errors on old versions of GCC I believe, so it compiled fine on my system. Fixed in the branch.
By: Paul Cadach (pcadach) 2006-03-06 11:01:26.000-0600

sip-t38.diff is compilation/run fixes for oej's http://svn.digium.com/svn/asterisk/team/oej/t38passthrough
By: Paul Cadach (pcadach) 2006-03-06 11:05:29.000-0600

Something is broken in trunk - T.38 call from Kapanga SIP phone to Cisco-2821 is dropped with messages:
Mar  6 22:55:47 VERBOSE[13322] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A
(0) ] [SIP/pcadach-97de]
Mar  6 22:55:47 VERBOSE[13322] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A
(0) ] [SIP/cisco-1bc2]
Mar  6 22:55:47 VERBOSE[13322] logger.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A
(0) ] [SIP/pcadach-97de]
Mar  6 22:55:47 VERBOSE[13322] logger.c: Got UDPTL packet from 10.174.1.7:19294
(type 0, seq 0, len 6)
Mar  6 22:55:47 VERBOSE[13322] logger.c: << [ TYPE: Unknown Frametype '11' (11)
SUBCLASS: Unknown Subclass (1) ] [SIP/cisco-1bc2]
Mar  6 22:55:47 VERBOSE[13322] logger.c: >> [ TYPE: Unknown Frametype '11' (11)
SUBCLASS: Unknown Subclass (1) ] [SIP/pcadach-97de]
Mar  6 22:55:47 DEBUG[13322] channel.c: Didn't get a frame from channel: SIP/pca
dach-97de
Mar  6 22:55:47 DEBUG[13322] channel.c: Bridge stops bridging channels SIP/pcada
ch-97de and SIP/cisco-1bc2
By: Olle Johansson (oej) 2006-03-06 11:57:33.000-0600

PCadach: Confirm your disclaimer with Digium, please
By: Paul Cadach (pcadach) 2006-03-06 12:04:32.000-0600

My disclaimer is on file, of course.
By: adria vidal (adriavidal) 2006-03-07 10:35:15.000-0600

Asterisk SVN-oej-t38passthrough-r12282

Calls done between 2 Grandstream 386 (last Beta firmware), canreinvite=yes on both.
I get

on-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Mar  7 17:17:23 WARNING[689]: chan_sip.c:10315 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
By: adria vidal (adriavidal) 2006-03-08 11:06:44.000-0600

continue my report:
(both grandstream have t38 active)

- Native bridging SIP/1998-eab9 and SIP/1997-2e9a
Mar  8 17:15:22 WARNING[23968]: chan_sip.c:10315 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
Mar  8 17:15:22 WARNING[23968]: chan_sip.c:10315 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
Mar  8 17:15:24 WARNING[23968]: chan_sip.c:3904 process_sdp: Unknown SDP media type in offer: image 21188 udptl t38
Mar  8 17:15:24 WARNING[23968]: chan_sip.c:10315 handle_response_invite: Strange... The other side of the bridge don't have udptl struct
Mar  8 17:15:24 WARNING[23968]: chan_sip.c:3904 process_sdp: Unknown SDP media type in offer: image 21188 udptl t38
Mar  8 17:15:25 WARNING[23968]: chan_sip.c:3904 process_sdp: Unknown SDP media type in offer: image 21188 udptl t38
Mar  8 17:15:26 WARNING[23968]: chan_sip.c:3904 process_sdp: Unknown SDP media type in offer: image 21188 udptl t38
Mar  8 17:15:26 WARNING[23968]: chan_sip.c:3904 process_sdp: Unknown SDP media type in offer: image 21188 udptl t38
By: hristo (hristo) 2006-03-09 13:19:40.000-0600

I can see at least one report so far confirming that T.38 doesn't work for nat=yes and canreinvite=no.

I have the same problem. I am using the asterisk-1.2.4-t38-20060216.tar.bz2 patch against 1.2.4. Only one of the edinpoints is behind NAT.

I did some sniffing and discovered that the problem appears after the asterisk server gets reINVITE for the T.38 session. Before the reINVITE asterisk will relay all RTP packets to the public IP of the NATed endpoint. After the T.38 reINVITE it will indeed switch to T.38 but all T.38 packets for the NATed endpoint suddenly start being sent to the private IP instead of the public one, never really reching that endpoint and resulting in failed fax transmission.

RTP and T.38 packets for the other endpoint (without NAT) are properly relayed at all times.

I cannot test with the trunk version at present, but maybe somebody else can confirm if this is also an issue with trunk?
By: Olle Johansson (oej) 2006-03-10 15:29:43.000-0600

Added support for checking T38 in the dialplan function for channel info. My thought was to
be able to take invites to a lot of extensions, but redirect it in the dialplan to a T38 capable extension if we have T38 offers.

I have not checked this. Please check!

(t38passthrough branch)
By: Olle Johansson (oej) 2006-03-11 05:50:46.000-0600

I have updated the branch with support for peer and user settings (I hope). Check sip.conf.sample for configuration settings. I have not tested this, so please, please, please check this. The effect of this is that you can enable t38 support for the devices that need it and still have native RTP bridging for the other devices.

I've also added a check for T38 in the sipchaninfo dialplan function. (See previous note).

When the svn servers are back in synch, (they are currently three days behind) I do need your assistance testing this new code. Thank you!
By: Paul Cadach (pcadach) 2006-03-11 08:19:01.000-0600

sip-t38-2.diff fixes T.38 RTP header. Disclaimer is on file, of course.
By: steveu (steveu) 2006-03-11 09:38:58.000-0600

Unless someone implements the FEC RFC for the RTP stack in *, T.38 over RTP is pretty useless. Therefore, I wouldn't try turning on T.38 over RTP support.
By: Olle Johansson (oej) 2006-03-11 09:43:48.000-0600

steveu: Is that part of the RTP rfc's or where can we find more information about it?
By: Olle Johansson (oej) 2006-03-11 09:48:49.000-0600

pcadach: Added your patch. Thanks!
By: Olle Johansson (oej) 2006-03-11 10:00:27.000-0600

Found it: RTP FEC RFC
ftp://ftp.isi.edu/in-notes/rfc2733.txt
By: Olle Johansson (oej) 2006-03-11 10:09:27.000-0600

...found that there are several suggestions on enhancing or replacing this RFC. What's implemented out there?
By: Paul Cadach (pcadach) 2006-03-11 12:21:35.000-0600

Looks like I've prepared testbed for T.38 over chan_h323... But it's can't bridged with SIP channels :(
By: Paul Cadach (pcadach) 2006-03-11 13:05:28.000-0600

sip-t38-3.diff - added missing support of AST_FRAME_MODEM to ast_write(). Disclaimer is on file.
By: Paul Cadach (pcadach) 2006-03-11 13:59:59.000-0600

ast-t38-4.diff - support for dumping modem frames via ast_frame_dump() (CLI command - debug channel <xxx>).
By: Paul Cadach (pcadach) 2006-03-11 14:39:03.000-0600

oej: Some discussion about sending T.38 over RTP could be find here:
http://www1.ietf.org/mail-archive/web/avt/current/msg05716.html

As pointed on http://www.potaroo.net/ietf/idref/draft-jones-avt-audio-t38/, T.38 over RTP is defined in ITU's T.38 document.

steveu: Do you mean implementation of FEC in Asterisk's UDPTL? As I understand T.38 over RTP is just re-using RTP stack to transmit T.38 UDPTL packets instead of audio frames, so FEC should be implemented within UDPTL, not for RTP as common.
By: steveu (steveu) 2006-03-11 22:23:17.000-0600

This thing is becoming the blind leading the blind.

The latest T.38 spec defines T.38 over RTP. This makes use of the FEC in RTP itself. *'s RTP code does not support the RTP FEC spec, and without that is practically useless for T.38. T.38 really really needs FEC to be useful. That said, there are few boxes, apart from Cisco's, which support T.38 over RTP at this time. It isn't, perhaps, the highest priority right now.

I you had looked at the UDPTL code I wrote, you might have seen that most of it is implementing the two FEC modes defined for UDPTL. Apart from the FEC stuff, the udptl.c is basically a strip down and rework of rtp.c
By: steveu (steveu) 2006-03-11 22:40:43.000-0600

To get T.38 gateway and termination working smoothly it will be necessary to add an extra entry to the ast_frame structure. It need a uint16_t, or perhaps an int which contains the sequence number of the packet. I think this should have been there from the beginning, as it is quite useful for other things, like jitter management. For T.38 to work well the sequence number is essential.

Another thing needed to really make T.38 work nicely is the ability to send RTP or UDPTL packets with the same sequence number, under application control. Most T.38 implementations send multiple copies of packets containing the most critical information. This supplements FEC, and adds only a little to the total traffic. However, it is important the application have proper control over this. Either the application needs to be able to specify the sequence number of outgoing packets, or it needs to be able to say "send another exact copy of the last packet".
By: Paul Cadach (pcadach) 2006-03-12 09:00:56.000-0600

Currently I want to decide a mechanism to make T.38 pass-through working over different technologies (not SIP<->SIP only but SIP<->H.323 and SIP<->app_?xfax too) and I needs to know people's opinion about a way to do that elegant.
By: steveu (steveu) 2006-03-12 09:38:37.000-0600

If you add the sequence number to the ast_frame structure, app_rxfax to T.38 is basically working today. A couple of people have been exchanging a few FAXes using recent snapshots of spandsp with my latest app_rxfax. What is more interesting for most people is PSTN gateway operation. spandsp now has the engine to do that, which works in isolation. I haven't integrated it into * yet.

As far as SIP<->H.323 interworking is concerned, this is basically the same issue as SIP<->H.323 interworking for voice. Add the negotiation stuff to H.323 and it should roll. I have no real interest in H.323, so I did nothing about this. Interworking with IAX is also interesting. That requires more development, though.  IAX has no FEC option right now, so carrying T.38 packets over IAX would require FEC be added. (IAX has a reliable transmission mode, but the latency in that makes it useless as a substitute for UDPTL.

The final piece in the T.38 jigsaw is reliable transmission over TCP, suitable for internet aware FAX machines. I partially implemented this, but few things apart from Cisco boxes support it. Most FAX machines with an RJ45 on them don't seem to use it. :-\
By: Paul Cadach (pcadach) 2006-03-12 09:51:02.000-0600

sip-t38-transport.diff addressed to NAT/RTP re-use issues.

steveu: Currently chan_sip doesn't exchange messages about T.38 re-negotiation so it's not be able to tell to chan_h323 (and back) about requirements to switch to T.38. My opinion is to add special control frame (mode change) which will carry T.38 capabilities between channels and allow REQ/ACK/NAK/REJ behaviour within single control frame. Also, carrying of peer's IP addresses negotiated for T.38 (but it's not allowed for H.323) is good too for some sort of end-to-end bridging immediately on negotiation.
By: Denis Smirnov (mithraen) 2006-03-12 09:52:37.000-0600

steveu, I can't find at your site app_rxfax for spandsp 0.0.3, only for 0.0.2.
By: Denis Smirnov (mithraen) 2006-03-12 09:58:47.000-0600

steveu, I can't find at your site app_rxfax for spandsp 0.0.3, only for 0.0.2.
By: Olle Johansson (oej) 2006-03-12 10:09:36.000-0600

pcadach: Integrated your patches into the branch. Thanks!
By: Olle Johansson (oej) 2006-03-12 10:10:17.000-0600

pcadach: Integrated your patches into the branch. Thanks!
By: Paul Cadach (pcadach) 2006-03-12 13:48:35.000-0600

udptl-resend.diff provides ability to re-send last transmitted frame every 100 ms. Also, it forbids to duplicate frames coming with the same sequence number (re-send part compensates it).
By: steveu (steveu) 2006-03-12 16:07:51.000-0600

Now you are just adding things at random. What use is the ability to repeat a packet every 100ms? That kind of timing is worthless. The application needs to control the spacing directly. The code I wrote already deals with duplicates being returned to the application.
By: Paul Cadach (pcadach) 2006-03-12 20:43:13.000-0600

Steve, Asterisk is an application too, so it could decide about packet re-sending itself. Due to "guaranteed packet delivery" nature within Asterisk an application should not:
1) re-send any packets/messages;
2) maintain sequence numbers.
This is deal for transport level (udptl in our case). So, I'm doing right but probably setting packet re-sending interval should be controlled by configuration/application - it's not so complex to provide additional API function to setup re-sending interval.

Also, analyze RTP processing mechanism - it's maintains all timestamps/sequensing mostly at transport level rather than at application/core level.
By: adria vidal (adriavidal) 2006-03-13 11:38:22.000-0600

Till getting problems (2 Grandstream 386 t.38 enabled)
Mar 13 18:31:58 WARNING[15916]: chan_sip.c:10288 handle_response_invite: Strange... The other side of the bridge don't have udptl struct

[general]

t38pt_udptl = yes ; Default false
t38pt_rtp = no ; Default false
t38pt_tcp = no ; Default false, not yet used

& for devices

[1997]
username=1997
type=friend
secret=notocar
nat=yes
mailbox=1997
host=dynamic
dtmfmode=rfc2833

context=from-fax
canreinvite=yes

callerid="1998" <1997>

qualify=5000

allow=all

t38pt_udptl =yes ; Default false
t38pt_rtp = no ; Default false
t38pt_tcp = no ; Default false, not yet used
By: adria vidal (adriavidal) 2006-03-14 03:55:51.000-0600

Someone could post/help me with config files, all the time getting :

chan_sip.c:10288 handle_response_invite: Strange... The other side of the bridge don't have udptl struct

I'm very interested in deploying FAX with *, but have had any luck with these branch by now.

Adrià Vidal
By: luisbe (luisbe) 2006-03-15 08:16:20.000-0600

Following Oejs recommendations, we have been testing this branch as it is and having * out of the rtp stream commenting these lines out in sip_bidge:
if (ast_test_flag(&p0->t38.t38support, SIP_PAGE2_T38SUPPORT_UDPTL) && ast_test_flag(&p1->t38.t38support, SIP_PAGE2_T38SUPPORT_UDPTL)) {
               ast_log(LOG_NOTICE, "T38 UDPTL support enabled, native RTP bridging disabled\n");
               return AST_BRIDGE_FAILED_NOWARN;
       }

Other than receiving these two warnings, everything has worked fine.
WARNING[13438]: chan_sip.c:10288 handle_response_invite: Strange... The other side of the bridge don't have udptl st
ructSend
WARNING[13438]: chan_sip.c:3882 process_sdp: Unknown SDP media type in offer: image 18642 udptl t38ing to 192.168.7.83 : 5060 (non-NAT)

Let me know if anyone is interested in any specific test/information
By: luisbe (luisbe) 2006-03-15 08:35:43.000-0600

Following Oejs recommendations, we have been testing this branch as it is and having * out of the rtp stream commenting these lines out in sip_bidge:
if (ast_test_flag(&p0->t38.t38support, SIP_PAGE2_T38SUPPORT_UDPTL) && ast_test_flag(&p1->t38.t38support, SIP_PAGE2_T38SUPPORT_UDPTL)) {
               ast_log(LOG_NOTICE, "T38 UDPTL support enabled, native RTP bridging disabled\n");
               return AST_BRIDGE_FAILED_NOWARN;
       }

Other than receiving these two warnings, everything has worked fine.
WARNING[13438]: chan_sip.c:10288 handle_response_invite: Strange... The other side of the bridge don't have udptl st
ructSend
WARNING[13438]: chan_sip.c:3882 process_sdp: Unknown SDP media type in offer: image 18642 udptl t38ing to 192.168.7.83 : 5060 (non-NAT)

Let me know if anyone is interested in any specific test/information
By: Olle Johansson (oej) 2006-03-19 10:55:15.000-0600

Removed the debugging sip_bridge from the branch. Can be re-enabled by defining T38_DEBUG in chan_sip.c
By: George Pajari (netvoice) 2006-03-21 02:36:23.000-0600

Firstly let me thank Olle for creating the T38 passthrough branch so that this work can move ahead with parallel development of chan_sip and Asterisk as a whole. This move obviously took a fair bit of work but it absolutely critical to enabling this bit to be tested and eventually incorporated into a production release. Thanks!

With that said, we still have some work to be done:

(1) Preliminary testing shows that at some point the SIP_PAGE2_T38SUPPORT_UDPTL bit in t38.t38support is getting cleared causing the preliminary steps to permit the transition to T.38 to fail. This problem is not observed in the  asterisk-1.2.4-t38-20060216.tar.bz2 version. I have not yet tracked down this problem but point it out to others who might be testing the T38 branch.

(2) Both versions (the T38 branch with the SIP_PAGE2_T38SUPPORT_UDPTL bit forced on at all times and the asterisk-1.2.4-t38-20060216) fail to switch to T.38 mode when trying to link an SPA-2100 to a Patton SmartNode 2400. I'm still working on this problem but the symptom is that the REINVITE from the SPA-2100 is ignored by Asterisk.

Here is a short version of what happens:
   -- SIP/604nnnnnnn-e74b answered SIP/sn2400a-bb84
   -- Attempting native bridge of SIP/sn2400a-bb84 and SIP/604nnnnnnn-e74b
Mar 19 05:02:51 NOTICE[13749]: chan_sip.c:2849 sip_bridge: T38 UDPTL support enabled native RTP bridging disabled

<-- SIP read from 66.nnn.nnn.nnn:5061:
INVITE sip:sn2400a@nnn.nnn.nnn.nnn SIP/2.0
Via: SIP/2.0/UDP 66.nnn.nnn.nnn:5061;branch=z9hG4bK-95f4f452
From: <sip:604nnnnnnn@66.nnn.nnn.nnn:5061>;tag=bec81d18f467dc7i1
To: "sn2400a" <sip:sn2400a@nnn.nnn.nnn.nnn>;tag=as6f62e961
Call-ID: 2f8bb5ed40fc1c381e0ea5215bee19bb@nnn.nnn.nnn.xxx
CSeq: 101 INVITE
Max-Forwards: 70
Contact: <sip:604nnnnnnn@66.nnn.nnn.nnn:5061>
Expires: 30
User-Agent: Sipura/SPA2100-3.2.2
Content-Length: 349
Content-Type: application/sdp

v=0
o=- 1363296 1363296 IN IP4 66.nnn.nnn.nnn
s=-
c=IN IP4 66.nnn.nnn.nnn
t=0 0
m=image 16408 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:72
a=T38FaxUdpEC:t38UDPRedundancy

--- (12 headers 15 lines)---

Using INVITE request as basis request - 2f8bb5ed40fc1c381e0ea5215bee19bb@nnn.nnn.nnn.xxx

Sending to 66.nnn.nnn.nnn : 5061 (non-NAT)
Got T.38 offer in SDP
Peer audio RTP is at port 66.nnn.nnn.nnn:65535
Peer T.38 UDPTL is at port 66.nnn.nnn.nnn:16408
Capabilities: us - 0x8000e (gsm|ulaw|alaw|h263), peer - audio=0x4 (ulaw)/video=0x0 (nothing), combined - 0x4 (ulaw)
Non-codec capabilities: us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)

But nothing is sent back to the SPA-2100!

The SPA-2100 resends the INVITE many times but Asterisk will have nothing to do with it: "Ignoring this INVITE request"

And that's where things stop dead.

I'm going to concentrate on fixing this problem first (using the 1.2.4 code) then move back to figuring out why the T.38 UDPTL bit is getting cleared in Olle's merged code.

Anyone working on this is welcome to correspond with me directly.


On a related note I'm a bit skeptical about the report by luisbe (see 0042733 above) that the merged version is actually running in T.38 mode. The two errors he reports ("The other side of the bridge don't have udptl struct" and "Unknown SDP media type in offer: image 18642 udptl t38") suggest strongly that the attempt to negotiate T.38 failed and the fax was sent in G.711 mode. We have seen these errors and upon investigation it was determined that the devices did not switch to T.38 but sent the fax in G.711.
By: element (element) 2006-03-29 07:03:19.000-0600

I havent had luck compiling the latest revision 16081. Here is the error when i issue a make:

gcc  -D_FILE_OFFSET_BITS=64 -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6  -march=i686         -fomit-frame-pointer  -DWITH_SMDI -Wno-missing-prototypes -Wno-missing-declarations -DCRYPTO -fPIC    -c -o chan_sip.o chan_sip.c
chan_sip.c: In function `sip_alloc':
chan_sip.c:3483: error: `global_tos' undeclared (first use in this function)
chan_sip.c:3483: error: (Each undeclared identifier is reported only once
chan_sip.c:3483: error: for each function it appears in.)
make[1]: *** [chan_sip.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-t38-03292006/channels'
make: *** [subdirs] Error 1

I am using whitebox enterprise linux and i pulled the distro from svn.

Note: an earlier version- Asterisk SVN-oej-t38passthrough-r12677 compiled and ran fine for me.

Maybe this release is in development and i should try later or grab another version?
By: Rosario Pingaro (rpingar) 2006-03-30 08:05:59.000-0600

Hi Steveu,

any new news about t.38 gateway possibilities?

Hope the father of spandsp and t.38 passthrough should help us closing the gap between * and other carrier grade gateway.

Thanks in advance
Rosario
By: element (element) 2006-04-03 17:10:55

I tried compiling the latest t38 revision 17103. The make error is:

gcc  -D_FILE_OFFSET_BITS=64 -pipe  -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3  -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE  -O6  -march=i686         -fomit-frame-pointer  -DWITH_SMDI -Wno-missing-prototypes -Wno-missing-declarations -DCRYPTO -fPIC    -c -o chan_sip.o chan_sip.c
chan_sip.c: In function `sip_alloc':
chan_sip.c:3483: error: `global_tos' undeclared (first use in this function)
chan_sip.c:3483: error: (Each undeclared identifier is reported only once
chan_sip.c:3483: error: for each function it appears in.)
make[1]: *** [chan_sip.o] Error 1

I am Using whitebox linux (redhat enterprise 4 clone):
Linux server4 2.6.9-5.0.5.ELsmp #1 SMP Thu May 19 19:24:44 CDT 2005 i686 i686 i386 GNU/Linux

Anyone have suggestions? Also Digium support considers this a feature and hesitated when i asked them to assist. I am willing to pay for help to get t38 working through asterisk between a cisco 5400 gw and a nextone endpoint- any takers? (my email: critestcb at gmail.com)
By: Rosario Pingaro (rpingar) 2006-04-06 04:34:55

t.38 gateway to test?
please!
By: dario (dario) 2006-04-11 04:50:01

Hi
I looking for working version t38passthrough. I'm going to test it with HT-286 and cisco router. Could you tell me which version (revision svn) I should use?

Regards
By: Serge Vecher (serge-v) 2006-04-11 08:57:40

dario: please read prior posts carefully -- your answer is already there. The branch that contains the latest t.38 code is http://svn.digium.com/svn/asterisk/team/oej/t38passthrough/. It is also included in OEJ's test-branch (that has all the latest Asterisk innovations) at http://svn.digium.com/svn/asterisk/team/oej/test-this-branch/

Thank you for testing and please report back your findings!
By: dario (dario) 2006-04-11 09:23:18

I've read. But... http://svn.digium.com/svn/asterisk/team/oej/t38passthrough/. dosn't compile, and  http://svn.digium.com/svn/asterisk/team/oej/test-this-branch/  dosnt run :(
By: element (element) 2006-04-13 01:48:13

Dario, the last version i was able to get to compile was 12677, grab it here:

svn checkout http://svn.digium.com/svn/asterisk/team/oej/t38passthrough -r 12677

it seems there are some key changes in the /include/asterisk/module.h file of the recent versions but im not a programmer and am having trouble finding out what the issue is..

It is unfortunate this feature has lost traction since it is one of the features seperating "the men from the boys" at least in the wholesale voip us market.
By: Olle Johansson (oej) 2006-04-13 06:43:56

Friends, I've been spending quite a lot of time keeping the t38 branch up to date.

If there are errors, and you can't compile and run it on your system, then you have to report it as a bug here or on the asterisk-dev mailing list - not just go and implement another patch or fixing something without contributing back. The branch is the path to integration into trunk. If you guys does not test and report back when there's problems, this will never make it into trunk.
By: Gregor Moeller (bommel) 2006-04-13 13:08:16

The latest oej version compiles, if line 3412 in channels/chan_sip.c

ast_udptl_settos(p->udptl, global_tos);

is changed to

                 ast_udptl_settos(p->udptl, global_tos_sip);

I don't know, if global_tos should be initialized too,
so it could have been used also.

I've got the same problems as netvoice with patched asterisk-1.2.4 ignoring the reinvite but detecting T.38 and with the t38passthrough branch by oej not recognizing the t.38 media in SDP body. Some debugging output thrown in shows that already p->udptl itself isn't TRUE anymore when if-block starting at line 3813 is evaluated:

if (p->udptl && (ast_test_flag(&p->t38.t38support, SIP_PAGE2_T38SUPPORT_UDPTL)) && (sscanf(m, "image %d udptl t38 %n", &x, &len) == 1)) {
if (debug)
ast_verbose("Got T.38 offer in SDP\n");
found = 1;
udptlportno = x;


So later, at line 3848 "found" stays FALSE and we get the warning:

if (!found )
ast_log(LOG_WARNING, "Unknown SDP media type in offer: %s\n", m);

I couldn't track it down further yet.
By: Paul Cadach (pcadach) 2006-04-13 13:43:46

sip-t38-5.diff - just 20 minute patch to make oej's branch to build.
By: simishag (simishag) 2006-04-13 16:05:31

uploaded t38-19892.diff. fixes:

1) add sdpLineNum_iterator_init() (will compile but not link without this patch)
2) replace global_tos with global_tos_sip

patch 1 seems fairly obvious, it is copied verbatim from chan_mgcp.c.  patch 2 i'm not as sure about but it at least builds ok.

oej: we all appreciate the work you've done, but the bug fixed in patch #2 was reported 10 days ago. the bug was very obvious: an incorrectly named variable that would immediately break the compile. patch #1 became obvious to me as soon as i tried to build this. how long does it take to get these fairly minor fixes into svn?
By: simishag (simishag) 2006-04-13 16:11:13

t38passthrough/include/asterisk/module.h is different from the mainline module.h.  ASTERISK_GPL_KEY is defined differently: t38's version indicates "(c) Digium" and the mainline is "(c) Linux Support Services". this causes headaches with module loading since verify_key() fails if the modules aren't built against the right header.

running a diff between the 2 files shows a lot of other changes as well. can anyone shed any light on this? what mainline version is t38passthrough based on?
By: Diego Valencia (diencia) 2006-04-14 07:34:30

Hi, I see the ASTERISK_GPL_KEY problem when I try to use codec_g729a.so for G729 licenses.

[codec_g729a.so]Apr 14 09:35:31 WARNING[17756]: loader.c:768 __load_resource: Unexpected key returned by module /usr/lib/asterisk/modules/codec_g729a.so
Apr 14 09:35:31 WARNING[17756]: loader.c:773 __load_resource: 1 error loading module /usr/lib/asterisk/modules/codec_g729a.so, aborted
Apr 14 09:35:31 WARNING[17756]: loader.c:866 print_and_load: Loading module codec_g729a.so failed!

Is there any way to solve this problem?

Thanks
By: Serge Vecher (serge-v) 2006-04-14 13:23:46

dilencia: as noted in http://bugs.digium.com/view.php?id=6931 and asterisk mailing lists, the g.729 codec distributed by Digium is incompatible at the moment with the latest trunk (and all branches automerged to it) due to ongoing loader module changes. If you are testing t.38 capability, please disable the g.729 codec and watch the asterisk-lists or digium website on the status of loader changes. Thank you.
By: dario (dario) 2006-04-20 16:55:08

Hi,

I downloaded svn revision 12667 t38passthrough. Configure it:
sip.conf:
[general]
context=default                 ; Default context for incoming calls
bindport=5060                   ; UDP Port to bind to (SIP standard port is 5060)
bindaddr=0.0.0.0                ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=yes                   ; Enable DNS SRV lookups on outbound calls
t38pt_udptl = yes
;--------------------------- T.38 FAX PASSTHROUGH SUPPORT ------------------------------------
;
; These settings are available in the [general] section as well as in device configurations
;
t38pt_udptl = yes               ; Default false
;t38pt_rtp = no         ; Default false
;t38pt_tcp = no         ; Default false, not yet used
;t38udptlsupport=yes
;
canreinvite=yes         ;
[50]
type=friend
allow=all
username=50
password=xxx
dtmfmode=rfc2833
host=dynamic
context=remote
nat=yes
t38pt_udptl=Yes               ; Default false

[51]
type=friend
allow=all
username=51
password=zzz
dtmfmode=rfc2833
host=dynamic
context=remote
t38pt_udptl=yes

But when I send fax from 50 to 51 (both ht-286, fax mode t.38) i received on console

Apr 20 22:57:57 WARNING[13118]: chan_sip.c:10284 handle_response_invite: Strange                               ... The other side of the bridge don't have udptl struct
Apr 20 22:57:57 WARNING[13118]: chan_sip.c:10284 handle_response_invite: Strange                               ... The other side of the bridge don't have udptl struct
Apr 20 22:57:57 WARNING[13118]: chan_sip.c:10284 handle_response_invite: Strange                               ... The other side of the bridge don't have udptl struct
Apr 20 22:57:57 WARNING[13118]: chan_sip.c:10284 handle_response_invite: Strange                               ... The other side of the bridge don't have udptl struct
Apr 20 22:57:59 WARNING[13118]: chan_sip.c:3858 process_sdp: Unknown SDP media t                               ype in offer: image 12000 udptl t38
Apr 20 22:58:00 WARNING[13118]: chan_sip.c:3858 process_sdp: Unknown SDP media t                               ype in offer: image 12000 udptl t38

What is wrong?

Regards
By: Clod Patry (junky) 2006-04-21 02:37:42

its pretty clear with this message: "The other side of the bridge don't have udptl struct", no?
By: dario (dario) 2006-04-21 04:18:08

Hello,

What is "other side of the bridge"? I have two ht-286 terminals with the same software - Program-- 1.0.7.19    Bootloader-- 1.0.8.9    HTML-- 1.0.7.18    VOC-- 1.0.0.10, and T.38 enabled.
By: Adolfo R. Brandes (arbrandes) 2006-04-23 14:40:53

I have again backported the whole T.38 shebang to the stable branch.  The port was based on two versions of the t38passthrough branch: r19125, the latest unconflicted automerge, and r13623, the latest version without the new chan_sip flag structure.  Basically, the port contains everything that matters, EXCEPT:

* chan_sip.c: r15282, new flag structure (not the point of this backport)
* chan_sip.c: r15329, handle_common_options for the T.38 stuff (due to lack of new flag structure)
* chan_sip.c: PCadach's sip-t38-5.diff or simishag's t38-19892 (it was a non-issue in stable).
* udptl.c: PCadach's udptl-resend.diff (the jury's still out on that one)

Alert 1: I haven't fixed any bugs, just ported the current state of the t38passthrough (actually, it's more likely I introduced a bug or two!).  This is just so more people can afford to test the code, and thus help this bug move along.

Alert 2: I also haven't tested this anywhere near enough.  It compiles and runs, but that's as far as I got.  Please test more.

Alert 3: For users of my previous 1.2.4 patch, mind that there is no longer a T38 CFLAG in the Makefile.  T38 support is compiled by default.  Nevertheless, you can configure it on a per peer/user basis.

Untarring will create asterisk-1.2.7.1-t38-20060423/.  Copy the files therein to your out-of-the-box asterisk-1.2.7.1; don't use a checkout with T38 patches previously applied, or you'll get conflicts.  And then:

$patch -p0 < asterisk-1.2.7.1-t38-20060423.diff
$make
$make install


By: simishag (simishag) 2006-04-24 17:01:18

Thanks for the updates! I was able to get this built and running. I pulled the release down from SVN (/tags/1.2.7.1/) and then applied the patch. I haven't tested t38 support yet but SIP voice calls go through okay.

Questions:

1) Is there a SVN branch that includes your patches? It's definitely easier to do a single pull rather than apply a patch later.

2) What is the status of the t38passthrough branch? It still doesn't build (chan_sip.c again). Is there active development on t38passthrough or should people who want t38 support stick to 1.2.7.1 and your patch?
By: simishag (simishag) 2006-04-24 17:05:07

Off the main topic:

Every time I submit a note here, the Web server takes forever to respond, and I eventually get this error:

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/mantis/branches/1.0/core/database_api.php on line 106

The submitted note appears to be recorded okay but the error is annoying. Any Digium admins around who can look into this?
By: friese (friese) 2006-04-25 06:19:53

i try the new asterisk-1.2.7.1-t38-20060423.tar.bz2 Patch, the problem is now this error messages:

chan_sip.c:3490 process_sdp: Unknown SDP media type in offer: image 16416 udptl t38

i think it means that the sender is capable of sending t38, but asterisk is not capable of handling this. Or is now something wrong in my sip.conf ??
I'm thankful for any hint
By: Nick Gazaloff (nickg) 2006-04-25 11:15:27

Version 1.2.7.1-t38-20060423 fails somewhere to detect a peer as t38-capable, and then disables t38 entirely returning "488 Not Acceptable Here". I could not make it work. I tried Wellgate FXS-02A on one end and Cisco AS5400 on the other, with Asterisk between.

And, besides that, does the patch require to enable reinvites? I have some t38-capable peers for which I want to stay on media path.
By: Adolfo R. Brandes (arbrandes) 2006-04-26 06:46:41

Believe it or not I have yet to test T38 with the patch I concocted.  I'll try to do that today.

There is one thing I noticed, though: if you set t38 support globally (in the [general] section of sip.conf as opposed to the peer's section), it seems that the peers are not inheriting it.  You can check by a "sip show settings" and then a "sip show peer XXXX".  Setting t38pt_udptl=yes in the peer's section seems to work, though.

This is probably because I missed some new ast_copy_flags() that were introduced in trunk and are taken for granted in the t38passthrough branch.  I'll look into it ASAP.

Again, let me reiterate that since I haven't tested the patch, I don't know if T38 is working at all with it.  It's great, though, that you guys have already started testing it.  I'll try to fix any patch-specific bugs as soon as I can.

Which brings me to simishag's questions and the state of the t38passthrough branch: simply put, we should ask Olle and Steve about what's up.  The branch hasn't been automerged in two weeks, and there haven't been any new patches committed since March 27, partly because there hasn't been any new T38 development since even earlier in the year.

Nevertheless, even though there is no 1.2-t38passthrough branch (and there probably won't be) we should all continue submitting new T38 functionality as diffs to trunk, so that they can be included by Olle in the T38 branch that DOES exist, and so that, ideally, T38 passthrough makes it into asterisk-1.4.

However, any fixes specific to the asterisk-1.2.7.1-t38 patch (NOT including any new T38 functionality) would certainly be welcomed by all.  The question is how to submit them; a diff of a diff spells certain trouble.  I suggest that diffs to a previously patched asterisk-1.2.7.1 be posted here, with names based on the latest full patch submitted and incremental suffixes.  For example, asterisk-1.2.7.1-t38-20060423-1.diff, asterisk-1.2.7.1-t38-20060423-2.diff, and so on, until one day somebody collects them and releases a new full patch (hopefully with new T38 stuff from the t38passthrough branch ;).


By: Adolfo R. Brandes (arbrandes) 2006-04-26 06:55:52

ALERT: for those of you testing the 1.2.7.1 patch, the syntax of t38 sip.conf settings changed!  Aside from being able to set the variables in the peer section, it is no longer "t38udptlsupport=yes", but "t38pt_udptl=yes".  The other two variables are similarly different.

Check the new configs/sip.conf.sample!
By: dario (dario) 2006-04-26 08:03:12

Does anybody knows how to configure HT-286<-->Asterisk<-->Cisco gateway<--> PSTN<--> FAX  to work with T.38. Now when I send fax from FAX to HT-286 T.38 is working, but I try to send fax from HT-286 to FAX,  asterisk (or Cisco) uses G.711 not T.38.

Regards


By: steveu (steveu) 2006-04-29 09:47:59

The current T.38 chan_sip code includes the following:

/* Maximum Fax Rate */
#define T38FAX_RATE_2400 (1 << 8) /*!< 2400 bps t38FaxRate */
#define T38FAX_RATE_4800 (1 << 9) /*!< 4800 bps t38FaxRate */
#define T38FAX_RATE_7200 (1 << 10) /*!< 7200 bps t38FaxRate */
#define T38FAX_RATE_9600 (1 << 11) /*!< 9600 bps t38FaxRate */
#define T38FAX_RATE_12000 (1 << 12) /*!< 12000 bps t38FaxRate */
#define T38FAX_RATE_14400 (1 << 13) /*!< 14400 bps t38FaxRate */

This seems to be based on a misunderstanding of the t38FaxRate parameter, and is too restrictive.

The field is a general indicator for bandwidth allocation, in hundreds of bits per second. It is not an actual image bit rate. Its kind of unclear exactly what it should be set to. For example, if you send extra FEC data, it seems unclear if you should increase t38FaxRate to allow for that. The range currently covered is inadequate. It doesn't allow for the faster V.34 fax rates many things now support.
By: steveu (steveu) 2006-04-29 09:54:28

The current T.38 chan_sip code includes the following:

/* Maximum Fax Rate */
#define T38FAX_RATE_2400 (1 << 8) /*!< 2400 bps t38FaxRate */
#define T38FAX_RATE_4800 (1 << 9) /*!< 4800 bps t38FaxRate */
#define T38FAX_RATE_7200 (1 << 10) /*!< 7200 bps t38FaxRate */
#define T38FAX_RATE_9600 (1 << 11) /*!< 9600 bps t38FaxRate */
#define T38FAX_RATE_12000 (1 << 12) /*!< 12000 bps t38FaxRate */
#define T38FAX_RATE_14400 (1 << 13) /*!< 14400 bps t38FaxRate */

This seems to be based on a misunderstanding of the t38FaxRate parameter, and is too restrictive.

The field is a general indicator for bandwidth allocation, in hundreds of bits per second. It is not an actual image bit rate. Its kind of unclear exactly what it should be set to. For example, if you send extra FEC data, it seems unclear if you should increase t38FaxRate to allow for that. The range currently covered is inadequate. It doesn't allow for the faster V.34 fax rates many things now support.
By: steveu (steveu) 2006-04-30 05:45:40

arbrandes on 04-23-06 14:40 wrote

* udptl.c: PCadach's udptl-resend.diff (the jury's still out on that one)

That patch is completely useless. It is doing the wrong thing. What robust UDPTL needs (and what a number of implementations do) is to repeat only a few high importance packets, and repeat them without any delay. The patch turns on repeating of everything, and spreads out the repeats in time. This has no value at all for UDPTL (since T.38 is the only thing using UDPTL). I guess a similar addition to RTP might be of value for some special applications, but I can't think what. I think anything the wants repeat transmissions to overcome packet loss will want the copies to be send concurrent with the original. If they are spread in time FEC schemes are a much better solution, and both UDPTL and RTP already have those defined.

What the current UDPTL code lacks is either a way to send the same packet number twice, or a way to tag a frame to say "send two copies of this one".
By: Dirk Willbrandt (dirkw) 2006-05-09 01:59:32

im not able to get t38 with the latest patches to work.
In the *-CLI i get the message "Unknown SDP media type in offer: image 18772 udptl t38".

I tried t38 with the kapanga Softphone and a Cisco PGW with t38 support on the other end.
My nGrep-Traces show the Message "Not Acceptable Here".
When i type sip show settings i see that t38 is active and for the User/Peers it is activ too.

Is there something more that i have to configure ?!
By: dario (dario) 2006-05-09 14:39:12

Hello,

Is it possible to limit speed to 9600 when asterisk works in t.38 mode? Always when I send a fax I see negotiation from 14400bps to 9600bps
v17-14400-long-training
..
v17-12000-long-training
..
v17-9600-long-training
It always takes about 15 seconds.
I'd like to eliminate this negotiation

Regadrs


By: steveu (steveu) 2006-05-10 07:28:28

dario - reporter:

A T.38 pass-through box should certainly not be playing games like that. Any limitations like that should be imposed at your gateways. If things are always falling back to 9600 it sounds like you have a really lousy gateway.
By: Olle Johansson (oej) 2006-05-10 08:26:54

I moved the branch to
http://svn.digium.com/svn/asterisk/team/group/t38passthrough

Please continue testing, thanks!
By: dario (dario) 2006-05-10 08:49:46

Hi Steveu,
My gateway is configured to send fax with 9600.
My cisco gateway requests T38MaxBitRate=9600, asterisk sends this request to ma SPA-9000 with T38MaxBitRate=9600, but SPA-9000 responses to asterisk with T38MaxBitRate=14400. I suppose that tihs is a problem, but I'm not able to change this.
When I change configuration on my cisco gateway to 14400, it requests T38MaxBitRate=14400, but asterisk sends request to SPA-9000 with T38MaxBitRate=9600.

Regards
By: steveu (steveu) 2006-05-10 09:04:27

dario - reporter:

Ignore T38MaxBitRate. It doesn't really mean anything. If you look in the T.38 spec, the definition of T38MaxBitRate is very vague. The speeds at which things work are determined by the FAX machines themselves. All the T.38 boxes in between can do is fool the FAX machines into using a lower rate, if they cannot work at the rate the FAX machines can. Most T.38 gateways can only do V.17 FAXing, so they need to fool two V.34 capable machines into not using V.34. This process has nothing to do with T38MaxBitRate.
By: dario (dario) 2006-05-10 09:20:51

Hi Oej

New version dosn't compile:

chan_sip.c: In function 'handle_request_invite':
chan_sip.c:11892: error: 'ignore' undeclared (first use in this function)
chan_sip.c:11892: error: (Each undeclared identifier is reported only once
chan_sip.c:11892: error: for each function it appears in.)

Regards
By: Andreas Junklewitz (aj) 2006-05-11 09:03:31

@dario: I think that the ignore parameter has been removed from handle_request_invite() so every "ignore" (lines 11892, 11919) in that functin has to be replaced by ast_test_flag(req, SIP_PKT_IGNORE)

Regards
By: dario (dario) 2006-05-11 12:08:23

Hello Oej,

I've changed chan_sip.c how advised AJ. Now I have a problem like Dirkw.
I get the message "Unknown SDP media type in offer: image 18772 udptl t38".

Regards
By: Serge Vecher (serge-v) 2006-05-11 13:27:59

steve: I would apreciate it, if could review all of the patches attached to this bug and specify which ones are obsolete (need to be deleted) and which ones, if any, still need to be applied to OEJ's branch.

thank you very much. steve; just attempting to perform a little clean up here.
By: steveu (steveu) 2006-05-11 21:47:56

The only patches which still look relevant are the ones to backport T.38 passthrough to Asterisk 1.2.4 and 1.2.7.1. Things like the UDPTL transport are in the trunk code already, and the chan_sip stuff in the trunk seems to have everything useful in it.

Clearly more patching is required before the T.38 support is properly functional, but I don't think anything useful is lurking in the patches. I am puzzled, though. This has been changed to a trunk issue, but nothing seems to have been done in the SVN trunk so far. Was the status change just a bit premature?

If I prepare patches to get core support for T.38 termination and T.38 gateway operation into 1.4, are they likely to make it in? The issues there are to change the frame structure to include the frame sequence number, to allowing missing frames to be clearly identified, and a repeats count, to allow an application to request multiple transmissions of key frames. The first should be non-contentious - all apps which don't use it will ignore it.
By: Serge Vecher (serge-v) 2006-05-12 09:44:02

thank you, Steve: I've cleaned up all the patches except for stable ones.

I've changed the fields for trunk, because, as far as I know (correct me if I am wrong, please), the most up-to-date t.38 code is contained in the trunk-integrated team/group/t38passthrough branch. As far as I understand, the code in the branch is slated to go into trunk (as soon as there are reports of code working, I guess). I don't know if there is any more work that needs to be done on the branch; for one, an automerge conflict circa rev 26725 needs resolution.

I don't know if you have commit access to the branch, Steve -- if you don't, perhaps you could ask KPF for it; this way you can bring the branch to the state it needs to be in to be ready for merging. Thanks.
By: Andreas Junklewitz (aj) 2006-05-12 11:47:23

From looking into the T.38 standard and into my T.38 Ethereal logs I think that both ideas from steveu are very good ones.

1. a frame sequence number, to allowing missing frames to be identified by the application

The T.38/T.30 protocol has some kind of inherent redundancy in it, so that the application could react in a clever way, if it knows that certain frames are missing. For example, using transfered TCF after the training phase the application could locally compensate even multiple missing t4-non-ecm data frames with zero data. But of course, the application has to know how many frames are missing.

2. a repeats count, to allow an application to request multiple transmissions of key frames

I think that the application should transmit frames including T30 indications about four times. Because loosing these indications could easily confuse the receiving gateway or fax maschine, so that it will finish this connection.

Regards
By: steveu (steveu) 2006-05-12 12:05:30

A T.38 application *must* know which frames are missing if it is to do its best in mitigating them. The UDPTL transport already commited to *'s trunk deals with  both the FEC schemes defined for UDPTL. The core of * was modified months ago to be able to deal with frames recovered by FEC processing.

I haven't seen any implementation that sends as many as four copies of the same packet. Two or three is more usual. Which ones they actually duplicate varies somewhat. The indicators are really the critical ones.
By: steveu (steveu) 2006-05-12 12:08:51

vechers:

I have no desire to have commit access.
By: Andreas Junklewitz (aj) 2006-05-13 08:56:38

steveu> I haven't seen any implementation that sends as many as four copies of the same packet.

Routers using Audiocodes-DSPs with SW version 1.07.20 are sending T30-indications four times. Maybe this is a little bit overdone.

Regards
By: steveu (steveu) 2006-05-13 10:46:57

That is rather interesting. The snag is you can never tell when a thing like that is a meaningful response to problems they have experienced in the field, and when its a bug :-)

I still have to refine the multiple sending strategy in my own code, and I expect to revise it based on real world experience when I start to get feedback from users. I guess copying someone elses practice might be a good starting point, though.
By: harry (hgaillac) 2006-05-13 18:30:43

I patched chan_sip.c with asterisk-1.2.7.1-t38-20060423.tar.bz2 however i can not put on hold or park an incoming call from zap channels .

no problem between sip to sip phone .
By: Pavel D.Kuzin (mirackle) 2006-05-15 01:34:47

i have a last asterisk from trunk branch of CVN.
Now testing with planet FXS gateway any my VOIP provider.
Both supports t38, but when provider sends me udptl offer, i`m seen in console:

Unknown SDP media type in offer: image 19888 udptl t38

Please help.

There is host config:
[500]
type=friend
username=500
secret=12345
callerid="Fax Mashine 2"
host=dynamic
nat=never
canreinvite=yes
context=default
disallow=all
allow=g729
dtmfmode=rfc2833
accountcode=nodex
t38pt_udptl = yes               ; Default false
t38pt_rtp = yes         ; Default false
t38pt_tcp = yes         ; Default false, not yet used


provider config:
[equant-sip]
type=friend
host=192.168.39.253
context=default
canreinvite=yes
nat=no
disallow=all
allow=g729
dtmfmode=rfc2833
amaflags=billing
accountcode=equant
t38pt_udptl=yes
t38pt_rtp=yes
t38pt_tcp=yes          ; Default false, not yet used


   -- SIP/equant-sip-8e1e is ringing
alligator*CLI>
<-- SIP read from 10.210.2.2:5060:
INVITE sip:9013721339@195.135.232.92 SIP/2.0
Via: SIP/2.0/UDP 10.210.2.2;branch=z9hG4bK07615eb3a
Content-Length: 319
To: "9013721339" <sip:9013721339@195.135.232.92>;tag=as08c82ae4
From: <sip:6linehotel4@10.210.2.2>;tag=48dba2e4cd21b44
Call-ID: 5c78722759c0f36d649084fc1fe2342b@195.135.232.92
CSeq: 125789650 INVITE
Supported: timer
Min-SE: 1800
Session-Expires: 3600
Allow: INVITE, ACK, BYE, CANCEL, REFER, NOTIFY
Content-Type: application/sdp
Contact: sip:6linehotel4@10.210.2.2
Supported: replaces
User-Agent: MxSipApp/4.4.13.94 MxSF/v3.2.7.41

v=0
o=MxSIP 1306603815897910379 55321458764188386 IN IP4 10.210.2.2
s=-
c=IN IP4 10.210.2.2
t=0 0
m=image 6010 udptl t38
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxVersion:0
a=T38FaxUdpEC:t38UDPRedundancy

--- (15 headers 13 lines)---
Using INVITE request as basis request - 5c78722759c0f36d649084fc1fe2342b@195.135.232.92
Sending to 10.210.2.2 : 5060 (NAT)
May 15 16:43:55 WARNING[23433]: chan_sip.c:3728 process_sdp: Unknown SDP media type in offer: image 6010 udptl t38
May 15 16:43:55 WARNING[23433]: chan_sip.c:3728 process_sdp: Unknown SDP media type in offer: image 6010 udptl t38
Transmitting (NAT) to 10.210.2.2:5060:
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 10.210.2.2;branch=z9hG4bK07615eb3a;received=10.210.2.2
From: <sip:6linehotel4@10.210.2.2>;tag=48dba2e4cd21b44
To: "9013721339" <sip:9013721339@195.135.232.92>;tag=as08c82ae4
Call-ID: 5c78722759c0f36d649084fc1fe2342b@195.135.232.92
CSeq: 125789650 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:9013721339@195.135.232.92>
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing


By: dario (dario) 2006-05-15 13:26:17

Hi,

Asterisk 1.2.7.1 with   asterisk-1.2.7.1-t38-20060423 patch doesn't work (T.38). A trunk http://svn.digium.com/svn/asterisk/team/group/t38passthrough doesnt work too for me. I  always see: Unknown SDP media type in offer
By: Pavel D.Kuzin (mirackle) 2006-05-16 02:38:21

asterisk 1.2.4 with patch asterisk-1.2.4-t38-20060216.tar.bz2 working ok?
By: dario (dario) 2006-05-16 03:10:46

Yes, it is.
By: harry (hgaillac) 2006-05-16 04:24:46

Does  asterisk-1.2.7.1-t38-20060423.tar.bz2 [^] (23,861 bytes) 04-23-06 14:39 solve problem beetween zap ans sip channels when caller is put on hold or park ?

Harry
By: Pavel D.Kuzin (mirackle) 2006-05-16 07:25:00

Yes, asterisk 1.2.4 seems works with patch, but have another trouble.

asterisk tryes initiate t38 session with my provider, but provider sends BYE to me immediatly.
anybody was seen this problem?

alligator*CLI>
<-- SIP read from 192.168.39.253:5060:
INVITE sip:500@192.168.39.42 SIP/2.0
Via: SIP/2.0/UDP 192.168.39.253:5060
From: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
To: "Fax Mashine 2" <sip:500@192.168.39.42>;tag=as79c1c023
Call-ID: 5637e6417e5a8aef62d2a1fd48ad86e1@192.168.39.42
CSeq: 103 INVITE
Contact: <sip:88122304573@192.168.39.253;user=phone>
Max-Forwards: 10
User-Agent: MERA MSIP v.1.0.1
Content-Type: application/sdp
Content-Length:   187

v=0
o=- 1147768051 1147768051 IN IP4 192.168.39.253
s=-
c=IN IP4 192.168.39.253
t=0 0
m=image 24064 udptl t38
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy

Reliably Transmitting (NAT) to 192.168.39.253:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.39.253:5060;received=192.168.39.253
From: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
To: "Fax Mashine 2" <sip:500@192.168.39.42>;tag=as79c1c023
Call-ID: 5637e6417e5a8aef62d2a1fd48ad86e1@192.168.39.42
CSeq: 103 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:500@192.168.39.42>
Content-Type: application/sdp
Content-Length: 241

v=0
o=root 29639 29640 IN IP4 192.168.39.42
s=session
c=IN IP4 192.168.39.42
t=0 0
m=image 20234 udptl t38
a=T38FaxVerison:0
a=T38FaxFillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferedTCF
a=T38FaxMaxBuffer:400
a=T38FaxMaxDatagram:400
a=T38FaxUdpEC:t38UDPRedundancy


<-- SIP read from 192.168.39.253:5060:
ACK sip:500@192.168.39.42 SIP/2.0
Via: SIP/2.0/UDP 192.168.39.253:5060;received=192.168.39.253
From: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
To: "Fax Mashine 2" <sip:500@192.168.39.42>;tag=as79c1c023
Call-ID: 5637e6417e5a8aef62d2a1fd48ad86e1@192.168.39.42
CSeq: 103 ACK
Max-Forwards: 10
User-Agent: MERA MSIP v.1.0.1
Content-Length: 0



<-- SIP read from 192.168.39.253:5060:
BYE sip:500@192.168.39.42 SIP/2.0
Via: SIP/2.0/UDP 192.168.39.253:5060
From: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
To: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
Call-ID: 5637e6417e5a8aef62d2a1fd48ad86e1@192.168.39.42
CSeq: 104 BYE
Max-Forwards: 10
User-Agent: MERA MSIP v.1.0.1
Content-Length: 0


--- (9 headers 0 lines)---
Sending to 192.168.39.253 : 5060 (NAT)
Transmitting (NAT) to 192.168.39.253:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.39.253:5060;received=192.168.39.253
From: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
To: <sip:88122304573@192.168.39.253>;tag=3c790e00ffff6910ff00000802ffffff
Call-ID: 5637e6417e5a8aef62d2a1fd48ad86e1@192.168.39.42
CSeq: 104 BYE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:500@192.168.39.42>
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing
By: Dirk Willbrandt (dirkw) 2006-05-18 07:17:02

Hi all,

Version 1.2.4 doesn't work for me too.
After applying the Patch on the Released 1.2.4 version from digium FTP-Server i get compile errors about udptl.

"...No target to make udptl..."

What is wrong ?!
By: Serge Vecher (serge-v) 2006-05-18 09:01:55

dirkw, Mirakle, et. al:

Please test the code in t38passthrough branch. If you are having trouble with 1.2.x t.38 branches, please use asterisk-users and IRC channels for support. Thank you!
By: steveu (steveu) 2006-05-21 06:29:13

I just uploaded udptl.c.patch and frame.h.patch. These provide features needed for T.38 termination and T.38 gateway. "seqno" has already been added to the frame structure, but conditional on the use of a jitter buffer. That seems odd, since I would have thought a jitter buffer was a core feature. :-\  Anyway, I have made it non-conditional, and added another variable, "tx_copies". This allows an application to request multiple transmissions of key frames. The changes to udptl.c make use of these changes. I think these are the only remaining infrastructure changes needed for full T.38 support.
By: steveu (steveu) 2006-05-21 10:53:52

vechers:

Nobody can test the t38passthrough branch, as it no longer exists. Olle has bundled things into his test-this-branch branch. That requires about 20 bug fixes to get it to build and start running. I think nobody is currently testing T.38 support, except in the backports.
By: dario (dario) 2006-05-21 14:39:52

Oej wrote on 10 May:
"I moved the branch to
http://svn.digium.com/svn/asterisk/team/group/t38passthrough [^]

Please continue testing, thanks!"

Regards
By: steveu (steveu) 2006-05-21 19:34:15

Oej wrote on 19 May that we should now be test-this-branch. However, for completeness, neither test-this-branch or group/t38passthrough will build abd run without numerous fixes.
By: Andreas Junklewitz (aj) 2006-05-22 12:53:07

steveu> I think these are the only remaining infrastructure changes needed for full T.38 support.

For T.38 terminal support this seems true to me. But I see no infrastructure to provide a gateway (T.30/T.38) between two channels. There is only terminating and spying support in the channel interface, isn't it ? The only gateway I see is the app_dial application. So a way could be to copy and modify app_dial and the bridging between different channels. But this looks really cumbersome to me. Some infrastructure for a gateway would be nice.

Regards
By: steveu (steveu) 2006-05-22 19:28:16

AJ:

Are you referring to how the gateway engine plugs into the call pipeline?

Right now I do T.38 termination by an enhanced app_rxfax and app_txfax which can switch between audio processing, and T.38 packet processing. I think that is clean, and requires no most than the patches I submitted a couple of days ago as a long term solution.

Right now I have my T.38 gateway engine fudged into a channel (chan_unicall to be exact) for development purposes. This is not generic, but I'm not sure how much that matters. There are only a few channel types which communicate with the PSTN, and only those have any meaningful use for T.38 gateway. Right now, Asterisk doesn't have a concept of a two way module to plug into a pipeline, or a scheme by which they could be controlled. Things like codecs are strictly one way operations.

Anyone's input on this is welcome. The patches I submitted are the only essential ones to make T.38 terminal and T.38 gateway viable. However, something that makes T.38 processing, or other similar processing (V.150 maybe), plugable in a stream might be worthwhile.
By: Andreas Junklewitz (aj) 2006-05-23 08:48:01

steveu> Are you referring to how the gateway engine plugs into the call pipeline?

Correct.

steveu> plugable in a stream might be worthwhile.

I think that also. I hope the that the admins and managers are also agree to that.
By: Claudio Martin (claudio) 2006-05-30 15:15:41

hi all,  i lost some information about current version of t38passthrough support.  
- what is working and what isn't ?  
- i see there was an old problem for passthru when asterisk and ATA was behind nat, anyone has fix this ?  
- and what about t.38 over rtp or tcp support ? working or not ?  
- finally what i have to test or better, what is the difference of t38passthrough brach and test-this-branch ?    
tanx
By: Matthew Simpson (matthewsimpson) 2006-05-31 18:36:34

My test results from a Sipura 2100 --> Asterisk --> Lucent APX t.38 gateway --> PSTN

1.2.4 with t.38 patch -- asterisk detects t.38 sdp offering, then promptly sends some kind of corrupt data that crashes the ethernet card on my apx [wtf?]

1.2.7.1 with t.38 patch -- sip show settings and sip show peer xxx shows that t.38 udptl support is on, but asterisk never detects t.38 sdp offering.  

team/group/t38passthrough SVN -- same as 1.2.7.1, asterisk never detects t.38 sdp offering
By: Serge Vecher (serge-v) 2006-06-01 16:40:07

matthewsimpson, et al: the branch has received some updates today. Please keep testing and have those reports coming ...
By: Matthew Simpson (matthewsimpson) 2006-06-01 18:19:19

vechers, none of the changes seem to be relevant to the problem where asterisk does not detect the t.38 sdp offering.
By: Serge Vecher (serge-v) 2006-06-01 18:29:25

matthewsimpson: it is preferable that you test first and then make assertive statements. Thanks
By: Matthew Simpson (matthewsimpson) 2006-06-01 18:37:33

vechers, it was downloaded and tested, and still doesn't work.  I poked into SVN to see what changes were made, and like I said, the changes made had nothing to do with the original problem.
By: Matthew Simpson (matthewsimpson) 2006-06-01 18:40:27

I have a lucent APX pstn gateway that can be tested against, contact me at matthew@txlink.net if you wish to test against it.  I also can originate faxes via a sipura 2100.
By: Pavel D.Kuzin (mirackle) 2006-06-05 04:59:26

just downloaded team/group/t38passthrough.
Seems asterisk does not see udptl offering from peers.
By: Dirk Willbrandt (dirkw) 2006-06-07 03:49:09

how can we test the t38 branch when asterisk doesn't see that it is an udptl invite?
Is there any reason why the asterisk is doing this?
Is there something that we had to change in the config?
By: Serge Vecher (serge-v) 2006-06-07 09:40:46

matthewsimpson, Mirackle, dirkw: the dev team needs some debugging information in order to figure out where the exact breakage point is with not udptl detection: can you please:

1. Post relevant sip.conf snippets.
2. Make sure your logger.conf has the following line:
  console => notice,warning,error,debug
3. Start Asterisk, at cli type set debug 4; set verbose 4; sip debug
4. Attempt the call; capture all of the console output into a file and post here as an _attachment_

Thanks for testing!
By: Matthew Simpson (matthewsimpson) 2006-06-08 16:31:35

I uploaded sip conf.txt which is my sip.conf

I also uploaded bad capture 06 08 2006.txt as you asked with the sip debug of a failed call.  as you can see asterisk does not recognize the udptl offer.

proxy5*CLI> show version
Asterisk SVN-group-t38passthrough-r31688 built by root @ proxy5 on a i686 running Linux on 2006-06-08 21:11:02 UTC
By: steveu (steveu) 2006-06-08 20:39:12

Interesting. There is no rtpmap entry for t38 in that log. I don't think that is supposed to be valid. The last time I played with chan_sip I don't think it was allowed for. However, if people do that in the real world, it needs to be catered for.
By: Matthew Simpson (matthewsimpson) 2006-06-08 22:04:35

The 06 08 2006 sip capture is a Sipura 2100 originating a fax call to a Lucent APX 8000 running TAOS 11.0 gateway to the PSTN.  The T.38 reinvites seem to be quite similar from both devices.

I have also tested Cisco 5400 originating a fax call to the Lucent with the same result.
By: marvinek (marvinek) 2006-06-12 11:10:31

Why where the latest uploads from steveu deleted, I was just about to start testing T38->PSTN termination , anyway passthrough works well for me , thanks for great job
By: Serge Vecher (serge-v) 2006-06-12 12:18:48

marvinek: I've deleted the patches because they were merged into the t38passthrough branch. http://lists.digium.com/pipermail/svn-commits/2006-June/014191.html

Since you've managed to get the passthrough going, could you kindly share what sourcebase you've used, equipment and setup, as well as sip.conf settings? Thanks.
By: Matthew Simpson (matthewsimpson) 2006-06-13 12:11:39

....

are there any updates?  why doesn't * see the UDPTL offer?
By: Matt O'Gorman (mogorman) 2006-06-13 13:37:11

committed into trunk 33890. thanks
By: Matt O'Gorman (mogorman) 2006-06-13 13:41:42

and thanks to everyone who helped work on or contributed to any way to adding testing etc this new feature
By: Digium Subversion (svnbot) 2008-01-15 17:12:00.000-0600

Repository: asterisk
Revision: 11813

A   team/oej/t38passthrough/

------------------------------------------------------------------------
r11813 | oej | 2008-01-15 17:12:00 -0600 (Tue, 15 Jan 2008) | 2 lines

Branch for issue ASTERISK-4957

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

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