Custom Query (2195 matches)

At the moment when building android using clang, the build process will use ar/ranlib from host machine's binutils. This is not a problem on linux, however error will be raised on MacOS:

warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: ../lib/libpj-arm-unknown-linux-androideabi.a the table of contents is empty (no object file members in the library define global symbols)
output/pjlib-test-arm-unknown-linux-androideabi/main.o: In function `main':
pjlib/build/../src/pjlib-test/main.c:(.text.main+0x3c): undefined reference to `PJ_SOCK_DGRAM'
pjlib/build/../src/pjlib-test/main.c:(.text.main+0x4c): undefined reference to `PJ_SOCK_DGRAM'
pjlib/build/../src/pjlib-test/main.c:74: undefined reference to `pj_str'
pjlib/build/../src/pjlib-test/main.c:76: undefined reference to `pj_strtoul'
pjlib/build/../src/pjlib-test/main.c:82: undefined reference to `pj_str'
...

This ticket will check and use the binutils from the android ndk.

On certain errors such as EINTR, it may be desirable for pjsip_endpt_handle_events2() to return immediately, instead of sleeping first.

However, for backward compatibility, we decide to change the sleep to a max of 10ms and provide a compile time option to disable it completely (by default, it's enabled).

Thanks to Kal Conley for the patch.

Method SipHeader::fromPj() which converts pjsip_hdr to SipHeader, uses a local char array with a fixed size of 256 to buffer information from the pjsip_hdr.

This buffer is quite small, which leads to an unnecessary exception when large headers are exchanged. In one instance we encountered such an exception while receiving a large “Authorization”-Header.

This patch will try to allocate larger buffer space, instead of returning error on the first try.

Thanks to David Wichter for the report.

Pjsip is bundled with libSRTP 2.1, however users are allowed to use external libSRTP (see r5656). This ticket will enabled AES-GCM when using external libSRTP specially version 1.x and 2.0.0.

Thanks to Alexander Traud for the patch.

This ticket will implement callback on_buddy_evsub_state() for pjsua2. The new callback is:

Buddy::onBuddyEvSubState(OnBuddyEvSubStateParam &prm)

This is useful for application that needs more detail information about the event, e.g XML-construct in the message.

Thank you to David Wichter for the report and suggestion.

In pjsua2, when Call object is about to be destroyed, it will call:

pjsua_call_set_user_data(id, NULL);
hangup(prm);

which will prevent any further callbacks to be invoked, meaning that application creating pjmedia_port in onStreamCreated() may not get the notification to destroy it in onStreamDestroyed().

This ticket is to add a new callback on_stream_created2() with the option to allow pjsua to manage the pjmedia port destruction instead.

Thanks to Kal Conley (b17c0de) for the original patch.

In on_snd_dev_operation() callback, sometimes it may be helpful to know which sound device is being opened/closed. This ticket will make sure that if pjsua_get_snd_dev() is called from within the callback, it will provide the desired info.

Setting CXXCFLAGS manually sometimes is needed, e.g: set "-std=c++03" option. However the current build configuration might ignore/overwrite it.

This patch will make sure that the CXXCFLAGS is applied correctly.

Thanks to Alexander Traud for the patch.

When there is double unregistration for the same ioqueue key, some ioqueue backends will eventually reject every ioqueue key registration with error code PJ_ETOOMANY and this is not recoverable. Sample log line:

Handshake failed in accepting a.b.c.d:n: Too many objects of the specified type (PJ_ETOOMANY)

PJ_ETOOMANY is returned by ioqueue key registration because the maximum key count (ioqueue->count) has a very high number (0xFFFFFFFF) which actually representing a negative value in a signed number (note that ioqueue->count is unsigned).

Alternative solutions

1. It will be ideal if the ioqueue itself can detect and avoid double key unregistration, however as by default each key is recycled (reused after some period of unregistration), this solution may not be bullet proof.
2. Another approach is to avoid double key unregistration in a bit higher level, e.g: active socket, this is good but still applications using ioqueue directly will not be protected.
3. Check application for possible double key unregistration. For example in SSL socket, there was similar report documented in ticket #1930.

Thank you Peter Koletzki for the report.

Parsing the numeric header fields like cseq, ttl, port, etc. all had the potential to overflow, either causing unintended values to be captured or, if the values were subsequently converted back to strings, a buffer overrun. This will lead to a potential exploit using carefully crafted invalid values. To address this, new "strto" functions have been created that do range checking and those functions are used wherever possible in the parser.

This patch will:

• Created pjlib/include/limits.h and pjlib/include/compat/limits.h to either include the system limits.h or define common numeric limits if there is no system limits.h.
• Created strtoi_validate functions in sip_parser that take bounds and on failure call the on_str_parse_error function which prints an error message and calls PJ_THROW.
• Updated sip_parser to validate the numeric fields.
• Fixed an issue in sip_transport that prevented error messages from being properly displayed.
• Added "volatile" to some variables referenced in PJ_CATCH blocks as the optimizer was sometimes optimizing them away.
• Fixed length calculation in sip_transaction/create_tsx_key_2543 to account for signed ints being 11 characters, not 9.

Thanks to:

• Youngsung Kim at LINE Corporation for the report
• George Joseph <gjoseph@digium.com> for the patch

See ticket #2092 for more details.

See ticket #2093 for more info.

It would be nice if PJSIP allows not only to load certificate from a file, but also from a memory, for example if the certificate is embedded in the application or if it's retrieved from Windows certificate store. Also it may improve performance, especially for server app, because currently the same certificate may be read again and again from disk.

Thanks Klaus Darilion and Peter Koletzki for the suggestion.

Currently the UDP and ICE media transport has the capability to switch destination RTP/RTCP address to the source address of the RTP/RTCP packets, if they are different than the original address set in SDP received from remote.

It may be better to put this functionality in the stream instead, for the following reason:

1. the stream has more information about the packet, such as RTP pt, SSRC, and info from RTCP statistic
2. some application that uses media transport wants to inspect and possibly filter the source address
3. some firewall such as Microsoft Forefront Threat Management Gateway wants us to send the RTP to the address in SDP, regardless of the source address of the RTP packet

Although there seem to be no standard that describes the feature specification clearly, it seems to be widely used. Having it implemented in the library should be practical, especially for PJSUA2 apps (note that there is already an implementation in pjsua sample app using PJSUA API). Thanks to David Wichter for the suggestion.

Considering that this is a proprietary feature (see ​here) and it may not be desirable on some system, e.g: SIP INFO message burst may introduce congestion on the network and may cause load spike on SIP server, the feature should be configurable and by default it is disabled.

This ticket will introduce pjsua_dtmf_method to specify the DTMF sending method.

PJSUA API
To send DTMF as SIP INFO:
Set pjsua_call_send_dtmf_param.method to PJSUA_DTMF_METHOD_SIP_INFO when calling pjsua_call_send_dtmf().

To get the notification of incoming DTMF:
Use on_dtmf_digit2() callback.

PJSUA2 API
To send DTMF as SIP INFO:
Set CallSendDtmfParam::method to PJSUA_DTMF_METHOD_SIP_INFO when calling Call::sendDtmf().

To get the notification of incoming DTMF:
Use Call::onDtmfDigit() callback.

String types in pjsua_call_info is pj_str_t which is basically not a null-terminated string, but pjsua app use the string fields as if they were null-terminated (e.g: print them using simple %s's printf() format).

When mixing hundreds or more ports, the mix loop is one of the bottlenecks. This ticket will reduce the CPU load substantially.

Thanks to Kal Conley (b17c0de) for the patch.

PJMEDIA test result using mips_test with 256 calls:

Clock  Item                                      Time     CPU    MIPS
 Rate                                           (usec)    (%)

without patch:
8KHz conference bridge with 256 calls            7391    0.739   59.88

with patch:
8KHz conference bridge with 256 calls            4888    0.489   39.60

Add PJSUA API to register transport factory that has been created by application. This can be useful if application wants to implement custom SIP transport and use it with pjsua.

Thanks to Peter Koletzki for the patch.

Miscellaneous updates and fixes

In sip_dialog.c create_uas_dialog() there are several error conditions (such as PJSIP_EINVALIDURI and PJSIP_SC_BAD_REQUEST) which cause the flow to go to on_error BEFORE dialog lock gets a chance to be incremented.

Thanks to Fredrik Hansson for the report and the patch.

Once a pjsip transport is removed from the hash table, it cannot be manually destroyed.

Scenario:

1. pjsip_transport_register() can move a transport from the hash table to tp_list. See ticket #1774.

2. Calling pjsip_transport shutdown() to that transport will not destroy it since pjsip_transport_add_ref() and pjsip_transport_dec_ref() will have no effect, due to is_transport_valid() check.

Thanks to Joshua Colp for the patch.

This ticket will add more documentation in the description of the library's functions, such as the APIs in pjsip's sip_parser, sdp parser, and xml parser. In particular, the doc will clearly state about the requirement that the buffer must be NULL terminated and the size parameter must not include the NULL terminator.

Also in the ticket:

• Modify the spec of pjlib-util's scanner. Originally, the spec said that the scanner will add the NULL terminator right AFTER the end of the buffer, however it turns out that the current implementation doesn't do that, probably for a few good reasons, i.e. to avoid buffer overwrite, prevent writing to a read-only buffer, and avoid synchronization issue (when more than one thread process the same buffer) . So, we change the spec instead, to require that the input buffer passed to the scanner to be NULL terminated by app.
• There are a few instances in the library where we don't pass NULL terminated buffer to the scanner. This is intentional and should be safe because:
  • The buffer should be part of a bigger, NULL-terminated buffer (for example, when parsing each line in the SDP).
  • We can take advantage of another character as the sentinel (such as newline).
• Add robustness check in sip_multipart to prevent buffer overflow

The default return code for pjsip_find_msg() was PJ_SUCCESS so if a Content-Length header wasn't found at all, pjsip_find_msg() was returning PJ_SUCCESS instead of PJSIP_EMISSINGHDR.

Also added the volatile keyword to a few variables what are used both inside and outsude the PJ_TRY/PJ_CATCH block.

Thanks to George Joseph for the patch.

When building libyuv as dll on Visual Studio 2015, linker error was generated

1>compare.obj : error LNK2019: unresolved external symbol _HammingDistance_X86
referenced in function _ComputeHammingDistance
1>..\..\lib\libyuv-i386-Win32-vc14-Debug.dll : fatal error LNK1120: 1 unresolved
externals

The issue seems to have been corrected on the current version (17 Nov 2017). Unfortunately, to build correctly on Visual Studio 2005, we still need one additional modification to the previous one.

According to RFC 3261 section 12.1.2 UAC Behavior:

... A UAC MUST be prepared to
receive a response without a tag in the To field, in
which case the tag is considered to have a value of null.

This is to maintain backwards compatibility with RFC
2543, which did not mandate To tags.

So even if the To tag is missing, the response should still be handled for backwards compatibility.

Thanks Kevin Harwell for the report and the patch.

When building pjsip as dll on Visual Studio 2015, we got a linker error

error LNK2001: unresolved external symbol

This ticket will also move pjsip_use_compact_form (an undocumented runtime option to enable compact form for SIP encoding) to pjsip_cfg_t.use_compact_form.

Users still be able to use compact form using compile time options PJSIP_ENCODE_SHORT_HNAME.

Add compile-time setting PJMEDIA_CONF_USE_AGC to enable/disable simple AGC in conference.

If enabled, also reduce the adjustment time of the current simple AGC algorithm.

Currently there's no general outbound proxy settings in pjsua2. Although this is perhaps intentional, since app can also use account's proxy settings instead, but since pjsua already have this setting, we can easily export it to pjsua2 as well.

Currently IPv6 addresses are printed as is, i.e. without brackets, in various places such as:

pjsip/src/pjsua-lib/pjsua_core.c:logging_on_tx_msg, and
pjsip/src/pjsua-lib/pjsua_core.c:logging_on_rx_msg

pjsip/src/pjsua-lib/pjsua_acc.c:acc_check_nat_addr
with "IP address change detected for account"

pjsip/src/pjsua-lib/pjsua_acc.c:update_keep_alive
with "Keep-alive timer started for acc"

pjsip/src/pjsip/sip_transport_tcp.c:on_connect_complete
pjsip/src/pjsip/sip_transport_tls.c:on_connect_complete
with "transport %.*s:%d is connected to"

For clarity, it is desirable for these addresses to be printed with the brackets, especially if there's a port number behind it.

In the SIP message itself, we have implemented this by adding beginquote and endquote, such as in pjsua_acc.c: acc_check_nat_addr(), pjsua_acc_create_uac_contact(), pjsua_acc_create_uas_contact()

So we probably need to use pj_sockaddr_print() or create a helper new pjlib API instead of copy-pasting it all over the place.

Currently pj_getaddrinfo() in pjsip_resolve will only return the first address.

So this can be useful in situations where that first address has an address family which is unsupported by applications (such as IPv4-only client which receives an IPv6 address when trying to register, hence causing it to fail).

Thanks to Alexander Traud for the report.

Scenario:

A                      B
<-- Established call -->
--------  REFER   ----->
<-------  4xx     ------ 

Currently, the log will print: "Warning: received NOTIFY without message body" and the on_call_transfer_status() callback is not called.

Thanks to Joshua Elliott for the report.

Some WAV files might have extra chunks after DATA chunk. Currently wav_playlist will reject this file. This ticket will fix this.

Thanks to Kai Ludwig for the report.

*IMPORTANT*: Further testing seems to suggest that separating worker threads doesn't improve the situation. Thus, it is recommended to use the approach officially suggested by the mobile platforms (Android, Apple, Windows) themselves, i.e. to completely deactivate all worker threads and shutdown or put your application in sleep mode, and rely on push notifications to wake it up when needed. This way, application will be able to consume as minimal power as possible.

Reported that on some platforms, such as Google Pixel XL running Android 8.0, and when device is not connected to computer (via USB), select() may block much longer than the specified timeout param, for example:

pjsip-2.7.1
NDK: r10d (similar result using r15c)
Device: Google Pixel XL
OS: Android 8.0

Charging (USB to computer):
19:20:13.781            TTT  select: n=1024, rv=0, elapsed=10, timeout=10
19:20:14.811            TTT  select: n=1024, rv=0, elapsed=10, timeout=10
19:20:15.023            TTT  select: n=1024, rv=1, elapsed=5, timeout=10
19:20:15.837            TTT  select: n=1024, rv=0, elapsed=10, timeout=10

Not charging (or to AC -> Not USB to computer)
19:23:41.819            TTT  select: n=1024, rv=0, elapsed=1959, timeout=10
19:23:41.841            TTT  select: n=1024, rv=0, elapsed=10, timeout=10
19:24:09.848            TTT  select: n=1024, rv=0, elapsed=26339, timeout=10
19:24:19.140            TTT  select: n=1024, rv=0, elapsed=9164, timeout=10

As currently each worker thread (also by default there will be only one worker thread) polls both, network events and timer events, such long block in network poll will affect timer events, e.g: TCP/TLS transport get disconnected by server/router as keep-alive packet not delivered in timely manner.

This ticket introduces compile time setting PJSUA_SEPARATE_WORKER_FOR_TIMER which when it is set, timer heap and network events will be polled from different worker thread, i.e: one thread will be dedicated for timer heap events polling and other thread(s) will poll network events.

Thanks Sébastien Tardif for the report.

Reported that changing capture/playback device on an active call using PJSUA2 AudDevManager::setPlaybackDev/setCaptureDev() does not work, it is the next call that will use the new capture/playback device.

After investigation, AudDevManager::setPlaybackDev/setCaptureDev() always sets mode to PJSUA_SND_DEV_NO_IMMEDIATE_OPEN, so PJSUA simply saves the new sound device IDs for future device open without reopening currently active sound device.

Thank you Thomas Hackl for the report.

Scenario:

1. DNS lookup returning two servers.
2. Sending INVITE to first server over TCP.
3. Response received with code 503 (Service Unavailable).
4. Failover to second server, sending second INVITE after restarting the session.
5. TCP connection for the first INVITE getting disconnected and causing call disconnection (while second INVITE is still outstanding).

The call disconnection is issued from here​, it is because the first INVITE transaction is terminated with status code PJSIP_SC_TSX_TRANSPORT_ERROR.

The idea is to ignore transport error on transaction that is already PJSIP_TSX_STATE_COMPLETED (sent/received final response) as it is kind of useless, and even can be dangerous. Note that transport error piggybacks tsx timeout timer, which is usually used for shifting tsx state. So cancelling timeout timer and rescheduling for transport error must be followed by another rescheduling (from transport error handler) for shifting tsx state, or otherwise the tsx will stuck in that state.

When investigating this issue, we found a related issue. Based on #1619, a call should be disconnected upon transport error only when the transaction is initial INVITE transaction, in the scenario, the transport error happens in INVITE transaction but not (or no longer) the initial INVITE transaction. Moreover, the block that disconnecting call​ in inv_on_state_calling() is supposed to be applicable for non-INVITE transaction only, so transport error case should be excluded from that block.

Thanks Joshua Colp for the report and the analysis.

The APIs will be useful for application that needs to work with multiple sound devices concurrently. It can also help application to simplify the tasks of improving media framework clock as described here.

Specifications

1. Audio device configuration settings to be supported:
   • PJSUA: ​pjmedia_snd_port_param.
   • PJSUA2: only playback and record device IDs.
2. Application can apply further settings whenever needed by:
   • PJSUA: querying the sound device port and apply further settings directly to it using PJMEDIA Sound Device Port APIs.
   • PJSUA2: inheriting class ExtraAudioDevice and apply the settings using the same approach as PJSUA above. This needs be done in C++.
3. Audio device must be registered to the conference bridge:
   • PJSUA: it must have API to query the conference bridge port.
   • PJSUA2: it must be a descendant of ​AudioMedia.

Sample code using PJSUA

enum { EXTRA_SND_DEV_ID  = 3; };

pjmedia_snd_port_param ext_param;
pjsua_ext_snd_dev *ext_snd_dev;
pjsua_conf_port_id ext_id;

/* Generate params (with default values) */
status = pjmedia_snd_port_param_default(&ext_param);
status = pjmedia_aud_dev_default_param(EXTRA_SND_DEV_ID, &ext_param.base);

/* Create the extra audio device */
status = pjsua_ext_snd_dev_create(&ext_param, &ext_snd_dev);
ext_id = pjsua_ext_snd_dev_get_conf_port(ext_snd_dev);

/* Connect extra audio dev mic to main audio dev */
status = pjsua_conf_connect(ext_id, 0);

/* Connect main audio dev mic to extra audio dev */
status = pjsua_conf_connect(0, ext_id);

...

/* Destroy extra audio dev (after no longer used) */
pjsua_ext_snd_dev_destroy(ext_snd_dev);

Sample code using PJSUA2

/* Use Null Audio Device as main media clock. This is useful for improving
 * media clock (see also https://trac.pjsip.org/repos/wiki/FAQ#tx-timing)
 * especially when sound device clock is jittery.
 */
ep.audDevManager().setNullDev();

/* Install extra audio device */
ExtraAudioDevice *auddev2 = new ExtraAudioDevice(-1, -1);
try {
    auddev2->open();
} catch (...) {
    std::cout << "Extra sound device failed" << std::endl;
}

/* Create WAV player and play the WAV to extra audio speaker */
AudioMediaPlayer amp;
amp.createPlayer(PATH_TO_WAV_FILE);
if (auddev2->isOpened())
    amp.startTransmit(*auddev2);

/* Wait for the WAV playback */
pj_thread_sleep(5000);

...

/* Destroy extra audio device (after no longer used) */
delete auddev2;

Currently, in the account settings, SIP and media has to be predetermined whether it wants to use a particular IP version, IPv4 or IPv6. As a result, typically two accounts are required for each IP version, one for IPv4, and one for IPv6.

It is desirable that a more flexible/smart detection mechanism is employed, such as:

• Ability to handle both IP versions in SIP and media, especially in the case of incoming offer where we can check what the remote wants.
• Specify a preference of one IP version over the other, but still can handle both.
• Match the IP version for SIP and media, i.e. if SIP signalling is done via IPv6, then media will also use IPv6.

Thanks to Alexander Traud for the suggestion.

Will be continued in #2146

Scenario:

• An active account re-registers
• The re-registration fails (such as when the DNS resolution times out after 10 seconds)
• At exactly the same time, the keep-alive timer fires.

The issue was consistently reproducible under a very high network load, with the re-registration interval set to 5 seconds, DNS timeout default (10 seconds) and keepalive interval default (15 seconds). Since 5+10 seconds == 15 seconds, the 2 events coincide and lead to the following backtrace:

Thread #1 (Suspended : Signal : SIGSEGV:Segmentation fault)	
	keep_alive_timer_cb() at pjsua_acc.c:1,981 0x76bcb424	
	pj_timer_heap_poll() at timer.c:643 0x76e43244	
	pjsip_endpt_handle_events2() at sip_endpoint.c:713 0x76cc0dd8	
	worker_thread() at pjsua_core.c:695 0x76bde404	
Thread #2
	__pthread_mutex_unlock_usercnt() at pthread_mutex_unlock.c:66 0x4940a4d8 
	__GI___pthread_mutex_unlock() at pthread_mutex_unlock.c:315 0x4940a588 
	pj_mutex_unlock() at os_core_unix.c:1,323 0x76e4241c 
	PJSUA_UNLOCK() at pjsua_internal.h:584 0x76be4244 
	pjsua_acc_set_registration() at pjsua_acc.c:2,682 0x76be4244 
	pj::Account::getInfo() at account.cpp:737 0x76e86438 

There are two problems here:

• timer.c: pj_timer_heap_poll() places the timer onto the freelist and releases the global lock before calling the callback -- thus the callback may operate on a timer already freed! Proposed fix: keep timer_entry out of the freelist until the callback is done.
• pjsua_acc.c: Even with the 1st issue fixed, the account registration could still be canceled "exactly when the callback fires", because the lock is released before the callback ... thus putting NULL into the ka_transport thus causing the crash. Proposed fix: protect against NULL in ka_transport.

Thanks to Martin Oberhuber for the report and the patch.

In the IP address change scenario, IP version may be switched (e.g: IPv4 to IPv6 or vice versa). In this case, when remote target is an IP address, application needs to be able to update the remote target for resuming a call via re-INVITE/UPDATE.

It happens after calling AudDevManager::setNoDev(), then trying to set back the audio device with setCaptureDev()/setPlaybackDev(). This is because in pjsua2, we can only set one device (either capture/playback) at a time, so the other device still has an invalid ID.

Assertion failed: (param && id!=PJMEDIA_AUD_INVALID_DEV), function pjmedia_aud_dev_default_param, file ../src/pjmedia/audiodev.c, line 487.

GnuTLS is a secure communications library implementing the SSL, TLS and DTLS protocols and technologies around them.

Thanks to Alexandre Viau from Savoir-faire Linux for the patch.

Currently the library will fail to build when using LibreSSL, since it uses symbols not known to LibreSSL. This patch will fix that error.

Thanks to Alexander Traud for the patch.

Passing an incorrect frame size to opus_decode() can cause decode error or recovery failure (log: "Recover failed!").

Scenario:

1. An account is registered using a TCP/TLS transport, as allow_via_rewrite is set, account's Via is rewritten with public IP.
2. The TCP/TLS transport gets disconnected.
3. INVITE for the account is sent using a new TCP/TLS transport, Via header for this INVITE is local IP address (of the new transport), this is as expected because no re-REGISTER has been sent and the account's Via address is no longer valid.
4. CANCEL is sent, but using current account's Via address while it should use the same Via header as the original INVITE to be cancelled, so this CANCEL is rejected with status code 481 (transaction does not exist).

See also #1996.

Thanks Marcus Froeschl for the report.

Support C# binding using SWIG. The resulting C# binding can then be used for C# apps, as well as for Xamarin projects.

Requirements:

1. Install swig-csharp
2. (For C#/Xamarin development): Download Visual Studio from ​xamarin.com.

How to create C# binding:

1. Go to pjsip-apps/src/swig.
2. Run make.

To create Xamarin sample app:

1. From Visual Studio, create new solution "Forms". Name it pjsua2xamarin in directory pjsip-apps/src/swig/csharp (we will refer this directory as [csharp_dir]).
2. In the multiplatform section (pjsua2xamarin.pjsua2xamarin):
   • Add pjsua2 folder ([csharp_dir]/pjsua2xamarin/pjsua2xamarin/pjsua2).
   • Add sample.cs file ([csharp_dir]/pjsua2xamarin/pjsua2xamarin/sample.cs).
3. Add code to run sample (such as in pjsua2xamarin.Droid MainActivity.cs or pjsua2xamarin.iOS AppDelegate.cs):

      pjsua2xamarin.sample test = new sample();
      test.test1();
   

4. Add PJSIP libraries.
   • For Android: Add lib folder ([csharp_dir]/Droid/lib) and change the Build Action of libpjsua2.so to Android Native Library. For more details, please refer to the ​official doc.
   • For iOS: Add the fat static library file (each architecture's resulting libpjsua2.a is located in [csharp_dir]/iOS/lib/[arch]). For more info, please refer to the ​official doc.
5. Set application permissions.
   See our sample apps (ipjsua for iOS and pjsua2 sample for Android) to see the typical basic permissions required.

Issues and solutions:

• The type or namespace name 'HandleRef' does not exist.
  SWIG requires .NET 2 or later by default and uses HandleRef. Make sure you are using the supported .NET framework version.
  ​https://github.com/swig/swig/issues/423
  ​https://github.com/swig/swig/issues/455
• TypeInitializationException, dll not found, unable to find pjsua2.
  This issue is likely caused by unsuccessful addition of the PJSIP libraries (see step 4 above), invalid path, or incorrect architecture of the libraries.
• Crashes when calling Endpoint.libInit(), or during initialization.
  This is likely caused by unauthorized permission (see step 5 above). App must list the required permissions and in some cases, specifically request for the permissions to the user, and user must grant those permissions.

In line with our roadmap for WebRTC interoperability, as mentioned in this draft of ​Web Real-Time Communication (WebRTC) document:

To reduce these costs and session set-up times,
   implementations are REQUIRED to support multiplexing RTP data packets
   and RTCP control packets on a single transport-layer flow.

this ticket will add support for RTP and RTCP multiplexing, in accordance to ​RFC 5761.

From the ​RFC 7587:

The Opus encoder can output encoded frames representing 2.5, 5, 10,
   20, 40, or 60 ms of speech or audio data.  Further, an arbitrary
   number of frames can be combined into a packet, up to a maximum
   packet duration representing 120 ms of speech or audio data.

For example, for a packet duration of 40ms, we can receive 1 frame of 40ms, 2x20ms, 4x10ms, etc. However, currently pjmedia only expects constant frame length to be specified during stream creation.

Thank you to Marcus Froeschl for the suggestion and patch testing.

Ticket #1107 and #1225, described that iOS will reset UDP socket when app goes to background. The library will then try to recreate the socket by calling replace_udp_sock().

However since iOS11, we see some cases that the method fail and lead to unusable UDP transport or even worst, an unresponsive library state.

Log:

ioq_select !Attempting to replace UDP socket 5 
ioq_select  Error replacing socket: Invalid argument
udp0x127d27e00  Warning: pj_ioqueue_recvfrom: [err 120009] Bad file descriptor

Steps to reproduce:

• run ipjsua
• register to a registrar using UDP
• lock-unlock the phone repeatedly

This ticket will retry the recreate socket/replace_udp_sock() if it fail and add a fallback mechanism (restart transport) from the app callback.

Log:

ioq_select !Attempting to replace UDP socket 5
ioq_select  Error get peer name 120022
ioq_select  Error set qos param 120022
ioq_select  Retry to replace UDP socket 5
ioq_select !Error get peer name 120022
ioq_select  UDP has been replaced successfully!

Receiving an SDP message body with an invalid fmtp attribute will cause a segmentation fault.

The following SIP message was used to reproduce the issue:

INVITE sip:5678@127.0.0.1:5060 SIP/2.0
To: <sip:5678@127.0.0.1:5060>
From: Test <sip:5678@127.0.0.1:5060>
Call-ID: adc9caea-2d0a-40af-9de5-1dd21387e03a
CSeq: 2 INVITE
Via: SIP/2.0/UDP 172.17.0.1:10394;branch=z9hG4bKadc9caea-2d0a-40af-9de5-1dd21387e03a
Contact: <sip:5678@172.17.0.1>
Content-Type: application/sdp
Content-Length: 228

v=0
o=- 1061502179 1061502179 IN IP4 172.17.0.1
c=IN IP4 172.17.0.1
t=0 0
m=audio 17000 RTP/AVP 9 0 101
a=rtpmap:8 alaw/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp\x00:101 0-16
a=sendrecv

Notes:

• \x00 should be replaced by the null character

GDB backtrace result:

Thread 197 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff65e57700 (LWP 10595)]
pjmedia_sdp_attr_get_fmtp (attr=<optimized out>, fmtp=fmtp@entry=0x7fff65e56430) at ../src/pjmedia/sdp.c:350
350	    while (pj_isdigit(*p) && p!=end)
(gdb) bt
#0  pjmedia_sdp_attr_get_fmtp (attr=<optimized out>, fmtp=fmtp@entry=0x7fff65e56430) at ../src/pjmedia/sdp.c:350

Thanks to Alfred Farrugia and Sandro Gauci from Enable Security for the finding and Kevin Harwell from Digium for the report.

CVE ID: ​CVE-2018-1000099

Receiving an SDP message body with an invalid media format description causes a segmentation fault.

The problematic SDP section is:

m=audio 17000 RTP/AVP 4294967296

GDB backtrace result:

Thread 26 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff0297700 (LWP 45)]
__longjmp_chk (env=env@entry=0x0, val=val@entry=1) at ../setjmp/longjmp.c:32
32	../setjmp/longjmp.c: No such file or directory.
(gdb) bt
#0  __longjmp_chk (env=env@entry=0x0, val=val@entry=1) at ../setjmp/longjmp.c:32
#1  0x00007ffff78ed4ae in pj_throw_exception_ (exception_id=1) at ../src/pj/except.c:54
#2  0x00007ffff7868070 in pool_callback (pool=<optimized out>, size=<optimized out>) at ../src/pjsip/sip_endpoint.c:143
#3  0x00007ffff78f1a93 in pj_pool_create_block (size=1407375809856000, pool=0x7fff8c002c90) at ../src/pj/pool.c:63
#4  pj_pool_allocate_find (pool=0x7fff8c002c90, size=1407375809852724) at ../src/pj/pool.c:138
#5  0x00007ffff78fbb75 in pj_strdup (pool=pool@entry=0x7fff8c002c90, dst=dst@entry=0x7fff8c027638, src=src@entry=0x7fff8c025638) at ../include/pj/string_i.h:41
#6  0x00007ffff78b287e in pjmedia_sdp_media_clone (pool=pool@entry=0x7fff8c002c90, rhs=0x7fff8c025608) at ../src/pjmedia/sdp.c:691
#7  0x00007ffff78b4069 in pjmedia_sdp_session_clone (pool=pool@entry=0x7fff8c002c90, rhs=0x7fff8c01cdb8) at ../src/pjmedia/sdp.c:1422
#8  0x00007ffff7847f31 in create_sdp_body (c_sdp=<optimized out>, pool=0x7fff8c002c90) at ../src/pjsip-ua/sip_inv.c:1722
#9  process_answer (inv=inv@entry=0x7fff8c009f28, st_code=st_code@entry=200, local_sdp=local_sdp@entry=0x0, tdata=0x7fff8c002d38, tdata=0x7fff8c002d38) at ../src/pjsip-ua/sip_inv.c:2257
#10 0x00007ffff7848681 in pjsip_inv_answer (inv=0x7fff8c009f28, st_code=st_code@entry=200, st_text=st_text@entry=0x0, local_sdp=local_sdp@entry=0x0, p_tdata=p_tdata@entry=0x7ffff0296d10) at ../src/pjsip-ua/sip_inv.c:2393

Thanks to Alfred Farrugia and Sandro Gauci from Enable Security for the finding and Kevin Harwell from Digium for the report.

CVE ID: ​CVE-2018-1000098

A place for any bug fixes or enhancements related to DTLS-SRTP.

Currently when UDP media transport is created and attached, read operation is started immediately. Unfortunately, when remote starts sending RTP packet in the beginning of a call (especially when local is the SDP offerer), local stream may not be ready yet, so some initial inbound RTP packets will be read by the transport but then simply discarded as no stream is attached to the transport yet.

This ticket will change the behavior so read operation is started when pjmedia_transport_media_start() is called. So any incoming packet will be buffered by OS until read operation is started. This should be able to reduce missing video keyframe packets (or generally any initial RTP packets) as pjmedia_transport_media_start(), which starts read operation, is called after stream is instantiated.

Add support for SSRC attribute (​RFC 5576), and CNAME (​RFC 7022) in the SDP.

This ticket is created with the aim to support WebRTC interoperability according to this ​draft document:

Implementations are REQUIRED to support signalled RTP synchronisation
   source (SSRC) identifiers.

When a sender sends packets intensively to a receiver that has packet processing rate lower than the sending rate, the packet will be buffered by PJLIB SSL socket and after sometime the sender will get PJ_ENOMEM error and eventually drop the connection while there are still some pending outgoing packets in PJLIB SSL socket. Application cannot trace which packets have been sent and which packets are still pending (buffered in SSL socket).

After investigation, when sending buffer is full, any sending operation will still write to OpenSSL BIO while it should not, it should simply return error, e.g: PJ_ENOMEM. After sometime, it somehow cause OpenSSL to initiate SSL renegotiation and when renegotiation fails (e.g: due to timeout), SSL connection will be dropped.

Thanks Peter Koletzki for the report.

Currently SRTP crypto and keying method is configurable via callback, i.e: on_create_media_transport_srtp() in PJSUA or onCreateMediaTransportSrtp() in PJSUA2 (only crypto). And after some review and internal discussions, we decided to deprecate the callback and move the settings to account config, here are some reasons:

• SRTP setting type used in callback param is pjmedia_srtp_setting, which has some fields that are PJMEDIA specifics, e.g: close_member_tp, cb, user_data. So this ticket will also create a new SRTP settings specifically for PJSUA and PJSUA2.
• media transport settings are usually configurable via account setting (instead of PJSUA/PJSUA2 callback), so it'd better to use the same pattern for SRTP.

Here are sample codes to enable DTLS-SRTP in outgoing SDP offer:

• using PJSUA:

   acc_cfg.srtp_opt.keying_count = 2;
   acc_cfg.srtp_opt.keying[0] = PJMEDIA_SRTP_KEYING_DTLS_SRTP;
   acc_cfg.srtp_opt.keying[1] = PJMEDIA_SRTP_KEYING_SDES; // optional, as a fallback for handling incoming call using SRTP with SDES
  

• using PJSUA2:

  acc_cfg.mediaConfig.srtpOpt.keyings.push_back(PJMEDIA_SRTP_KEYING_DTLS_SRTP);
  acc_cfg.mediaConfig.srtpOpt.keyings.push_back(PJMEDIA_SRTP_KEYING_SDES); // optional, as a fallback for handling incoming call using SRTP with SDES
  

The PJLIB mutex functions all check for NULL mutexes but pj_atomic_destroy() is not setting its mutex to NULL after it destroyed it so any attempts to use the atomic again would cause a crash. This ticket does not address why an attempt was made to use the atomic again but it does prevent the crash.

Thank you George Joseph for the patch.

Reported that there have been cases that when the transaction timer callback is called when the transaction is already destroyed. This causes a crash. We now check the transaction state and return if the transaction is already destroyed.

Thank you George Joseph for the report and the patch.

In YUV format, if the buffer is all zero, it will be displayed as green (as compared to RGBA format, where it will be black). Unfortunately currently buffer is initialized with zero. As most video codecs uses I420 format, perhaps it is better to have special initialization for I420 so the screen will be black.

The allocation and initialization of frame buffer is done in pjmedia/src/pjmedia/vid_port.c, in function pjmedia_vid_port_create().

Failed STUN resolution when starting the library might lead to a crash caused by double free.

Scenario:

1. Set stun_ignore_failure to PJ_FALSE.
2. Turn networking OFF (Linux nework connections menu)
3. Start the application
4. pjsua_core.c !.STUN resolution failed: gethostbyname() has returned error (PJ_ERESOLVE).
5. pjsua_core.c .Error resolving STUN server: gethostbyname() has returned error (PJ_ERESOLVE) [status=70018]
6. double free, crash

Internal flow:

• pjsua_init() -> resolve_stun_server() : fail -> schedule timer to call destroy_stun_resolve_cb()
• exit pjsua_init() -> destroy_stun_resolve() -> shedule new timer to destroy STUN session. The previous timer entry hasn't been processed by worker thread
• double free and crash in busy_sleep()

Thank you to Denis Poltorak for the report.

In AMR (narrow band), SID frames are of type 8. However in AMR-WB, SID frames are of type 9 (see 3GPP TS 26.201 Table 1a). This is also in line with ​RFC 4867: " ... or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB... "

According to the doc of pjsua_transport_config:

    /**
     * UDP port number to bind locally. This setting MUST be specified
     * even when default port is desired. If the value is zero, the
     * transport will be bound to any available port, and application
     * can query the port by querying the transport info.
     */
    unsigned		port;

However, currently setting the port to zero will result to it being assigned the default port number instead (which is set to 4000).

In PJSIP stream, DTMF duration/timestamp is currently calculated using the actual clock rate, while it should be using the signalled rate. This will affect codecs such as Opus or G722.

Thanks to Marcus Froeschl for the report.

Currently the setting PJMEDIA_DTMF_DURATION specifies the duration in timestamp units. Thus, if using codecs with different clock rates, the time duration will vary. It may be desirable for some apps to be able to configure it in real time unit, i.e. in milliseconds, thus we introduce a new setting PJMEDIA_DTMF_DURATION_MSEC.

In OpenSSL 1.1.0 the ephemeral ECDH is already initialized in automatic mode, so there is really no need to do anything explicit about it.

=== begin citation ===
*) SSL_{CTX_}set_ecdh_auto() has been removed and ECDH is support is
     always enabled now.  If you want to disable the support you should
     exclude it using the list of supported ciphers. This also means that
the
     "-no_ecdhe" option has been removed from s_server.
https://www.openssl.org/news/changelog.html#x10
=== end citation ===

The code in ssl_sock_ossl.c falls to branch initializing only prime256v1 (aka secp256r1) elliptic curve in the context, after the call SSL_CTX_ctrl(ctx,94,1,NULL) is unsuccessful with OpenSSL 1.1.0x. When using server certificate with EC key based on any other curve, the listener fails TLS negotiation with misleading alert "no shared cipher", because the context's curve set applies to both EECDH and ECDSA. (Certificates with RSA keys work well.) Also, the EECDH itself is limited to use the only (from today's perspective the weakest acceptable) curve for key negotiation.

Thanks to Tzafrir Cohen for the patch.

In the doc of the API pjmedia_conf_connect_port(pjmedia_conf *conf, unsigned src_slot, unsigned sink_slot, int level):

@param level         This argument is reserved for future improvements
                     where it is possible to adjust the level of signal
                     transmitted in a specific connection. For now,
                     this argument MUST be zero.

This ticket will implement that improvement.

Thanks to Michael Scheiffler for the original patch and Thibault Groisil for subsequent improvements and fix.

On iOS when app goes into the background, the VideoToolbox? session will be invalid, thus it will generate continuous error. Then, when it returns to the foreground, this session will need to be reset in order for the encoding/decoding process to resume normally, otherwise the errors will continue and the video will freeze.

Thanks to Narayanan Kannan for the report.

The same issue as in ticket #1464 happens again.

The ticket doesn't entirely fix the problem, because PJSUA_LOCK() can be called by the upper functions instead, such as:

 	pjsua_call_on_state_changed(pjsip_inv_session * inv, pjsip_event * e) Line 4016	C
 	inv_set_state(pjsip_inv_session * inv, pjsip_inv_state state, pjsip_event * e) Line 317	C
 	inv_on_state_null(pjsip_inv_session * inv, pjsip_event * e) Line 3941	C
 	mod_inv_on_tsx_state(pjsip_transaction * tsx, pjsip_event * e) Line 717	C
 	pjsip_dlg_on_tsx_state(pjsip_dialog * dlg, pjsip_transaction * tsx, pjsip_event * e) Line 2069	C
 	mod_ua_on_tsx_state(pjsip_transaction * tsx, pjsip_event * e) Line 178	C
 	tsx_set_state(pjsip_transaction * tsx, pjsip_tsx_state_e state, pjsip_event_id_e event_src_type, void * event_src, int flag) Line 1268	C
 	tsx_on_state_null(pjsip_transaction * tsx, pjsip_event * event) Line 2483	C
 	pjsip_tsx_send_msg(pjsip_transaction * tsx, pjsip_tx_data * tdata) Line 1790	C
 	pjsip_dlg_send_request(pjsip_dialog * dlg, pjsip_tx_data * tdata, int mod_data_id, void * mod_data) Line 1288	C
 	pjsip_inv_send_msg(pjsip_inv_session * inv, pjsip_tx_data * tdata) Line 3282	C
 	on_make_call_med_tp_complete(int call_id, const pjsua_med_tp_state_info * info) Line 518	C
 	pjsua_call_make_call(int acc_id, const pj_str_t * dest_uri, const pjsua_call_setting * opt, void * user_data, const pjsua_msg_data * msg_data, int * p_call_id) Line 919	C

In the above stack trace, both pjsua_call_make_call() and on_make_call_med_tp_complete() both call PJSUA_LOCK().

The fix in this current ticket will improve the one in #1464 by ensuring that PJSUA_LOCK is not held before calling the callback. Note that if deadlock issue still persists, we may need to consider using group lock or chain the locks with pj_grp_lock_chain_lock()).

Thanks to Marcus Froeschl again for the report.

When testing pjsip on Raspberry Pi, it is reported that some weird sound issue happen if call lasted longer than ~30s. When checked with address sanitizer tools, the output is like this:

==3210==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x6f5fd020,0x6f5fd1cc) and [0x6f5fd0c0, 0x6f5fd26c) overlap
    #0 0x59e37 in __interceptor_memcpy.part.36 (/home/pi/projects/sip/pjsip/simple_pjsua/simple_pjsua+0x59e37)
    #1 0x4dc79f in iLBC_encode ../../ilbc/iLBC_encode.c:311
    #2 0x2c7693 in ilbc_codec_encode ../src/pjmedia-codec/ilbc.c:754
    #3 0x3316f7 in pjmedia_codec_encode ../include/pjmedia/codec.h:1069

The issue is that iLBC sometimes uses memcpy() even when the source and the target storage overlap. This causes undefined behaviour and memmove() should be used in such cases (instead of memcpy()).

Similar issue was reported at ​https://issues.asterisk.org/jira/browse/ASTERISK-20231.

Thanks to Christian Hoff for the report and patch.

Scenario:

1. Thread 1 deletes SipAccount instance, which derived from PJSUA2 Account. In SipAccount destructor, some SipAccount member objects have been destroyed.
2. Thread 2 invokes Account callback onRegState() (e.g: from registration refresh), it tries to access SipAccount member objects, as some of them have been destroyed, crash occurs.

Some related facts:

1. Account destructor and onRegState() callback are mutual exclusive, because in PJSUA level, they are protected with PJSUA lock. But SipAccount destructor and onRegState() callback are not mutual exclusive.
2. Once pjsua_acc_del() in Account destructor is executed, onRegState() should never be invoked (for unregistration completion). Unfortunately, in derived class destruction, parent/Account destructor is called last.

The proposed solution is to introduce new Account method, i.e: Account::shutdown(), that internally will invoke PJSUA pjsua_acc_del(), so derived class could call this method first in its destructor to avoid invocation of onRegState() when it is being destroyed. Or alternatively, application can manually call Account::shutdown() before deleting the derived class instance.

Thanks Thomas Hackl for the report.

Currently stream buffer is calculated from specified codec maximum bitrate with 200 ms frame duration. Unfortunately, for some codecs that supports variable bitrate (VBR) and variable frame length such as Opus, it can be too small as the frame size may become very large exceeding the precalculated stream buffer size, which may lead to buffer overflow issues. Thanks Marcus Froeschl for the report and the analysis.

When there is no pjsua account available, and incoming call is received, assertion is raised:

pjsua_acc_find_for_incoming: assertion "pjsua_var.acc_cnt!=0" failed

In this case, assertion should be avoided since it is an uncontrollable event.

Thanks to Stanley Knapczyk for the report.

Scenario:

1. SIP server is configured with both Session Expires (SE) and Min-SE are set to 3600.
2. A & B clients are configured with SE & Min-SE set to default values (i.e: SE = 1800, Min-SE = 90).
3. A calls B, B receives INVITE with only Min-SE header and its value is 3600.
4. B answer the call without SE & Min-SE headers (session timer inactive).
5. B sends re-INVITE/UPDATE/call-hold with SE & Min-SE headers (attempt to activate session timer), unfortunately it uses SE=1800 while previously server has signaled that its Min-SE is 3600.
6. B receives 422 response as expected, and crashes.

After investigation, there seem to be a couple of bugs in the library:

1. When callee receives Min-SE header only, it doesn't update local SE to that Min-SE, so in any future outgoing request, the callee will use its original SE (which may be lower than caller's Min-SE and trigger 422 response).
2. The library wrongly assumes that 422 response can only occur in initial INVITE, while in the reported scenario it occurs in subsequent INVITE for call hold (due to bug #1 above), this is the main cause of the crash.

Thanks Shilpi Gupta for the report.

Sample exception message:

Swig::DirectorException: No enum class org.pjsip.pjsua2.pjsip_tsx_state_e
                         with value 377750600

SWIG requires C++ enum data to have a valid value so it can be correctly mapped to Java enum object. Unfortunately some PJSUA2 C++ objects do not initialize basic type data member (including enum) in its constructor and such uninitialized data member may have an invalid value, so when SWIG needs to map an invalid C++ enum value to Java, exception occurs.

Kazuhiko Yoneda for the report and the patch.

Currently libyuv converter backend does not support YV12/NV21 and when YV12/NV21 is listed first, YV12/NV21 will be the default format, and opening video preview will fail due to unsupported format error in the attempt of creating converter (as the renderer does not support YV12/NV21 either).

Previously, tickets #657, #1644, and #1764 allowed invite session to follow SDP answer changes in forking scenario (i.e: when responses have different To tags). This ticket expands the behavior to non-forking scenario, as long as the previous 18x response is not reliable (i.e: using 100rel), this should be inline with ​RFC 6337 section 3.1.1.

This new behavior can be turned off via compile-time setting PJSIP_ACCEPT_MULTIPLE_SDP_ANSWERS or run-time setting pjsip_cfg()->endpt.accept_multiple_sdp_answers. Application can inspect the new flag inv->updated_sdp_answer to check if the SDP negotiation was done with an initial or an updated SDP answer. Furthermore, the existing flag inv->following_fork can be used for checking whether the SDP answer update was on forking scenario.

Thanks George Joseph for the feedback and the patch.

Program received signal SIGSEGV, Segmentation fault.

0x0000000000429047 in pjsua_call_hangup (call_id=2, code=0, reason=0x0,
    msg_data=0x0) at ../src/pjsua-lib/pjsua_call.c:2370
2370   if (call->inv->role == PJSIP_ROLE_UAS)

Step to reproduce:
Run pjsua with dummy TURN server.
--use-ice --use-turn --turn-srv 8.8.8.8:12345 --turn-user na --turn-passwd na
then make call and immediately hangup

If ICE setup takes a long time, for example when using a non-responsive TURN server, call->inv hasn't been created yet, thus causing the crash.

Analysis: Before the crashing line, there's a conditional statement:

    if ((call->med_ch_cb && !call->inv) ||
	((call->inv != NULL) && (call->inv->state == PJSIP_INV_STATE_NULL)))

So, it's possible to enter the block with call->inv == NULL, however later we immediately access call->inv->role, thus causing the crash.

Thanks to Håkan Berg for the report.

This ticket is an initial implementation of ​RFC 4585:

1. PJMEDIA
   • Interworking and coexistence of AVP & AVPF: modify SDP negotiation, transport proto checks in media transports, stream info, etc
   • Implement RTCP-FB packets (generic NACK, NACK-PLI, SLI, RPSI) generation APIs.
   • RTCP-FB support in SDP (​https://tools.ietf.org/html/rfc4585#section-4).
   • Parse RTCP-FB info from SDP and add the info into pjmedia_stream_info for RTCP-FB operational in the stream.
   • Implement RTCP-FB functionality in audio stream, only generic NACK will be implemented.

2. PJSUA/PJSUA2
   • Add RTCP-FB setting structure into account config.

Monitoring RTCP-FB event in application

Application can monitor RTCP Feedback events by implementing PJSUA callback on_call_media_event or PJSUA2 callback Call::onCallMediaEvent(). Sample code for PJSUA:

static void on_call_media_event(pjsua_call_id call_id,
                                unsigned med_idx,
                                pjmedia_event *event)
{
  if (event->type == PJMEDIA_EVENT_RX_RTCP_FB) {
    /* Incoming RTCP-FB event */
    pjmedia_event_rx_rtcp_fb_data *fb_data = (pjmedia_event_rx_rtcp_fb_data*)
                                             event.data.ptr;
    if (fb_data->cap.type == PJMEDIA_RTCP_FB_NACK && fb_data->cap.param.slen == 0)
    {
      /* Generic NACK */
      /* NACK message can be accessed via 'fb_data->msg.nack' */
      ...
    }
  }
}

Currently the resolver releases the mutex when invoking callback, which may cause crash in these scenarios:

• destroy from within callback context,
• destroy while callback is being executed (from any context).

The crash can be avoided by replacing the mutex with group lock (thanks to reference counter functionality provided by the group lock).

Also note that the resolver docs recommends to destroy-recreate the resolver to overcome growing memory problem (see section "Resolver Limitations" in ​here). With the potential crash scenarios described above, it may not be a simple task for application to destroy the resolver without stopping ioqueue & timer first.

Sometimes, it is desirable to delay answering incoming INVITE/re-INVITE, when: A. application needs to perform certain setup which may take some time B. the preparation affects the SDP answer. An example of this is if the application uses third party media, thus it needs to setup the third party media and put the media info in the SDP.

This ticket will add the following:

• Callback on_call_rx_reinvite() in pjsua, and onCallRxReinvite() in pjsua2, for app to receive notification of incoming re-INVITE and decide if it wants to answer asynchronously at a later timing.
• API pjsua_call_answer_with_sdp() for pjsua. And add sdp parameter in CallOpParam for pjsua2, to be used in Call::answer().

The pj_grp_lock_dump() locks the same lock it is dumping and at the end releases it. Unfortunately, the release also call pj_grp_lock_dec_ref() on the lock which calls pj_grp_lock_dump() and ends up in infinite loop.

Thanks Imad Khazali for the report.

To maintain existing calls in IP change scenario, re-INVITE needs to be sent (e.g: for updating Contact header and reinit media). Unfortunately when a call belongs to a non-registering account, such re-INVITE is never sent.

Decoding fmtp is not removed even though Opus config has been changed.

After app calls pjmedia_codec_get_default_param() which will generate default decode fmtp as well, changing the config by calling pjmedia_codec_opus_set_default_param() currently can only add/change the fmtp, but not remove the ones that are not necessary. For example, enabling CBR, then disabling it, will still have the fmtp "cbr=1".

Currently local account is always bound to a transport since r5784 (of 2.8). Unfortunately the current account matching algo in pjsua_acc_find_for_incoming() may select a local account with incompatible transport type, which may cause failure in sending response with error PJSIP_ETPNOTSUITABLE.

If account is enabling NAT64 in its config, trying IPv4 STUN resolution is not necessary and may cause unwanted delay.

Note: the fix in this ticket doesn't affect STUN resolution that is not initiated by an account or a call.

• Recent changes may have increased SIP message size (perhaps mainly from increased SDP size) and when the SIP message size exceeds ~1300 bytes, the SIP message will be sent via TCP transport (if TCP transport is available). Unfortunately, some test components, e.g: SIPp, are configured to use UDP only, so some Python script tests will fail.

From ​https://tools.ietf.org/html/rfc5245#section-15.4

This means that the ice-ufrag
  attribute will be at least 4 characters long, and the ice-pwd at
  least 22 characters long

This ticket will also separate the compile time settings for ice-ufrag length (default still 8) and ice-pwd length (default is 24).

INVITE session (pjsip_inv_session) pjsip_tx_data field (last_answer) is an object shared with pjsip_transaction.last_tsx.

Since it's a shared object, modifying it might trigger a deadlock. The deadlock can be prevented by cloning the pjsip_tx_data and avoid the use of shared object.

Here is the link to the original report:

• ​https://issues.asterisk.org/jira/browse/ASTERISK-27966

Thanks to Richard Mudgett for the patch.

Reported error logs:

Failed creating STUN transport #1 for comp 1: gethostbyname() has returned error (PJ_ERESOLVE)

Failed creating STUN transport #1 for comp 1: Not found (PJ_ENOTFOUND)

The PJ_ERESOLVE error seems to be caused by IPv4 address being resolved to IPv6 address, note that when configured STUN server has IPv4 and it works, only the IPv4 STUN server address will be used.

While the PJ_ENOTFOUND error seems to be caused by failure in host interface enumeration (pj_enum_ip_interface()).

So, in generating STUN & host candidates, I think we should be more forgiving on errors (e.g: skipping STUN Binding resolution when STUN server resolution fails, use default address when host interface enumeration fails).

Thanks Oded Arbel for the report.

Currently, video port's renderer frame buffer is allocated according to the size of the video device's (i.e. the renderer's) parameters, while actually it should be based on the frame size given by video stream instead.

SYSTEM_CLOCK will stop when the device is in deep sleep (on mobile, this can be achieved by pressing the screen lock key and having no app running in background) (see ​here).

This is similar to ticket #1961 for Android.

This ticket will add a timeout (compile time setting PJSIP_TCP_INITIAL_TIMEOUT) to disconnect a TCP server connection if it doesn't receive any data following a successful connect.

Note that when a TCP server connection is idle or not referred anymore, idle timeout will disconnect the connection, refer to PJSIP_TRANSPORT_SERVER_IDLE_TIME

Thanks to Peter Koletzki for the suggestion.

Currently PJSUA media (i.e: internal state call->media) is not yet updated when on_stream_created() is called, as the media update processing is done on provisional media (i.e: internal state call->media_prov) instead. This will cause PJ_EINVAL returned when invoking any PJSUA API that uses call->media, such as pjsua_call_get_stream_info(), from within the on_stream_created() callback.

Thank you Dmytrii Gonchar for the report.

When sending re-INVITE with PJSUA_CALL_REINIT_MEDIA set, the media will reinitialize and the call media order might be different with the media SDP order.

Currently, on re-INVITE with PJSUA_CALL_REINIT_MEDIA the call media is rearrange and later the media order on SDP might get change on pjmedia_sdp_neg_modify_local_offer2().

This will lead to PJMEDIA_EINVALIMEDIATYPE when calling pjmedia_stream_info_from_sdp().

This ticket will avoid rearrangeing media when reinitializing media.

Implement TLS transport for TURN protocol, using the new PJLIB SSL transport object.

Replacing PJ_LOG for writing error message log with status code.

Currently pjsua always create media transports (UDP/ICE, with SRTP as an adapter). It may be desirable for some apps (such as the ones which use 3rd party media) to prevent this media tp creation. In this case, pjmedia_transport_loop can be used as an alternative.

When receiving SIP message within/creating dialog, PJSIP should rewrite the Contact (and first Route if it is an initial INVITE transaction) if it is using IPv4 address, as otherwise, PJSIP will send a new request (within dialog) to that IPv4 address.

Thanks Kyle Kurz for the report.

pjsua_core::resolve_stun_server                                             .... Ignoring STUN resolution failure (by setting)
  pjsua_core::pjsua_resolve_stun_servers
    pjsua_core::resolve_stun_entry                                          .... Trying STUN server IPv4 (1 of 1)
      stun_sock::pj_stun_sock_create
      stun_sock::pj_stun_sock_start
        srv_resolver::pj_dns_srv_resolve                                     .... Starting async DNS A query_job 
              resolver::pj_dns_resolver_start_query                              .... Picked up DNS A record from cache, ttl=616663478
                stun_sock::dns_srv_resolver_cb /* called sync. since DNS record is cached*/
              stun_sock::get_mapped_addr
                    stun_session::pj_stun_session_create_req
                    stun_session::pj_stun_session_send_msg                        .... Error sending STUN request: Network is unreachable
                      stun_transaction::pj_stun_client_tsx_create                 .... STUN client transaction created
                          stun_transaction::pj_stun_client_tsx_send_msg               .... STUN sending message (transmit count=1)
                            stun_transaction::tsx_transmit_msg                        .... STUN error sending message: Network is unreachable
                          stun_session::pj_stun_msg_destroy_tdata
                            stun_session::destroy_tdata                               .... tdata 0x1030f24a8 destroy request, force=0, tsx=0x1030f2630
                              stun_transaction::pj_stun_client_tsx_schedule_destroy   .... STUN transaction  0x1030f2630 schedule destroy
                    stun_sock::sess_fail                                          .... Session failed because STUN Binding request failed: Network is unreachable
                      pjsua_core::test_stun_on_status                             .... STUN resolution failed: Network is unreachable

/* pjsua_resolve_stun_servers Loops for 64 sec before Timeout */
 stun_sock::pj_stun_sock_destroy                                                  .... STUN sock 0x103022e28 request, ref_cnt=3
   stun_session::pj_stun_session_destroy                                   .... STUN session 0x102918228 destroy request, ref_cnt=3

The issue is caused when DNS resolution (pj_dns_srv_resolve() ) in pj_stun_sock_start() returns synchronously and the DNS resolution callback has been called. However, there is currently no mechanism to propagate the error from inside the callback to stun_sock, thus pj_stun_sock_start() will always return PJ_SUCCESS. This causes pjsua STUN server resolution to continue waiting until it times out.

(Note that this issue first appears because of ticket #1962, which directly returns without setting any error status after synchronous failure, to prevent double destruction.)

Thanks to Imad Khazali for the report and analysis.