Rennyo
asked on
Lengthy faxes die on T37 route to mail server
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_on ramp_buff_ finished_c allback:
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:
//-1/5CED68EFB260/SMTPC/es mtp_client _engine_se nd_data_ci sco:exit@8 60
here it dies:
109036: Feb 17 11:46:37.279 GMT: //79557/5CED68EFB260/MSPI_ ON/mspi_on ramp_buff_ finished_c allback:
MMccb(Call State=CONFERENCED, Buffer Count=1)
109037: Feb 17 11:46:37.279 GMT: //-1/5CED68EFB260/SMTPC/es mtp_client _engine_se nd_data_ci sco:exit@8 60
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 -> 172.20.5.11(25)]
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.
//79557/5CED68EFB260/MSPI_ ON/mspi_on ramp_buff_ finished_c allback:
MMccb(Call State=CONFERENCED, Buffer Count=2)
109272: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es mtp_client _engine_se nd_data_ci sco:exit@8 60
109273: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es mtp_client _engine_wr ite:
SOFTWARE_ERROR_INFORMATION AL; esmtp_engine_write failed, rc=-1
109274: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es mtp_client _engine_wr ite:
return code=-1
109275: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es mtp_client _engine_se nd_data_ci sco:exit@8 29
109276: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es mtp_client _engine_wo rk_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!
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_
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:
//-1/5CED68EFB260/SMTPC/es
here it dies:
109036: Feb 17 11:46:37.279 GMT: //79557/5CED68EFB260/MSPI_
MMccb(Call State=CONFERENCED, Buffer Count=1)
109037: Feb 17 11:46:37.279 GMT: //-1/5CED68EFB260/SMTPC/es
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 -> 172.20.5.11(25)]
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.
//79557/5CED68EFB260/MSPI_
MMccb(Call State=CONFERENCED, Buffer Count=2)
109272: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es
109273: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es
SOFTWARE_ERROR_INFORMATION
109274: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es
return code=-1
109275: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es
109276: Feb 17 11:47:04.283 GMT: //-1/5CED68EFB260/SMTPC/es
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!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
the limits for imap and pop3 were well-documented, but buried for smtp. This helps!
Thanks!