Commit Graph

105 Commits

Author SHA1 Message Date
George Joseph
30415944a8 pjproject_bundled: Disable PJSIP_UNESCAPE_IN_PLACE
When pjsip_parse_uri is called with PJSIP_UNESCAPE_IN_PLACE enabled,
the input uri string will become corrupted if it contains escape sequences.
It's not possible to automatically strdup or strdupa the input string because
the output uri pj_str_t's will have pointers to chunks of the input string.
Getting around this would require more memory management code and wouldn't
be worth the savings of doing the unescape in place.

ASTERISK-25970 #close
Reported-by: Dmitriy Serov

Change-Id: I28dc0e599b5108f7959b9c46dc8278371b372f88
2016-04-28 17:01:32 -05:00
George Joseph
bd3671b397 pjproject: Add patch for removing strip of '[]' from header params
From the patch submitted to Teluu on 4/12/2016
<<<<<<<<<
The wholesale stripping of '[]' from header parameters causes issues if
something (like a port) occurs after the final ']'.

'[2001🅰️:b]' will correctly parse to '2001🅰️:b'
'[2001🅰️:b]:8080' will correctly parse to '2001🅰️:b' but the scanner is left
with ':8080' and parsing stops with a syntax error.

I can't even find a case where stripping the '[]' is a good thing anyway.  Even
if you continued to parse and resulted in a string that looks like this...
'2001🅰️🅱️8080', it's not valid.

This came up in Asterisk because Kamailio sends us a Contact with an alias
URI parameter that has an IPv6 address in it like this:
Contact: <sip:1171@127.0.0.1:5080;alias=[2001:1:2::3]~43691~6>
which should be legal but causes a syntax error because of the characters
after the final ']'.  Even if it didn't, the '[]' should still not be stripped.

I've run the Asterisk Test Suite for PJSIP (252 tests) many of which are IPv6
enabled.  No issues were caused by removing the code that strips the '[]'.
>>>>>>>>>>>

ASTERISK-25123 #close
Reported-by: Anthony Messina

Change-Id: I5cb33f4ebf07ee1f2b26d07caae715e2ec65595a
2016-04-12 15:47:25 -05:00
George Joseph
8637f29d24 pjproject: Add patch to fix Via IPv6 parsing
There's a bug in pjproject's sip_parser where the ":" wasn't correctly
interpreted. This is causing IPv6 addresses in the "received" parameter of the
Via header to cause a syntax check failure.

This patch was submitted to Teluu on 4/10/2016.

ASTERISK-25910 #close
Reported-by: Anthony Messina

Change-Id: Ic7e4c4aa14ded61860401ec349f5177568c4d922
2016-04-10 14:23:07 -05:00
George Joseph
392341ba37 pjproject-bundled: Cleanups for reported issues
PortAudio should no longer be required
PJSIP_MAX_PKT_LEN is now 6000
Older autoconf issue fixed. (CentOS 6)

Change-Id: I463fa9586cbe7c6b3b603289f535bd8e361611dd
2016-03-23 09:11:24 -05:00
George Joseph
3173e91bab 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-03-01 09:30:43 -07:00