Asterisk cannot work with WebRTC, max packet length too small

Thanks for taking the time to report this bug and try to make Ubuntu better.

I can confirm that pjproject version 2.7.2~dfsg-1 available in Bionic has the maximum packet length set to 4000:

$ sed -n 333,339p pjsip/include/pjsip/sip_config.h
/**
 * Maximum packet length. We set it more than MTU since a SIP PDU
 * containing presence information can be quite large (>1500).
 */
#ifndef PJSIP_MAX_PKT_LEN
# define PJSIP_MAX_PKT_LEN 4000
#endif

In the latest versions (i.e. version in Focal) the pjproject source code was embedded in the asterisk source package and it does not depend on pjproject from the system anymore. I checked the file debian/pjproject_2.8\~dfsg.orig.tar.bz2 (which is a DFSG free version of pjproject) in the asterisk source package version 1:16.2.1~dfsg-2ubuntu1 present in Focal and the defined maximum packet length is the same:

$ sed -n 357,363p pjsip/include/pjsip/sip_config.h
/**
 * Maximum packet length. We set it more than MTU since a SIP PDU
 * containing presence information can be quite large (>1500).
 */
#ifndef PJSIP_MAX_PKT_LEN
# define PJSIP_MAX_PKT_LEN 4000
#endif

The same applies to version 2.9 of pproject in the asterisk source package version 1:16.12.0~dfsg-1 in Groovy. Seen this as a pattern in all those releases I believe we should bring this to Debian and discuss this change with the asterisk maintainers there. Could you please file a bug in Debian describing your problem and link it here?

When you compile asterisk with embedded pjproject version, I believe the asterisk build process is patching pjproject with content of https://github.com/asterisk/asterisk/tree/master/third-party/pjproject/patches

In particular, it uses its own config_site.h, with a larger max packet size (used to be 32000, now is 65535).

Hello Michael,

I agree and I set the bug tasks accordingly: bug Triaged in Bionic, Fix Released in >= Focal.

Patching Bionic's pjproject to increase PJSIP_MAX_PKT_LEN wouldn't be difficult, more difficult is assessing how safe would be to do so in terms of regression potential for existing use cases.

The asterisk upstream change in the bundled pjproject didn't seem to have required any extra care:

https://github.com/asterisk/asterisk/commit/e7d9e42616975b594f7ad45baeb4305a61fa6dd0

At the time of the change the version of the embedded pjproject was 2.6:

https://github.com/asterisk/asterisk/blob/e7d9e42616975b594f7ad45baeb4305a61fa6dd0/third-party/versions.mak

which is lower than what we have in Bionic, so the change should be safe.

Thanks for the explanation Michael, I did not check what the upstream build system is doing properly. From what I understood this bug affects the src:pjproject version 2.7.2~dfsg-1 in Bionic and not asterisk itself. The asterisk in Bionic has the patch to increase the value to 32000:

$ git branch
* ubuntu/bionic-devel
  ubuntu/devel
  ubuntu/focal-devel
$ head debian/changelog
asterisk (1:13.18.3~dfsg-1ubuntu4) bionic; urgency=medium

  * No-change rebuild against libcurl4

 -- Steve Langasek <email address hidden> Wed, 28 Feb 2018 06:44:47 +0000

asterisk (1:13.18.3~dfsg-1ubuntu3) bionic; urgency=high

  * No change rebuild against openssl1.1.

$ sed -n 71p third-party/pjproject/patches/config_site.h
#define PJSIP_MAX_PKT_LEN 32000

However, it is patched to use pjproject from the system so it does not apply it, the onward versions use the embedded pjproject which follows what upstream is doing and their patch applies during build time (setting this variable to 32000). Am I right? If so let's mark asterisk as not affected and pjproject as affected. Or are you requesting to increase this value to 65535 like upstream did on their master branch? In this case it would affect src:pjproject in Bionic and src:asterisk in Focal and Groovy.

Moreover, as Paride highlighted we would need to have a detailed analysis about the potential regression this change could bring to a stable release.

I see 2 possible paths:
1) change PJSIP_MAX_PKT_LEN in system pjproject
2) compile asterisk with bundled pjproject

The problem with the first option is that it is binary incompatible. PJSIP_MAX_PKT_LEN is used in sip_transport.h to define the size of struct field. Changing that value means you have to recompile and publish all components that are using it.

IMO the second option is the safest, because it only affects asterisk (and only one module of asterisk, which is unlikely to be used directly by some 3rd-party component). It then becomes purely an asterisk packaging issue.