#13 Cisco UC520 handshake problem

v1.0 (example)
closed-invalid
nobody
5
2010-02-07
2010-02-03
Pete Davidson
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.

Discussion

  • Pete Davidson
    Pete Davidson
    2010-02-03

    serial trace file

     
    Attachments
  • Pete Davidson
    Pete Davidson
    2010-02-03

    Wireshark file

     
    Attachments
    • status: open --> pending
     
  • 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.

     
  • Pete Davidson
    Pete Davidson
    2010-02-05

    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?

     
  • Pete Davidson
    Pete Davidson
    2010-02-05

    T38modem Trace File

     
    Attachments
  • Pete Davidson
    Pete Davidson
    2010-02-05

    Correct T38modem trace file added. Sorry about that.

     
    • status: pending --> open
     
  • > 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

     
    • status: open --> pending
     
  • Pete Davidson
    Pete Davidson
    2010-02-06

    Wireshark trace file

     
    Attachments
  • Pete Davidson
    Pete Davidson
    2010-02-06

    My trace of tty communication

     
    Attachments
  • Pete Davidson
    Pete Davidson
    2010-02-06

    T38Modem trace file level 5

     
  • Pete Davidson
    Pete Davidson
    2010-02-06

    • status: pending --> open
     
  • Pete Davidson
    Pete Davidson
    2010-02-06

    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.

     
    • status: open --> pending
     
  • Pete Davidson
    Pete Davidson
    2010-02-07

    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.

     
  • Pete Davidson
    Pete Davidson
    2010-02-07

    • status: pending --> open
     
  • Pete Davidson
    Pete Davidson
    2010-02-07

    • status: open --> closed-invalid
     
  • Pete Davidson
    Pete Davidson
    2010-02-07

    Not a problem with T38Modem.