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
