asterisk/main/udptl.c

1440 lines
42 KiB
C
Raw Normal View History

/*
* Asterisk -- An open source telephony toolkit.
*
* UDPTL support for T.38
*
* Copyright (C) 2005, Steve Underwood, partly based on RTP code which is
* Copyright (C) 1999-2009, Digium, Inc.
*
* Steve Underwood <steveu@coppice.org>
* Kevin P. Fleming <kpfleming@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*
* A license has been granted to Digium (via disclaimer) for the use of
* this code.
*/
/*!
* \file
*
* \brief UDPTL support for T.38 faxing
*
*
* \author Mark Spencer <markster@digium.com>
* \author Steve Underwood <steveu@coppice.org>
* \author Kevin P. Fleming <kpfleming@digium.com>
*
* \page T38fax_udptl T.38 support :: UDPTL
*
* Asterisk supports T.38 fax passthrough, origination and termination. It does
* not support gateway operation.
*
* UDPTL is handled very much like RTP. It can be reinvited to go directly between
* the endpoints, without involving Asterisk in the media stream.
*
* \b References:
* - udptl.c
* - app_fax.c
*/
/*! \li \ref udptl.c uses the configuration file \ref udptl.conf
* \addtogroup configuration_file Configuration Files
*/
/*!
* \page udptl.conf udptl.conf
* \verbinclude udptl.conf.sample
*/
/*** MODULEINFO
<support_level>core</support_level>
***/
#include "asterisk.h"
#include <sys/time.h>
#include <signal.h>
#include <fcntl.h>
#include "asterisk/module.h"
#include "asterisk/udptl.h"
#include "asterisk/frame.h"
#include "asterisk/channel.h"
#include "asterisk/acl.h"
#include "asterisk/config_options.h"
#include "asterisk/lock.h"
#include "asterisk/utils.h"
#include "asterisk/netsock2.h"
#include "asterisk/cli.h"
#include "asterisk/unaligned.h"
/*** DOCUMENTATION
<configInfo name="udptl" language="en_US">
<configFile name="udptl.conf">
<configObject name="global">
<synopsis>Global options for configuring UDPTL</synopsis>
<configOption name="udptlstart">
<synopsis>The start of the UDPTL port range</synopsis>
</configOption>
<configOption name="udptlend">
<synopsis>The end of the UDPTL port range</synopsis>
</configOption>
<configOption name="udptlchecksums">
<synopsis>Whether to enable or disable UDP checksums on UDPTL traffic</synopsis>
</configOption>
<configOption name="udptlfecentries">
<synopsis>The number of error correction entries in a UDPTL packet</synopsis>
</configOption>
<configOption name="udptlfecspan">
<synopsis>The span over which parity is calculated for FEC in a UDPTL packet</synopsis>
</configOption>
<configOption name="use_even_ports">
<synopsis>Whether to only use even-numbered UDPTL ports</synopsis>
</configOption>
<configOption name="t38faxudpec">
<synopsis>Removed</synopsis>
</configOption>
<configOption name="t38faxmaxdatagram">
<synopsis>Removed</synopsis>
</configOption>
</configObject>
</configFile>
</configInfo>
***/
#define UDPTL_MTU 1200
#if !defined(FALSE)
#define FALSE 0
#endif
#if !defined(TRUE)
#define TRUE (!FALSE)
#endif
#define LOG_TAG(u) S_OR(u->tag, "no tag")
#define DEFAULT_UDPTLSTART 4000
#define DEFAULT_UDPTLEND 4999
static int udptldebug; /*!< Are we debugging? */
static struct ast_sockaddr udptldebugaddr; /*!< Debug packets to/from this host */
#define LOCAL_FAX_MAX_DATAGRAM 1400
#define DEFAULT_FAX_MAX_DATAGRAM 400
#define FAX_MAX_DATAGRAM_LIMIT 1400
#define MAX_FEC_ENTRIES 5
#define MAX_FEC_SPAN 5
#define UDPTL_BUF_MASK 15
typedef struct {
int buf_len;
uint8_t buf[LOCAL_FAX_MAX_DATAGRAM];
} udptl_fec_tx_buffer_t;
typedef struct {
int buf_len;
uint8_t buf[LOCAL_FAX_MAX_DATAGRAM];
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int fec_len[MAX_FEC_ENTRIES];
uint8_t fec[MAX_FEC_ENTRIES][LOCAL_FAX_MAX_DATAGRAM];
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int fec_span;
unsigned int fec_entries;
} udptl_fec_rx_buffer_t;
/*! \brief Structure for an UDPTL session */
struct ast_udptl {
int fd;
char resp;
struct ast_frame f[16];
unsigned char rawdata[8192 + AST_FRIENDLY_OFFSET];
unsigned int lasteventseqn;
int nat;
int flags;
struct ast_sockaddr us;
struct ast_sockaddr them;
int *ioid;
struct ast_sched_context *sched;
struct io_context *io;
void *data;
char *tag;
ast_udptl_callback callback;
/*! This option indicates the error correction scheme used in transmitted UDPTL
* packets and expected in received UDPTL packets.
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
enum ast_t38_ec_modes error_correction_scheme;
/*! This option indicates the number of error correction entries transmitted in
* UDPTL packets and expected in received UDPTL packets.
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
unsigned int error_correction_entries;
/*! This option indicates the span of the error correction entries in transmitted
* UDPTL packets (FEC only).
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
unsigned int error_correction_span;
/*! The maximum size UDPTL packet that can be accepted by
* the remote device.
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
int far_max_datagram;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
/*! The maximum size UDPTL packet that we are prepared to
* accept, or -1 if it hasn't been calculated since the last
* changes were applied to the UDPTL structure.
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
int local_max_datagram;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
/*! The maximum IFP that can be submitted for sending
* to the remote device. Calculated from far_max_datagram,
* error_correction_scheme and error_correction_entries,
* or -1 if it hasn't been calculated since the last
* changes were applied to the UDPTL structure.
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
int far_max_ifp;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
/*! The maximum IFP that the local endpoint is prepared
* to accept. Along with error_correction_scheme and
* error_correction_entries, used to calculate local_max_datagram.
*/
int local_max_ifp;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int tx_seq_no;
unsigned int rx_seq_no;
udptl_fec_tx_buffer_t tx[UDPTL_BUF_MASK + 1];
udptl_fec_rx_buffer_t rx[UDPTL_BUF_MASK + 1];
};
struct udptl_global_options {
unsigned int start; /*< The UDPTL start port */
unsigned int end; /*< The UDPTL end port */
unsigned int fecentries;
unsigned int fecspan;
unsigned int nochecksums;
unsigned int use_even_ports;
};
static AO2_GLOBAL_OBJ_STATIC(globals);
struct udptl_config {
struct udptl_global_options *general;
};
static void *udptl_snapshot_alloc(void);
static int udptl_pre_apply_config(void);
static struct aco_type general_option = {
.type = ACO_GLOBAL,
.name = "global",
.category_match = ACO_WHITELIST_EXACT,
.item_offset = offsetof(struct udptl_config, general),
.category = "general",
};
static struct aco_type *general_options[] = ACO_TYPES(&general_option);
static struct aco_file udptl_conf = {
.filename = "udptl.conf",
.types = ACO_TYPES(&general_option),
};
CONFIG_INFO_CORE("udptl", cfg_info, globals, udptl_snapshot_alloc,
.files = ACO_FILES(&udptl_conf),
.pre_apply_config = udptl_pre_apply_config,
);
static inline int udptl_debug_test_addr(const struct ast_sockaddr *addr)
{
if (udptldebug == 0)
return 0;
if (ast_sockaddr_isnull(&udptldebugaddr)) {
return 1;
}
if (ast_sockaddr_port(&udptldebugaddr)) {
return !ast_sockaddr_cmp(&udptldebugaddr, addr);
} else {
return !ast_sockaddr_cmp_addr(&udptldebugaddr, addr);
}
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
static int decode_length(uint8_t *buf, unsigned int limit, unsigned int *len, unsigned int *pvalue)
{
if (*len >= limit)
return -1;
if ((buf[*len] & 0x80) == 0) {
*pvalue = buf[*len];
(*len)++;
return 0;
}
if ((buf[*len] & 0x40) == 0) {
if (*len == limit - 1)
return -1;
*pvalue = (buf[*len] & 0x3F) << 8;
(*len)++;
*pvalue |= buf[*len];
(*len)++;
return 0;
}
*pvalue = (buf[*len] & 0x3F) << 14;
(*len)++;
/* We have a fragment. Currently we don't process fragments. */
ast_debug(1, "UDPTL packet with length greater than 16K received, decoding will fail\n");
return 1;
}
/*- End of function --------------------------------------------------------*/
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
static int decode_open_type(uint8_t *buf, unsigned int limit, unsigned int *len, const uint8_t **p_object, unsigned int *p_num_octets)
{
unsigned int octet_cnt = 0;
if (decode_length(buf, limit, len, &octet_cnt) != 0)
return -1;
/* Make sure the buffer contains at least the number of bits requested */
if ((*len + octet_cnt) > limit) {
return -1;
}
*p_num_octets = octet_cnt;
*p_object = &buf[*len];
*len += octet_cnt;
return 0;
}
/*- End of function --------------------------------------------------------*/
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
static unsigned int encode_length(uint8_t *buf, unsigned int *len, unsigned int value)
{
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int multiplier;
if (value < 0x80) {
/* 1 octet */
buf[*len] = value;
(*len)++;
return value;
}
if (value < 0x4000) {
/* 2 octets */
/* Set the first bit of the first octet */
buf[*len] = ((0x8000 | value) >> 8) & 0xFF;
(*len)++;
buf[*len] = value & 0xFF;
(*len)++;
return value;
}
/* Fragmentation */
multiplier = (value < 0x10000) ? (value >> 14) : 4;
/* Set the first 2 bits of the octet */
buf[*len] = 0xC0 | multiplier;
(*len)++;
return multiplier << 14;
}
/*- End of function --------------------------------------------------------*/
static int encode_open_type(const struct ast_udptl *udptl, uint8_t *buf, unsigned int buflen,
unsigned int *len, const uint8_t *data, unsigned int num_octets)
{
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int enclen;
unsigned int octet_idx;
uint8_t zero_byte;
/* If open type is of zero length, add a single zero byte (10.1) */
if (num_octets == 0) {
zero_byte = 0;
data = &zero_byte;
num_octets = 1;
}
/* Encode the open type */
for (octet_idx = 0; ; num_octets -= enclen, octet_idx += enclen) {
clang compiler warnings: Fix autological comparisons This fixes autological comparison warnings in the following: * chan_skinny: letohl may return a signed or unsigned value, depending on the macro chosen * func_curl: Provide a specific cast to CURLoption to prevent mismatch * cel: Fix enum comparisons where the enum can never be negative * enum: Fix comparison of return result of dn_expand, which returns a signed int value * event: Fix enum comparisons where the enum can never be negative * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be negative * presencestate: Use the actual enum value for INVALID state * security_events: Fix enum comparisons where the enum can never be negative * udptl: Don't bother to check if the return value from encode_length is less than 0, as it returns an unsigned int * translate: Since the parameters are unsigned int, don't bother checking to see if they are negative. The cast to unsigned int would already blow past the matrix bounds. * res_pjsip_exten_state: Use a temporary value to cache the return of ast_hint_presence_state * res_stasis_playback: Fix enum comparisons where the enum can never be negative * res_stasis_recording: Add an enum value for the case where the recording operation is in error; fix enum comparisons * resource_bridges: Use enum value as opposed to -1 * resource_channels: Use enum value as opposed to -1 Review: https://reviewboard.asterisk.org/r/4533 ASTERISK-24917 Reported by: dkdegroot patches: rb4533.patch submitted by dkdegroot (License 6600) ........ Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-04-09 12:57:21 +00:00
enclen = encode_length(buf, len, num_octets);
if (enclen + *len > buflen) {
ast_log(LOG_ERROR, "UDPTL (%s): Buffer overflow detected (%u + %u > %u)\n",
LOG_TAG(udptl), enclen, *len, buflen);
return -1;
}
if (enclen > 0) {
memcpy(&buf[*len], &data[octet_idx], enclen);
*len += enclen;
}
if (enclen >= num_octets)
break;
}
return 0;
}
/*- End of function --------------------------------------------------------*/
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
static int udptl_rx_packet(struct ast_udptl *s, uint8_t *buf, unsigned int len)
{
int stat1;
int stat2;
int i;
unsigned int ptr; /* an index that keeps track of how much of the UDPTL packet has been processed */
int seq_no;
const uint8_t *ifp = NULL;
const uint8_t *data = NULL;
unsigned int ifp_len = 0;
int repaired[16];
const uint8_t *bufs[ARRAY_LEN(s->f) - 1];
unsigned int lengths[ARRAY_LEN(s->f) - 1];
int span;
int entries;
int ifp_no;
ptr = 0;
ifp_no = 0;
memset(&s->f[0], 0, sizeof(s->f[0]));
/* Decode seq_number */
if (ptr + 2 > len)
return -1;
seq_no = (buf[0] << 8) | buf[1];
ptr += 2;
/* UDPTL sequence numbers are 16 bit so after 0xFFFF comes
0 which breaks all packet recovery logic. To fix this
if we see that next expected packet (rx_seq_no) is close
to or beyond the wrap around limit & the received packet
is still near zero, then we 'unwrap' the received seqno
so it has the value it would have had. After a 16
packet grace period (there shouldn't be more than
that many recovery packets) we wrap the expected
sequence number around and things can return back
to normal */
if (seq_no < 0x000F && s->rx_seq_no > 0xFFF0) {
/* received seq_no has wrapped adjust it */
seq_no += 0x10000;
} else {
/* otherwise make sure expected rx_seq_no is properly wrapped */
s->rx_seq_no &= 0xFFFF;
}
/* Break out the primary packet */
if ((stat1 = decode_open_type(buf, len, &ptr, &ifp, &ifp_len)) != 0)
return -1;
/* Decode error_recovery */
if (ptr + 1 > len)
return -1;
if ((buf[ptr++] & 0x80) == 0) {
/* Secondary packet mode for error recovery */
if (seq_no > s->rx_seq_no) {
/* We received a later packet than we expected, so we need to check if we can fill in the gap from the
secondary packets. */
int total_count = 0;
do {
unsigned int count;
if ((stat2 = decode_length(buf, len, &ptr, &count)) < 0)
return -1;
for (i = 0; i < count && total_count + i < ARRAY_LEN(bufs); i++) {
if ((stat1 = decode_open_type(buf, len, &ptr, &bufs[total_count + i], &lengths[total_count + i])) != 0) {
return -1;
}
/* valid secondaries can contain zero-length packets that should be ignored */
if (!bufs[total_count + i] || !lengths[total_count + i]) {
/* drop the count of items to process and reuse the buffers that were just set */
i--;
count--;
}
}
total_count += i;
}
while (stat2 > 0 && total_count < ARRAY_LEN(bufs));
/* Step through in reverse order, so we go oldest to newest */
for (i = total_count; i > 0; i--) {
if (seq_no - i >= s->rx_seq_no) {
/* This one wasn't seen before */
/* Decode the secondary IFP packet */
ast_debug(3, "Recovering lost packet via secondary %d, len %u\n", seq_no - i, lengths[i - 1]);
s->f[ifp_no].frametype = AST_FRAME_MODEM;
s->f[ifp_no].subclass.integer = AST_MODEM_T38;
s->f[ifp_no].mallocd = 0;
s->f[ifp_no].seqno = seq_no - i;
s->f[ifp_no].datalen = lengths[i - 1];
s->f[ifp_no].data.ptr = (uint8_t *) bufs[i - 1];
s->f[ifp_no].offset = 0;
s->f[ifp_no].src = "UDPTL";
if (ifp_no > 0)
AST_LIST_NEXT(&s->f[ifp_no - 1], frame_list) = &s->f[ifp_no];
AST_LIST_NEXT(&s->f[ifp_no], frame_list) = NULL;
ifp_no++;
}
}
}
}
else
{
int j;
int l;
int x;
/* FEC mode for error recovery */
/* Our buffers cannot tolerate overlength IFP packets in FEC mode */
if (ifp_len > LOCAL_FAX_MAX_DATAGRAM)
return -1;
/* Update any missed slots in the buffer */
for ( ; seq_no > s->rx_seq_no; s->rx_seq_no++) {
x = s->rx_seq_no & UDPTL_BUF_MASK;
s->rx[x].buf_len = -1;
s->rx[x].fec_len[0] = 0;
s->rx[x].fec_span = 0;
s->rx[x].fec_entries = 0;
}
x = seq_no & UDPTL_BUF_MASK;
memset(repaired, 0, sizeof(repaired));
/* Save the new IFP packet */
memcpy(s->rx[x].buf, ifp, ifp_len);
s->rx[x].buf_len = ifp_len;
repaired[x] = TRUE;
/* Decode the FEC packets */
/* The span is defined as an unconstrained integer, but will never be more
than a small value. */
if (ptr + 2 > len)
return -1;
if (buf[ptr++] != 1)
return -1;
span = buf[ptr++];
s->rx[x].fec_span = span;
/* The number of entries is defined as a length, but will only ever be a small
value. Treat it as such. */
if (ptr + 1 > len)
return -1;
entries = buf[ptr++];
if (entries > MAX_FEC_ENTRIES) {
return -1;
}
s->rx[x].fec_entries = entries;
/* Decode the elements */
for (i = 0; i < entries; i++) {
if ((stat1 = decode_open_type(buf, len, &ptr, &data, &s->rx[x].fec_len[i])) != 0)
return -1;
if (s->rx[x].fec_len[i] > LOCAL_FAX_MAX_DATAGRAM)
return -1;
/* Save the new FEC data */
memcpy(s->rx[x].fec[i], data, s->rx[x].fec_len[i]);
#if 0
fprintf(stderr, "FEC: ");
for (j = 0; j < s->rx[x].fec_len[i]; j++)
fprintf(stderr, "%02hhX ", data[j]);
fprintf(stderr, "\n");
#endif
}
/* See if we can reconstruct anything which is missing */
/* TODO: this does not comprehensively hunt back and repair everything that is possible */
for (l = x; l != ((x - (16 - span*entries)) & UDPTL_BUF_MASK); l = (l - 1) & UDPTL_BUF_MASK) {
int m;
if (s->rx[l].fec_len[0] <= 0)
continue;
for (m = 0; m < s->rx[l].fec_entries; m++) {
int k;
int which;
int limit = (l + m) & UDPTL_BUF_MASK;
/* only repair buffers that actually exist! */
if (seq_no <= (s->rx[l].fec_span * s->rx[l].fec_entries) - m) {
continue;
}
for (which = -1, k = (limit - s->rx[l].fec_span * s->rx[l].fec_entries) & UDPTL_BUF_MASK; k != limit; k = (k + s->rx[l].fec_entries) & UDPTL_BUF_MASK) {
if (s->rx[k].buf_len <= 0)
which = (which == -1) ? k : -2;
}
if (which >= 0) {
/* Repairable */
for (j = 0; j < s->rx[l].fec_len[m]; j++) {
s->rx[which].buf[j] = s->rx[l].fec[m][j];
for (k = (limit - s->rx[l].fec_span * s->rx[l].fec_entries) & UDPTL_BUF_MASK; k != limit; k = (k + s->rx[l].fec_entries) & UDPTL_BUF_MASK)
s->rx[which].buf[j] ^= (s->rx[k].buf_len > j) ? s->rx[k].buf[j] : 0;
}
s->rx[which].buf_len = s->rx[l].fec_len[m];
repaired[which] = TRUE;
}
}
}
/* Now play any new packets forwards in time */
for (l = (x + 1) & UDPTL_BUF_MASK, j = seq_no - UDPTL_BUF_MASK; l != x; l = (l + 1) & UDPTL_BUF_MASK, j++) {
if (repaired[l]) {
//fprintf(stderr, "Fixed packet %d, len %d\n", j, l);
s->f[ifp_no].frametype = AST_FRAME_MODEM;
s->f[ifp_no].subclass.integer = AST_MODEM_T38;
s->f[ifp_no].mallocd = 0;
s->f[ifp_no].seqno = j;
s->f[ifp_no].datalen = s->rx[l].buf_len;
s->f[ifp_no].data.ptr = s->rx[l].buf;
s->f[ifp_no].offset = 0;
s->f[ifp_no].src = "UDPTL";
if (ifp_no > 0)
AST_LIST_NEXT(&s->f[ifp_no - 1], frame_list) = &s->f[ifp_no];
AST_LIST_NEXT(&s->f[ifp_no], frame_list) = NULL;
ifp_no++;
}
}
}
/* If packets are received out of sequence, we may have already processed this packet from the error
recovery information in a packet already received. */
if (seq_no >= s->rx_seq_no) {
/* Decode the primary IFP packet */
s->f[ifp_no].frametype = AST_FRAME_MODEM;
s->f[ifp_no].subclass.integer = AST_MODEM_T38;
s->f[ifp_no].mallocd = 0;
s->f[ifp_no].seqno = seq_no;
s->f[ifp_no].datalen = ifp_len;
s->f[ifp_no].data.ptr = (uint8_t *) ifp;
s->f[ifp_no].offset = 0;
s->f[ifp_no].src = "UDPTL";
if (ifp_no > 0)
AST_LIST_NEXT(&s->f[ifp_no - 1], frame_list) = &s->f[ifp_no];
AST_LIST_NEXT(&s->f[ifp_no], frame_list) = NULL;
ifp_no++;
}
s->rx_seq_no = seq_no + 1;
return ifp_no;
}
/*- End of function --------------------------------------------------------*/
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
static int udptl_build_packet(struct ast_udptl *s, uint8_t *buf, unsigned int buflen, uint8_t *ifp, unsigned int ifp_len)
{
uint8_t fec[LOCAL_FAX_MAX_DATAGRAM * 2] = { 0, };
int i;
int j;
int seq;
int entry;
int entries;
int span;
int m;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int len;
int limit;
int high_tide;
seq = s->tx_seq_no & 0xFFFF;
/* Map the sequence number to an entry in the circular buffer */
entry = seq & UDPTL_BUF_MASK;
/* We save the message in a circular buffer, for generating FEC or
redundancy sets later on. */
s->tx[entry].buf_len = ifp_len;
memcpy(s->tx[entry].buf, ifp, ifp_len);
/* Build the UDPTLPacket */
len = 0;
/* Encode the sequence number */
buf[len++] = (seq >> 8) & 0xFF;
buf[len++] = seq & 0xFF;
/* Encode the primary IFP packet */
if (encode_open_type(s, buf, buflen, &len, ifp, ifp_len) < 0)
return -1;
/* Encode the appropriate type of error recovery information */
switch (s->error_correction_scheme)
{
case UDPTL_ERROR_CORRECTION_NONE:
/* Encode the error recovery type */
buf[len++] = 0x00;
/* The number of entries will always be zero, so it is pointless allowing
for the fragmented case here. */
clang compiler warnings: Fix autological comparisons This fixes autological comparison warnings in the following: * chan_skinny: letohl may return a signed or unsigned value, depending on the macro chosen * func_curl: Provide a specific cast to CURLoption to prevent mismatch * cel: Fix enum comparisons where the enum can never be negative * enum: Fix comparison of return result of dn_expand, which returns a signed int value * event: Fix enum comparisons where the enum can never be negative * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be negative * presencestate: Use the actual enum value for INVALID state * security_events: Fix enum comparisons where the enum can never be negative * udptl: Don't bother to check if the return value from encode_length is less than 0, as it returns an unsigned int * translate: Since the parameters are unsigned int, don't bother checking to see if they are negative. The cast to unsigned int would already blow past the matrix bounds. * res_pjsip_exten_state: Use a temporary value to cache the return of ast_hint_presence_state * res_stasis_playback: Fix enum comparisons where the enum can never be negative * res_stasis_recording: Add an enum value for the case where the recording operation is in error; fix enum comparisons * resource_bridges: Use enum value as opposed to -1 * resource_channels: Use enum value as opposed to -1 Review: https://reviewboard.asterisk.org/r/4533 ASTERISK-24917 Reported by: dkdegroot patches: rb4533.patch submitted by dkdegroot (License 6600) ........ Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-04-09 12:57:21 +00:00
encode_length(buf, &len, 0);
break;
case UDPTL_ERROR_CORRECTION_REDUNDANCY:
/* Encode the error recovery type */
buf[len++] = 0x00;
if (s->tx_seq_no > s->error_correction_entries)
entries = s->error_correction_entries;
else
entries = s->tx_seq_no;
/* The number of entries will always be small, so it is pointless allowing
for the fragmented case here. */
clang compiler warnings: Fix autological comparisons This fixes autological comparison warnings in the following: * chan_skinny: letohl may return a signed or unsigned value, depending on the macro chosen * func_curl: Provide a specific cast to CURLoption to prevent mismatch * cel: Fix enum comparisons where the enum can never be negative * enum: Fix comparison of return result of dn_expand, which returns a signed int value * event: Fix enum comparisons where the enum can never be negative * indications: tone_data.freq1 and freq2 are unsigned, and hence can never be negative * presencestate: Use the actual enum value for INVALID state * security_events: Fix enum comparisons where the enum can never be negative * udptl: Don't bother to check if the return value from encode_length is less than 0, as it returns an unsigned int * translate: Since the parameters are unsigned int, don't bother checking to see if they are negative. The cast to unsigned int would already blow past the matrix bounds. * res_pjsip_exten_state: Use a temporary value to cache the return of ast_hint_presence_state * res_stasis_playback: Fix enum comparisons where the enum can never be negative * res_stasis_recording: Add an enum value for the case where the recording operation is in error; fix enum comparisons * resource_bridges: Use enum value as opposed to -1 * resource_channels: Use enum value as opposed to -1 Review: https://reviewboard.asterisk.org/r/4533 ASTERISK-24917 Reported by: dkdegroot patches: rb4533.patch submitted by dkdegroot (License 6600) ........ Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2015-04-09 12:57:21 +00:00
encode_length(buf, &len, entries);
/* Encode the elements */
for (i = 0; i < entries; i++) {
j = (entry - i - 1) & UDPTL_BUF_MASK;
if (encode_open_type(s, buf, buflen, &len, s->tx[j].buf, s->tx[j].buf_len) < 0) {
ast_debug(1, "UDPTL (%s): Encoding failed at i=%d, j=%d\n",
LOG_TAG(s), i, j);
return -1;
}
}
break;
case UDPTL_ERROR_CORRECTION_FEC:
span = s->error_correction_span;
entries = s->error_correction_entries;
if (seq < s->error_correction_span*s->error_correction_entries) {
/* In the initial stages, wind up the FEC smoothly */
entries = seq/s->error_correction_span;
if (seq < s->error_correction_span)
span = 0;
}
/* Encode the error recovery type */
buf[len++] = 0x80;
/* Span is defined as an unconstrained integer, which it dumb. It will only
ever be a small value. Treat it as such. */
buf[len++] = 1;
buf[len++] = span;
/* The number of entries is defined as a length, but will only ever be a small
value. Treat it as such. */
buf[len++] = entries;
for (m = 0; m < entries; m++) {
/* Make an XOR'ed entry the maximum length */
limit = (entry + m) & UDPTL_BUF_MASK;
high_tide = 0;
for (i = (limit - span*entries) & UDPTL_BUF_MASK; i != limit; i = (i + entries) & UDPTL_BUF_MASK) {
if (high_tide < s->tx[i].buf_len) {
for (j = 0; j < high_tide; j++)
fec[j] ^= s->tx[i].buf[j];
for ( ; j < s->tx[i].buf_len; j++)
fec[j] = s->tx[i].buf[j];
high_tide = s->tx[i].buf_len;
} else {
for (j = 0; j < s->tx[i].buf_len; j++)
fec[j] ^= s->tx[i].buf[j];
}
}
if (encode_open_type(s, buf, buflen, &len, fec, high_tide) < 0)
return -1;
}
break;
}
s->tx_seq_no++;
return len;
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
int ast_udptl_fd(const struct ast_udptl *udptl)
{
return udptl->fd;
}
void ast_udptl_set_data(struct ast_udptl *udptl, void *data)
{
udptl->data = data;
}
void ast_udptl_set_callback(struct ast_udptl *udptl, ast_udptl_callback callback)
{
udptl->callback = callback;
}
void ast_udptl_setnat(struct ast_udptl *udptl, int nat)
{
udptl->nat = nat;
}
static int udptlread(int *id, int fd, short events, void *cbdata)
{
struct ast_udptl *udptl = cbdata;
struct ast_frame *f;
if ((f = ast_udptl_read(udptl))) {
if (udptl->callback)
udptl->callback(udptl, f, udptl->data);
}
return 1;
}
struct ast_frame *ast_udptl_read(struct ast_udptl *udptl)
{
int res;
struct ast_sockaddr addr;
uint8_t *buf;
buf = udptl->rawdata + AST_FRIENDLY_OFFSET;
/* Cache where the header will go */
res = ast_recvfrom(udptl->fd,
buf,
sizeof(udptl->rawdata) - AST_FRIENDLY_OFFSET,
0,
&addr);
if (res < 0) {
if (errno != EAGAIN)
ast_log(LOG_WARNING, "UDPTL (%s): read error: %s\n",
LOG_TAG(udptl), strerror(errno));
ast_assert(errno != EBADF);
return &ast_null_frame;
}
/* Ignore if the other side hasn't been given an address yet. */
if (ast_sockaddr_isnull(&udptl->them)) {
return &ast_null_frame;
}
/*
* If early media isn't turned on for the channel driver, it's going to
* drop this frame. By that time though, udptl has already incremented
* the expected sequence number so if the CPE re-sends, the second frame
* will be dropped as a dup even though the first frame never went through.
* So we drop the frame here if the channel isn't up. 'tag' is set by the
* channel drivers on T38_ENABLED or T38_PEER_REINVITE.
*/
if (udptl->tag == NULL) {
return &ast_null_frame;
}
if (udptl->nat) {
/* Send to whoever sent to us */
if (ast_sockaddr_cmp(&udptl->them, &addr)) {
ast_sockaddr_copy(&udptl->them, &addr);
ast_debug(1, "UDPTL (%s): NAT, Using address %s\n",
LOG_TAG(udptl), ast_sockaddr_stringify(&udptl->them));
}
}
if (udptl_debug_test_addr(&addr)) {
int seq_no;
/* Decode sequence number just for verbose message. */
if (res < 2) {
/* Short packet. */
seq_no = -1;
} else {
seq_no = (buf[0] << 8) | buf[1];
}
ast_verb(1, "UDPTL (%s): packet from %s (seq %d, len %d)\n",
LOG_TAG(udptl), ast_sockaddr_stringify(&addr), seq_no, res);
}
if (udptl_rx_packet(udptl, buf, res) < 1) {
return &ast_null_frame;
}
return &udptl->f[0];
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
static void calculate_local_max_datagram(struct ast_udptl *udptl)
{
Allow non-compliant T.38 endpoints to be supportable via configuration option. Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept as the T38FaxMaxDatagram value in their SDP, when in fact this value is supposed to be the maximum UDPTL payload size (datagram size) they can accept. If the value they supply is small enough (a commonly supplied value is '72'), T.38 UDPTL transmissions will likely fail completely because the UDPTL packets will not have enough room for a primary IFP frame and the redundancy used for error correction. If this occurs, the Asterisk UDPTL stack will emit log messages warning that data loss may occur, and that the value may need to be overridden. This patch extends the 't38pt_udptl' configuration option in sip.conf to allow the administrator to override the value supplied by the remote endpoint and supply a value that allows T.38 FAX transmissions to be successful with that endpoint. In addition, in any SIP call where the override takes effect, a debug message will be printed to that effect. This patch also removes the T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not actually had any effect for a number of releases. In addition, this patch cleans up the T.38 documentation in sip.conf.sample (which incorrectly documented that T.38 support was passthrough only). (issue #15586) Reported by: globalnetinc git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-10-05 19:45:00 +00:00
unsigned int new_max = 0;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
if (udptl->local_max_ifp == -1) {
ast_log(LOG_WARNING, "UDPTL (%s): Cannot calculate local_max_datagram before local_max_ifp has been set.\n",
LOG_TAG(udptl));
udptl->local_max_datagram = -1;
return;
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
/* calculate the amount of space required to receive an IFP
* of the maximum size supported by the application/endpoint
* that we are delivering them to (local endpoint), and add
* the amount of space required to support the selected
* error correction mode
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
switch (udptl->error_correction_scheme) {
case UDPTL_ERROR_CORRECTION_NONE:
/* need room for sequence number, length indicator, redundancy
* indicator and following length indicator
*/
new_max = 5 + udptl->local_max_ifp;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
break;
case UDPTL_ERROR_CORRECTION_REDUNDANCY:
/* need room for sequence number, length indicators, plus
* room for up to 3 redundancy packets
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
new_max = 5 + udptl->local_max_ifp + 2 + (3 * udptl->local_max_ifp);
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
break;
case UDPTL_ERROR_CORRECTION_FEC:
/* need room for sequence number, length indicators and a
* a single IFP of the maximum size expected
*/
new_max = 5 + udptl->local_max_ifp + 4 + udptl->local_max_ifp;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
break;
}
/* add 5% extra space for insurance, but no larger than LOCAL_FAX_MAX_DATAGRAM */
udptl->local_max_datagram = MIN(new_max * 1.05, LOCAL_FAX_MAX_DATAGRAM);
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
}
static void calculate_far_max_ifp(struct ast_udptl *udptl)
{
Allow non-compliant T.38 endpoints to be supportable via configuration option. Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept as the T38FaxMaxDatagram value in their SDP, when in fact this value is supposed to be the maximum UDPTL payload size (datagram size) they can accept. If the value they supply is small enough (a commonly supplied value is '72'), T.38 UDPTL transmissions will likely fail completely because the UDPTL packets will not have enough room for a primary IFP frame and the redundancy used for error correction. If this occurs, the Asterisk UDPTL stack will emit log messages warning that data loss may occur, and that the value may need to be overridden. This patch extends the 't38pt_udptl' configuration option in sip.conf to allow the administrator to override the value supplied by the remote endpoint and supply a value that allows T.38 FAX transmissions to be successful with that endpoint. In addition, in any SIP call where the override takes effect, a debug message will be printed to that effect. This patch also removes the T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not actually had any effect for a number of releases. In addition, this patch cleans up the T.38 documentation in sip.conf.sample (which incorrectly documented that T.38 support was passthrough only). (issue #15586) Reported by: globalnetinc git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-10-05 19:45:00 +00:00
unsigned new_max = 0;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
if (udptl->far_max_datagram == -1) {
ast_log(LOG_WARNING, "UDPTL (%s): Cannot calculate far_max_ifp before far_max_datagram has been set.\n",
LOG_TAG(udptl));
udptl->far_max_ifp = -1;
return;
}
/* the goal here is to supply the local endpoint (application
* or bridged channel) a maximum IFP value that will allow it
* to effectively and efficiently transfer image data at its
* selected bit rate, taking into account the selected error
* correction mode, but without overrunning the far endpoint's
* datagram buffer. this is complicated by the fact that some
* far endpoints send us bogus (small) max datagram values,
* which would result in either buffer overrun or no error
* correction. we try to accomodate those, but if the supplied
* value is too small to do so, we'll emit warning messages and
* the user will have to use configuration options to override
* the max datagram value supplied by the far endpoint.
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
switch (udptl->error_correction_scheme) {
case UDPTL_ERROR_CORRECTION_NONE:
/* need room for sequence number, length indicator, redundancy
* indicator and following length indicator
*/
new_max = udptl->far_max_datagram - 5;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
break;
case UDPTL_ERROR_CORRECTION_REDUNDANCY:
/* for this case, we'd like to send as many error correction entries
* as possible (up to the number we're configured for), but we'll settle
* for sending fewer if the configured number would cause the
* calculated max IFP to be too small for effective operation
*
* need room for sequence number, length indicators and the
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
* configured number of redundant packets
*
* note: we purposely don't allow error_correction_entries to drop to
* zero in this loop; we'd rather send smaller IFPs (and thus reduce
* the image data transfer rate) than sacrifice redundancy completely
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
*/
for (;;) {
new_max = (udptl->far_max_datagram - 8) / (udptl->error_correction_entries + 1);
if ((new_max < 80) && (udptl->error_correction_entries > 1)) {
/* the max ifp is not large enough, subtract an
* error correction entry and calculate again
* */
--udptl->error_correction_entries;
} else {
break;
}
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
break;
case UDPTL_ERROR_CORRECTION_FEC:
/* need room for sequence number, length indicators and a
* a single IFP of the maximum size expected
*/
Allow non-compliant T.38 endpoints to be supportable via configuration option. Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept as the T38FaxMaxDatagram value in their SDP, when in fact this value is supposed to be the maximum UDPTL payload size (datagram size) they can accept. If the value they supply is small enough (a commonly supplied value is '72'), T.38 UDPTL transmissions will likely fail completely because the UDPTL packets will not have enough room for a primary IFP frame and the redundancy used for error correction. If this occurs, the Asterisk UDPTL stack will emit log messages warning that data loss may occur, and that the value may need to be overridden. This patch extends the 't38pt_udptl' configuration option in sip.conf to allow the administrator to override the value supplied by the remote endpoint and supply a value that allows T.38 FAX transmissions to be successful with that endpoint. In addition, in any SIP call where the override takes effect, a debug message will be printed to that effect. This patch also removes the T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not actually had any effect for a number of releases. In addition, this patch cleans up the T.38 documentation in sip.conf.sample (which incorrectly documented that T.38 support was passthrough only). (issue #15586) Reported by: globalnetinc git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-10-05 19:45:00 +00:00
new_max = (udptl->far_max_datagram - 10) / 2;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
break;
}
/* subtract 5% of space for insurance */
udptl->far_max_ifp = new_max * 0.95;
}
enum ast_t38_ec_modes ast_udptl_get_error_correction_scheme(const struct ast_udptl *udptl)
{
return udptl->error_correction_scheme;
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
void ast_udptl_set_error_correction_scheme(struct ast_udptl *udptl, enum ast_t38_ec_modes ec)
{
udptl->error_correction_scheme = ec;
switch (ec) {
case UDPTL_ERROR_CORRECTION_FEC:
udptl->error_correction_scheme = UDPTL_ERROR_CORRECTION_FEC;
if (udptl->error_correction_entries == 0) {
udptl->error_correction_entries = 3;
}
if (udptl->error_correction_span == 0) {
udptl->error_correction_span = 3;
}
break;
case UDPTL_ERROR_CORRECTION_REDUNDANCY:
udptl->error_correction_scheme = UDPTL_ERROR_CORRECTION_REDUNDANCY;
if (udptl->error_correction_entries == 0) {
udptl->error_correction_entries = 3;
}
break;
default:
/* nothing to do */
break;
};
/* reset calculated values so they'll be computed again */
udptl->local_max_datagram = -1;
udptl->far_max_ifp = -1;
}
void ast_udptl_set_local_max_ifp(struct ast_udptl *udptl, unsigned int max_ifp)
{
/* make sure max_ifp is a positive value since a cast will take place when
* when setting local_max_ifp */
if ((signed int) max_ifp > 0) {
udptl->local_max_ifp = max_ifp;
/* reset calculated values so they'll be computed again */
udptl->local_max_datagram = -1;
}
}
unsigned int ast_udptl_get_local_max_datagram(struct ast_udptl *udptl)
{
if (udptl->local_max_datagram == -1) {
calculate_local_max_datagram(udptl);
}
/* this function expects a unsigned value in return. */
if (udptl->local_max_datagram < 0) {
return 0;
}
return udptl->local_max_datagram;
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
void ast_udptl_set_far_max_datagram(struct ast_udptl *udptl, unsigned int max_datagram)
{
if (!max_datagram || (max_datagram > FAX_MAX_DATAGRAM_LIMIT)) {
udptl->far_max_datagram = DEFAULT_FAX_MAX_DATAGRAM;
} else {
udptl->far_max_datagram = max_datagram;
}
/* reset calculated values so they'll be computed again */
udptl->far_max_ifp = -1;
}
unsigned int ast_udptl_get_far_max_datagram(const struct ast_udptl *udptl)
{
if (udptl->far_max_datagram < 0) {
return 0;
}
return udptl->far_max_datagram;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
}
unsigned int ast_udptl_get_far_max_ifp(struct ast_udptl *udptl)
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
{
if (udptl->far_max_ifp == -1) {
calculate_far_max_ifp(udptl);
}
if (udptl->far_max_ifp < 0) {
return 0;
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
return udptl->far_max_ifp;
}
struct ast_udptl *ast_udptl_new_with_bindaddr(struct ast_sched_context *sched, struct io_context *io, int callbackmode, struct ast_sockaddr *addr)
{
struct ast_udptl *udptl;
int x;
int startplace;
int i;
RAII_VAR(struct udptl_config *, cfg, ao2_global_obj_ref(globals), ao2_cleanup);
if (!cfg || !cfg->general) {
ast_log(LOG_ERROR, "Could not access global udptl options!\n");
return NULL;
}
if (!(udptl = ast_calloc(1, sizeof(*udptl)))) {
return NULL;
}
udptl->error_correction_span = cfg->general->fecspan;
udptl->error_correction_entries = cfg->general->fecentries;
udptl->far_max_datagram = -1;
udptl->far_max_ifp = -1;
udptl->local_max_ifp = -1;
udptl->local_max_datagram = -1;
for (i = 0; i <= UDPTL_BUF_MASK; i++) {
udptl->rx[i].buf_len = -1;
udptl->tx[i].buf_len = -1;
}
if ((udptl->fd = ast_socket_nonblock(ast_sockaddr_is_ipv6(addr) ?
AF_INET6 : AF_INET, SOCK_DGRAM, 0)) < 0) {
ast_free(udptl);
ast_log(LOG_WARNING, "Unable to allocate socket: %s\n", strerror(errno));
return NULL;
}
#ifdef SO_NO_CHECK
if (cfg->general->nochecksums)
setsockopt(udptl->fd, SOL_SOCKET, SO_NO_CHECK, &cfg->general->nochecksums, sizeof(cfg->general->nochecksums));
#endif
/* Find us a place */
x = (cfg->general->start == cfg->general->end) ? cfg->general->start : (ast_random() % (cfg->general->end - cfg->general->start)) + cfg->general->start;
if (cfg->general->use_even_ports && (x & 1)) {
++x;
}
startplace = x;
for (;;) {
ast_sockaddr_copy(&udptl->us, addr);
ast_sockaddr_set_port(&udptl->us, x);
if (ast_bind(udptl->fd, &udptl->us) == 0) {
break;
}
if (errno != EADDRINUSE && errno != EACCES) {
ast_log(LOG_WARNING, "Unexpected bind error: %s\n", strerror(errno));
close(udptl->fd);
ast_free(udptl);
return NULL;
}
if (cfg->general->use_even_ports) {
x += 2;
} else {
++x;
}
if (x > cfg->general->end)
x = cfg->general->start;
if (x == startplace) {
ast_log(LOG_WARNING, "No UDPTL ports remaining\n");
close(udptl->fd);
ast_free(udptl);
return NULL;
}
}
if (io && sched && callbackmode) {
/* Operate this one in a callback mode */
udptl->sched = sched;
udptl->io = io;
udptl->ioid = ast_io_add(udptl->io, udptl->fd, udptlread, AST_IO_IN, udptl);
}
return udptl;
}
void ast_udptl_set_tag(struct ast_udptl *udptl, const char *format, ...)
{
va_list ap;
ast_free(udptl->tag);
udptl->tag = NULL;
va_start(ap, format);
if (ast_vasprintf(&udptl->tag, format, ap) == -1) {
udptl->tag = NULL;
}
va_end(ap);
}
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
int ast_udptl_setqos(struct ast_udptl *udptl, unsigned int tos, unsigned int cos)
{
return ast_set_qos(udptl->fd, tos, cos, "UDPTL");
}
void ast_udptl_set_peer(struct ast_udptl *udptl, const struct ast_sockaddr *them)
{
ast_sockaddr_copy(&udptl->them, them);
}
void ast_udptl_get_peer(const struct ast_udptl *udptl, struct ast_sockaddr *them)
{
ast_sockaddr_copy(them, &udptl->them);
}
void ast_udptl_get_us(const struct ast_udptl *udptl, struct ast_sockaddr *us)
{
ast_sockaddr_copy(us, &udptl->us);
}
void ast_udptl_stop(struct ast_udptl *udptl)
{
ast_sockaddr_setnull(&udptl->them);
}
void ast_udptl_destroy(struct ast_udptl *udptl)
{
if (udptl->ioid)
ast_io_remove(udptl->io, udptl->ioid);
if (udptl->fd > -1)
close(udptl->fd);
if (udptl->tag)
ast_free(udptl->tag);
ast_free(udptl);
}
int ast_udptl_write(struct ast_udptl *s, struct ast_frame *f)
{
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
unsigned int seq;
unsigned int len = f->datalen;
/* if no max datagram size is provided, use default value */
const int bufsize = (s->far_max_datagram > 0) ? s->far_max_datagram : DEFAULT_FAX_MAX_DATAGRAM;
uint8_t buf[bufsize];
memset(buf, 0, sizeof(buf));
/* If we have no peer, return immediately */
if (ast_sockaddr_isnull(&s->them)) {
return 0;
}
/* If there is no data length, return immediately */
if (f->datalen == 0)
return 0;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
if ((f->frametype != AST_FRAME_MODEM) ||
(f->subclass.integer != AST_MODEM_T38)) {
ast_log(LOG_WARNING, "UDPTL (%s): UDPTL can only send T.38 data.\n",
LOG_TAG(s));
return -1;
}
if (len > s->far_max_ifp) {
Allow non-compliant T.38 endpoints to be supportable via configuration option. Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept as the T38FaxMaxDatagram value in their SDP, when in fact this value is supposed to be the maximum UDPTL payload size (datagram size) they can accept. If the value they supply is small enough (a commonly supplied value is '72'), T.38 UDPTL transmissions will likely fail completely because the UDPTL packets will not have enough room for a primary IFP frame and the redundancy used for error correction. If this occurs, the Asterisk UDPTL stack will emit log messages warning that data loss may occur, and that the value may need to be overridden. This patch extends the 't38pt_udptl' configuration option in sip.conf to allow the administrator to override the value supplied by the remote endpoint and supply a value that allows T.38 FAX transmissions to be successful with that endpoint. In addition, in any SIP call where the override takes effect, a debug message will be printed to that effect. This patch also removes the T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not actually had any effect for a number of releases. In addition, this patch cleans up the T.38 documentation in sip.conf.sample (which incorrectly documented that T.38 support was passthrough only). (issue #15586) Reported by: globalnetinc git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-10-05 19:45:00 +00:00
ast_log(LOG_WARNING,
"UDPTL (%s): UDPTL asked to send %u bytes of IFP when far end only prepared to accept %d bytes; data loss will occur."
"You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration.\n",
LOG_TAG(s), len, s->far_max_ifp);
len = s->far_max_ifp;
Rework of T.38 negotiation and UDPTL API to address interoperability problems Over the past couple of months, a number of issues with Asterisk negotiating (and successfully completing) T.38 sessions with various endpoints have been found. This patch attempts to address many of them, primarily focused around ensuring that the endpoints' MaxDatagram size is honored, and in addition by ensuring that T.38 session parameter negotiation is performed correctly according to the ITU T.38 Recommendation. The major changes here are: 1) T.38 applications in Asterisk (app_fax) only generate/receive IFP packets, they do not ever work with UDPTL packets. As a result of this, they cannot be allowed to generate packets that would overflow the other endpoints' MaxDatagram size after the UDPTL stack adds any error correction information. With this patch, the application is told the maximum *IFP* size it can generate, based on a calculation using the far end MaxDatagram size and the active error correction mode on the T.38 session. The same is true for sending *our* MaxDatagram size to the remote endpoint; it is computed from the value that the application says it can accept (for a single IFP packet) combined with the active error correction mode. 2) All treatment of T.38 session parameters as 'capabilities' in chan_sip has been removed; these parameters are not at all like audio/video stream capabilities. There are strict rules to follow for computing an answer to a T.38 offer, and chan_sip now follows those rules, using the desired parameters from the application (or channel) that wants to accept the T.38 negotiation. 3) chan_sip now stores and forwards ast_control_t38_parameters structures for tracking 'our' and 'their' T.38 session parameters; this greatly simplifies negotiation, especially for pass-through calls. 4) Since T.38 negotiation without specifying parameters or receiving the final negotiated parameters is not very worthwhile, the AST_CONTROL_T38 control frame has been removed. A note has been added to UPGRADE.txt about this removal, since any out-of-tree applications that use it will no longer function properly until they are upgraded to use AST_CONTROL_T38_PARAMETERS. Review: https://reviewboard.asterisk.org/r/310/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2009-07-23 21:57:24 +00:00
}
/* Save seq_no for debug output because udptl_build_packet increments it */
seq = s->tx_seq_no & 0xFFFF;
/* Cook up the UDPTL packet, with the relevant EC info. */
len = udptl_build_packet(s, buf, sizeof(buf), f->data.ptr, len);
if ((signed int) len > 0 && !ast_sockaddr_isnull(&s->them)) {
if (ast_sendto(s->fd, buf, len, 0, &s->them) < 0) {
ast_log(LOG_NOTICE, "UDPTL (%s): Transmission error to %s: %s\n",
LOG_TAG(s), ast_sockaddr_stringify(&s->them), strerror(errno));
}
if (udptl_debug_test_addr(&s->them)) {
ast_verb(1, "UDPTL (%s): packet to %s (seq %u, len %u)\n",
LOG_TAG(s), ast_sockaddr_stringify(&s->them), seq, len);
}
}
return 0;
}
static char *handle_cli_udptl_set_debug(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)
Merge a ton of NEW_CLI conversions. Thanks to everyone that helped out! :) (closes issue #10724) Reported by: eliel Patches: chan_skinny.c.patch uploaded by eliel (license 64) chan_oss.c.patch uploaded by eliel (license 64) chan_mgcp.c.patch2 uploaded by eliel (license 64) pbx_config.c.patch uploaded by seanbright (license 71) iax2-provision.c.patch uploaded by eliel (license 64) chan_gtalk.c.patch uploaded by eliel (license 64) pbx_ael.c.patch uploaded by seanbright (license 71) file.c.patch uploaded by seanbright (license 71) image.c.patch uploaded by seanbright (license 71) cli.c.patch uploaded by moy (license 222) astobj2.c.patch uploaded by moy (license 222) asterisk.c.patch uploaded by moy (license 222) res_limit.c.patch uploaded by seanbright (license 71) res_convert.c.patch uploaded by seanbright (license 71) res_crypto.c.patch uploaded by seanbright (license 71) app_osplookup.c.patch uploaded by seanbright (license 71) app_rpt.c.patch uploaded by seanbright (license 71) app_mixmonitor.c.patch uploaded by seanbright (license 71) channel.c.patch uploaded by seanbright (license 71) translate.c.patch uploaded by seanbright (license 71) udptl.c.patch uploaded by seanbright (license 71) threadstorage.c.patch uploaded by seanbright (license 71) db.c.patch uploaded by seanbright (license 71) cdr.c.patch uploaded by moy (license 222) pbd_dundi.c.patch uploaded by moy (license 222) app_osplookup-rev83558.patch uploaded by moy (license 222) res_clioriginate.c.patch uploaded by moy (license 222) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-11 19:03:06 +00:00
{
switch (cmd) {
case CLI_INIT:
e->command = "udptl set debug {on|off|ip}";
e->usage =
"Usage: udptl set debug {on|off|ip host[:port]}\n"
" Enable or disable dumping of UDPTL packets.\n"
" If ip is specified, limit the dumped packets to those to and from\n"
" the specified 'host' with optional port.\n";
Merge a ton of NEW_CLI conversions. Thanks to everyone that helped out! :) (closes issue #10724) Reported by: eliel Patches: chan_skinny.c.patch uploaded by eliel (license 64) chan_oss.c.patch uploaded by eliel (license 64) chan_mgcp.c.patch2 uploaded by eliel (license 64) pbx_config.c.patch uploaded by seanbright (license 71) iax2-provision.c.patch uploaded by eliel (license 64) chan_gtalk.c.patch uploaded by eliel (license 64) pbx_ael.c.patch uploaded by seanbright (license 71) file.c.patch uploaded by seanbright (license 71) image.c.patch uploaded by seanbright (license 71) cli.c.patch uploaded by moy (license 222) astobj2.c.patch uploaded by moy (license 222) asterisk.c.patch uploaded by moy (license 222) res_limit.c.patch uploaded by seanbright (license 71) res_convert.c.patch uploaded by seanbright (license 71) res_crypto.c.patch uploaded by seanbright (license 71) app_osplookup.c.patch uploaded by seanbright (license 71) app_rpt.c.patch uploaded by seanbright (license 71) app_mixmonitor.c.patch uploaded by seanbright (license 71) channel.c.patch uploaded by seanbright (license 71) translate.c.patch uploaded by seanbright (license 71) udptl.c.patch uploaded by seanbright (license 71) threadstorage.c.patch uploaded by seanbright (license 71) db.c.patch uploaded by seanbright (license 71) cdr.c.patch uploaded by moy (license 222) pbd_dundi.c.patch uploaded by moy (license 222) app_osplookup-rev83558.patch uploaded by moy (license 222) res_clioriginate.c.patch uploaded by moy (license 222) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-11 19:03:06 +00:00
return NULL;
case CLI_GENERATE:
return NULL;
}
if (a->argc < 4 || a->argc > 5)
Merge a ton of NEW_CLI conversions. Thanks to everyone that helped out! :) (closes issue #10724) Reported by: eliel Patches: chan_skinny.c.patch uploaded by eliel (license 64) chan_oss.c.patch uploaded by eliel (license 64) chan_mgcp.c.patch2 uploaded by eliel (license 64) pbx_config.c.patch uploaded by seanbright (license 71) iax2-provision.c.patch uploaded by eliel (license 64) chan_gtalk.c.patch uploaded by eliel (license 64) pbx_ael.c.patch uploaded by seanbright (license 71) file.c.patch uploaded by seanbright (license 71) image.c.patch uploaded by seanbright (license 71) cli.c.patch uploaded by moy (license 222) astobj2.c.patch uploaded by moy (license 222) asterisk.c.patch uploaded by moy (license 222) res_limit.c.patch uploaded by seanbright (license 71) res_convert.c.patch uploaded by seanbright (license 71) res_crypto.c.patch uploaded by seanbright (license 71) app_osplookup.c.patch uploaded by seanbright (license 71) app_rpt.c.patch uploaded by seanbright (license 71) app_mixmonitor.c.patch uploaded by seanbright (license 71) channel.c.patch uploaded by seanbright (license 71) translate.c.patch uploaded by seanbright (license 71) udptl.c.patch uploaded by seanbright (license 71) threadstorage.c.patch uploaded by seanbright (license 71) db.c.patch uploaded by seanbright (license 71) cdr.c.patch uploaded by moy (license 222) pbd_dundi.c.patch uploaded by moy (license 222) app_osplookup-rev83558.patch uploaded by moy (license 222) res_clioriginate.c.patch uploaded by moy (license 222) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-11 19:03:06 +00:00
return CLI_SHOWUSAGE;
if (a->argc == 4) {
if (!strncasecmp(a->argv[3], "on", 2)) {
udptldebug = 1;
memset(&udptldebugaddr, 0, sizeof(udptldebugaddr));
ast_cli(a->fd, "UDPTL Debugging Enabled\n");
} else if (!strncasecmp(a->argv[3], "off", 3)) {
udptldebug = 0;
ast_cli(a->fd, "UDPTL Debugging Disabled\n");
} else {
return CLI_SHOWUSAGE;
}
} else {
struct ast_sockaddr *addrs;
if (strncasecmp(a->argv[3], "ip", 2))
return CLI_SHOWUSAGE;
if (!ast_sockaddr_resolve(&addrs, a->argv[4], 0, 0)) {
return CLI_SHOWUSAGE;
}
ast_sockaddr_copy(&udptldebugaddr, &addrs[0]);
ast_cli(a->fd, "UDPTL Debugging Enabled for IP: %s\n", ast_sockaddr_stringify(&udptldebugaddr));
udptldebug = 1;
ast_free(addrs);
}
Merge a ton of NEW_CLI conversions. Thanks to everyone that helped out! :) (closes issue #10724) Reported by: eliel Patches: chan_skinny.c.patch uploaded by eliel (license 64) chan_oss.c.patch uploaded by eliel (license 64) chan_mgcp.c.patch2 uploaded by eliel (license 64) pbx_config.c.patch uploaded by seanbright (license 71) iax2-provision.c.patch uploaded by eliel (license 64) chan_gtalk.c.patch uploaded by eliel (license 64) pbx_ael.c.patch uploaded by seanbright (license 71) file.c.patch uploaded by seanbright (license 71) image.c.patch uploaded by seanbright (license 71) cli.c.patch uploaded by moy (license 222) astobj2.c.patch uploaded by moy (license 222) asterisk.c.patch uploaded by moy (license 222) res_limit.c.patch uploaded by seanbright (license 71) res_convert.c.patch uploaded by seanbright (license 71) res_crypto.c.patch uploaded by seanbright (license 71) app_osplookup.c.patch uploaded by seanbright (license 71) app_rpt.c.patch uploaded by seanbright (license 71) app_mixmonitor.c.patch uploaded by seanbright (license 71) channel.c.patch uploaded by seanbright (license 71) translate.c.patch uploaded by seanbright (license 71) udptl.c.patch uploaded by seanbright (license 71) threadstorage.c.patch uploaded by seanbright (license 71) db.c.patch uploaded by seanbright (license 71) cdr.c.patch uploaded by moy (license 222) pbd_dundi.c.patch uploaded by moy (license 222) app_osplookup-rev83558.patch uploaded by moy (license 222) res_clioriginate.c.patch uploaded by moy (license 222) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-11 19:03:06 +00:00
return CLI_SUCCESS;
}
static char *handle_cli_show_config(struct ast_cli_entry *e, int cmd, struct ast_cli_args *a)
{
RAII_VAR(struct udptl_config *, cfg, NULL, ao2_cleanup);
switch (cmd) {
case CLI_INIT:
e->command = "udptl show config";
e->usage =
"Usage: udptl show config\n"
" Display UDPTL configuration options\n";
return NULL;
case CLI_GENERATE:
return NULL;
}
if (!(cfg = ao2_global_obj_ref(globals))) {
return CLI_FAILURE;
}
ast_cli(a->fd, "UDPTL Global options\n");
ast_cli(a->fd, "--------------------\n");
ast_cli(a->fd, "udptlstart: %u\n", cfg->general->start);
ast_cli(a->fd, "udptlend: %u\n", cfg->general->end);
ast_cli(a->fd, "udptlfecentries: %u\n", cfg->general->fecentries);
ast_cli(a->fd, "udptlfecspan: %u\n", cfg->general->fecspan);
ast_cli(a->fd, "use_even_ports: %s\n", AST_CLI_YESNO(cfg->general->use_even_ports));
ast_cli(a->fd, "udptlchecksums: %s\n", AST_CLI_YESNO(!cfg->general->nochecksums));
return CLI_SUCCESS;
}
Merge a ton of NEW_CLI conversions. Thanks to everyone that helped out! :) (closes issue #10724) Reported by: eliel Patches: chan_skinny.c.patch uploaded by eliel (license 64) chan_oss.c.patch uploaded by eliel (license 64) chan_mgcp.c.patch2 uploaded by eliel (license 64) pbx_config.c.patch uploaded by seanbright (license 71) iax2-provision.c.patch uploaded by eliel (license 64) chan_gtalk.c.patch uploaded by eliel (license 64) pbx_ael.c.patch uploaded by seanbright (license 71) file.c.patch uploaded by seanbright (license 71) image.c.patch uploaded by seanbright (license 71) cli.c.patch uploaded by moy (license 222) astobj2.c.patch uploaded by moy (license 222) asterisk.c.patch uploaded by moy (license 222) res_limit.c.patch uploaded by seanbright (license 71) res_convert.c.patch uploaded by seanbright (license 71) res_crypto.c.patch uploaded by seanbright (license 71) app_osplookup.c.patch uploaded by seanbright (license 71) app_rpt.c.patch uploaded by seanbright (license 71) app_mixmonitor.c.patch uploaded by seanbright (license 71) channel.c.patch uploaded by seanbright (license 71) translate.c.patch uploaded by seanbright (license 71) udptl.c.patch uploaded by seanbright (license 71) threadstorage.c.patch uploaded by seanbright (license 71) db.c.patch uploaded by seanbright (license 71) cdr.c.patch uploaded by moy (license 222) pbd_dundi.c.patch uploaded by moy (license 222) app_osplookup-rev83558.patch uploaded by moy (license 222) res_clioriginate.c.patch uploaded by moy (license 222) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@85460 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2007-10-11 19:03:06 +00:00
static struct ast_cli_entry cli_udptl[] = {
AST_CLI_DEFINE(handle_cli_udptl_set_debug, "Enable/Disable UDPTL debugging"),
AST_CLI_DEFINE(handle_cli_show_config, "Show UDPTL config options"),
};
static void udptl_config_destructor(void *obj)
{
struct udptl_config *cfg = obj;
ao2_cleanup(cfg->general);
}
static void *udptl_snapshot_alloc(void)
{
struct udptl_config *cfg;
if (!(cfg = ao2_alloc(sizeof(*cfg), udptl_config_destructor))) {
return NULL;
}
if (!(cfg->general = ao2_alloc(sizeof(*cfg->general), NULL))) {
ao2_ref(cfg, -1);
return NULL;
}
return cfg;
}
static int removed_options_handler(const struct aco_option *opt, struct ast_variable *var, void *obj)
{
if (!strcasecmp(var->name, "t38faxudpec")) {
ast_log(LOG_WARNING, "t38faxudpec in udptl.conf is no longer supported.\n");
} else if (!strcasecmp(var->name, "t38faxmaxdatagram")) {
ast_log(LOG_WARNING, "t38faxmaxdatagram in udptl.conf is no longer supported; value is now supplied by T.38 applications.\n");
}
return 0;
}
static void __ast_udptl_reload(int reload)
{
if (aco_process_config(&cfg_info, reload) == ACO_PROCESS_ERROR) {
if (!reload) {
RAII_VAR(struct udptl_config *, udptl_cfg, udptl_snapshot_alloc(), ao2_cleanup);
if (aco_set_defaults(&general_option, "general", udptl_cfg->general)) {
ast_log(LOG_ERROR, "Failed to load udptl.conf and failed to initialize defaults.\n");
return;
}
ast_log(LOG_NOTICE, "Could not load udptl config; using defaults\n");
ao2_global_obj_replace_unref(globals, udptl_cfg);
}
}
}
static int udptl_pre_apply_config(void) {
struct udptl_config *cfg = aco_pending_config(&cfg_info);
if (!cfg->general) {
return -1;
}
#ifndef SO_NO_CHECK
if (cfg->general->nochecksums) {
ast_log(LOG_WARNING, "Disabling UDPTL checksums is not supported on this operating system!\n");
cfg->general->nochecksums = 0;
}
#endif
/* Fix up any global config values that we can handle before replacing the config */
if (cfg->general->use_even_ports && (cfg->general->start & 1)) {
++cfg->general->start;
ast_log(LOG_NOTICE, "Odd numbered udptlstart specified but use_even_ports enabled. udptlstart is now %u\n", cfg->general->start);
}
if (cfg->general->start > cfg->general->end) {
ast_log(LOG_WARNING, "Unreasonable values for UDPTL start/end ports; defaulting to %s-%s.\n", __stringify(DEFAULT_UDPTLSTART), __stringify(DEFAULT_UDPTLEND));
cfg->general->start = DEFAULT_UDPTLSTART;
cfg->general->end = DEFAULT_UDPTLEND;
}
if (cfg->general->use_even_ports && (cfg->general->end & 1)) {
--cfg->general->end;
ast_log(LOG_NOTICE, "Odd numbered udptlend specified but use_even_ports enabled. udptlend is now %u\n", cfg->general->end);
}
return 0;
}
static int reload_module(void)
{
__ast_udptl_reload(1);
return 0;
}
/*!
* \internal
* \brief Clean up resources on Asterisk shutdown
*/
static int unload_module(void)
{
ast_cli_unregister_multiple(cli_udptl, ARRAY_LEN(cli_udptl));
ao2_t_global_obj_release(globals, "Unref udptl global container in shutdown");
aco_info_destroy(&cfg_info);
return 0;
}
static int load_module(void)
{
if (aco_info_init(&cfg_info)) {
return AST_MODULE_LOAD_FAILURE;
}
aco_option_register(&cfg_info, "udptlstart", ACO_EXACT, general_options, __stringify(DEFAULT_UDPTLSTART),
OPT_UINT_T, PARSE_IN_RANGE | PARSE_DEFAULT,
FLDSET(struct udptl_global_options, start), DEFAULT_UDPTLSTART, 1024, 65535);
aco_option_register(&cfg_info, "udptlend", ACO_EXACT, general_options, __stringify(DEFAULT_UDPTLEND),
OPT_UINT_T, PARSE_IN_RANGE | PARSE_DEFAULT,
FLDSET(struct udptl_global_options, end), DEFAULT_UDPTLEND, 1024, 65535);
aco_option_register(&cfg_info, "udptlfecentries", ACO_EXACT, general_options, NULL,
OPT_UINT_T, PARSE_IN_RANGE | PARSE_RANGE_DEFAULTS,
FLDSET(struct udptl_global_options, fecentries), 1, MAX_FEC_ENTRIES);
aco_option_register(&cfg_info, "udptlfecspan", ACO_EXACT, general_options, NULL,
OPT_UINT_T, PARSE_IN_RANGE | PARSE_RANGE_DEFAULTS,
FLDSET(struct udptl_global_options, fecspan), 1, MAX_FEC_SPAN);
aco_option_register(&cfg_info, "udptlchecksums", ACO_EXACT, general_options, "yes",
OPT_BOOL_T, 0, FLDSET(struct udptl_global_options, nochecksums));
aco_option_register(&cfg_info, "use_even_ports", ACO_EXACT, general_options, "no",
OPT_BOOL_T, 1, FLDSET(struct udptl_global_options, use_even_ports));
aco_option_register_custom(&cfg_info, "t38faxudpec", ACO_EXACT, general_options, NULL, removed_options_handler, 0);
aco_option_register_custom(&cfg_info, "t38faxmaxdatagram", ACO_EXACT, general_options, NULL, removed_options_handler, 0);
__ast_udptl_reload(0);
ast_cli_register_multiple(cli_udptl, ARRAY_LEN(cli_udptl));
return AST_MODULE_LOAD_SUCCESS;
}
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_GLOBAL_SYMBOLS | AST_MODFLAG_LOAD_ORDER, "UDPTL",
.support_level = AST_MODULE_SUPPORT_CORE,
.load = load_module,
.unload = unload_module,
.reload = reload_module,
.load_pri = AST_MODPRI_CORE,
.requires = "extconfig",
);