Summary:	ASTERISK-14716: T38 passthrough errors in Asterisk 1.6.0.14-rc1
Reporter:	Berganz Francois (fcois93)	Labels:
Date Opened:	2009-08-25 10:41:20	Date Closed:	2011-06-07 14:08:14
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/T.38
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) issue-15779-log1.txt ( 1) log1.txt
Description:	hello, I am trying to do T38 passthrough my architecture: FAX-Asterisk-T38gateway the fax initiate call in g711 and after, invite again with T38. asterisk said at inviteT38: [Aug 25 17:32:30] WARNING[5198]: chan_sip.c:7025 process_sdp: Unsupported SDP media type in offer: image 8000 udptl t38 please help me how to do.
Comments:	By: Berganz Francois (fcois93) 2009-08-25 11:16:55 evolution: I added in sip.conf  t38pt_udptl=yes now, I have: [Aug 25 18:13:10] WARNING[5198]: chan_sip.c:6737 get_ip_and_port_from_sdp: Failed to read an alternate host or port in SDP. Expect audio problems [Aug 25 18:13:10] WARNING[5198]: chan_sip.c:17425 handle_request_invite: Failed to set an alternate media source on glared reinvite. Audio may not work properly on this call. I saw that I have a faxt38-SER-Asterisk-T38gateway the fax INVITE @SER the second INVITE is @Asterisk thats why asterisk reply that I think. but why? By: Berganz Francois (fcois93) 2009-08-26 02:23:42 Some news: Fax-asterisk-gatewayt38 Fax->* invite(g711) ... *->faxringing+200OK Fax->* invite(T38) * accept the T38 and reply trying *->* invite (t38) * find chan_sip.c:6737 get_ip_and_port_from_sdp: Failed to read an alternate host or port in SDP. Expect audio problems The problem is that asterisk generate an invite (t38) for himself with others parameters in the SDP Why? By: Kevin P. Fleming (kpfleming) 2009-08-27 11:16:07 I've recategorized this issue, changed its severity to 'minor' since it cannot be a blocking issue and moved your very long log to an attachment. I'd like to try to understand what your comments are saying, but your diagrams don't make much sense and the language barrier is obviously not helping :-) I'll review the log and see if I can figure out what is going on. By: Kevin P. Fleming (kpfleming) 2009-08-27 11:51:43 This log shows a failed T.38 reINVITE, because the peer that matches the incoming all (ser_sec1_g711) doesn't have t38pt_udptl enabled. Now that you've changed that setting, we'll need another log (uploaded as an attachment, please) showing the problem you are experiencing. By: Berganz Francois (fcois93) 2009-08-28 01:57:20 ser_sec1_g711 have t38pt_udptl enabled : [ser_sec1_g711] t38pt_udptl=yes type=peer qualify=200 disallow=all allow=ulaw allow=alaw host=217.64.X.X context=ser_sec insecure=invite canreinvite=yes nat=yes I will send you another log. but before, I had  T38gateway-sipProxy-Asterisk-sipProxy-Faxt38client now, I try with T38gateway-sipProxy-Asterisk-Faxt38client the fax is [gaia] type=friend disallow=all allow=alaw allow=ulaw dtmfmode=rfc2833 insecure=port canreinvite=no host=dynamic username=gaia secret=f... context=t38 nat=yes By: Berganz Francois (fcois93) 2009-08-28 02:03:06 I uploaded log1.txt I think that there is a problem between line 597 and 680. By: Kevin P. Fleming (kpfleming) 2009-09-01 15:32:59 Your Patton device is doing something incredibly strange: <--- SIP read from UDP://192.168.7.36:5060 ---> SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 192.168.7.40:5060;branch=z9hG4bK15b9df72;rport=5060 Record-Route: <sip:0.0.0.0;lr=on;ftag=as318313ba> From: "gaia" <sip:gaia@192.168.7.40>;tag=as318313ba To: <sip:0143620918@192.168.7.36>;tag=1880379773 Call-ID: 2177e0776ef133741b8423691ce29b5f@192.168.7.40 CSeq: 102 INVITE Contact: <sip:0143620918@192.168.8.40:5060> Server: Patton SN4961 4E30V 00A0BA04A020 R5.3 2009-01-15 H323 RBS SIP M5T SIP Stack/4.0.28.28 Content-Length: 0 See the Record-Route header there? It has a bogus IP address, and thus when Asterisk later tries to send a T.38 re-INVITE to that device, it fails because the INVITE is sent to the wrong address... and Asterisk receives its own invite, and the call falls apart. By: Berganz Francois (fcois93) 2009-09-02 08:23:55 I have a look thank you By: Leif Madsen (lmadsen) 2009-09-22 08:58:37 I'm closing this issue for now as it appears to be an issue with the end-device in use, and not so much an issue with Asterisk. If this is incorrect, then someone can reopen this issue, including the original reporter. Thanks!