Menu
▾
▴
#13 Cisco UC520 handshake problem
closed-invalid
nobody
5
2010-02-07
2010-02-03
No
Here is my setup:
Cisco UC520 with two imbedded linux platforms attached. One is faxing to the other. Each is running t38modem with opal using SIP.
The CISCO UC520 is acting as a B2BUA and sometimes does drops the first byte of a handshake signal such as MPS. This causes t38modem to respond ERROR to my AT+FRH command which is correct. However, on the next AT+FRH command t38modem responds with CONNECT and then NO CARRIER without a DLE ETX. Subsequent AT+FRH commands are ignored and the call fails.
I am attaching the t38modem trace with +tttt, a wireshark trace, and a trace showing what I am reading and writing.
serial trace file
Wireshark file
The t38modem trace file was not attached.
> on the next AT+FRH command t38modem responds with CONNECT
> and then NO CARRIER without a DLE ETX.
It's absolutely correct.
> Subsequent AT+FRH commands are ignored and the call fails.
They are not ignored. They was handled as expected.
Definitely It's a bug in your fax application.
In the normal case we would have:
AT+FRH=3
CONNECT
Data
DLE ETX
OK
In this error case we have
AT+FRH=3
CONNECT
NO CARRIER
Since Data normally follows CONNECT, how do we know that the NO CARRIER string is not data, unless the DLE ETX is sent to end data mode?
Shouldn't DLE ETX always follow a CONNECT response at some point to go back to command mode?
T38modem Trace File
Correct T38modem trace file added. Sorry about that.
> Since Data normally follows CONNECT, how do we know that the NO CARRIER
> string is not data, unless the DLE ETX is sent to end data mode?
T.30 says that the first octet should be address field (0xFF).
So if <CR><LF> received before address field, the fax application
should expect result code.
BTW: It's possible to get broken HDLC frame instead result code,
For example:
<CR><LF>CONNECT<CR><LF><CR><LF>NO CARRIER<CR><LF><DLE><ETX>
But it's not a big problem for robust fax applications.
> Shouldn't DLE ETX always follow a CONNECT response at some point to go
> back to command mode?
No, it should not.
T.31 says that after sending the CONNECT result code
"The DCE shall return to command state upon loss of
carrier, sending the NO CARRIER result code to the DTE"
and
"After the FCS octets are transferred, the DCE shall
mark the end of the frame with the characters <DLE> <ETX>"
Other words:
<CR><LF>CONNECT<CR><LF><CR><LF>NO CARRIER<CR><LF> - is correct
<CR><LF>CONNECT<CR><LF>blah blah blah<DLE><ETX> - is correct
<CR><LF>CONNECT<CR><LF><DLE><ETX> - is not correct
Wireshark trace file
My trace of tty communication
T38Modem trace file level 5
OK, I added code to my app to handle NO CARRIER after CONNECT, but there is still a problem. The AT+FRH=3 after the CONNECT/NO CARRIER does not return data until after the call fails. It misses multiple retries from the other fax machine. I added a timeout of 5 seconds and a continuous retry to see if that would help. I also added a plain AT before each retry to see if t38modem was still responding. I always get OK from the AT, but nothing from the AT+FRH=3 until the call has ended.
I have included a level 5 t38modem trace, a wireshark trace, and my tty trace.
After sending a page, the remote sends
MPS (preamble+ff+c8+f2+fcs) 3 times and
all of them received broken due to packed
lost (seq_number=274,280,284,287,291):
1. lost ff (274) so result is CONNECT+c8+f2+ERROR - correct.
Then CONNECT+NO CARRIER - correct.
2. lost preamble (280) so frame was ignored - correct or near to correct.
Also lost fcs (284).
3. lost preamble (287) so frame was ignored - correct or near to correct.
Also lost fcs (291).
Possible for 2 and 3 it should be more correct to return
CONNECT+NO CARRIER (it does not matter for your case).
Your early trace shows:
1. lost ff (276).
2. lost preamble (282) and fcs (286).
3. lost preamble (289) and fcs (293).
Absolutely the same octets were lost.
So it's a remote or proxy bug.
Yes, I see that now in the wireshark trace. Definitely a problem with the Cisco UC520. It shouldn't be dropping packets like that. Thanks for your help with this.
Not a problem with T38Modem.