Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

Professional Opinions
Ask a Question
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

troubleshooting Question

Lengthy faxes die on T37 route to mail server

Avatar of Rennyo
Rennyo asked on
RoutersExchangeEmail Protocols
2 Comments1 Solution997 ViewsLast Modified:
Faxes in excess of 10+ pages sent from pstn die with dropped pages and disconnects. After much debugging the issue was traced to E2K7 server. Appears to be buffer, or length of time a fax call stays open--certain faxes stop sending .tiffs to exchange after 15 pages or so.
Call clearing is normal (code 16)
debugs following--
Typical call flow for a t37 call
  Inbound fax to gateway
  Gateway uses onramp script to change faxes to tiff
  Gateway emails tiff files to Exchange using SMTP (TCP port 25)

During a test of 20+ fax pages sent inbound from pstn, the fax consistently stops.
Here are the steps for MSPI process (responsible for MTA transfer to Exchange) takes each time a new tiff attachment is being sent to Exchange for the same fax.
104434: Feb 17 11:39:46.369 GMT: //79557/5CED68EFB260/MSPI_ON/mspi_onramp_buff_finished_callback:
   MMccb(Call State=CONFERENCED, Buffer Count=1)
The SMTPC client in the t.37 stack leaves a message that the tiff data was sent
104435: Feb 17 11:39:46.369 GMT:
here it dies:
109036: Feb 17 11:46:37.279 GMT: //79557/5CED68EFB260/MSPI_ON/mspi_onramp_buff_finished_callback:
   MMccb(Call State=CONFERENCED, Buffer Count=1)
109037: Feb 17 11:46:37.279 GMT: //-1/5CED68EFB260/SMTPC/esmtp_client_engine_send_data_cisco:exit@860
109038: Feb 17 11:46:37.283 GMT: TCP0: RST received, Closing connection
109039: Feb 17 11:46:37.283 GMT: TCP0: state was ESTAB -> CLOSED [64679 ->]
109040: Feb 17 11:46:37.483 GMT: TCP0: ACK timeout timer expired
Once this port is closed, we no longer have the same session and when re-attempting to go down the same path there is socket erro that is being returned.
   MMccb(Call State=CONFERENCED, Buffer Count=2)
109272: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/esmtp_client_engine_send_data_cisco:exit@860
109273: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/esmtp_client_engine_write:
   SOFTWARE_ERROR_INFORMATIONAL; esmtp_engine_write failed, rc=-1
109274: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/esmtp_client_engine_write:
   return code=-1
109275: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/esmtp_client_engine_send_data_cisco:exit@829
109276: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/esmtp_client_engine_work_routine:
   ERROR, socket=2
109277: Feb 17 11:47:04.283 GMT: Released port 64679 in Transport Port Agent for TCP IP type 1 delay 240000
109278: Feb 17 11:47:04.283 GMT: TCB 0x4B3CDF84 destroyed

What E2K7 setting or reg hack is required to fix? Is there a system timeout in Exchange for tiff files sent via t37? These long faxes take awhile to transmit, convert to .tiff etc. and be sent. The actual size of the fax messages are minimal (768k for exmaple) so it's not a filesize issue. Critical!
Avatar of Rick Fee
Rick FeeFlag of United States of America imageMessaging Engineer - Disaster Recovery Engineer

Our community of experts have been thoroughly vetted for their expertise and industry experience.

This problem has been solved!
Unlock 1 Answer and 2 Comments.
See Answers