[VoiceOps] T38 over Sip
juna at is.co.za
Fri Aug 28 09:16:52 EDT 2009
Changing the codec to g711 has taken the "failure to train" error out,
if a single page is faxed it works!....if multiple pages are sent, only one
and a half pages of say three pages are received
On 2009/08/28 2:32 PM, "Alex Balashov" <abalashov at evaristesys.com> wrote:
> The call path is a little confusing (why is there an INVITE from
> 126.96.36.199 -> 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:
>>>> 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?
>>>> Please note: This email and its content are subject to the disclaimer as
>>>> displayed at the following link
>>>> 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
>> Please note: This email and its content are subject to the disclaimer as
>> displayed at the following link
>> Should you not have Web access, send a mail to disclaimers at is.co.za and a
>> copy will be emailed to you.
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.
More information about the VoiceOps