[VoiceOps] T38 over Sip

[Alex Balashov]

The call path is a little confusing (why is there an INVITE from 
196.38.232.2 -> 192.168.0.14 and then an INVITE back to the latter from 
the former?), but the basic problem seems to be that you the default 
voice codec set to G.729A.  This would explain why "training failed."

The way that T.38 setup works - at least, in the Cisco voice gateway 
world - is that the call is first established using a voice codec.  The 
DSPs on the receiving gateway analyze the acoustic content of the audio 
stream for fax tones and/or modem preambles ("listen").  If they are 
detected, the receiving gateway issues a re-INVITE and requests a switch 
to T.38 in its new SDP offer.

In order for this to happen, the frequency response of the codec must be 
sufficient to reconstruct the clear-channel PCM content of the bearer 
channel.  This is only possible with G.711u/A, which is little more than 
a packetised form of clear-channel 8 KHz PCM that carries the 3.1 KHz 
(300 Hz to 3400 Hz) bearer spectrum of a digital DS0 and/or a 
modem-grade analog line.

G.729A is a codec that uses some advanced compression techniques relying 
on CELP (Code Excited Linear Prediction).  Like many other compression 
schemes, it also shrinks the size of the data by referring via shorthand 
to elements of a waveform table/model that approximate the quantised 
value of a sample, but do not EQUAL it.  It's good enough for voice that 
humans don't see too much of a difference vs. clear-channel PCM, but for 
any sort of scheme reliant on the encoding of digital data into the 
acoustic content of the bearer, it will positively not work.

As a result, G.729A cannot be used for either the conveyance or 
detection of fax tones.  You need to switch this call to G.711u or 
G.711A (in Cisco, "g711ulaw" or "g711alaw") before the appropriate 
exchange can take place.  Hopefully, that should be all that is 
necessary to effect a switch to T.38.  Make sure the default audio codec 
for the call is G.711u/A END-TO-END (in all VoIP legs), so that no 
transcoding to/from G.729A occurs anywhere.

Of course, there are a variety of other issues that can be brought to 
bear on this scenario, but try that and see how it plays out.  One thing 
at a time.

Junaid Hattia wrote:

> So basically I cannot fax...attached is the wireshark trace
> 
> 
> On 2009/08/28 1:29 PM, "Alex Balashov" <abalashov at evaristesys.com> wrote:
> 
>> There are many things that could be wrong there.  Problem description is
>> not sufficient.
>>
>> Junaid Hattia wrote:
>>
>>> Howdy
>>>
>>> Ok so im trying to t38 over sip working with no luck
>>>
>>> My test lab is as follows:
>>>
>>> Pangea box connecting to a AS5400 via PRI, which then traverses an Acme
>>> Session director, broadsoft and then exits via PGW(SS7)
>>>
>>> The sniffer capture says ³failure to train²
>>>
>>>
>>> Any ideas?
>>>
>>> --
>>>  junaid
>>>
>>>
>>>
>>>
>>>
>>> Please note: This email and its content are subject to the disclaimer as
>>> displayed at the following link
>>> http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm.
>>> Should you not have Web access, send an email to
>>> mailto:disclaimers at is.co.za and a copy will be sent to you.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
> 
> 
> Please note: This email and its content are subject to the disclaimer as displayed at the following link http://www.is.co.za/legal/E-mail+Confidentiality+Notice+and+Disclaimer.htm. Should you not have Web access, send a mail to disclaimers at is.co.za and a copy will be emailed to you.


-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671