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