On 01/23/2013 04:32 PM, Carsten Maass wrote: > Hello all, > > we do have a problem here with Asterisk 11 talking T.38 to a t38modem > 2.0. The callflow is: > > ISDN PRI --> Berofix (10.1.1.150) --> Asterisk (10.1.1.148) --> t38modem > (10.1.1.148) --> Hylafax [1] > > Although the call gets connected, both parties are unable to negotiate > the audio codecs: > > [2013-01-23 21:59:57] VERBOSE[8805][C-00000000] chan_sip.c: Got T.38 > offer in SDP in dialog 237c0a65027630cd0c8bf2e70b5b3dc7@10.1.1.148:5060 > [2013-01-23 21:59:57] VERBOSE[8805][C-00000000] chan_sip.c: > Capabilities: us - (alaw), peer - > audio=(nothing)/video=(nothing)/text=(nothing), combined - (nothing) > [2013-01-23 21:59:57] VERBOSE[8805][C-00000000] chan_sip.c: Non-codec > capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x0 (nothing), > combined - 0x0 (nothing) > [2013-01-23 21:59:57] VERBOSE[8805][C-00000000] chan_sip.c: Got T.38 > Re-invite without audio. Keeping RTP active during T.38 session. > > which results in a "SIP/2.0 488 Not acceptable here" from the Asterisk > and the call gets disconnected. > > Asterisk full log with SIP trace is at http://pastebin.com/NNr6BTdp > > This looks a lot like > https://issues.asterisk.org/jira/browse/ASTERISK-15596 which doesn't > seems to be solved by now. > > Is this still a known issue in Asterisk 11? What can I do to make > Asterisk 11 play nice with t38modem v2.0? > > > Environment: > -------------- > Red Hat Enterprise Linux Server release 6.3 (Santiago) > > Linux myhost.mydomain.local 2.6.32-279.19.1.el6.x86_64 #1 SMP Sat Nov 24 > 14:35:28 EST 2012 x86_64 x86_64 x86_64 GNU/Linux > > T38Modem Version 2.0.0 > (OPAL-3.9.0/3.9beta0, PTLIB-2.9.0/2.9beta0 (svn:24165)) by Vyacheslav > Frolov on Unix Linux (2.6.32-279.19.1.el6.x86_64-x86_64) > > Asterisk 11.1.0 > Hylafax 6.0.6 > > > Thanx in advance and greetings, > Carsten. >
I don't think it's the same issue. In that issue, it looks like T.38 negotiation never succeeded - which isn't the case in your call flow. In your posted log file, the call flow looks something like this: 10.1.1.150:5060 Asterisk 10.1.1.148:6050 INVITE w/ audio ----> <----------- 100 INVITE w/ audio -----> <----------- 180 <-------------- 100 <-------------- 180 <----------- 180 <------------ 200 w/ audio ACK ----------------> <-------- 200 w/ audio ACK ----------> <------------- INVITE w/ image only 100 ------------> <------------ INVITE w/ image only 100 ----------> 200 w/ image -> <------------ ACK 200 w/ image -------> <------------ ACK At this point, everything is okay - the fax session has been negotiated successfully. Unfortunately, at this point, the endpoint at 10.1.1.148 decides to send *another* SIP re-INVITE with image only. I can only surmise that it didn't like the negotiated SDP we sent it: Asterisk 200 OK to re-INVITE #1: m=image 4588 udptl t38 a=T38FaxVersion:0 a=T38MaxBitRate:14400 a=T38FaxRateManagement:transferredTCF a=T38FaxMaxDatagram:399 T38Modem re-INVITE #2: m=image 5002 udptl t38 a=recvonly a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF Either it really doesn't like the BitRate/Datagram attributes, really wants to be receive only, or just decided to send yet another re-INVITE. Anyway. Asterisk wasn't a fan of this re-INVITE. So we send a 488. And the T38Modem keeps on trying it, until finally the session times out and 10.1.1.150 terminates the whole thing. Is this a bug in Asterisk? Without a full pcap, it's hard to know for sure. There are some ways in which Asterisk will determine that it's not going to be able to support the T.38 negotiation. If nothing else, the fact that the endpoint continued to offer the exact same SDP in various re-INVITE requests and ignored the negotiated offer isn't a good sign that Asterisk would be able to do much to appease it. -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users