[asterisk-users] Asterisk 11 with t38modem 2.0: "488 Not acceptable here"

[Matthew Jordan]

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 at 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