Summary:	ASTERISK-09073: Problems
Reporter:	Badalian Vyacheslav (slavon)	Labels:
Date Opened:	2007-03-22 06:22:18	Date Closed:	2007-03-26 10:31:05
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Experement: Have 2 cisco (fax t38 fallback g711) and PAP2 (t38 not support) Try send fax: E1 <- CISCO1 (t38pt_udptl=no) <- * <- PAP2 (t38pt_udptl=no) - OK E1 <- CISCO1 (t38pt_udptl=yes) <- * <- PAP2 (t38pt_udptl=no) - FAILED (* try do t38, but it know that pap2 not support it) E1 <- CISCO1 (t38pt_udptl=yes) <- * <- CISCO827(t38pt_udptl=yes) - OK Thanks
Comments:	By: Serge Vecher (serge-v) 2007-03-22 08:43:55 so what exactly is the problem? By: Serge Vecher (serge-v) 2007-03-22 08:44:21 always attach a sip debug for sip bugs! 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 -Tvvvvvdddddngc | tee /tmp/verbosedebug.txt' 4) Enable SIP transaction logging with the following CLI commands (1.4/trunk commands in parenthesis): set debug 4 (core set debug 4) set verbose 4 (core set verbose 4) sip debug (sip set debug) 5) Reproduce the problem 6) Trim startup information and attach verbosedebug.txt to the issue. By: Joshua C. Colp (jcolp) 2007-03-22 11:41:52 If the issue is that Asterisk does not fall back onto ULAW, then we already have an issue open for that. By: Badalian Vyacheslav (slavon) 2007-03-22 15:49:23 serge-v i say logic to reproduce bug. I don't have the fax and pap2 (its use clients), we use cisco phones that work normal. To debug i must ask client for help... bad idea... I see that if i turn on t38 support on all our cisco (for peer2peer connections) i have problems witch clients that try send fax from PAP2... on cisco all fax go normal =( i can do any realtime debug on system, but i can't do special test or reboot system...  i simple see bug in work time and ask to u that i see... if i can get any log - i get... sorry for my half-reports - but it all that i can do =( file - I think if Asterisk know that client have set t38support to yes or not, it must do this logic: Sender and reciver have t38pt_udptl=yes - do t38 Passthrough... If anyone have t38pt_udptl=no - do only g711 Passthrough... All work if both peer have turn on or off this option... why if one have ON and second have OFF asterisk try do t38 Passthrough? Asterisk know that is unreal (i say this then i set "t38pt_udptl=no" on one peer) p.s. All peers have canreinvite=no to do all witch asterisk as middle point. Thanks and sorry for my English ;) By: Grigoriy Puzankin (boroda) 2007-03-26 08:06:10 The problem occurs when you have ATA-devices with and without T.38 support. There's no way to send faxes between them. I agree with slavon that Asterisk should use at least G711 passthrough if one of SIP peers does not have T.38 support. If both ATA's support T.38 - then use it. The situation becomes more dramatic when I have SIP provider that supports T.38, but not all ATA-devices at my Asterisk support T.38. I can't use T.38 at all. When trying to send a fax between devices with "t38pt_udptl=no" and "t38pt_udptl=yes" Asterisk hangs up the call with message "chan_sip.c: Got error on T.38 re-invite. Bad configuration. Peer needs to have T.38 disabled." I'm using Asterisk 1.4.2. It's very easy to reproduce this behavior. By: Serge Vecher (serge-v) 2007-03-26 10:30:53 as file mentioned, this is already a known issue. Please track the progress in 8677. Thanks for reporting.