build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-18 20:54:28 -07:00
|
|
|
/*
|
|
|
|
|
* Asterisk config_site.h
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <sys/select.h>
|
|
|
|
|
|
2016-10-05 13:53:10 -06:00
|
|
|
/*
|
|
|
|
|
* Since both pjproject and asterisk source files will include config_site.h,
|
|
|
|
|
* we need to make sure that only pjproject source files include asterisk_malloc_debug.h.
|
|
|
|
|
*/
|
2018-02-19 19:55:50 -06:00
|
|
|
#if !defined(_ASTERISK_ASTMM_H)
|
2016-10-05 13:53:10 -06:00
|
|
|
#include "asterisk_malloc_debug.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-08-26 13:34:22 -06:00
|
|
|
/*
|
|
|
|
|
* Defining PJMEDIA_HAS_SRTP to 0 does NOT disable Asterisk's ability to use srtp.
|
|
|
|
|
* It only disables the pjmedia srtp transport which Asterisk doesn't use.
|
|
|
|
|
* The reason for the disable is that while Asterisk works fine with older libsrtp
|
|
|
|
|
* versions, newer versions of pjproject won't compile with them.
|
|
|
|
|
*/
|
|
|
|
|
#define PJMEDIA_HAS_SRTP 0
|
|
|
|
|
|
build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-18 20:54:28 -07:00
|
|
|
#define PJ_HAS_IPV6 1
|
2017-10-23 02:02:22 -04:00
|
|
|
#if !defined(AST_DEVMODE) && !defined(PJPROJECT_BUNDLED_ASSERTIONS)
|
build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-18 20:54:28 -07:00
|
|
|
#define NDEBUG 1
|
2017-10-23 02:02:22 -04:00
|
|
|
#endif
|
|
|
|
|
|
build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-18 20:54:28 -07:00
|
|
|
#define PJ_MAX_HOSTNAME (256)
|
|
|
|
|
#define PJSIP_MAX_URL_SIZE (512)
|
|
|
|
|
#ifdef PJ_HAS_LINUX_EPOLL
|
|
|
|
|
#define PJ_IOQUEUE_MAX_HANDLES (5000)
|
|
|
|
|
#else
|
|
|
|
|
#define PJ_IOQUEUE_MAX_HANDLES (FD_SETSIZE)
|
|
|
|
|
#endif
|
|
|
|
|
#define PJ_IOQUEUE_HAS_SAFE_UNREG 1
|
|
|
|
|
#define PJ_IOQUEUE_MAX_EVENTS_IN_SINGLE_POLL (16)
|
|
|
|
|
|
|
|
|
|
#define PJ_SCANNER_USE_BITWISE 0
|
|
|
|
|
#define PJ_OS_HAS_CHECK_STACK 0
|
2017-01-03 14:14:09 -07:00
|
|
|
|
|
|
|
|
#ifndef PJ_LOG_MAX_LEVEL
|
2016-11-23 18:27:54 -06:00
|
|
|
#define PJ_LOG_MAX_LEVEL 6
|
2017-01-03 14:14:09 -07:00
|
|
|
#endif
|
|
|
|
|
|
2016-07-17 17:28:36 -06:00
|
|
|
#define PJ_ENABLE_EXTRA_CHECK 1
|
build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-18 20:54:28 -07:00
|
|
|
#define PJSIP_MAX_TSX_COUNT ((64*1024)-1)
|
|
|
|
|
#define PJSIP_MAX_DIALOG_COUNT ((64*1024)-1)
|
|
|
|
|
#define PJSIP_UDP_SO_SNDBUF_SIZE (512*1024)
|
|
|
|
|
#define PJSIP_UDP_SO_RCVBUF_SIZE (512*1024)
|
|
|
|
|
#define PJ_DEBUG 0
|
|
|
|
|
#define PJSIP_SAFE_MODULE 0
|
|
|
|
|
#define PJ_HAS_STRICMP_ALNUM 0
|
2016-12-06 16:45:38 -06:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Do not ever enable PJ_HASH_USE_OWN_TOLOWER because the algorithm is
|
|
|
|
|
* inconsistently used when calculating the hash value and doesn't
|
|
|
|
|
* convert the same characters as pj_tolower()/tolower(). Thus you
|
|
|
|
|
* can get different hash values if the string hashed has certain
|
|
|
|
|
* characters in it. (ASCII '@', '[', '\\', ']', '^', and '_')
|
|
|
|
|
*/
|
|
|
|
|
#undef PJ_HASH_USE_OWN_TOLOWER
|
|
|
|
|
|
2016-04-28 15:54:07 -06:00
|
|
|
/*
|
|
|
|
|
It is imperative that PJSIP_UNESCAPE_IN_PLACE remain 0 or undefined.
|
|
|
|
|
Enabling it will result in SEGFAULTS when URIs containing escape sequences are encountered.
|
|
|
|
|
*/
|
|
|
|
|
#undef PJSIP_UNESCAPE_IN_PLACE
|
2020-07-22 14:57:44 -03:00
|
|
|
#define PJSIP_MAX_PKT_LEN 65535
|
build-system: Allow building with static pjproject
Background here:
http://lists.digium.com/pipermail/asterisk-dev/2016-January/075266.html
From CHANGES:
* To help insure that Asterisk is compiled and run with the same known
version of pjproject, a new option (--with-pjproject-bundled) has been
added to ./configure. When specified, the version of pjproject specified
in third-party/versions.mak will be downloaded and configured. When you
make Asterisk, the build process will also automatically build pjproject
and Asterisk will be statically linked to it. Once a particular version
of pjproject is configured and built, it won't be configured or built
again unless you run a 'make distclean'.
To facilitate testing, when 'make install' is run, the pjsua and pjsystest
utilities and the pjproject python bindings will be installed in
ASTDATADIR/third-party/pjproject.
The default behavior remains building with the shared pjproject
installation, if any.
Building:
All you have to do is include the --with-pjproject-bundled option on
the ./configure command line (and remove any existing --with-pjproject
option if specified). Everything else is automatic.
Behind the scenes:
The top-level Makefile was modified to include 'third-party' in the
list of MOD_SUBDIRS.
The third-party directory was created to contain any third party
packages that may be needed in the future. Its Makefile automatically
iterates over any subdirectories passing on targets.
The third-party/pjproject directory was created to house the pjproject
source distribution. Its Makefile contains targets to download, patch
configure, generate dependencies, compile libs, apps and python bindings,
sanitized build.mak and generate a symbols list.
When bootstrap.sh is run, it automatically includes the configure.m4
file in third-party/pjproject. This file has a macro to download and
conifgure pjproject and get and set PJPROJECT_INCLUDE, PJPROJECT_DIR
and PJPROJECT_BUNDLED. It also tests for the capabilities like
PJ_TRANSACTION_GRP_LOCK by parsing preprocessor output as opposed to
trying to compile. Of course, bootstrap.sh is only run once and the
configure file is incldued in the patch.
When configure is run with the new options, the macro in configure.m4
triggers the download, patch, conifgure and tests. No compilation is
performed at this time. The downloaded tarball is cached in /tmp so
it doesn't get downloaded again on a distclean.
When make is run in the top-level Asterisk source directory, it will
automatically descend all the subdirectories in third_party just as it
does for addons, apps, etc. The top-level Makefile makes sure that
the 'third-party' is built before 'main' so that dependencies from the
other directories are built first.
When main does build, a new shared library (libasteriskpj) is created that
links statically to the pjproject .a files and exports all their symbols.
The asterisk binary links to that, just as it does with libasteriskssl.
When Asterisk is installed, the pjsua and pjsystest apps, and the pjproject
python bindings are installed in ASTDATADIR/third-party/pjproject. This
will facilitate testing, including running the testsuite which will be
updated to check that directory for the pjsua module ahead of the system
python library.
Modules should continue to depend on pjproject if they use pjproject APIs
directly. They should not care about the implementation. No changes to any
res_pjsip modules were made.
Change-Id: Ia7a60c28c2e9ba9537c5570f933c1ebcb20a3103
2016-01-18 20:54:28 -07:00
|
|
|
|
|
|
|
|
#undef PJ_TODO
|
|
|
|
|
#define PJ_TODO(x)
|
2016-06-29 15:09:02 -05:00
|
|
|
|
|
|
|
|
/* Defaults too low for WebRTC */
|
2020-04-28 12:31:28 -03:00
|
|
|
#define PJ_ICE_MAX_CAND 64
|
2016-11-14 15:57:08 -06:00
|
|
|
#define PJ_ICE_MAX_CHECKS (PJ_ICE_MAX_CAND * PJ_ICE_MAX_CAND)
|
2016-11-01 11:56:24 +00:00
|
|
|
|
|
|
|
|
/* Increase limits to allow more formats */
|
|
|
|
|
#define PJMEDIA_MAX_SDP_FMT 64
|
|
|
|
|
#define PJMEDIA_MAX_SDP_BANDW 4
|
2022-04-11 06:30:33 -03:00
|
|
|
#define PJMEDIA_MAX_SDP_ATTR (PJMEDIA_MAX_SDP_FMT*3 + 4)
|
2016-11-01 11:56:24 +00:00
|
|
|
#define PJMEDIA_MAX_SDP_MEDIA 16
|
2018-07-11 11:57:53 -05:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Turn off the periodic sending of CRLNCRLN. Default is on (90 seconds),
|
|
|
|
|
* which conflicts with the global section's keep_alive_interval option in
|
|
|
|
|
* pjsip.conf.
|
|
|
|
|
*/
|
|
|
|
|
#define PJSIP_TCP_KEEP_ALIVE_INTERVAL 0
|
|
|
|
|
#define PJSIP_TLS_KEEP_ALIVE_INTERVAL 0
|
2022-02-24 13:48:19 -04:00
|
|
|
|
|
|
|
|
#define PJSIP_TSX_UAS_CONTINUE_ON_TP_ERROR 0
|
|
|
|
|
#define PJ_SSL_SOCK_OSSL_USE_THREAD_CB 0
|
|
|
|
|
#define PJSIP_AUTH_ALLOW_MULTIPLE_AUTH_HEADER 1
|