[Home]

Summary:ASTERISK-09126: T.38 passthrough fails if caller offers T.38 in the initial INVITE
Reporter:thdei (thdei)Labels:
Date Opened:2007-03-28 04:54:37Date Closed:2007-12-06 10:16:02.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) fax.txt
( 1) verbosedebug-not-work.txt
( 2) verbosedebug-not-work-mot-important-line.txt
( 3) verbosedebug-work.txt
Description:I have this configuration :
Fax1 <-> HT488 <-> Asterisk <-> Patton 4524 <-> Fax2

If I call from Fax1 to Fax2, it works but if I call Fax2 to Fax1, it doesn't work at all, even with a normal call.

In fact, the Patton give in the SDP message codecs G729,PCMA,PCMU and T.38 and Asterisk always take the T.38 codec directly. The T.38 is normally not take in first...
Comments:By: Serge Vecher (serge-v) 2007-03-28 08:39:31

As per bug guidelines, you need to attach a SIP debug trace illustrating the problem. Also, do the same for the working call, so we can compare. Please do the following:
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: thdei (thdei) 2007-03-28 09:19:57

Ok, done. Sorry


By: Serge Vecher (serge-v) 2007-03-28 09:34:47

ok, please post the sip.conf [general] section and peers/friends involved.
By: thdei (thdei) 2007-03-28 10:25:52

[general]
context=default    
bindport=5060          
bindaddr=0.0.0.0          
srvlookup=yes          
disallow=all        
allow=g729
allow=gsm                  
allow=alaw
dtmfmode = rfc2833          
rtcachefriends=yes
rtupdate=yes
language=en
tos=184
notifyringing=yes
t38pt_udptl = yes

and the phone is 0625037902 in db with normal parameters
By: Serge Vecher (serge-v) 2007-03-28 10:51:33

the difference between non-working and working scenario is that caller offers T.38 parameters upfront in former. From what I remember, the known working scenario is to rely on reinvite.
By: thdei (thdei) 2007-03-28 11:47:56

Yes, I'm agree, it's just because the patton give the T.38 in the SDP message.
But ... I didn't find a solution for this problem from Patton side or Asterisk side.On the patton side, I am not able to not send the T38 in sdp messages without disable all T38 connection. On the Asterisk side, i'm not able to priorize the codec or just disable the T.38 for the first communication.

Normaly, it's only after a reinvite methode that the communication become in T.38 and so, why the asterisk allow a T38 codec with the first communication ?


By: Digium Subversion (svnbot) 2007-12-06 10:11:43.000-0600

Repository: asterisk
Revision: 91439

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r91439 | file | 2007-12-06 10:11:42 -0600 (Thu, 06 Dec 2007) | 4 lines

Add support for accepting and sending T.38 in the initial INVITE.
(closes issue ASTERISK-9126)
Reported by: thdei

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

http://svn.digium.com/view/asterisk?view=rev&revision=91439
By: Digium Subversion (svnbot) 2007-12-06 10:16:02.000-0600

Repository: asterisk
Revision: 91440

_U  trunk/
U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r91440 | file | 2007-12-06 10:16:01 -0600 (Thu, 06 Dec 2007) | 12 lines

Merged revisions 91439 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r91439 | file | 2007-12-06 12:14:26 -0400 (Thu, 06 Dec 2007) | 4 lines

Add support for accepting and sending T.38 in the initial INVITE.
(closes issue ASTERISK-9126)
Reported by: thdei

........

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

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