Summary:	ASTERISK-07398: Support for t38 only call
Reporter:	Dave Hindmarsh (niteowldave)	Labels:
Date Opened:	2006-07-25 19:27:24	Date Closed:	2011-06-07 14:02:52
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 070806_t38.log ( 1) msg.t38.002-trim.cap ( 2) sip-t38.txt
Description:	When an t38 ATA invites with t38 only in the initial SDP asterisk does not create a channel for the call as there is no audio capability.  Asterisk returns a Not Acceptable Here message. Asterisk seems to totally skip over the t38 code even though it has correctly worked out that the request contains a valid t38 jointcapability. The advantage as I see it to using this method, ie, t38 in the original call setup is that there is no re-invite required and hence the ATAs can be behind a NAT. I have tested the ATAs with SER and the t38 call goes through correctly.
Comments:	By: Dave Hindmarsh (niteowldave) 2006-07-31 20:56:31 Upon further testing I noticed that when the invite comes to request the T.38 switch over it only contains the t.38 capabilities.  There is already a channel up for the call using the audio codec previously negotiated. Asterisk seems to discard the previously negotiated capabilities of audio and rejects the call because no audio capabilities were offered in the t.38 invite. Asterisk recognises the channel associated with the invite has already been established but instead of adding the t.38 capability to the already negotiated audio capability it tries to set up a completely new set of joint capabilities which of course don't include any audio capability as none was offered in the t.38 invite request. Is it possible to add the t.38 capability to the already negotiated capabilities so that asterisk can complete the invite as there would be a joint capability of the previously negotiated audio capability along with the new t.38 capability thet was offered in the re-invite request. By: Ahsan Masood (ahsan) 2006-08-07 06:04:23 I am using the trunk version and using two sipura2100 for T38 Passthrough test. Asterisk is showing NOTICE[19447]: chan_sip.c:4859 process_sdp: No compatible codecs, not accepting this offer! I have attaced the SIP logs(0806_t38.log). By: Ahsan Masood (ahsan) 2006-08-07 06:12:11 I haved tested both sipura with SER and outbound proxy for T38 and it worked. I have attached the working SIP log(msg.t38.002-trim.cap By: Serge Vecher (serge-v) 2006-08-07 10:06:55 ahsan: please follow these instructions to make SIP logs with DEBUG-enabled (like niteowldave's)   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: Olle Johansson (oej) 2006-08-07 10:44:11 The current design of the T.38 support does not support this call setup. Thus we have to treat this issue as a feature request. I agree that it should be possible, but can't classify this as a bug in the code. This may be worked on after the 1.4 release. By: Ahsan Masood (ahsan) 2006-08-07 10:57:55 Thanks for replying. I have just uploaded the 2nd logs as it might be useful. With current asterisk trunk version, I am unable to get T38 Fax working. I have two sipura 2100 registered as a Sip extension and I am unable to get asterisk T.38 working. I have tested Sipura -> SER -> Cisco media gateway and it worked. I can help in testing asterisk T.38 and Cisco gateway as well. My current sip.conf has following in default context t38pt_udptl=yes t38pt_rtp=no t38pt_tcp=no and Extensions are as [200] type=friend dtmfmode=rfc2833 context=default host=dynamic callgroup=1 pickupgroup=1 username=200 secret=002 allow=all ;allow=ulaw canreinvite=no callerid=Reception <200> accountcode=200 trustrpid=yes t38pt_udptl=yes t38pt_rtp=yes t38pt_tcp=yes [201] type=friend dtmfmode=rfc2833 context=default host=dynamic callgroup=1 pickupgroup=1 username=200 secret=002 ;disallow=all allow=all accountcode=201 canreinvite=no trustrpid=yes t38pt_udptl=yes t38pt_rtp=no t38pt_tcp=no Please let me know if I can help in any way with testing. Regards, Ahsan By: Serge Vecher (serge-v) 2006-08-07 11:02:48 ahsan: if you can narrow down your issue down to not being able to establish a T.38 passthrough call between two Sipuras, then please open a new bug report with SIP Debug logs attached. By: Dave Hindmarsh (niteowldave) 2006-08-07 19:03:10 Ashan, did you end up getting this to work or raise a new bug report for getting the Sipura 2100s to work together. By: Ahsan Masood (ahsan) 2006-08-08 03:15:25 I have created a new ticket 7679 with all the details. By: Serge Vecher (serge-v) 2006-08-08 08:53:18 changing severity to feature and leaving report open for now until the development team has made a final decision on this issue. Right now, this is borderline feature-bug. Any interested parties can tip the scales in favor of "positive" resolution by producing a patch based on current trunk or funding work by means of a bounty. Thanks By: Gert (breezzboss) 2006-08-18 07:01:07 Ashan, I am working with a platform using Cisco 5350 - SER and can't get a successful incoming fax completed from PSTN via Cisco to Sipura 2100. I would appreciate you support By: Serge Vecher (serge-v) 2006-08-18 08:22:27 breezzboss: please do not use the bug-tracker to solicit support. Either email the asterisk-users mailing list, join the #asterisk channel on IRC or hire a consultant. Thanks. By: Joshua C. Colp (jcolp) 2006-08-30 11:50:11 I'm suspending this for now as it would require some interesting modifications to make it work. The Asterisk core expects audio to exist in some form at the beginning. We will probably revisit this in the future though.