in some T.38 packets from Commetrex and Cisco machines.
}
/*- End of function --------------------------------------------------------*/
+static void process_hdlc_data(t31_t38_front_end_state_t *fe, const uint8_t *buf, int len)
+{
+ if (fe->hdlc_rx.len + len <= T31_T38_MAX_HDLC_LEN)
+ {
+ bit_reverse(fe->hdlc_rx.buf + fe->hdlc_rx.len, buf, len);
+ fe->hdlc_rx.len += len;
+ }
+ else
+ {
+ fe->rx_data_missing = TRUE;
+ }
+ /*endif*/
+}
+/*- End of function --------------------------------------------------------*/
+
static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type, int field_type, const uint8_t *buf, int len)
{
t31_state_t *s;
/*endif*/
if (len > 0)
{
- if (fe->hdlc_rx.len + len <= T31_T38_MAX_HDLC_LEN)
- {
- bit_reverse(fe->hdlc_rx.buf + fe->hdlc_rx.len, buf, len);
- fe->hdlc_rx.len += len;
- }
- else
- {
- fe->rx_data_missing = TRUE;
- }
- /*endif*/
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
fe->timeout_rx_samples = fe->samples + ms_to_samples(MID_RX_TIMEOUT);
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_OK!\n");
- /* The sender has incorrectly included data in this message. It is unclear what we should do
- with it, to maximise tolerance of buggy implementations. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_OK messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC OK (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
if (data_type == T38_DATA_V21)
hdlc_accept_t38_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, !fe->rx_data_missing);
}
/*endif*/
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
fe->timeout_rx_samples = fe->samples + ms_to_samples(MID_RX_TIMEOUT);
break;
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_BAD!\n");
- /* The sender has incorrectly included data in this message. We can safely ignore it, as the
- bad FCS means we will throw away the whole message, anyway. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_BAD messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC bad (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
if (data_type == T38_DATA_V21)
else
hdlc_accept_t38_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, FALSE);
/*endif*/
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
fe->timeout_rx_samples = fe->samples + ms_to_samples(MID_RX_TIMEOUT);
break;
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_OK_SIG_END!\n");
- /* The sender has incorrectly included data in this message. It is unclear what we should do
- with it, to maximise tolerance of buggy implementations. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_OK_SIG_END messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC OK, sig end (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
if (data_type == T38_DATA_V21)
/*endif*/
crc_itu16_append(fe->hdlc_rx.buf, fe->hdlc_rx.len);
hdlc_accept_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, !fe->rx_data_missing);
- hdlc_rx_status(s, SIG_STATUS_CARRIER_DOWN);
}
else
{
hdlc_accept_t38_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, !fe->rx_data_missing);
- non_ecm_rx_status(s, SIG_STATUS_CARRIER_DOWN);
}
/*endif*/
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
+ if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ {
+ if (data_type == T38_DATA_V21)
+ hdlc_rx_status(s, SIG_STATUS_CARRIER_DOWN);
+ else
+ non_ecm_rx_status(s, SIG_STATUS_CARRIER_DOWN);
+ /*endif*/
+ }
+ /*endif*/
fe->timeout_rx_samples = 0;
break;
case T38_FIELD_HDLC_FCS_BAD_SIG_END:
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_BAD_SIG_END!\n");
- /* The sender has incorrectly included data in this message. We can safely ignore it, as the
- bad FCS means we will throw away the whole message, anyway. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_BAD_SIG_END messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC bad, sig end (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
if (data_type == T38_DATA_V21)
- {
hdlc_accept_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, FALSE);
- hdlc_rx_status(s, SIG_STATUS_CARRIER_DOWN);
- }
else
- {
hdlc_accept_t38_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, FALSE);
- non_ecm_rx_status(s, SIG_STATUS_CARRIER_DOWN);
- }
/*endif*/
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
+ if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ {
+ if (data_type == T38_DATA_V21)
+ hdlc_rx_status(s, SIG_STATUS_CARRIER_DOWN);
+ else
+ non_ecm_rx_status(s, SIG_STATUS_CARRIER_DOWN);
+ /*endif*/
+ }
+ /*endif*/
fe->timeout_rx_samples = 0;
break;
case T38_FIELD_HDLC_SIG_END:
}
/*- End of function --------------------------------------------------------*/
-static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type, int field_type, const uint8_t *buf, int len)
+static void process_hdlc_data(t38_gateway_state_t *s, int data_type, const uint8_t *buf, int len)
{
+ t38_gateway_hdlc_buf_t *hdlc_buf;
int i;
+
+ hdlc_buf = &s->core.hdlc_to_modem.buf[s->core.hdlc_to_modem.in];
+ /* Check if this data would overflow the buffer. */
+ if (hdlc_buf->len + len > T38_MAX_HDLC_LEN)
+ {
+ s->core.hdlc_to_modem.buf[s->core.hdlc_to_modem.in].flags |= HDLC_FLAG_MISSING_DATA;
+ return;
+ }
+ /*endif*/
+ hdlc_buf->contents = (data_type | FLAG_DATA);
+ bit_reverse(&hdlc_buf->buf[hdlc_buf->len], buf, len);
+ /* We need to send out the control messages as they are arriving. They are
+ too slow to capture a whole frame before starting to pass it on.
+ For the faster frames, take in the whole frame before sending it out. Also, there
+ is no need to monitor, or modify, the contents of the faster frames. */
+ if (data_type == T38_DATA_V21)
+ {
+ for (i = 1; i <= len; i++)
+ edit_control_messages(s, 0, hdlc_buf->buf, hdlc_buf->len + i);
+ /*endfor*/
+ /* Don't start pumping data into the actual output stream until there is
+ enough backlog to create some elasticity for jitter tolerance. */
+ if (hdlc_buf->len + len >= HDLC_START_BUFFER_LEVEL)
+ {
+ if (s->core.hdlc_to_modem.in == s->core.hdlc_to_modem.out)
+ {
+ /* Output is not running, so kick it into life. */
+ if ((hdlc_buf->flags & HDLC_FLAG_PROCEED_WITH_OUTPUT) == 0)
+ hdlc_tx_frame(&s->audio.modems.hdlc_tx, hdlc_buf->buf, hdlc_buf->len + len);
+ else
+ hdlc_tx_frame(&s->audio.modems.hdlc_tx, hdlc_buf->buf + hdlc_buf->len, len);
+ /*endif*/
+ }
+ /*endif*/
+ hdlc_buf->flags |= HDLC_FLAG_PROCEED_WITH_OUTPUT;
+ }
+ /*endif*/
+ }
+ /*endif*/
+ hdlc_buf->len += len;
+}
+/*- End of function --------------------------------------------------------*/
+
+static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type, int field_type, const uint8_t *buf, int len)
+{
t38_gateway_state_t *s;
t38_gateway_t38_state_t *xx;
t38_gateway_hdlc_buf_t *hdlc_buf;
hdlc_buf = &s->core.hdlc_to_modem.buf[s->core.hdlc_to_modem.in];
}
/*endif*/
- /* Check if this data would overflow the buffer. */
- if (len <= 0)
- break;
- /*endif*/
- if (hdlc_buf->len + len > T38_MAX_HDLC_LEN)
- {
- s->core.hdlc_to_modem.buf[s->core.hdlc_to_modem.in].flags |= HDLC_FLAG_MISSING_DATA;
- break;
- }
- /*endif*/
- hdlc_buf->contents = (data_type | FLAG_DATA);
- bit_reverse(&hdlc_buf->buf[hdlc_buf->len], buf, len);
- /* We need to send out the control messages as they are arriving. They are
- too slow to capture a whole frame before starting to pass it on.
- For the faster frames, take in the whole frame before sending it out. Also, there
- is no need to monitor, or modify, the contents of the faster frames. */
- if (data_type == T38_DATA_V21)
- {
- for (i = 1; i <= len; i++)
- edit_control_messages(s, 0, hdlc_buf->buf, hdlc_buf->len + i);
- /*endfor*/
- /* Don't start pumping data into the actual output stream until there is
- enough backlog to create some elasticity for jitter tolerance. */
- if (hdlc_buf->len + len >= HDLC_START_BUFFER_LEVEL)
- {
- if (s->core.hdlc_to_modem.in == s->core.hdlc_to_modem.out)
- {
- /* Output is not running, so kick it into life. */
- if ((hdlc_buf->flags & HDLC_FLAG_PROCEED_WITH_OUTPUT) == 0)
- hdlc_tx_frame(&s->audio.modems.hdlc_tx, hdlc_buf->buf, hdlc_buf->len + len);
- else
- hdlc_tx_frame(&s->audio.modems.hdlc_tx, hdlc_buf->buf + hdlc_buf->len, len);
- /*endif*/
- }
- /*endif*/
- hdlc_buf->flags |= HDLC_FLAG_PROCEED_WITH_OUTPUT;
- }
- /*endif*/
- }
+ if (len > 0)
+ process_hdlc_data(s, data_type, buf, len);
/*endif*/
- s->core.hdlc_to_modem.buf[s->core.hdlc_to_modem.in].len += len;
break;
case T38_FIELD_HDLC_FCS_OK:
xx->current_rx_field_class = T38_FIELD_CLASS_HDLC;
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_OK!\n");
- /* The sender has incorrectly included data in this message. It is unclear what we should do
- with it, to maximise tolerance of buggy implementations. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(s, data_type, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_OK messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (hdlc_buf->len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "HDLC frame type %s - CRC OK\n", t30_frametype(hdlc_buf->buf[2]));
if (hdlc_buf->contents != (data_type | FLAG_DATA))
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_BAD!\n");
- /* The sender has incorrectly included data in this message. We can safely ignore it, as the
- bad FCS means we will throw away the whole message, anyway. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(s, data_type, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_BAD messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (hdlc_buf->len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "HDLC frame type %s - CRC bad\n", t30_frametype(hdlc_buf->buf[2]));
/* Only bother with frames that have a bad CRC, if they also have some content. */
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_OK_SIG_END!\n");
- /* The sender has incorrectly included data in this message. It is unclear what we should do
- with it, to maximise tolerance of buggy implementations. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(s, data_type, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_OK_SIG_END messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (hdlc_buf->len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "HDLC frame type %s - CRC OK, sig end\n", t30_frametype(hdlc_buf->buf[2]));
if (hdlc_buf->contents != (data_type | FLAG_DATA))
/*endif*/
hdlc_buf->contents = (data_type | FLAG_DATA);
finalise_hdlc_frame(s, TRUE);
+ }
+ /*endif*/
+ if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ {
queue_missing_indicator(s, T38_DATA_NONE);
xx->current_rx_field_class = T38_FIELD_CLASS_NONE;
}
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_BAD_SIG_END!\n");
- /* The sender has incorrectly included data in this message. We can safely ignore it, as the
- bad FCS means we will throw away the whole message, anyway. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(s, data_type, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_BAD_SIG_END messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (hdlc_buf->len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "HDLC frame type %s - CRC bad, sig end\n", t30_frametype(hdlc_buf->buf[2]));
if (hdlc_buf->contents != (data_type | FLAG_DATA))
hdlc_buf->contents = 0;
}
/*endif*/
+ }
+ /*endif*/
+ if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ {
queue_missing_indicator(s, T38_DATA_NONE);
xx->current_rx_field_class = T38_FIELD_CLASS_NONE;
}
}
/*- End of function --------------------------------------------------------*/
+static void process_hdlc_data(t38_terminal_front_end_state_t *fe, const uint8_t *buf, int len)
+{
+ if (fe->hdlc_rx.len + len <= T38_MAX_HDLC_LEN)
+ {
+ bit_reverse(fe->hdlc_rx.buf + fe->hdlc_rx.len, buf, len);
+ fe->hdlc_rx.len += len;
+ }
+ else
+ {
+ fe->rx_data_missing = TRUE;
+ }
+}
+/*- End of function --------------------------------------------------------*/
+
static int process_rx_data(t38_core_state_t *t, void *user_data, int data_type, int field_type, const uint8_t *buf, int len)
{
t38_terminal_state_t *s;
/*endif*/
if (len > 0)
{
- if (fe->hdlc_rx.len + len <= T38_MAX_HDLC_LEN)
- {
- bit_reverse(fe->hdlc_rx.buf + fe->hdlc_rx.len, buf, len);
- fe->hdlc_rx.len += len;
- }
- else
- {
- fe->rx_data_missing = TRUE;
- }
- /*endif*/
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
fe->timeout_rx_samples = fe->samples + ms_to_samples(MID_RX_TIMEOUT);
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_OK!\n");
- /* The sender has incorrectly included data in this message. It is unclear what we should do
- with it, to maximise tolerance of buggy implementations. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_OK messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC OK (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
hdlc_accept_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, !fe->rx_data_missing);
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
fe->timeout_rx_samples = fe->samples + ms_to_samples(MID_RX_TIMEOUT);
break;
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_BAD!\n");
- /* The sender has incorrectly included data in this message. We can safely ignore it, as the
- bad FCS means we will throw away the whole message, anyway. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_BAD messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC bad (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
hdlc_accept_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, FALSE);
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
fe->timeout_rx_samples = fe->samples + ms_to_samples(MID_RX_TIMEOUT);
break;
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_OK_SIG_END!\n");
- /* The sender has incorrectly included data in this message. It is unclear what we should do
- with it, to maximise tolerance of buggy implementations. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_OK_SIG_END messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC OK, sig end (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
hdlc_accept_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, !fe->rx_data_missing);
- hdlc_accept_frame(s, NULL, SIG_STATUS_CARRIER_DOWN, TRUE);
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
+ if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ hdlc_accept_frame(s, NULL, SIG_STATUS_CARRIER_DOWN, TRUE);
+ /*endif*/
/* Treat this like a no signal indicator has occurred, so if the no signal indicator is missing, we are still OK */
fake_rx_indicator(t, s, T38_IND_NO_SIGNAL);
break;
if (len > 0)
{
span_log(&s->logging, SPAN_LOG_WARNING, "There is data in a T38_FIELD_HDLC_FCS_BAD_SIG_END!\n");
- /* The sender has incorrectly included data in this message. We can safely ignore it, as the
- bad FCS means we will throw away the whole message, anyway. */
+ /* The sender has incorrectly included data in this message. Cisco implemented inserting
+ HDLC data here and Commetrex followed for compatibility reasons. We should, too. */
+ process_hdlc_data(fe, buf, len);
}
/*endif*/
/* Some T.38 implementations send multiple T38_FIELD_HDLC_FCS_BAD_SIG_END messages, in IFP packets with
incrementing sequence numbers, which are actually repeats. They get through to this point because
of the incrementing sequence numbers. We need to filter them here in a context sensitive manner. */
- if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ if (fe->hdlc_rx.len > 0)
{
span_log(&s->logging, SPAN_LOG_FLOW, "Type %s - CRC bad, sig end (%s)\n", (fe->hdlc_rx.len >= 3) ? t30_frametype(fe->hdlc_rx.buf[2]) : "???", (fe->rx_data_missing) ? "missing octets" : "clean");
hdlc_accept_frame(s, fe->hdlc_rx.buf, fe->hdlc_rx.len, FALSE);
- hdlc_accept_frame(s, NULL, SIG_STATUS_CARRIER_DOWN, TRUE);
+ fe->hdlc_rx.len = 0;
}
/*endif*/
- fe->hdlc_rx.len = 0;
fe->rx_data_missing = FALSE;
+ if (t->current_rx_data_type != data_type || t->current_rx_field_type != field_type)
+ hdlc_accept_frame(s, NULL, SIG_STATUS_CARRIER_DOWN, TRUE);
+ /*endif*/
/* Treat this like a no signal indicator has occurred, so if the no signal indicator is missing, we are still OK */
fake_rx_indicator(t, s, T38_IND_NO_SIGNAL);
break;
projects / thirdparty / freeswitch.git / commitdiff
