Skip to content

Commit 3569ef7

Browse files
committed
Ignore superfluous T38_FIELD_HDLC_SIG_END sent by some implementations
Ignore T38_FIELD_HDLC_SIG_END when received following a T38_FIELD_HDLC_FCS_OK_SIG_END or T38_FIELD_HDLC_FCS_BAD_SIG_END
1 parent 933d40d commit 3569ef7

File tree

3 files changed

+12
-6
lines changed

3 files changed

+12
-6
lines changed

src/t31.c

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -643,8 +643,10 @@ static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type,
643643
/*endif*/
644644
/* Some T.38 implementations send multiple T38_FIELD_HDLC_SIG_END messages, in IFP packets with
645645
incrementing sequence numbers, which are actually repeats. They get through to this point because
646-
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
647-
if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
646+
of the incrementing sequence numbers. Some others send T38_FIELD_HDLC_SIG_END following a
647+
T38_FIELD_HDLC_FCS_OK_SIG_END or T38_FIELD_HDLC_FCS_BAD_SIG_END. We need to filter them here
648+
in a context sensitive manner. */
649+
if (t->current_rx_data_type != data_type || (t->current_rx_field_type != field_type && t->current_rx_field_type != T38_FIELD_HDLC_FCS_OK_SIG_END && t->current_rx_field_type != T38_FIELD_HDLC_FCS_BAD_SIG_END))
648650
{
649651
/* WORKAROUND: At least some Mediatrix boxes have a bug, where they can send this message at the
650652
end of non-ECM data. We need to tolerate this. We use the generic receive complete

src/t38_gateway.c

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1308,8 +1308,10 @@ static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type,
13081308
/*endif*/
13091309
/* Some T.38 implementations send multiple T38_FIELD_HDLC_SIG_END messages, in IFP packets with
13101310
incrementing sequence numbers, which are actually repeats. They get through to this point because
1311-
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
1312-
if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
1311+
of the incrementing sequence numbers. Some others send T38_FIELD_HDLC_SIG_END following a
1312+
T38_FIELD_HDLC_FCS_OK_SIG_END or T38_FIELD_HDLC_FCS_BAD_SIG_END. We need to filter them here
1313+
in a context sensitive manner. */
1314+
if (t->current_rx_data_type != data_type || (t->current_rx_field_type != field_type && t->current_rx_field_type != T38_FIELD_HDLC_FCS_OK_SIG_END && t->current_rx_field_type != T38_FIELD_HDLC_FCS_BAD_SIG_END))
13131315
{
13141316
if (hdlc_buf->contents != (data_type | FLAG_DATA))
13151317
{

src/t38_terminal.c

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -534,8 +534,10 @@ static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type,
534534
/*endif*/
535535
/* Some T.38 implementations send multiple T38_FIELD_HDLC_SIG_END messages, in IFP packets with
536536
incrementing sequence numbers, which are actually repeats. They get through to this point because
537-
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
538-
if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
537+
of the incrementing sequence numbers. Some others send T38_FIELD_HDLC_SIG_END following a
538+
T38_FIELD_HDLC_FCS_OK_SIG_END or T38_FIELD_HDLC_FCS_BAD_SIG_END. We need to filter them here
539+
in a context sensitive manner. */
540+
if (t->current_rx_data_type != data_type || (t->current_rx_field_type != field_type && t->current_rx_field_type != T38_FIELD_HDLC_FCS_OK_SIG_END && t->current_rx_field_type != T38_FIELD_HDLC_FCS_BAD_SIG_END))
539541
{
540542
/* WORKAROUND: At least some Mediatrix boxes have a bug, where they can send this message at the
541543
end of non-ECM data. We need to tolerate this. We use the generic receive complete

0 commit comments

Comments
 (0)