This discussion is locked


Unanswered Question
Nov 18th, 2010

Join Cisco expert David Hanes, a technical leader in Customer Advanced Engineering who is CCIE certified and the coauthor of the book "Fax, Modem, and Text for IP Telephony" as he covers the Cisco fax technologies over IP. He is a technical expert in the area of fax over IP technologies and assists with network design and troubleshooting for critical fax over IP deployments.  Since joining Cisco in 1997, he has worked as a Technical Assistance Center (TAC) engineer for the WAN, WAN Switching, and Multiservice Voice teams, a team lead for the Multiservice Voice team, and an Escalation Engineer covering a variety of voice and fax technologies. He holds a bachelor of science degree in electrical engineering from North Carolina State University and CCIE certification #3491.  This Ask the Expert session will guide you through the T.38 design best practices and will give you the knowledge to make sure that your T.38 integrations and designs are successful. The T.38 protocol has emerged as the de facto standard for transporting fax traffic in unified communications networks. However, to get the most from T.38 and deploy it effectively, certain design best practices must be followed.

Remember to use the rating system to let David know if you have received an adequate response.

David might not be able to answer each question due to the volume expected  during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through December 3, 2010. Visit this forum often to view responses to your questions and the questions of other community  members

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (6 ratings)
mikewhitton Fri, 11/19/2010 - 04:36

Which software based modem do you recommend for use with a fax server?  I am currently researching the implementation of a new fax server using T.38 via HylaFax and t38modem with Cisco Hardware and H.323 gateway.

Also, where can I see the video of this presentation?


mikewhitton Fri, 11/19/2010 - 04:36

Btw, I purchased a copy of your book, it was quite nice...

sergesandler Mon, 11/22/2010 - 20:56
/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;}

There are numerous software solutions apart from T38modem with Hylafax, e.g. Cisco Fax Server (RightFax); XMedius from; SatisFAXtion Fax Server from; FaxVoip from among others.

It is interesting to know which of those products were tested for T.38 interoperability with Cisco gateways.

Most of those solutions implemented as Exchange connector/ Fax Server would compromise real-time fax experience from the end user point of view, so it is not the same as connecting fax machine via T.38-capable ATA.

Michael Hanes Tue, 11/23/2010 - 06:17

Hi Mike,

In regards to a software based fax/modem, I had had pretty good luck with just about all class 2.0 and above devices. I have not performed a lot of testing in this area so your mileage may vary but I would not expect you to encounter any problems related to a class 2.0 modem when its communications are transported over T.38.

The recorded version of my T.38 webcast will be posted here -

I do not see it here yet so I will follow up and try to get an idea of when exactly it will be available.

Also, thanks for the positive feedback about the book. I am glad that you like it and I hope that you continue to find it useful.



Sergio Ricardo ... Fri, 11/19/2010 - 05:53

Hi David,

Are you answering Cisco Fax Server design questions too?

I'd like to know, regarding Cisco Fax Server integrated to a Cisco UC solution with CUCM and Cisco h323 gateways, What are the possibilities to create a AutoAttendant solution that could ask to the originator caller the destination user fax number?

The second question is, in a centralized Cisco Fax Server design What should be the fax protocol for remote gateways that use low codec for voice as G729?

The last questios is What is the recommended type of integration with IBM Domino?

Thanks in advance, Sergio.


manipandey Sun, 11/21/2010 - 10:28

Hi David,

It's nice to see that there is a special session for FAX over IP. I met you in Person at Cisco Networkers 2010@Vegas and also gone multiple time the great book written by you.

Issue (Refer-Open SR-616076263 specific to the FAX call over IP using CUBE setup).  :

1st- With VG224, fax is working but I am clueless how the Fax call is using end to end G728r Codec and the calls are happening as normal Voice Call. Can't see the change between call starting as voice and going to FAX specific setup. Guess is that by default ISR has FAX relay enabled and this call is using the same relay setup.

Looking for a step by step way of debug commands and sh command and what to look for in those debug which will show the call flow. I used debug voip ccapi inout but really can't make out the difference between Voice and a Fax call. It's confusing.

2nd case, I have one ATA connected to remote 2 site and in that case only one way Fax is happening i.e Fax from HQ to  ATA connected FAX is happening but other way around that is From ATA connected FAX to HQ PBX fax is not happening. It may be an issue with the FAX passthrough but instead of jumping to conclusion, aim of this Q is what the best step of troubleshooting a FAX call.



Michael Hanes Tue, 11/23/2010 - 08:06

Hi Mani,

Thanks for the positive feedback on the book and thanks for attending our session at Cisco Live!

Viewing a complete FoIP call flow can be confusing. The output from debug voip ccapi can be helpful if you are used to reading this debug and know what to look for. Probably the most comprehensive tool is a Wireshark capture and then you can definitely see what is happening in regards to codec switchovers and so forth.

On the voice gateway, there are some show commands that help you confirm that a codec switchover has occurred and what codecs are being used for the call:

1) The show call active voice brief command provides the most information but you may have to parse through a few pages of call legs and do some CLI filtering if you have a lot of calls occurring at once. Here is an example of show call active voice brief output displaying a g729 voice call -

126C : 58 11411290ms.1 +10520 pid:1 Originate 200 active

dur 00:00:08 tx:112/2154 rx:307/6092

IP SRTP: off rtt:1ms pl:5930/0ms lost:0/0/0 delay:60/60/70ms g729r8

This same call switches over to G.711 when fax tones are detected and you can see the new codec being displayed

126C : 58 11411290ms.1 +10520 pid:1 Originate 200 active

dur 00:00:41 tx:1677/252554 rx:1953/258112

IP SRTP: off rtt:4ms pl:40/0ms lost:1/0/0 delay:60/60/60ms g711ulaw TextRelay: off

  media inactive detected:n

2) You can also use the command show voice call summary. Here is an example where the codec shows T.38:

Router#show voice call summary

PORT           CODEC     VAD VTSP STATE            VPM STATE

============== ========= === ==================== ======================

0            t38        n   S_FAX                 FXSLS_CONNECT

3) The command show voice call status also shows the codec during a call. In this example the T.38 fax speed is shown but voice/passthrough codecs are also displayed:

Router#sh voice call status

CallID CID  ccVdb      Port Slot/DSP:Ch  Called #   Codec    MLPP Dial-peers

0x2B   124D 0x86E26350  0        0/1:1   5000       14400           1/2

1 active call found

You can repeat the commands above throughout the call and watch the codec settings. This will allow you to determine if switchovers are occurring or not without having to resort to packet captures or debugs.

In regards to troubleshooting your ATA problem, the simplest troubleshooting methodology for FoIP is to first confirm that the initial voice call is set up between the two endpoints. In many cases, this can be easily accomplished by picking up the handset on fax devices and having a conversation. Or you may need to look at a packet capture or the commands listed above. Once you have confirmed that this initial voice call is setting up correctly, then you need to confirm that a proper switchover is occurring. In the case of the ATA186, only an NSE-based passthrough switchover is supported. So you need to make sure that this is configured on the remote device (IOS command modem passthrough under dial peer) and that the NSE messages are being exchanged correctly. You can also confirm again with the show commands above. If the voice call and switchover are all occurring, and faxes are still failing then you need to start investigating the fax media stream for corruption or T.30 negotiation problems. I hope this helps.



manipandey Tue, 11/23/2010 - 19:02

Thanks David for your explanation. I was following all the command mentioned in your reply but may be I have to try that throughout the call duration and hope I will be able to find something.

One more clarification:

Whether Clear Channel and T.38 setup for fax transmission co-exist? If yes, then what's the required configuration and what will be the call behaviour? Sometime there are scenario where you have VG224 and ATA's and that makes things little confusing.

Also, any specific design for a scenario where there exist two setup

A normal fax setup which can work with T.38 and

on the other hand, stand-alone secure fax machines which are having a hardware based secure device attached and can't tolerate any change with digitiged FAX media throughout the FAX transmission. I read it in your book regarding Clear Channel or hair pinning but not sure how to achieve it?

any pointers?


Michael Hanes Wed, 11/24/2010 - 06:40

Hi Mani,

Yes, you will need to repeat those commands throughout the call and then you can notice any switchovers/codec changes.

The term "clear channel" is defined differently depending on who you talk to. I have spoke with some who ue this term instead of passthrough using the G.711 codec. Cisco also has a clear channel codec where the DSP performs no signal manipulation (levels, echo cancellation, etc.). I have also seen the term referred to specifically for TDM hairpinning across the backplane of ISR voice gateways. Can you confirm exactly what you mean by "clear channel" because it is not clear to me and I want to make sure I give you the answer that you are looking for?

When you mention T.38 and "clear channel" together then it makes me think that you are talking about having passthrough or the clear channel codec running simultaneously with T.38. I have never run faxes over the clear channel codec as G3 faxes need echo cancellation enabled but if you are referring to passthrough then this can be run with T.38. Specifically you will need to run NSE-based passthrough ("modem passthrough" in IOS configuration). You can configure NSE-based passthrough and T.38 simultaneously.

I have not worked with secure faxes but I am assuming that their transmission methods are similar to secure phones, which use a modem V.32 or V.34 modulation. This modem modulation can be passed via G.711. If the secure fax is actually a STE (Secure Terminal Equipment) then you may be able to implement Cisco's secure modem relay feature to pass the traffic -

If you truly need a "clear channel" for secure fax transmissions, then you can configure the clear channel codec under the voip dial peer if you must transport the call over an IP network. If you want to just pass the transmission between two telephony ports on a ISR then hairpinning is possible by simply routing via POTS dial peers. You will need to have both ports tied to the TDM backplane and the same clock source.


manipandey Wed, 12/01/2010 - 13:13


By clear Channel, I was referring a setup where Analog FAX machine is connected to ATA or VG and at the gateway level it's gets modulated and Demodulated and gets transmitted over IP media.IP Media is not doing any packet level changes and just passing whatever information it received without any add on to that information.

Looking for specific configuration and how well this can be scaled where CCM is acting as a calling agent and number of such FAX machine is around 100+ in total?

Thanks and regards


Michael Hanes Thu, 12/02/2010 - 08:32

Hi Mani,

I apologize but I am still a little confused by what you mean by clear channel. In your last post you mention that by clear channel you are referring to, "a setup where Analog FAX machine is connected to ATA or VG and at the gateway level it's gets modulated and Demodulated and gets transmitted over IP media". A modulation and demodulation process only occurs with a fax relay protocol like T.38. Are you talking about T.38 when you refer to clear channel?

You then mention in your next sentence about clear channel that "IP Media is not doing any packet level changes and just passing whatever information it received without any add on to that information." This makes me think that you are talking about passthrough now as the exact fax tones are digitized and simply passed over IP using the G.711 codec with passthrough and no changes are made at all to the fax messaging. Fax relay protocols like T.38 have the ability to manipulate the fax messaging and change negotiation speeds and the ECM setting.

Can you confirm if you are talking specifically about passthrough or T.38 when you refer to clear channel? You have also mentioned my book in previous posts. Is there a specific page or section that discusses what you are trying to accomplish?

I apologize again if I am missing something but I just want to be sure that we are both talking about the same thing. Once we get our terminology synchronized, I will be able to answer your question better about scaling 100+ faxes in a CUCM environment. The short answer is more than likely going to be that 100+ is fine. CUCM can easily handle that and much more with all of the various fax transport mechanisms. Depending on the fax transport mechanism, most limitations are on the voice gateway side.



manipandey Thu, 12/02/2010 - 11:34

Hi David,

Sorry for creating confusion but I myself is confused now about which solution will work for the following scenario which co-exist at all location :

1) Normal FAX call from point A to Point B without any external secure device - T38 FAX relay is the solution for this.

2) Analog Fax connected to a Hardware device doing Encryption and then connected to VG or ATA need to send the fax at the other end device which is connected the same way i.e VG/ATA and Encryption device then the FAX machine.

I haven't tested but I was told that it has been observed working over a Layer 2 connectivity or VPN but it was observed not working over an IP link.

So, my thought is- to have this working the only thing needed is :

After encryption device, the stream carrying FAX encrypted detail need to be received as is at the other end

What does that mean in my term is "that the IP media just act as transit path or carrier for the fax message and don't do any changes in the encrypted message"

I am not sure which solution will work for this and need to test out in detail.. At this moment it can be passthrough or T38 or tweaking the HairPin setup.

Though I am still trying to understand the Hairpin calls as stated in your book page 237(Chapter 7) and whether FAX server is necessary..The T1/E1 connection to the FAX server as depicted in the diagram can be a Voice Gateway at the other end of the WAN and in place of FAX server a FAX machine connected to it.



Michael Hanes Fri, 12/03/2010 - 08:09

Hi Mani,

Thanks for the clarifications. It looks like you have a few different scenarios that you are looking at. I agree that T.38 is your best bet for normal faxing between two endpoints across an IP network.

In your scenario with the encryption device, most people have the best luck with the modem passthrough feature on Cisco voice gateways. Most of the encryption devices that I have seen use a modem modulation and modem passthrough is your best bet for passing this type of information. There are different encryption methods and protocols so your mileage will vary but this is where I would start -

If this does not work you may want to try hard coding the dial peer to the clear channel codec and giving this a try. The clear channel codec does not make any changes to the bit stream and this may work better for some encryption methods.

In regards to a hairpin scenario, it is important to remember that the router is just connecting telephony ports. There is not a WAN involved but possibly a PSTN. The gateway is simply joining two POTS ports together and an IP connection is not involved. This would probably work for your encryption devices but I was under the impression that your locations were connected by IP. I hope this explanation makes sense.



Michael Hanes Tue, 11/23/2010 - 07:26

Hi Sergio,

Sure, I will be happy to address any questions that are FoIP related.

- The auto attendant solution that you describe is something that I have not seen implemented before but I see no technical reason that it would not work. After playing some sort of announcement asking the user to enter the destination fax digits, the auto attendant could then route the call to a fax server and ask the user to start the fax communication on their end. What I am not sure about is the capabilities of the auto attendant to perform this function as this is not a product I deal with regularly. From a faxing perspective I see no problems implementing this.

- The Cisco Fax Server (and all of the fax servers that I have worked with) require the fax call to initially negotiate with G.711 before switching over to T.38. Fortunately, this G.711 call only last for a few seconds (less than 2 seconds if I remember correctly from my last testing with the Cisco Fax Server). So, you just experience a small spike in bandwidth. Of course, once the switchover to T.38 (without redundancy enabled) is made then the bandwidth drops to around that of a G.729 call or a little less. You also may be able to transcode between G.729 and G.711 as well using CUBE before the T.38 switchover occurs.

- I have not performed a Domino integration with the Cisco Fax Server. Specific Cisco fax server questions such as this are usually best answered by the Open Text experts on the email alias



fatai.oyejobi Mon, 11/22/2010 - 10:11


I configured 802.1x on a 3560, then about an hour later, it started rebooting every 20 min.  I removed the switch from the stack and replaced it with another.  As I was about to log in to the switch, it won't take the passowrd anymore, and it keeps asking me for password each time I pressed "Enter".  How can I get back to the switch?

I will appreciate your help.


metalium2007 Mon, 11/22/2010 - 11:03

Maybe you could try the right thread for this question.

It is a little bit, just a little bit out of the context.

Thank you,


metalium2007 Mon, 11/22/2010 - 11:05


Im implementing a kind of transcoder device between Cisco Fax Relay and T.38.

You have the Cisco Fax Relay world then a gateway with two E1 interfaces and then T.38 world.

Cisco Fax relay world --->gatewayE1 1/0 ---->Virtual PSTN --> gateway E1 1/0 -----> voip to T.38 world

The gateway is the same with a back-to-back connection.

Is this a supported scenario?

Thank you.


Felipe Garrido Tue, 11/23/2010 - 07:16


The individual parts, Cisco Fax relay, back to back E1 and T.38, are supported configurations. I don't see any reason why this would not work. It's not the most ideal scenario, but it should still work.


Michael Hanes Tue, 11/23/2010 - 08:16

I agree with Felipe here that all of the pieces are supported and most of the instances that I recall where this has been implemented have been successful. I would just caution that you are adding extra delay in this solution as every IP to PSTN transition encounters a 300ms playout buffer delay. While this can be adjusted, this increased delay can impact the success rate of faxes if there is already a lot of delay in the fax path.



metalium2007 Wed, 11/24/2010 - 04:08

Hello David,

My topology is this one:

Fax connected to FXS in Cisco Fax relay in Gateway1 ---> voip -> gateway2 E1 1/0 ---->Virtual PSTN --> gateway2 E1 1/0 -----> voip -> Fax connected to FXS in T.38

When I send a fax from Cisco Fax Relay to T.38 call is getting disconnected 40 seconds with sending incomplete displayed in origin fax.

What can be the issue here? Can you help me?

Keep up the good work!

Thank you


Kenan Muharemagic Wed, 11/24/2010 - 04:26

hi met,

how do you loop a call from a voip dial-peer through an E1 PRI card and back to a voip dial peer?

metalium2007 Wed, 11/24/2010 - 05:32

Just basic dial-peer routing.

You receive the call...point it to E1 1/0. You'll receive it on  E1 1/1 then  you just point it to another voip dial-peer.

Some voice translation-profiles and rules and you've got it....

metalium2007 Wed, 11/24/2010 - 06:08

Hello David...

I think I solved my problem lowering the fax playout-delay to 100 ms on the voice-ports of my E1-back-to-back connection.

Can you please explain me the exact behaviour of this command?

Thank you!

Michael Hanes Wed, 11/24/2010 - 07:02

When dealing with VoIP and FoIP, jitter can be a problem. Packets can take different amounts of time routing through an IP network. The packets can take different paths and encounter different amounts of delay. Packets may even arrive out of order. Therefore, a playout buffer is used for VoIP and FoIP to store up a certain amount of packets to ensure that all have arrived before playing them out the telephony interface.

With VoIP a dynamic buffer is used that can change as network conditions change. However, when this buffer grows or shrinks, voice samples may be lost but this is not a problem for voice as it can tolerate a little loss. FoIP on the other hand is data and cannot tolerate any loss. So, the playout buffer cannot change and it must be static.

With T.38, Cisco sets the playout buffer to a fixed 300ms value. This is a large value and means that T.38 packets can handle network jitter up to 300 ms. Fax has a high tolerance for delay so creating a 300 ms playout buffer is usually not a problem and it prevents T.38 fax from being affected by jitter for the most part. It would be rare to have an IP network with more than 300 ms of jitter.

Occasionally scenarios occur where there are multiple IP to PSTN hops or satellite links and the delay starts to really add up. Every IP to TDM hop with Cisco voice gateways adds an additional 300 ms of roundtrip to delay. Performing the virtual PSTN E1 loop that you have increases round trip delay by an additional 600 ms. This is on top of the 600 ms you already have because of your endpoint voice gateways. You have now easily crossed the 1000 ms mark where fax may begin to have problems negotiating because of too much delay.

By reducing the playout buffer in both directions to 100 ms, you are cutting a total of 400 ms from the roundtrip delay of your fax call.This was obviously enough to bring down your delay budget enough for the faxes to negotiate. Most IP networks I encounter do not have more than 100 ms of jitter so this is more than likely a safe setting but you should realize that if jitter in your network goes above 100ms then your fax calls could start taking a long time to get through or start failing. Adjusting the playout delay lower for your T.38 traffic is not a problem as long as you do not set it below the amount of jitter in your network.

I know that this is a long answer but hopefully it provides the answer that you are looking for.


metalium2007 Wed, 11/24/2010 - 07:23

Thank you for your answer David. It's always a pleasure to talk with someone that know what we are dealing with.

I would just like to understand why faxes doesnt work with the default 300 ms fax playout buffer, and they start to work perfectly with a configured 100 ms fax playout buffer. Problem is solved, but I really would like to understand what is the issue.

Thank you!


Michael Hanes Wed, 11/24/2010 - 07:53

Let me see if I can clarify a little further exactly what is going on when your faxes failing with the 300ms setting. Fax machines exchange T.30 messages which need to receive a response by a certain timeout period defined by a T4 timer. This timer is around 3 seconds but in reality we have seen some devices use a shorter timeout period. The T.30 message negotiation that initially occurs when a fax call is being setup is timing out. Messages are exchanged by both sides but responses to these messages are not seen before the message is retransmitted. If you were to run a "debug fax relay t30 all-level-1", when your problem is occurring, you will probably see the critical DIS and DCS messages consistently timing out and being resent. Eventually, the fax endpoints give up trying to setup the call and they disconnect.

Once you lower the playout buffer size, and therefore the amount of delay between these fax endpoints, these T.30 negotiation messages are received in a more timely manner. The negotiation completes and the fax page is sent successfully.

Does the explanation above help you understand the issue a little better?


metalium2007 Wed, 11/24/2010 - 09:33

Hello David,

Thank you very much for your detailed description of the problem.

I won't bother you longer with this issue! (Just tell me where can I buy you a beer!)



Kenan Muharemagic Wed, 11/24/2010 - 01:58

Hi guys.

I have a question regarding T38 fax with Cisco ISR gateways.

Last few days i have been trying to get a T38 fax server (XMedius) to work over an ITSP SIP trunk without any success.

The setups is something like:

T38 Fax Server (XMedius) <--> SIP <--> Cisco2801 <--> SIP <--> ITSP

First of all is this a supported setup with a T38 FAX server and an ITSP SIP trunk?

For testing purposes i tried this using an analog phone line connected to an FXO port, added a pots dial-peer and the fax was working fine but for some reason it does not work through the SIP trunk.

I have attached the config and a debug output for reference.

Felipe Garrido Wed, 11/24/2010 - 07:30

The debug messages are getting rate-limited due to the collection method. Please enable logging to the buffer and collect the again. Add the following configuration,

no logging monitor

no logging console

no logging queue-limit

no logging rate-limit

logging buffer 2000000

service sequence-number

Next, enable the following debugs,

debug ccsip message

debug voip ccapi inout

use a telnet program that allows logging to a file.

Issue the clear log command.

Make the test call.

After the call fails, issue the following commands to retreive the debug output.

terminal length 0

show log

My guess, with the current debugs, is that the ITSP doesn't support t.38.


Felipe Garrido Wed, 11/24/2010 - 08:12

For inbound calls, the ITSP is sending a 488 media not acceptable when the re-invite for switchover to t.38 is sent. For outbound calls, the ITSP is never sending the re-invite to perform the switchover to t.38. This indicates that the ITSP does not support t.38.


Kenan Muharemagic Tue, 11/30/2010 - 07:15

Well some good news... in cooperation with the ITSP we got the FoIP to work.

Thanks for the help guys.

amirhuskic Fri, 11/26/2010 - 01:37
/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Navadna tabela"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}


I have question about T.38 fax and CUBE. Our setup is:

VG202 <-> SCCP <-> CUCM 7.x <-> SIP <-> CUBE 2821 <-> SIP <-> ITSP

Sending and receiving faxes worked for 2 weeks without problem. Last week it stops without reason. It isn’t possible to send or receive fax. Since begin configuration didn’t changed. Cisco TAC suggested to change SCCP between VG202 and CUCM to H323 but still doesn’t work. Is first setup supported and which one is the recommended? Thank you for your help.

Best regards

Michael Hanes Mon, 11/29/2010 - 13:14

Honestly I am not sure how your initial setup was working for T.38 fax to an ITSP as SCCP does not support standards-based T.38. Only NSE-based T.38 using a Cisco proprietary switchover is supported with SCCP and this would not be supported by the SIP ITSP. Possibly, the T.38 negotiation was failing and G.711 was being used. Is G.711 your voice codec from the VG202 to the ITSP?

The proper configuration here is to use H.323 or SIP on the VG202 instead of SCCP. Both the H.323 and SIP call control protocols support standards-based T.38 that is compatible with SIP ITSP connections. To troubleshoot this you would need to look at the H245 messaging for H.323 using debug h245 asn1 to confirm that the switchover to T.38 is occurring properly. You should see an H.245 Request Mode message being sent and acknowledged requesting a switchover for T.38.

Feel free to post your VG202 configuration and debug capture and I will take a look if you would like.



c.hennrich Mon, 11/29/2010 - 13:29


I have the same setup and I was looking for MGCP instead of SCCP as protocol for the VG224 and T38 with external ITSP. You say one should use SIP or H323 for this. So now my question, is MGCP also an option as long a I use CA controlled mode?

Many thanks!

Michael Hanes Mon, 11/29/2010 - 14:07

Yes, you are correct. I should have been more clear with my previous answer. H.323 and SIP support standards-based T.38 to an ITSP with or without a CA (like CUCM). MGCP only supports standards-based T.38 to an ITSP if a CA is present. In your scenario, with MGCP in CA-controlled mode, standards-based T.38 us supported to an ITSP.



amirhuskic Tue, 11/30/2010 - 07:28

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Navadna tabela"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

Hello David,

thank you for quick response. In attachment is VG202 configuration and incoming fax debug trace. On CUCM is configured H323 to VG202. Thank you for help and time.

Best regards,


Michael Hanes Wed, 12/01/2010 - 08:21

Hi Amir,

Looking at the "debug h245 asn1" messaging, you are encountering a problem switching over from G711alaw to T.38. For whatever reason the ITSP and the Cisco voice gateway are having an interoperability issue during this switchover process. The initial T.38 H.245 Request Mode message is acknowledged by the ITSP and the G.711alaw logical channels are closed but when the T.38 logical channels are being opened, the ITSP sends the following message -

Nov 30 13:30:54.219: H245 MSC INCOMING PDU ::=

value MultimediaSystemControlMessage ::= request : closeLogicalChannel :


      forwardLogicalChannelNumber 2

      source user : NULL


The ITSP has encountered an error of some sort and is requesting that the T.38 logical channel be closed right after it was opened. I did not see a T.38 parameter mismatch in the messaging so I am guessing that the ITSP may not be happy with the H.245 message flow or the order of the messages. In the past I have seen problems where some devices expect a certain message ordering as logical channels are opened and closed. Can you get a packet capture of this problem? This will make the message flow easier to see and also may highlight any message flow problems.

I did not see anything wrong with your configuration. If you can attach a packet capture I will take a look and see if I can figure out what exactly is happening. If I am not able to see why the ITSP is closing the T.38 logical channels, then you will need to contact your ITSP and provide them the packet capture to figure out why they are sending the message above before the T.38 fax call can complete.


amirhuskic Thu, 12/02/2010 - 02:16

/* Style Definitions */ table.MsoNormalTable {mso-style-name:"Navadna tabela"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0cm; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi; mso-fareast-language:EN-US;}

Hi David,

Yesterday I did some testing with different configuration settings. After on CUCM H323 GW to VG202 I disabled option MTP Required faxes start to working. Thank you very much for your help, time and support.

Best regards,


Michael Hanes Thu, 12/02/2010 - 08:45

Hi Amir,

I did not realize that you had an MTP in this call flow. There are issues sometimes with MTPs and transcoders being involved in FoIP switchovers. I am glad to hear that you figured this out and resolved your issue.



c.hennrich Thu, 12/02/2010 - 08:01


question about the ATA-187 and faxing, does the ATA support both flavors of T.38 (NSE based and protocol/standard based)? or just one?

I could not find a hint in the Cisco documentation:

Thank you!

With Best regards!

Michael Hanes Thu, 12/02/2010 - 10:33

The ATA187 supports standards-based or protocol-based T.38. From all of the information that I have seen on the ATA187, it does not support Cisco proprietary NSE-based T.38.



pompeo_marino Thu, 12/02/2010 - 08:33

Hi Davis,

we are implementing a FAX Server over IP connected via SIP to our Cluster Call Manager, the software is provided by IMECOM.

Our CUCM cluster is protected with a Checkpoint firewall (R65 HFA70) configured with voip domains, and it doesn't work with the fax server.

Do you have any suggestion or best practice guide?

Thanks in advance.


Michael Hanes Thu, 12/02/2010 - 10:15

I am not familiar with the IMECOM or the Checkpoint Firewall products so it is hard to know what problems you may be encountering. Here are a few suggestions:

- Make sure that you are using the G.711 codec. All of the fax servers that I have experience with only support this codec when setting up the initial voice call before transitioning to T.38. From an integration standpoint, this tends to be responsible for a lot of the problems.

- Does the IMECOM product use a Dialogic fax engine (like the SR140)? If so, the Cisco Fax Server product also uses a Dialogic fax engine and most of the design docs available for the Cisco Fax Server would be applicable to the IMECOM product as well.

- If you can get a packet capture of the failing fax call, I should be able to see what is happening at a protocol level and this might provide some additional information as to the cause of your problem.



letmeinnn Thu, 12/02/2010 - 08:42

T.38 and SR140 issue.

We are trying to get T.38 set up on our network and get rid of fax passthrough.

we used the following:

mgcp package-capability fxr-package
mgcp default-package fxr-package
mgcp fax rate 14400
no mgcp fax t38 ecm
no mgcp fax t38 inhibit

we can get a fax tone if we dial but when we debug fax relay t30 it shows the following:

000676: Dec  2 08:37:15.159 PST: 1/0/0:23 (39)  65518954 fr-entered=10(ms)
    timestamp=65520544 fr-msg-tx CSI
    timestamp=65521154 fr-msg-tx DIS
    timestamp=65526964 fr-msg-tx CSI
    timestamp=65527574 fr-msg-tx DIS
    timestamp=65529794 fr-msg-det DCS
    timestamp=65539834 fr-msg-tx CSI
    timestamp=65540444 fr-msg-tx DIS
    timestamp=65542674 fr-msg-det DCS
    timestamp=65552634 fr-msg-tx CSI
    timestamp=65553244 fr-msg-tx DIS
    timestamp=65557864 fr-msg-det DCS

and the faxes fail.

We are using it on a 2811 with MGCP and 12.4.25d


Michael Hanes Thu, 12/02/2010 - 10:39

Your MGCP configuration is correct and working fine.

Your debug output is interesting... it appears to show a delay problem. Typically when we see these T.30 negotiation messages repeating themselves in this manner it means that the T4 timer on the fax machine endpoints is expiring and resending the messages before a response is received. Can you provide the call path for your scenario? Obviously, you have a fax server at one end and an MGCP voice gateway somewhere in the path but what other devices and networks are between the fax server and the terminating fax machine?



letmeinnn Thu, 12/02/2010 - 12:16

We have tried these configurations in a couple different locations.

We tried it at our head office with two 3845 gateways plugged into a 3750 switch and using a tr1034 over a pstn and got similar results after enabling t38.  The first gateway receives calls and the second hosts the t1 for the tr1034.

This issue was intermittent depending on the sending fax machine (one canon would never complete the fax, another one would work fine) and we had to roll back because it was service affecting.  Remove t38 and all faxes come through.  We started to test with a different gateway that we are able to reset without affecting users.

The above debug comes from a 2811 connected to the fax server over a WAN (avg 60ms) into a 3745 router, then a 3750 switch which the fax server and sr140 are plugged into.  Fax machine is at a remote location calling a number on the remote gateway.


Michael Hanes Fri, 12/03/2010 - 09:02

Hi Kevin,

Your scenarios sounds pretty basic so I am not sure where you would be picking up so much delay if that is the cause of your problem. Whenever I have seen the debug messages appear like yours, in my experience it has been a delay issue. Either that or something is preventing the fax messages from making it to the other device so both keep repeating their initial negotiation messages over and over until they give up and disconnect the call.

The next step here is probably going to be a PCM capture on the DSP to confirm how these messages are being sent out on the POTS port and what amount of delay is present. Cisco TAC will need to be involved though as they have the ability to decode the capture file that you collect. The problem you are encountering is not seen much and a PCM capture is the best tool for determining the root cause.

A packet capture may also be helpful in seeing if this is a delay issue. It is not as definitive in as the PCM capture but it can provide good information as to what is going on. If you want to make a packet capture of a failing call then I would be happy to take a look.



letmeinnn Fri, 12/03/2010 - 09:53

I upgraded the remote gateway to 15.1.3 and I was finally able to succesfully receive a fax with the same config.


Michael Hanes Fri, 12/03/2010 - 09:59

Hi Kevin,

Good to know. I wish I had an explanation for you here but there was obviously a software defect. I have just never known one to cause the debug output that you were seeing. Thanks for the follow-up!



Login or Register to take actions

This Discussion

Posted November 18, 2010 at 2:11 PM
Replies:56 Avg. Rating:5
Views:19426 Votes:0

Related Content

Discussions Leaderboard

Rank Username Points
1 21,026
2 15,047
3 10,314
4 7,999
5 4,856
Rank Username Points