Summary:	ASTERISK-07638: [patch] t.38 passthrough not working when endpoints are behind a NAT
Reporter:	Marek Cervenka (cervajs)	Labels:
Date Opened:	2006-08-31 09:58:38	Date Closed:	2007-02-05 10:26:15.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) boat.tif ( 1) boat-t38.tif ( 2) chan_sip.c-svn-47446 ( 3) chan_sip-t38-fix.diff ( 4) kapanga-t38-no-nat.txt.log ( 5) kapanga-vp100.txt ( 6) log_t38.txt ( 7) t38_log_1.log ( 8) t38.log ( 9) T38-01Dec06-001.log (10) t38-11132006.log.log (11) t38-2kapanga.txt (12) T-38-fail-over-ipsec-fail (13) t38-is-sip-only.txt (14) t38-kapanga-both-behind-nat (15) t38-kapanga-with_nat.log (16) t38Log-Nov21-001.txt (17) T-38-working.tif (18) vdebug_01Dec06.txt (19) vdebug_04Dec06.log (20) working-T-38-kapanga-with-nat
Description:	i have this topology (ATA - 2x grandstream ht496 fw 1.0.3.44, t.38 on) ATA -NAT- ASTERISK(public ip) -ANOTHER NAT- ATA trying t.38 passthrough in sip.conf per phone t38pt_udptl = yes i have this problem chan_sip.c:4586 process_sdp: Unsupported SDP media type in offer: image 10912 udptl t38 do you want SIP traffic dump or i have problem in config/hw/sw/mind?
Comments:	By: Serge Vecher (serge-v) 2006-08-31 10:25:59 AFAIK, canreinvite must be on for T.38 passthrough to work. Since your endpoints behind a NAT, canreinvite will not work. So, you are looking at a currently unsupported network configuration. Let's see a SIP Debug trace though: 1) Prepare test environment (reduce the ammount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterik. 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Save complete console log to file and _attach_ said file to the bug. By: Marek Cervenka (cervajs) 2006-09-13 15:49:25 working on test lab meantime ... i set up http://www.voip-info.org/tiki-index.php?page=Asterisk%20T.38 By: Marek Cervenka (cervajs) 2006-09-13 18:49:18 ok, topology changed => simple scenario one subnet 192.168.1.0/24 2 kapanga softphone, one asterisk svn trunk - Asterisk SVN-trunk-r42893 (no NATs!) uploaded sip debug t38-2kapanga.txt same problem as with grandstreams WARNING[18321]: chan_sip.c:4633 process_sdp: Unsupported SDP media type in offer: image 5124 UDPTL t38 By: Leonardo Gomes Figueira (sabbathbh) 2006-09-29 14:53:08 I'm trying with 2 UTStarcom IAN-02EX ATAs and 1.4 branch and got the same problem: [Sep 29 16:39:19] WARNING[30981]: chan_sip.c:4643 process_sdp: Unsupported SDP media type in offer: image 4504 udptl t38 Asterisk and ATAs on the same LAN with canreinvite working between then. No NAT. I don't know if the T.38 implementation on this ATAs really work since I didn't find on google anyone that already tested this but I would like to help solving this issue anyway (and find out if this ATAs work with T.38). Do you want debug/sip debug ? Connected to Asterisk SVN-branch-1.4-r43997 currently running on pfdesenv (pid = 30932) By: jmls (jmls) 2006-11-02 12:20:19.000-0600 I think any debugs / logs you can provide will be helpful for the developers. Thanks. By: Leonardo Gomes Figueira (sabbathbh) 2006-11-06 08:38:37.000-0600 Unfortunately I don't have any T.38 capable ATAs available anymore so I can't really help right now. Maybe someone else could provide this debug info ? Sorry. By: Ahsan Masood (ahsan) 2006-11-08 11:39:46.000-0600 Hi, I have installed a latest asterisk trunk version (SVN-trunk-r47321)and configured two grandstream ATAs (496 and 386). Both ATA's are using a same fimware verson 1.0.3.44. Both ATA are registed to asterisk on local network without NAT and I am unable to send faxes between them. Please find the attached log file (t38.log) for aerisk cli debug report. I have different kind of ATAs over here and will be happy to help in testing this feature. Regards, Ahsan Masood Telappliant Ltd. By: dea (dea) 2006-11-08 16:15:51.000-0600 ahsan-   Do you have 't38pt_udptl = yes' set for the ata peers?  Your log clearly shows the t38 offer in the SDP, but the log also claims it was not found. By: Ahsan Masood (ahsan) 2006-11-09 09:34:42.000-0600 Yes, I have set t38pt_udptl = yes. My sip.conf entries for both ATA looks like [200] type=friend context=from-sip host=dynamic secret=200 canreinvite=yes t38pt_udptl = yes disallow=all allow=alaw [201] type=friend context=from-sip host=dynamic secret=201 canreinvite=yes t38pt_udptl = yes disallow=all allow=alaw By: Leonardo Gomes Figueira (sabbathbh) 2006-11-09 10:32:50.000-0600 Is there an "t38pt_udptl = yes" on [general] section of sip.conf ? It must be there too. By: Ahsan Masood (ahsan) 2006-11-09 11:14:48.000-0600 I got t38pt_udptl=yes in  general section, run the test again and T.38 failed and fax worked on alaw. still reciving debug message [Nov  9 18:19:20] DEBUG[20548]: chan_sip.c:4889 process_sdp: Peer doesn't provide T.38 UDPTL By: dea (dea) 2006-11-09 12:32:31.000-0600 I believe that is progress, but a new debug log will be required to confirm that. It now appears that the SDP is properly parsed and the T38 capabilities identified, but for some reason the udptl port number is not recorded. Can you attach another log? By: Ahsan Masood (ahsan) 2006-11-09 12:40:42.000-0600 Please find latest logs (t38_log_1.log) By: dea (dea) 2006-11-09 15:46:45.000-0600 Did you have 'core set debug 4' for this log?  There are messages I would expect to see that are not present. The interesting bit is that Asterisk appears to complete the T38 negotiation, ACK'ing the 200 OK responses from the ATAs after the T38 re-invite, but immediately sends another invite to use RTP. I think I see a possible cause, but will need a log with the logging levels mentioned by serge-v in the first post. By: dea (dea) 2006-11-09 18:31:30.000-0600 Here is a super small patch that checks to see if we have completed T38 negotiation inside of sip_set_rtp_peer() Looking over the logs on this bug and 7679, it looks like the callback to sip_set_rtp_peer is triggered when the T38 code re-assigns the port number, which then triggers a re-invite for RTP. Consider the patch a proof of concept only at this point, there may be a better way, but I would be interested to see a log after this patch is applied (sip debug; core set verbose 4; core set debug 4) By: dario (dario) 2006-11-10 06:40:15.000-0600 Please find latest logs from my configuration: SPA-9000 and cisco router (log_t38.txt) Regards By: Ahsan Masood (ahsan) 2006-11-10 08:53:57.000-0600 After patching, I am getting these errors. [CC] chan_sip.c -> chan_sip.o chan_sip.c: In function `sip_set_rtp_peer': chan_sip.c:16703: error: structure has no member named `lock' chan_sip.c:16709: error: structure has no member named `lock' make[1]: *** [chan_sip.o] Error 1 make: *** [channels] Error 2 By: dario (dario) 2006-11-10 08:57:51.000-0600 I have patched chan_sip.c and now T.38 is working (SVN-branch-1.4-r47405M) Regards By: Ronald Chan (loloski) 2006-11-10 09:08:23.000-0600 Dario:   is this environment applicable for you ? ATA -NAT- ASTERISK(public ip) -ANOTHER NAT- ATA just like the original reporter? if this t38 pass thru is working in this environment. it's great we have it now :) Ronald By: dario (dario) 2006-11-10 09:26:18.000-0600 Sorry, it is without NAT :(, I will check it on Monaday with NAT By: Ronald Chan (loloski) 2006-11-10 10:17:05.000-0600 dario:   ok i'll try to test this functionality also using kapanga softphone on both ends. using a both with nated and a non-nat environment, hoping we get this in. also i will try both SVN-trunk and 1.4-beta3 with above patch by DEA... thanks i will get back into this asap Ronald By: dea (dea) 2006-11-10 10:41:25.000-0600 ahsan, you line numbers are nowhere near close to what I have.  I do have another small patch in my tree, but it would not explain the huge difference.  Can you post the SVN number you have? How did you apply the patch and did it generate any errors other than fuzz? One point to clear up about this bug, while it was reported against NAT, the issue was not about NAT.  The bug would trigger on any call that started by using RTP and then attempted to switch to udptl. By: Ronald Chan (loloski) 2006-11-10 11:09:34.000-0600 DEA: same error encounter with ahsan it applies cleanly but failed to build patch -p0 < ../../1.4/patch/t38.diff patching file channels/chan_sip.c Hunk #1 succeeded at 16705 (offset 224 lines). chan_sip.c: In function ?sip_set_rtp_peer?: chan_sip.c:16707: error: ?struct sip_pvt? has no member named ?lock? make[1]: *** [chan_sip.o] Error 1 make: *** [channels] Error 2 Path: . URL: http://svn.digium.com/svn/asterisk/trunk Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Revision: 47438 Node Kind: directory Schedule: normal Last Changed Author: file Last Changed Rev: 47438 Last Changed Date: 2006-11-11 00:55:13 +0800 (Sat, 11 Nov 2006) Properties Last Updated: 2006-11-11 01:06:45 +0800 (Sat, 11 Nov 2006) hope this help By: dea (dea) 2006-11-10 11:19:13.000-0600 I'm checking out a fresh copy and will check the patch against it. The only reference to lock in the patch is a copy and paste from a similar test in sip_set_rtp_peer.  Perhaps locking rules changed between 47337 and 47438 By: Ahsan Masood (ahsan) 2006-11-10 11:21:40.000-0600 DEA:   Asterisk Version. SVN-trunk-r47321 Patched as patch -p0 < ../../1.4/patch/t38.diff Got succeeded message but got errors on make install. By: Ronald Chan (loloski) 2006-11-10 11:39:04.000-0600 DEA: i was able to patch and build it cleanly on branch 1.4 inline with your. in this release Path: . URL: http://svn.digium.com/svn/asterisk/branches/1.4 Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Revision: 47444 Node Kind: directory Schedule: normal Last Changed Author: rizzo Last Changed Rev: 47444 Last Changed Date: 2006-11-11 01:13:34 +0800 (Sat, 11 Nov 2006) Properties Last Updated: 2006-11-11 01:28:22 +0800 (Sat, 11 Nov 2006) maybe i should start testing it here on svn-branch-1.4beta first before jumping the gun on my head in trunk nah maybe i can do both for sure :) By: dea (dea) 2006-11-10 11:42:19.000-0600 SVN 47444 takes the patch with a little fuzz, compiles and installs. The error is odd, as sip_pvt most definately has a member named lock. I suspect an issue with the patch(ing) Can either of you paste a few lines of code before and after the line identified in the make error into a txt and attach it? By: Ronald Chan (loloski) 2006-11-10 12:04:08.000-0600 Before the patch applies it's on line 16706 on SVN Last Changed Author: russell Last Changed Rev: 47446 Last Changed Date: 2006-11-11 01:53:46 +0800 (Sat, 11 Nov 2006) Properties Last Updated: 2006-11-11 02:06:49 +0800 (Sat, 11 Nov 2006) i will apply it manually and create a svn diff format By: Ronald Chan (loloski) 2006-11-10 12:12:54.000-0600 DEA: still the same error even applied it by hand. chan_sip.c: In function ?sip_set_rtp_peer?: chan_sip.c:16707: error: ?struct sip_pvt? has no member named ?lock? make[1]: *** [chan_sip.o] Error 1 make: *** [channels] Error 2 Path: . URL: http://svn.digium.com/svn/asterisk/trunk Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Revision: 47448 Node Kind: directory Schedule: normal Last Changed Author: russell Last Changed Rev: 47446 Last Changed Date: 2006-11-11 01:53:46 +0800 (Sat, 11 Nov 2006) Properties Last Updated: 2006-11-11 02:06:49 +0800 (Sat, 11 Nov 2006) i'm just wondering what really happen i will try to look also on the code if there's really change between the lines. Ronald By: Ronald Chan (loloski) 2006-11-10 12:20:22.000-0600 DEA: please take a look at this http://pastebin.ca/245191 for more information By: dea (dea) 2006-11-10 12:46:11.000-0600 Thanks.  The problem is obvious now. My patch is against SVN ./branches/1.4 since this is a bug there. It looks you and ashan are running Trunk which has changes to the locking rules. Change this in my patch: ast_mutex_unlock(&p->lock); to this: sip_pvt_unlock(p); And you'll be able to test.   Also the log_t38.txt posted today does show progress.  Asterisk is no longer triggering the re-invite, but the Cisco router is.  Now to find why.  The log claims that NAT is off for both peers, on the RTP and T38 stacks.  This might be a config issue, and it might be a code issue.  I'll need to see the relevant sections of the sip.conf that was used to generate log_t38.txt By: Ronald Chan (loloski) 2006-11-10 13:59:05.000-0600 DEA:      I will attach the the log here kapanga-t38-no-nat.txt regarding the udptl negotiation, the fax went thru on both softphone but the problem is, it's corrupted. it might be the softphone issue as well, i will mail kapanga mailing list about this :) environment WinXP->Kapanga --> * <-- Kapanga>WinXP Ronald By: Ronald Chan (loloski) 2006-11-11 00:11:17.000-0600 Beta Tester/Developer   Whatever configuration i check/uncheck with these T38 capable softphone, the closes thing i get is this it's no longer corrupted but still crappy :)  i will attach both the original boat.tiff file and the received boat-t38.tiff file using ulaw as a codec i also check with alaw but it's the same thing. please confirm if someone has successfully sending T38 fax over different T38 capable device, this will elimate my doubt that the culprit is *. By: Olle Johansson (oej) 2006-11-12 09:42:24.000-0600 I've committed some T.38 related patches - please retest with latest 1.4 and svn trunk. Thanks for all kinds of feedback. By: Ronald Chan (loloski) 2006-11-12 11:01:17.000-0600 Oej: here's my latest test from SVN Trunk still the same image i get after the T38 negotiation has take place please see t38-11132006.log URL: http://svn.digium.com/svn/asterisk/trunk Repository UUID: 65c4cc65-6c06-0410-ace0-fbb531ad65f3 Revision: 47514 Node Kind: directory Schedule: normal Last Changed Author: oej Last Changed Rev: 47514 Last Changed Date: 2006-11-13 00:15:49 +0800 (Mon, 13 Nov 2006) Properties Last Updated: 2006-11-13 00:36:24 +0800 (Mon, 13 Nov 2006) By: Olle Johansson (oej) 2006-11-12 11:09:26.000-0600 Thanks for fast feedback! By: Olle Johansson (oej) 2006-11-15 15:40:44.000-0600 Can't do much in Asterisk about the image, it's up to the endpoints. We just need to make sure that the passthrough works. Any open unresolved issues with latest svn trunk 1.4? By: Ronald Chan (loloski) 2006-11-16 04:46:12.000-0600 oej: since, i don't really know rfc3261 in general, base on the log i post t38-11132006.log.log, could you or someone verify if T38-pass thru thing has been done in this case??? if yes, maybe you can close this for now until someone request to re-open this ticket Many thanks !!! Ronald By: Ronald Chan (loloski) 2006-11-16 05:08:53.000-0600 To cervajs: when i'm doing this test my sip configuration doesn't match to your topology as you describe above there's no NAT involve in my setup with canreinvite set to yes. T38 settings was on for both peers. i hope i made myself clear on this. since there's no clear direction wethere this stuff was really working on both nated and non-nated environment i decided to choose non NAT since it's very easy to setup, could someone lift a hand on this, and check also if this pass thru thing applicable as per original report?. Ronald By: Marek Cervenka (cervajs) 2006-11-16 05:09:42.000-0600 same topology as note from 09-13-06 18:49 call from kapanga -> asus vp100 asterisk SVN-branch-1.4-r47712 [Nov 16 11:44:34] WARNING[3749] chan_sip.c: Unsupported SDP media type in offer: image 10014 UDPTL t38 dump i attach kapanga-vp100.txt (maybe t.38 in vp100 is bad, look at dump please) By: Ronald Chan (loloski) 2006-11-16 05:21:45.000-0600 cervajs: ok i will produce this with NAT also with both kapanga softphone, aiming for other developers to think of this, since my C and asterisk internals is very very limited, what we can do for now is to test this and aid them for some insight produce by our log Best regards, Ronald By: dea (dea) 2006-11-16 11:16:46.000-0600 cervajs, are you sure that 't38pt_udptl = yes' is set on the vp100? The Unsupported SDP message can be triggered if the peer does not have t38 support turned on.  The SVN rev you have does have support for both 'udptl' and 'UDPTL' in the SDP, so this is not the case sensitivity bug that popped up in another report. OEJ, is the test for p->udtpl needed when scanning the SDP?  If it was removed, we would always detect the T38 offer, and later in the code, say near where we setup the udptl port, warn if we have a t38 offer, but the user/peer does not have support turned on?  It might make it clearer why a failure to negotiate t38 occured. By: Ronald Chan (loloski) 2006-11-16 17:55:03.000-0600 To ALL: i think this is not the case for kapanga softphone with phone behind a nat with canreinvite set to no. please check my new debug trace By: dea (dea) 2006-11-16 18:52:40.000-0600 loloski, did the session work or fail?  The log looks like the Asterisk server properly relayed the udptl packets between the endpoints until the kapanga endpoint sent the 'Bye'. The only other issue that stands out in the logs is that the Linksys PAP2 insists on sending keep-alive notifies, which Asterisk doesn't care for and replies with 489 'Bad Event' By: Ronald Chan (loloski) 2006-11-16 19:44:38.000-0600 DEA: Please disregard The linksys PAP2 on the picture sorry. i will retest this again. with both kapanga soft phone on the network with both nat=yes and canreinvite=no. By: Ronald Chan (loloski) 2006-11-16 20:12:40.000-0600 DEA: please check this recent logs, both peer is set to nat=yes canreinvite=no on my perspective, the call is said to be complete. but i can't produce now the crappy image i produce on my previous test with nat=no and canreinvite=yes. i hope this may help you and other developers along the way :) Thank you!! By: Ronald Chan (loloski) 2006-11-16 21:17:24.000-0600 TO ALL: yes, good news after downloading recent kapanga softphone 1.00.2152 build i was able to send and receive fax perfectly using with nat=yes and canreinvite=no please check the recent logs and sample image Ronald By: Ronald Chan (loloski) 2006-11-17 04:57:22.000-0600 DEA & others: guys, when i'm writing this i'm very hesistant simply because the topology i'm using slightly modified against the original report, but here it is this time T-38 pass through failed to finish the transmission. T-38 Softphone 1 -> IPSEC/l2tpd -> * -> T-38 Softphone 2 T-38 Sofphone 1 = 192.168.8.128     IPSEC/l2tpd GW = 203.177.215.181 * = 210.213.241.172 T-34 Softphone 2 = 192.168.4.4  As you can see this is same NAT -> NAT scenario the only thing that's being add here is the IPSEC/l2tpd which i know it's very heavy. it can cause a lot of network jitters which i think this is the main cause this test to fail. do we need to  pursue in this setup? or shall we go back on the test case with the original reporter? _NO_FLAME_WAR_PLS i just want to help :) p.s. Sorry for my horrible english since i'm not a native english speaker :) i hope i made my self clear on this. Ronald Ronald By: Marek Cervenka (cervajs) 2006-11-17 05:18:11.000-0600 to DEA: i'm pretty sure to have t38pt_udptl = yes sip show peer 200 T38 pt UDPTL : Yes sip show peer 201 T38 pt UDPTL : Yes By: Ronald Chan (loloski) 2006-11-17 05:49:54.000-0600 cervajs: i'm using SVN-branch-1.4-r47751M ? and yours ? how about in [general] section of sip.conf ? did you add this t38pt_udptl = yes ? By: dea (dea) 2006-11-17 11:43:16.000-0600 loloski-    Your English is fine.  I am pretty sure I don't speak your native language, so I appreciate your efforts.  Your ipsec-fail log actually looks good, maybe the udptl packets are a little smaller than they should be (I don't know what size is healthy), but the communications setup seems to complete. cervajs-   There are only 2 reasons to get this:      Unsupported SDP media type in offer: image 10912 udptl t38   1.  The 't38pt_udptl = yes' options is not set   2.  The SDP offer is not a perfect match.      A.  The code to find the image offer is/was case sensitive.       'image 12345 udptl t38' would match       'image 12345 UDPTL t38' would not The case sensitivity issue was had a fix implimented before the version you last reported to be testing (branches-1.4-47712), but it might not be working as expected.  I'll take a look. The Kapanga-vp100 log shows that the VP100 offered T38 with UDPTL, and Asterisk rejected it.  Loloski has reported success with the Kapanga softphone.  So if the option is turned on, then issue is likely back on the upper case UDPTL. By: Ronald Chan (loloski) 2006-11-17 12:00:20.000-0600 DEA:  Thanks a lot, well as far as i can say maybe it could be MTU issue's since ipsec/l2tpd was set to 1452 wherein you can set this to low or even higher i'll check later on if setting MTU to 1492 will solve this, well i'll handle this and report asap, to others please help us to test this in order for us to move forward without your help this issue will rest in this bug tracker forever :) peace ^_^ By: Ronald Chan (loloski) 2006-11-20 18:52:46.000-0600 DEA: this is reproducible in in IPSEC/l2tpd scenario maybe it's not related to MTU. setting MTU to 1492/1400 doesn't make sense at all. cervajs: did you make any progress on your testing environment??? Ronald By: Marek Cervenka (cervajs) 2006-11-21 03:21:17.000-0600 waiting for second licence for kapanga (donated by kapanga for asterisk testing) i'm ordered grandstream ht496 i will edit this note asap loloski: can we make interoperability tests together? my mail cervajs at freevoice.cz By: Ahsan Masood (ahsan) 2006-11-21 03:52:58.000-0600 Hi All, I am using asterisk verion SVN-trunk-r47790 and tested the T.38 feature between two local HT-496 (using latest beta firmware 1.0.3.57) and fax failed. My extensions looks like [200] type=friend context=from-sip host=dynamic secret=200 t38pt_udptl = yes disallow=all allow=alaw [201] type=friend context=from-sip host=dynamic secret=201 t38pt_udptl = yes disallow=all allow=alaw and t38pt_udptl = yes in general section. Logs are attached as t38_ht496.log. Please let me know if any change or further testing required. By: Marek Cervenka (cervajs) 2006-11-21 04:16:57.000-0600 to ahsan: this "Peer doesn't provide T.38 UDPTL" looks like you have "fax mode: passthrough" in ht496. can you check? you must have T.38 By: Alex lake (alexlake) 2006-11-21 04:44:08.000-0600 Hello there, loloski asked me to "help out" here and I'm certainly willing to put a bit of time in.... I have a very similar problem, but it's got nothing to do with NAT. SVN r47866 on Ubuntu 5.10 Essentially I'm getting the "Unsupported SDP media type in offer: image 47174 udptl t38" problem leading to a SIP 488 (Not acceptable here) I do have "canreinvite = yes" and "t38pt_udptl = yes" in sip.conf for appropriate peers ASIDE: Do these both need to be in both inbound AND outbound peer configuration sections, or is it controlled by just one? My setup involves no NAT at all. We have a carrier who operates a Cisco box (5400 on SW v12.3) clever enough to invoke t38 on the fly. The call flow is: PSTN_A--->Cisco--[Internet]-->Asterisk---[Internet]-->Cisco--->PSTN_B When PSTN_B is a fax machine, the fax answer tone is recognised by the Cisco which sends us a new invitation (see below) which results in the warning shown above. Is this any use? Do you need any more files/traces/etc? Should I stay here? Cancel my own bug report? No.     Time        Source                Destination           Protocol Info      6 5.999566    83.245.6.83           89.202.128.200        SIP/SDP  Request: INVITE sip:442070173460@89.202.128.200, with session description Frame 6 (923 bytes on wire, 923 bytes captured) Ethernet II, Src: ZyxelCom_53:59:ce (00:a0:c5:53:59:ce), Dst: Dell_22:69:48 (00:13:72:22:69:48) Internet Protocol, Src: 83.245.6.83 (83.245.6.83), Dst: 89.202.128.200 (89.202.128.200) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol    Request-Line: INVITE sip:442070173460@89.202.128.200 SIP/2.0    Message Header    Message body        Session Description Protocol            Session Description Protocol Version (v): 0            Owner/Creator, Session Id (o): msw 6754 2344 IN IP4 83.245.6.83            Session Name (s): sip call            Connection Information (c): IN IP4 83.245.6.84            Time Description, active time (t): 0 0            Media Description, name and address (m): image 47174 udptl t38            Media Attribute (a): T38FaxUdpEC:t38UDPRedundancy            Media Attribute (a): T38FaxMaxDatagram:72            Media Attribute (a): T38FaxMaxBuffer:200            Media Attribute (a): T38FaxRateManagement:transferredTCF            Media Attribute (a): T38FaxTranscodingJBIG:0            Media Attribute (a): T38FaxTranscodingMMR:0            Media Attribute (a): T38FaxFillBitRemoval:0            Media Attribute (a): T38MaxBitRate:14400            Media Attribute (a): T38FaxVersion:0 By: Ahsan Masood (ahsan) 2006-11-21 04:58:22.000-0600 Cervajs: Fax mode is set to T.38 as default. (Fax Mode:  T.38 (Auto Detect)) Not sure why its doing like that. I have also reported this to grandstream and wiating for thier response. By: Alex lake (alexlake) 2006-11-21 05:02:20.000-0600 ahsan - I'd have thought the reason is that most IP networks are not good enough for fax over the audio channel - even sending uncompressed (64kbps) can have problems with latency. Thus the best chances for success are to use T38 while in the VOIP domain and hope that PSTN gateways can do the conversion! By: Ahsan Masood (ahsan) 2006-11-21 06:22:39.000-0600 alexlake: I am using both HT-496 on the same network and I don't think its a network issue. By: Ronald Chan (loloski) 2006-11-21 07:40:32.000-0600 cervajs: did you get my e-mail?? please reply about the arrangements of the testing, alexkake: could you please provide, the sip debug and udptl debug logs on your end, hoping for some developers to pick this up, whethere here or on your own bug report. core set verbose 3 sip set debug udptl debug Bug Marshall: Please inform me if this is not the right thing to do, since there's a lot of T-38 passthrough related issue, i think it's best if we can consolidate it here first, then inform everyone if they are really need to file their own bug report. Thank you!! Ronald By: Alex lake (alexlake) 2006-11-21 09:11:06.000-0600 See t38Log-Nov21-001.txt for console trace of call that attempts to transfer to T.38 By: Ahsan Masood (ahsan) 2006-11-21 10:36:51.000-0600 I have two HT-496 and two Sipura 2100 and Asterisk box wih external IP. Please let me know if I can help with any further testing. ~Ahsan By: Ronald Chan (loloski) 2006-11-21 11:05:52.000-0600 ahsan & others: for those people interested on doing interoperability testing please e-mail me the details. my * is on dynamic ip with public address. i have kapanga softphones to be used in T-38 nego. my e-mail is loloski at yahoo dot com definetly this will be on NAT to NAT scenario just in case there are people interested just jump in. you can add me to YM too. though i have linksys PAP2-NA adapter claim to be a T38 capable device but i haven't tried it yet because i don't have a fax machine to plug in there. Ronald By: dea (dea) 2006-11-21 11:06:44.000-0600 Alexlake-  442070173450 is setup as a peer, does it have 't38_udptl = yes' set? It looks like you are using the same peer to setup both legs of this call, hair-pinning though a proxy.   Can we see the section of sip.conf related to Gamma-OUT? By: Alex lake (alexlake) 2006-11-21 11:41:06.000-0600 [gamma-OUT] type            = peer context         = from-gamma host            = 83.245.6.83 allow           = alaw t38pt_udptl     = yes canreinvite     = yes (I tried your implicit suggestion of "t38_udptl = yes" and it didn't help) BTW - You are right about the "hairpinning" (a kind of local tromboning) By: Marek Cervenka (cervajs) 2006-11-22 12:28:11.000-0600 i have found why some users report [Nov 22 19:20:10] WARNING[14396]: chan_sip.c:4756 process_sdp: Unsupported SDP media type in offer: image 5120 UDPTL t38 this is because without t38pt_udptl = yes in [general] section T.38 DONT WORK! BUT in example config we have ;----------------------------------------- T.38 FAX PASSTHROUGH SUPPORT ----------------------- ; ; This setting is available in the [general] section as well as in device configurations. ; Setting this to yes, enables T.38 fax (UDPTL) passthrough on SIP to SIP calls, provided ; both parties have T38 support enabled in their Asterisk configuration (either general or ; peer/user/friend sections) ; ; t38pt_udptl = yes            ; Default false (either general or peer/user/friend sections) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is NOT true By: Marek Cervenka (cervajs) 2006-11-22 12:43:26.000-0600 same topology as note from 09-13-06 18:49 asterisk  SVN-branch-1.4-r47911 kapanga 2152b build t38pt_udptl = yes added to [general] t.38 fax works (but receiving kapanga crash after fax transmission(this is kapanga bug, not bug in asterisk. i'm in contact with kapanga support) to loloski: i sent email to you By: dea (dea) 2006-11-22 13:08:34.000-0600 cervajs-   Great catch.  I intended to look at that, and well, work got in the way. To summerize your findings:            General             User/Peer         Result     1.     No(default)           No(default)       No     2.     No                    Yes               No     3.     Yes                   No                No     4.     Yes                   Yes               Yes So 1, 3 and 4 work as expected, but 2 is inconsistent.  That should be an easy fix. By: Ronald Chan (loloski) 2006-11-22 13:39:30.000-0600 DEA: I colloborate with ahsan today, using his grandstream ATA adapter we found out that even his ata is on the same network. it doesn't work in some cases. with canreinvite=no, nat=yes one time we got a complete T38 transmission and fax. in this setting most of the time there's an exchange of UDPTL packet's going on but failed to complete the fax. with canreinvite=yes, nat=no           doesn't work with canreinvite=yes, nat=never        doesn't work with canreinvite=no,  nat=no           doesn't work with canreinvite=yes, nat=nonat        doesn't work either. but on my testing at home, with kapanga canreinvite=no,nat=yes works 100% all the time. nat=no, canreinvite=yes it work's but sometimes it failed. cervajs: your are right some time kapanga crash after fax transmission. but it's kapanga issue anymore. ahsan: if you have time, could you sent here the sip debug so that they can see it. i forgot to log those traces on my putty. By: dea (dea) 2006-11-22 15:02:23.000-0600 Looking deeper at the t38 support code, I think the only sip.conf setting that matters right now is t38pt_udptl in the [general] section.  Settings per peer/user just do not seem to be considered. Can someone test with the option turned on in [general] and both:   Explicitly off (t38pt_udptl=no) on a user/peer   Not present on a user/peer I think we will find that the user/peer setting does not matter, and it is not as trivial a fix as I first thought.  If I am right, we can get past the negotiation issues with a work-around and move on to why is seems to fail after negotiation. By: Alex lake (alexlake) 2006-11-23 03:52:06.000-0600 Good spot on the [General] section It looks like you can turn it OFF on the Peer. My tests show: [General] [Peer] yes       yes       It works yes       -         It works yes       no        It fails -         yes       It fails -         no        It fails -         -         It fails - = Node not specified When I say "It works" I mean you don't get the "Unsupported SDP media type" warning. I've still got trouble (i.e. Asterisk is still sending a 488) but it's progress! By: Alex lake (alexlake) 2006-11-23 04:00:41.000-0600 I think I may be having trouble with the media types I allow through my Asterisk. I've uploaded t38_day2.txt My sip.conf is now: [general] context         = default port            = 5060 bindaddr        = 0.0.0.0 nat             = no reinvite        = no canreinvite     = yes disallow        = all allow           = alaw trustrpid       = yes sendrpid        = yes t38pt_udptl     = yes [gamma-OUT] type            = peer context         = from-gamma host            = 83.245.6.83 allow           = alaw t38pt_udptl     = yes canreinvite     = yes By: Marek Cervenka (cervajs) 2006-11-27 16:12:09.000-0600 same topology as note from 09-13-06 18:49 Asterisk SVN-branch-1.4-r48054 kapanga 2152b build grandstream ht496 1.0.3.57 kapanga->ht496 works ok! ht496->kapanga (1/3 is ok, 2/3 black - this is not related to the bug, it's kapanga/ht496 problem!) this note is only for testers -> info about working configuration please add working configurations to the wiki at http://www.voip-info.org/tiki-index.php?page=Asterisk%20T.38 By: Alex lake (alexlake) 2006-11-29 04:57:17.000-0600 I think I'm going to give up on this as a way of allowing fax to transit our network. I did wonder if it was possible from within a dialplan or AGI session to get a call reinvited, but I've heard from someone who knows about this kind of thing that it isn't. I know this is drifting from the topic, but if any kind soul can suggest how I might manage to do a reinvite (i.e. cut out the "hairpin"), that would be mucho appreciated! Good luck, chaps! By: Alex lake (alexlake) 2006-11-29 10:07:30.000-0600 I presume that someone has got T.38 passthru working. I wonder if it might be possible to see the .conf files and SIP/debug logs for a successful call? Thanks! Alex By: dea (dea) 2006-11-29 11:16:04.000-0600 Alex, you posted on 11/23 that you uploaded a new log name t38_day2.txt, but it is not attached to this bug.  Did it get added to the wrong bug? From the other reports, I think we have made good progress, and I'd like to see if we can figure out your '488' issue. Thanks. By: Alex lake (alexlake) 2006-12-01 03:29:56.000-0600 Sorry - I could have sworn that I did, but must be deluded. I'll arrange a fresh one.... By: Alex lake (alexlake) 2006-12-01 03:54:37.000-0600 T38-01Dec06-001.log now uploaded. It would appear that the Cisco is issuing the INVITE but without a media stream that Asterisk can do anything with. Perhaps I need to add something to the "allow" bit of sip.conf or else get the carrier to modify the way in which the Cisco is configured? Either way, a log (and sip.conf) from a good T38 reinvitation (SOMEONE must have one!!!) would be a very useful point for comparison. By: Alex lake (alexlake) 2006-12-01 03:56:46.000-0600 BTW - where is the best documentation for T.38 in Asterisk? By: Serge Vecher (serge-v) 2006-12-01 10:20:51.000-0600 alexlake: it's useful to see what asterisk is "thinking" with debug log enabled. Please reproduce per the following instructions: 1) Prepare test environment (reduce the amount of unrelated traffic on the server); 2) Make sure your logger.conf has the following line:   console => notice,warning,error,debug 3) restart Asterisk with the following command:   'asterisk -Tvvvvvdddddgc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands: set debug 4 set verbose 4 sip debug 5) Attach verbosedebug.txt to the issue. By: Alex lake (alexlake) 2006-12-01 10:57:28.000-0600 OK, although I note for reference that I had to use core set debug 4 core set verbose 4 sip set debug gamma-OUT File uploaded: vdebug_01Dec06.txt By: dea (dea) 2006-12-01 12:34:27.000-0600 I think this is related to your use of the Local channel. Following the log flow, the '488' error follows 'This Call is UP' in handle_request_invite().  We send a '488' in a number of situations, but the log flow points to a test to see if the target peer (bridgepeer) is using SIP for it's channel tech. At the point of the failure, I think that 442070605610 is set to Local and will fail. I think I can get you a small patch to test this, but if you can modify your dialplan to not use the Local channel for calls to/from 442070605610 we can prove or disprove this theory.  This is not suggested as a perminant change, just a debugging step, and will provide the same validation as a patch. By: Alex lake (alexlake) 2006-12-04 03:31:59.000-0600 OK -  vdebug_04Dec06.log now uploaded which shouldn't be using the local channel. ATTENTION!!! It would appear that this log is unreliable. I'm going to do another one... By: Alex lake (alexlake) 2006-12-04 04:06:12.000-0600 Just an interim progress report - it does get further with the non-local dial. There is still a problem but it looks like it might not be anything to do with Asterisk. Will report more progress later. Cheers! By: Serge Vecher (serge-v) 2006-12-04 09:30:54.000-0600 Dan: do you want to attach the small patch you've mentioned for testing purposes? By: dea (dea) 2006-12-04 11:11:56.000-0600 Serge-v,    The small patch would be just to add new LOG_DEBUG statements where I think the code is triggering the '488', and would not change the behaviour, which is why I suggested that Alexlake try without using the Local channel (either would confirm the location of the failure). I'm going to look a little deeper at the current logging in chan_sip with regards to T38.  There are a number of conditions that trigger the same log/warning/error message which makes finding the exact location of the problem difficult. On a housekeeping note, Alex's issue is not NAT, and not really related to the Cisco endpoints like his original bug-report.  This bug and 7679 appear to be resolved with OEJ's recent fixes in branches/1.4 and Trunk. By: Alex lake (alexlake) 2006-12-04 11:17:06.000-0600 Not going through the Local channel does resolve my issue. I have a slight problem that I'm trying to keep both tickets updated and this one is not really relevant. So I'm going to focus on my own issue 8387! By: Serge Vecher (serge-v) 2006-12-04 11:23:56.000-0600 DEA: thanks for the update. Can we please get a confirmation that oej's fixes 1.4 svn r > 48199 have fixed the original issue? By: dea (dea) 2006-12-04 11:58:43.000-0600 I'll try to summerize the status from the three related t38 bugs (7844, 7679 and 8387) Issue 1-   SDP case sensitivity.  Some endpoints put UDPTL instead of udptl in the SDP offer (fixed) Issue 2-   RTP timeouts.  A re-invite to t38 after RTP was negotiated would cause the call to drop after the rtp timeout period (fixed) Issue 3-   Global T38 configuration inheritance.  T38 will only work if it is enabled in the [general] section of the config (not really fixed, but at least the requirement is documented) Issue 4-   T38 is only supported on SIP.  Use of other channels, including local, would trigger a 488 Unsupported.  I've attached a small patch to make it clear why the T38 setup was rejected. Reporters Cervajs(7844), Alexlake (8387), Loloski, Ivoc, Coppens_b. Marcelbarbulescu and Andrew all report success with recent code and the [general] section requirement. Reporter Ahsan(7679) has not confirmed success in his ticket or in 7844, but the other reporters have covered the same test case. By: Serge Vecher (serge-v) 2006-12-04 13:01:59.000-0600 excellent summary, DEA. Let's commit the little patch and close the reports ... By: Marek Cervenka (cervajs) 2006-12-04 18:08:15.000-0600 DEA: can you please sumarize which scenario is supported with current t.38 passthrough code a configuration? 1) ata1 - nat -asterisk- SAMEnat* - ata2   (*same subnet as ata1) 2) ata1 - nat -asterisk- ANOTHERnat - ata2   3) ata1 - nat -asterisk- NOnat - ata2 4) ata1 - NOnat -asterisk- NOnat - ata2 from my testing ad 1) (both canreinvite=no) - works ok ad 3) fail (sip channels are packet2packet bridged) ad 4) (both canreinvite=yes) - works ok By: dea (dea) 2006-12-04 19:55:50.000-0600 cervajs,    Unfortunatly I cannot.  I don't have any T38 gear, so I have based all of my efforts on the posted logs and code review.    Your summary is about what I would expect, with case 3 being an unknown.  If you can post a log for such a session, I can review it.  I would hazard a guess that the packet2packet bridge does not work with udptl sessions, but that is a wild guess without looking at the code.  OEJ might have a couple thoughts on this point as I believe that he has had other problems with the packet2packet feature recently. By: Olle Johansson (oej) 2007-01-26 02:34:24.000-0600 ...busy actually testing t.38 stuff... By: Olle Johansson (oej) 2007-01-26 05:27:58.000-0600 Asterisk t.38 passthrough and NAT is severly broken, or I must be missing something critical. I get incoming UDPTL packets, but Asterisk does not send anything anywhere, just swallows them. I've spent many hours trying to figure this out now... I suspected the RTP bridge and disabled that to get the generic bridge going, but then I got channel locks when I had incoming RTP packets at the same time as chan_sip was trying to lock the channel for T.38 re-invite. Asterisk gave up with a "503 server error". This is bad. Who tested this before commit? By: hristo (hristo) 2007-01-27 12:11:19.000-0600 T.38 was working around 16-Nov-2006 (refer to note 54736 in issue 7679).  I'm pretty sure NAT tests were also ok at that time. A little bit later, after adding functionality to disable RTP timers with T.38 the swallow behavior appeared (as mentioned in note 55871/issue 7679). I don't know if RTP timers themselves introduced the swallow bug (I think it was present before that???) or if it was introduced by some other change at about the same time, but hopefully this will give you a clue where to look for the problem... By: ivoc (ivoc) 2007-01-29 11:58:10.000-0600 Tested using revisions in the range 47584-48215. UDPTL packet forwarding works fine up to revision 47625 /inclusive/. Seems the update after that caused the problem: ------------------------------------------------------------------------ r47628 | file | 2006-11-15 00:05:03 +0200 (Wed, 15 Nov 2006) | 2 lines Only keep the video RTP structure around if 1. Video support is enabled and 2. A video codec is enabled on the dialog ------------------------------------------------------------------------ By: dea (dea) 2007-01-29 13:13:32.000-0600 This code in sip_write() ~line 3504 looks fishy:     if (p->udptl && ast->_state != AST_STATE_UP)         res = ast_udptl_write(p->udptl, frame); The vrtp changes do not make sense as a cause, but the above test seems backwards.... By: Olle Johansson (oej) 2007-01-30 11:18:37.000-0600 DEA: yes, I spotted that part but when I labbed, we never used that part of the code. Thanks for all research, I'll try to look further into this during this week. By: dea (dea) 2007-01-30 12:50:11.000-0600 verbose_debug_no_UDPTL_r51360_wDEBUG.txt attached to 7679 provides a hint near the end of the log.  At timestamp Jan 24 10:36:59 we get an entry showing that we've returned from p2p bridging through ast_channel_bridge. And further examination shows we are going into p2p mode.  So what we need to do is when we get into a T38 re-invite we need to tear down the p2p and route the packets back through sip_read/sip_write Not that I know where or how to do that... By: Olle Johansson (oej) 2007-02-01 12:03:18.000-0600 - T.38 passthrough without re-invites, without NAT now works - T.38 passthrough with re-invites works, T.38 goes directly between two devices Tested with SIPura SPA 2100, latest 1.4 from svn. Please test with NAT. By: dea (dea) 2007-02-01 12:30:19.000-0600 Just a quick question, the only change in svn is the one I pointed out in post 0058432, are we sure that is enough? The reason I ask is that in sip_rtp_read() we return a NULL frame if the channel does not have RTP, but what if the call never negotiated RTP and went straight to UDPTL? Should the:   if (!p->rtp) be changed to:   if (!p-rtp && !p->udptl) By: Olle Johansson (oej) 2007-02-01 15:18:58.000-0600 - tested with NAT and it works. By: Olle Johansson (oej) 2007-02-01 15:19:53.000-0600 DEA: THe main changes was in rtp.c By: dea (dea) 2007-02-01 15:36:25.000-0600 Ah.  I see the addition frametypes added to the p2p and native bridge loops. That still leaves the question about the case where there is no RTP, and at a different level (philosophical, I guess) does it make sense to handle udptl bridging in rtp.c? These maybe questions better suited to the -dev list, so if a discussion is worthwhile I canask over there... By: ivoc (ivoc) 2007-02-05 02:43:42.000-0600 Works fine now. By: Joshua C. Colp (jcolp) 2007-02-05 10:26:08.000-0600 I'm comfortably that this issue has been fixed now, but if this is not the case please reopen. Thanks! DEA - I would take that to -dev, it's a larger issue then just T38.