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 a mail to disclaimers at is.co.za and a copy will be emailed to you.
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
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
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.
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
Alex Balashov wrote:
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.
Side note: Actually, G.711 - and indeed, standard DS1 digital PCM bearer channels - do some "rounding" too. It's called logarithmic companding. The type of logarithmic companding is indicated by the "mu" (uLaw) or A suffix. The basic idea there is that the more median portion of the spectrum of human vocal capabilities is expressed with closer fit, but the more outlying portions more approximately, with deltas in the "steps" that grow as a logarithmic progression. This is why hold music sounds very lopsided on a phone - even without the fancy variable bit-rate and adaptive codecs used by mobile equipment. Some parts of it are very obviously clearer than others. The other - and perhaps even more significant - reason is the 3.1 KHz total bearer spectrum. Good human hearing tops out at about 20 KHz. Most music relies a lot on the higher range - certainly, well above ~3 KHz. However, T.30 terminals (fax machines) were designed to work with this logarithmic companding in mind. Companding is not the same as "vicious compression." It's roughly the same difference as between a raw PCM WAV rip of a song from an audio CD, and the MP3 format. The latter gets you upwards of 10:1 compression ratio without significant loss from the point of view of human subjectivity, but if you're trying to encode any data into the analog signal, forget it. -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Also, all this T.38 magic applies to V.21 (14.4 kbps) faxing. As Scott Berkman can attest - we were mutually involved in a rollout related to this some months ago - the Cisco T.38 implementation doesn't support relay at Super G3 (V.34) speeds, nor does it detect Super G3 preambles properly in order to attempt a switch to T.38 at any relay speed. Have fun with that. :-) -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Thanks Alex Changing the codec to g711 has taken the "failure to train" error out, The result: 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 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.
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.
Junaid Hattia wrote:
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
Yep, well, that's generally where the other problems I alluded to crop up symptomatically. This is a complex - and, even more importantly in the case of T.38 and anything fax-related, a multi-vendor - call path. 1) Where is the fax being sent from? a) Is it a Super G3 fax machine? b) Have you ruled out the possibility of interference and/or poor PSTN service quality on the sending side? c) Does wherever you're sending from consistently work fine if you send to a conventional fax machine on your side? 2) Have you verified that the switch to T.38/UDPTL actually takes place, with a packet capture? Or does it stay G.711? It may be that the data is being exchanged using G.711u analog pass-through, which is the mode in which things stay if T.38 cannot be negotiated between all the media endpoints, and/or if fax tones are not properly detected because the sender is SG3, and/or similar situations. Analog pass-through will work, to some extent, but not over anything less than a very, very well-engineered IP network from a QoS standpoint. Even then, with all the media traversal steps involved here, I don't know that the reliability issue can be overcome for analog pass-through. T.30 is exponentially more sensitive to jitter and even the slightest bit of packet loss than voice; a little QoS issue will cause a faint (and perhaps not audible) crackle in speech, but it'll cause bits to be flipped or missing in modulated digital data. :-) And fax was built for the PSTN and synchronous transport, not at all designed to be resilient to this packetisation business. -- Alex -- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
Next time you include a capture, don't include your telnet session where we can see you log in. A simple "port 5060" when you start the capture will prevent this. Anyways, if you don't see something like this: m=image 16002 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38MaxBitRate:14400 a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:72 in the SDP section, T38 is not attempting to kick in. Lee Riemer - Director IP Voice Bestline Communications, L.P. 512.328.9095 Voice 512.328.0038 Fax 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. ------------------------------------------------------------------------
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
We are only experiencing problems when trying to send multi page faxes, when sending single page faxes it completes successfully. Please see the attached sniffer traces, they include calls with both single page and multipage faxes over T.38 with ecm disabled and the G711ulaw It would seem that no data is transmitted after the MPS message Pleasee see below the fax configuration voice service voip fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none sip ! ! voice class codec 1 codec preference 1 g711ulaw dial-peer voice 1 voip description sip fax test translation-profile outgoing voip destination-pattern 0T voice-class codec 1 session protocol sipv2 session target ipv4:192.168.0.14 incoming called-number 0873514633 fax-relay ecm disable fax protocol t38 nse force ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw ! dial-peer voice 2 pots tone ringback alert-no-PI destination-pattern 0873514633 direct-inward-dial port 6/0:D forward-digits all ! Looking at the trace I'm concerned about the t38:t30- No-signal messages On 2009/08/28 6:13 PM, "Lee Riemer" <lriemer at bestline.net> wrote:
Next time you include a capture, don't include your telnet session where we can see you log in. A simple "port 5060" when you start the capture will prevent this.
Anyways, if you don't see something like this:
m=image 16002 udptl t38 a=T38FaxVersion:0 a=T38FaxRateManagement:transferredTCF a=T38FaxFillBitRemoval:0 a=T38FaxTranscodingMMR:0 a=T38FaxTranscodingJBIG:0 a=T38MaxBitRate:14400 a=T38FaxUdpEC:t38UDPFEC a=T38FaxMaxBuffer:200 a=T38FaxMaxDatagram:72
in the SDP section, T38 is not attempting to kick in.
Lee Riemer - Director IP Voice Bestline Communications, L.P. 512.328.9095 Voice 512.328.0038 Fax
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> <mailto: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.
_______________________________________________ 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.
Attached is a call flow.... The basic prolem is that a fax call cannot be completed... 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.
participants (3)
-
abalashov＠evaristesys.com -
juna＠is.co.za -
lriemer＠bestline.net