Custom Query (2195 matches)

Test framework for pjsua which automates testing of various settings and scenarios.

See ticket #272

See ticket #272

Some STUN servers return XOR_MAPPED_ADDRESS attribute even though client doesn't send the STUN2 MAGIC number in the request. This would cause the (old) STUN resolver in PJLIB-UTIL to fail to resolve the address, with typical error messages look like this:

09:29:44.465 pjsua_core.c Error contacting STUN server: No STUN mapped address attribute (PJLIB_UTIL_ESTUNNOMAP) [status=320009]

The solution is either to add XOR_MAPPED_ADDRESS parsing capability to the resolver, or to upgrade this resolver with the new STUN stuffs in PJNATH, or to deprecate this old resolver and create similar functionality in PJNATH (this probably is the best option).

It is common for an agent to place whitespaces (typically newlines) in the base64 encoded input. Currently this would raise assertion in the base256_char() function.

The VoIP metrics calculations needs to be revisited to check if it handles correctly these cases:

• no gap.
• no burst.
• neither of both, no lost/discarded packet.

There is a symptom reported by Johan Lantz about possibility of division by zero, see ​here.

This is a duplication of ticket #722 for the 1.0 branch.

Both the EC options (ec_options) field in the media config and in pjsua_set_ec() argument are ignored and don't have any effect to the echo cancellation setting.

As it is, the pjmedia echo canceller (which uses Speex AEC by default on desktop platforms) would barely reduce any echo. Experimenting with plain Speex AEC API shows that it works, so there must be something in the wrapper/framework that causes it to stop working.

We use polling for the ioqueue and timer heap on most platforms except Symbian. This wastes CPU and power, which is an important issue on mobile devices.

The following snippet:

void test() 
{
    int id = 101;
    PJ_USE_EXCEPTION;
 
    PJ_TRY {
        PJ_LOG(3, ("", "throwing signal %d now", id));
        PJ_THROW(id);
    } PJ_CATCH_ANY {
        id = PJ_GET_EXCEPTION();
        PJ_LOG(3, ("", "caught and reraising %d", id));
        PJ_THROW(id);
    } PJ_END;
 
    PJ_LOG(3, ("", "Never gets called"));
};

leads to an endless loop:

INFO: 08:58:50.682          throwing signal 101 now
INFO: 08:58:50.682          caught and reraising 101
INFO: 08:58:50.682          caught and reraising 101
INFO: 08:58:50.682          caught and reraising 101
...

Thanks Roman Puls for the report.

Reported that there is a time gap in function pj_timer_heap_poll() after the unlock_timer_heap(ht) that pj_stun_session can be destroyed and crash inside on_cache_timeout()

Stack trace:

Exception thrown: read access violation.
   tdata->sess was 0xFFFFFFFFFFFFFFF7. occurred
on_cache_timeout(pj_timer_heap_t * timer_heap, pj_timer_entry * entry) Line 226
   at pjnath\src\pjnath\stun_session.c(226)
pj_timer_heap_poll(pj_timer_heap_t * ht, pj_time_val * next_delay) Line 651
   at pjlib\src\pj\timer.c(651)

Analysis: This should be the crashing line: sess = tdata->sess; which indicates that tdata pool was already released when on_cache_timeout() was invoked. Who destroyed the tdata? It should not be STUN session destroy because the timer is scheduled using sess->grp_lock. So far, the (only) suspect is app, i.e: via pj_stun_msg_destroy_tdata(). So, created a patch that introduces tdata->grp_lock which is used in scheduling tdata cache timeout timer (was scheduled using sess->grp_lock). However, it still crashed on different location:

Exception thrown: read access violation.
   atomic_var was 0xFFFFFFFFFFFFFFFF. occurred
pj_atomic_dec_and_get(pj_atomic_t * atomic_var) Line 800
   at pjlib\src\pj\os_core_win32.c(800)
grp_lock_dec_ref(pj_grp_lock_t * glock) Line 554
   at pjlib\src\pj\lock.c(554)
pj_grp_lock_dec_ref(pj_grp_lock_t * glock) Line 647
   at pjlib\src\pj\lock.c(647)
pj_timer_heap_poll(pj_timer_heap_t * ht, pj_time_val * next_delay) Line 654
   at pjlib\src\pj\timer.c(654)

Analysis: The call stack indicates that tdata had been destroyed after timer callback on_cache_timeout() returned (might be destroyed by the callback itself or by other thread). For STUN response scenario (the only scenario that triggers cache timer scheduling), delete_tdata() should only be invoked by either on_cache_timeout() callback or STUN session destroy. And in this case, it seems that both invoked delete_tdata() in a race scenario which destroyed tdata prematurely.

The initial patch is then updated with additional ammo:

• also add ref STUN session when scheduling cache so STUN session is guaranteed to be still valid in the callback,
• in the on_cache_timeout(), destroy_tdata() is done inside STUN session lock, because it updates sess->cached_response_list.

Thanks Hugo Sobral for the report.

Currently when buddy's presence subscription fails in pjsua-api (i.e. SUBSCRIBE request fails to establish subscription), PJSUA-API will not try to send another SUBSCRIBE ever, so if buddy is online then we won't get notified. Application is currently responsible for managing timer to send another subscribe periodically to probe to buddy's presence.

Ideally PJSUA-API should maintain this timer internally on behalf of application to make life easier.

Note that this only applies to when SUBSCRIBE fails - if SUBSCRIBE succeeds, then buddy's presence will be monitored normally.

The pj_timer_heap_cancel_if_active() API may be given bad timer entry to cancel, because as the name suggest, caller does not check if the entry is active or not. In this case it should just ignore it rather than raising an assertion.

Some timer crash reports that are difficult to reproduce and analyse from log & callstack. Here are typical reported callstacks:

#0  0x00007f7ae3dc0249 in copy_node (ht=0x184cbf0, slot=2305, moved_node=0x7f797732f0c0) at ../src/pj/timer.c:137
#1  0x00007f7ae3dc0677 in reheap_up (ht=0x184cbf0, moved_node=0x7f780e0f2990, slot=2305, parent=1152) at ../src/pj/timer.c:208
#2  0x00007f7ae3dc0882 in remove_node (ht=0x184cbf0, slot=2305) at ../src/pj/timer.c:254
        parent = 1152
        moved_node = 0x7f780e0f2990
        removed_node = 0x7f797f4a9e08
#3  0x00007f7ae3dc0b64 in cancel (ht=0x184cbf0, entry=0x7f797f4a9e08, flags=1) at ../src/pj/timer.c:353
        timer_node_slot = 2305
#4  0x00007f7ae3dc1061 in cancel_timer (ht=0x184cbf0, entry=0x7f797f4a9e08, flags=0, id_val=0) at ../src/pj/timer.c:591
        count = 32634
#5  0x00007f7ae3dc10ea in pj_timer_heap_cancel (ht=0x184cbf0, entry=0x7f797f4a9e08) at ../src/pj/timer.c:611
#6  0x00007f7ae3d0f0c8 in pjsip_endpt_cancel_timer (endpt=0x184c908, entry=0x7f797f4a9e08) at ../src/pjsip/sip_endpoint.c:848

#0  0x00007f543c47dc2a in copy_node (ht=0xbdc8f0, slot=0, moved_node=0x7f51653ca820) at ../src/pj/timer.c:137
#1  0x00007f543c47e146 in remove_node (ht=0xbdc8f0, slot=0) at ../src/pj/timer.c:245
        parent = 139999765322679
        moved_node = 0x7f51653ca820
        removed_node = 0x7f50e53f7e30
#2  0x00007f543c47eb97 in pj_timer_heap_poll (ht=0xbdc8f0, next_delay=0x7f5123517cd0) at ../src/pj/timer.c:643
        node = 0x7f50fe3fad70
        grp_lock = 0x7f52d8e53ba8
        now = {sec = 12628573, msec = 998}
        count = 1

As we can see, the callstack does not really tell the owner of the entry or if the entry is still valid or already freed, because the entry is allocated by application. Moreover, timer structure is public, including its internal states such as _timer_id, _timer_value, _grp_lock, so application may access those internal states directly, which is potentially harmful.

So the goal of this ticket are to:

• Refactor current implementation:
  • Maintain duplicates of entry timer instances and hide the internal states, except _timer_id. Tthis behavior is configurable via the compile-time setting PJ_TIMER_HEAP_USE_COPY (default enabled).
  • Set timer debug (PJ_TIMER_DEBUG) to on by default.
  • Provide some protection against crash due to accidental timer entry modification or premature deallocation (to get the protection, PJ_TIMER_HEAP_USE_COPY must be enabled to allow timer heap to check against the copy if the timer entry has changed. PJ_POOL_RELEASE_WIPE_DATA (default: disabled) is also recommended to be switched on to make sure any freed memory to be wiped out first.)

When the protection detects some changes, PJSIP will print log beginning with "Bug!" such as "Bug! Polling entry 0x7fad11807ea8 from ../src/pjlib-test/timer.c line 646 has been deallocated without being cancelled". The timer heap itself can then resume as per normal, but it is recommended to fix the real bug itself when encountering such message.

• Update timer stress test (continuation of #2176)
  • Testing race conditions with many worker threads performing random tasks of scheduling, cancelling, and polling.

Currently PJLIB timer heap uses CLOCK_MONOTONIC for timestamp clock on some platforms including Android, unfortunately it will stop when CPU goes deep sleep, so certain event may not fire at the scheduled time.

Thank you Itay Bianco for the report.

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.

Rules about who should generate the timestamp is not clear. There may also be places where timestamp information is regenerated.

Tone generation API in pjsua2 and the SWIG wrappers

If remote sends answer with multiple codecs, we will send re-INVITE to lock to one of the codec. When ICE negotiation completes, we would also need to send re-INVITE to update the default candidate (as per ICE spec).

It would be nice if these re-INVITES are combined, to reduce message round-trips, because anyway we are not able to send/receive media until ICE negotiation completes.

Based on SIPit tests, some remote may also not be able to handle re-INVITE before ICE negotiation completes.

Steps to reproduce:

1. reduce transaction timeout to 16 seconds or less
2. send request with TCP to an nonexistent address
3. transaction timeout will occur first
4. transport error event will be called, but transaction will not be destroyed

The corresponding ticket for 1.0 branch is #907

Transaction timer I should be set to zero for reliable transports, not T4.

Ticket #883 added a new keep-alive mechanism for the stream, which would still be performed even when the stream is being paused. Unfortunately, no packet is transmitted on the RTCP port in this situation.

This ticket would enable packet transmission for this situation. With this ticket, an RTCP packet would be transmitted periodically as long as PJMEDIA_STREAM_ENABLE_KA is set to non-zero (note that by default it is disabled).

Changeset r5000 tries to avoid transport-state "Connected" event getting propagated to application after the transport is shutdown. However it introduces a bug that may prevent the transport from getting destroyed because reference counter may never reaches zero.

Sample scenario in function stateless_send_transport_cb() in sip_util.c:

1. pjsip_endpt_acquire_transport2() is invoked which creates a new TCP/TLS transport client. Note that this function also adds reference counter, and starts try to connect to remote.
2. pjsip_transport_send() is invoked with callback set to itself (i.e: send_response_transport_cb()).
3. Application (not sip_util.c) invokes pjsip_transport_shutdown() to this transport, e.g: because of IP change on iOS to close the TCP socket immediately (to avoid spurious wakeups, see #1482).
4. Connected event comes from the ioqueue, TCP/TLS transport see that transport is being shutdown, so it simply returns (see r5000) without notifying application about the sending status.
5. stateless_send_transport_cb() never gets notification of the sending status, so the transport reference counter never reaches zero.

Original report

Multiple requests should reuse the same connection if one already exists to the remote server. When a transport error occurs, the next request should establish a new connection and any following requests should use that same one. With r6002 patch, when a transport error occurs, every new request creates a new connection so you can wind up with thousands of open TCP sockets, possibly exhausting file handles, and increasing memory usage. Reverting commit r6002 (and r6021) restores the expected behavior.

After investigation, the pjsip_tpmgr_acquire_transport2() actually tries to lookup any matching transport to be reused, but unfortunately the search does not check if the matching transport is in shutdown state. And later, when it realizes that the transport is in shutdown state, it simply drops the transport and create a new one.

Thanks to George Joseph for the report.

At the moment, the transport state is only called when TCP connection is closed abnormally. It won't be called if the TCP closure is initiated by us.

Some application wants to keep track of alive TCP (and possibly TLS) connections. For this, they need to be notified when:

• TCP is shutdown, regardless of the reason
• TCP is destroyed, so that they could quit the app gracefully.

On iOS, when doing an IPv6 address lookup, the sockaddr structure copied back to the caller is too short so the IPv6 address is truncated.

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.

Scenario:

• 180 response arrives, with a tag and without route set
• 200 response arrives, with the same tag as 180 response, but with route set.

In this case, dialog MUST update the route set, according to section 13.2.2.4 of RFC 3261.

Thanks Binu K S for reporting and observing this.

This is copy of ticket #152 for trunk.

Currently BYE on early state (before final response is received) is not handled by the invite session. Consider the following scenario:

1. UAS receives INVITE
2. UAS sends 18x
3. UAS sends 200/OK, but this 200/OK is lost
4. UAS hangs up immediately, BYE is sent

The corresponding ticket for the 1.0.x branch is ticket #799

This is duplicate of ticket #798 for the 1.0.x branch. Please see ticket #798 for the description.

This would cause subsequent request from the UAC (such as PRACK) to fail.

Normally we should be able to call UDP connect() and just call send(). This however will trigger exception on Symbian S60 3rd Edition, for both the base and MR2 version.

The PJLIB test to reproduce this is:

• udp_test() in sock.c.
• sock_perf_test() in sock_perf.c

The UDP keep-alive on the account is still running even after the account is deleted with pjsua_acc_del(). Updating the ka_interval with pjsua_acc_modify() also has no effect on the keep-alive.

Ticket #2201 will restart UDP transport when replace_udp_socket() fail when sending data.

Currently when the send data fail, the library will try to resend after trying to replace the socket by calling replace_udp_socket(). However if if it fails again, it will try to restart the transport.

It is possible that the replace_udp_socket() fails, and the UDP transport restart is not called. In this case, restarting UDP transport is preferred rather than trying to resend the data.

Scenario:

• we send INVITE
• we receive 200/OK (with multiple codecs)
• something failed when creating the media
• we send BYE (and ACK for the INVITE)
• shortly later, we send UPDATE to lock the codec

The URI comparison for name address (pjsip_name_addr_compare() function) doesn't check if the object being passed is indeed a name address object, and not other URI object.

Original report can be found ​here.

The scenario is:

1. SRTP is set to disabled/0 for the account.
2. SDP initial offer/answer agrees that SRTP is not being used.
3. Then a new offer comes and tries to activate SRTP using duplicated m line (SRTP mode 3).
4. As the active media/audio index is 0 and the first media line in the new offer uses RTP/SAVP transport type, PJSUA-LIB fails to generate the answer because of invalid media transport type.

So, on such case PJSUA-LIB should be able to choose a media appropriately depending on the SRTP setting (in the account setting). And it should also handle SRTP status changes, e.g: from inactive to active and perhaps to inactive again and so on.

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.

When making call using the flag PJSUA_CALL_INCLUDE_DISABLED_MEDIA with video being disabled, call initialization will get stuck because we are waiting for all media (including disabled) to finish media transport creations.

PJSIP is unable to recognize the Event header if it is encoded with the short from ("o" character).

Calling pjmedia_tonegen_play() to play next tone after pjmedia_tonegen_stop() did not play the tone.

This is the copy of ticket #139 for main trunk.

Transaction may fail to be created/registered to the hash table with the following error message:

"Unable to register transaction (key exists)"

It has been reported that this happened in this scenario:

• in simulated very bad network conditions, with modified Wifi router's iptable to reject certain TCP packets. When TCP disconnect event is received, renew the registration if account id is valid or start SIP registration from the beginning. Thanks Tamàs Solymosi for the report.

When account URI contains display name, pjsip incorrectly interpret successful REGISTER response as unregistration response.

A bug causes PJSIP to respond to authentication challenge with unknown algorithm when it should reject it.

The client registration temporarily increases the pending_tsx flag before calling the callback. This is intended to prevent application from deleting the registration while it's in the callback. Unfortunately this also prevents application from sending another REGISTER request before the pending_tsx flag is not zero.

The solution for this is to separate the has_pending_tsx flag with the flag to prevent deletion.

When the configure script detects the availability of OpenSSL and ALSA libraries, TLS and ALSA support will be included with the library.

But unfortunately this causes undefined symbol error when running Python application, for example:

python pjsua_app.py
 Traceback (most recent call last):
   File "pjsua_app.py", line 8, in ?
     import py_pjsua
 ImportError: /usr/lib/python2.4/site-packages/py_pjsua.so: undefined symbol: 
 snd_pcm_close

Thanks Matthias Laur for the report.

Scenario:

1. TCP is connecting, and the connection establishment is taking more than 32 seconds to complete.
2. The UAC transaction times-out after 32 seconds.
3. When the TCP "connected" event is eventually processed, the request gets transmitted, even though the transaction has been reported as timed-out previously.

Thank you Roni Salfati for the report.

Modifying account config settings, i.e: via pjsua_acc_modify(), is not supposed to always trigger re-registration, for example modifying call or media settings such as SIP session timer, SRTP settings. However, such unexpected re-registration case has been found.

After investigation, it seems to be caused by that proxy setting is mistakenly detected as being modified. The proxy change detection is done using CRC comparison, and the initial CRC calculation in pjsua_acc_add() is performed before the proxy URI normalization.

On stack shutdown/restart, some pending operations on a transmit buffer may be forced to break/stop the operation without notifying the application and cause the transmit buffer dangling unfreed. As the transmit buffer may hold OS resources (e.g: atomic counter, mutex, memory), this will introduce OS resource leak issue (especially on resource with 'OS handle' such as mutex, note that memory will automatically be freed by PJLIB memory pool framework on stack shutdown).

After investigation, here are possible async operations involving transmit buffer:

• DNS resolve.
• Transport send:
  • for TCP/TLS, it may actually a connect pending, this should be safe already, as on_data_sent() callback is invoked during transport destruction,
  • the async send operation itself.

Note that even usually there is timeout timer on every async operation, normally the timer poll is stopped during shutdown stage, so we cannot rely on it.

Alternative solution:

• Introduce new behaviour: always invoke callback on DNS/transport destruction for any pending operation. This is considered to be risky as it potentially introduces more issues :)
• Maintain a list of pending transmit buffers, so SIP endpoint can free any 'dangling' transmit buffers when the SIP endpoint is destroyed.

Steps to reproduce with pjsua app

• Pending DNS resolve:
  • replace "status = pj_ioqueue_sendto(...)" with "status = PJ_EPENDING" in pjlib-util/src/pjlib-util/resolver.c
  • specify nameserver setting in pjsua config param, e.g: --nameserver 8.8.8.8
  • send OPTIONS message to a target URI with hostname, then quit pjsua.
• Pending send:
  • replace any "status = pj_activesock_send(...)" with "status = PJ_EPENDING" in sip_transport_tcp.c
  • send OPTIONS message via TCP, then quit pjsua.

When a transport is registered to the transport manager, it is stored in a hash table according to its key, hence may overwrite a previous entry. The overwritten transport will thus be not properly destroyed when the transport manager is shutdown.

Known issues:

• Timer not freed/deleted when application quits before DNS resolving finished.
• RSocket, timer (and perhaps other resources, e.g: mutex) not freed/closed, when application quits before NAT detection finished.

The report and proposed solution can be found ​here.

It seems that PortAudio? WMME implementation also has this issue, while PortAudio? source code is currently used as external source (not copied into PJSIP SVN).

A unit test failure in the timestamp test that occurrs when the tests are run on a very fast cpu. The number of ticks that elapses in 10 seconds on a XP machine with a multi ghz cpu is greater than the u32 that holds the delta, causing the measured ticks to get truncated and the test to fail.

Thanks Seth Hinze for the report and the patch.

Handle these cases:

• active vs passive roles
• various conversions
• conversion that is instantiated at run-time

Unit test framework in PJLIB, and management of unit test scripts, and integrate it with test dashboard software such as CDash.

Review unit tests deactivated in runall.py to check for false negatives, also fix failing PJSIP module tests (pjlib-test, pjmedia-test, etc).

Mainly focus on fixing spurious test results. This ticket is also a continuation of #1828.

The fixed buffer based pool (created by pj_pool_create_on_buf()) will raise assert if no memory can be allocated. This is unnecessary, and it should just return NULL to let the pool raise PJ exception as normal.

The IOCP documentation says that application needs to call CloseHandle() to unregister the socket from the IOCP, and PJLIB does this in ioqueue_winnt.c.

We assumed that a call to CloseHandle() should close the socket (just like closesocket()), since a socket should just be another handle in Windows NT.

But turns out this is not the case. A call to CloseHandle() doesn't seem to close the socket, as the socket still appears in "netstat" output. Also further down it will cause "Invalid handle" exception to be raised in debug mode when WSACleanup() is called.

Checking at MSDN documentation about CloseHandle() (see ​http://msdn.microsoft.com/en-us/library/ms724211(VS.85).aspx), actually it does suggest application to call both for socket, i.e. always follow closesocket() call with CloseHandle(). This is what it says:

After closing a socket using the closesocket function, ensure that you release the socket by calling CloseHandle. For more information, see ​Socket Closure.

But alas! From experimentation, turns out that calling CloseHandle() after closesocket() will raise "Invalid handle" exception in debug mode. This was tested on WinXP SP2.

After application has marked client registration session for deletion(pjsip_regc_destroy() is called), the client registration session does not respond to authentication challenge in 401/407 response.

Here are the steps to reproduce it:

 // Create Un-REGISTER request
 status = pjsip_regc_unregister(regc, &tdata);

 // Send the request.
 status = pjsip_regc_send(regc, tdata);

 // Signal regc to destroy itself after all transactions complete
 status = pjsip_regc_destroy(regc);  

Currently the unregistration function in PJSIP client registration (pjsip_regc_unregister()) sends REGISTER with Expires=0 for all contacts including those that are registered by other endpoints (because Contact header is set to "*"). This is not the correct behavior since it prevents more than one AOR to be registered.

pjmedia/alaw_ulaw.h is missing PJ_BEGIN/END_DECL constructs, causing unresolved error when it is used by C++ function.

Thanks Alain Totouom <atotouom at gmx de> for the fix.

See ticket #227

Update the BlackBerry/BB10 audio device to the latest SDK R6.

Thanks Bob Cripps for the patch.

The Contact URI is calculated from the STUN mapped address for the SIP transport, which in the symmetric NAT case would be different than rport received from REGISTER response. This would cause subsequent request directed towards the endpoint to not reach the endpoint.

PJSUA-LIB should detect the difference between Contact port and rport, and update the Contact address and registration to use the rport.

Ticket #381 (released in version 0.8) added the ability to update Contact header of account registration for UDP transport. This is useful for clients that are behind symmetric NAT.

This ticket apply the same trick for TCP and TLS transport as well. Please see ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-March/002178.html for background discussion.

Thanks Klaus Darilion for the info.

Currently we support:

• STUN: draft-ietf-behave-rfc3489bis-18
• ICE: draft-ietf-mmusic-ice-19.txt
• TURN: draft-ietf-behave-turn-09

STUN spec has been published as RFC 5389, while TURN spec had advanced into draft-ietf-behave-turn-13 (with major changes).

Also while we're at it, possibly add some ICE samples and more tests.

If stream keep-alive is enabled and it uses empty RTP as the keep-alive mechanism (PJMEDIA_STREAM_ENABLE_KA == PJMEDIA_STREAM_KA_EMPTY_RTP), the RTP sequence may be out of sync when the media is paused and the keep-alive keeps running. This may cause the receiver (such as SRTP module) to reject the RTP packets after media is resumed. Thus, we need to update the RTCP stats when sending keep-alive as well.

Thanks to Viktor Krykun for the report.

Changes in the STUN specification from rfc3489bis-06 to rfc3489bis-10:

• STUN transaction timeout is no longer hardcoded to 1600ms, but rather 16*RTO
• Changes in MESSAGE-INTEGRITY calculation, with regard to the message length value. Previously in bis-06, the length was set to the actual/final length of the message. Now the length is the message length after M-I is added, but before any other attributes past M-I (such as FINGERPRINT) is added.
• Similarly for FINGERPRINT calculation
• HMAC padding for MESSAGE-INTEGRITY is no longer necessary
• Some STUN status codes related to client error were removed:
  • 430 Stale Credentials
  • 431 Integrity Check Failure
  • 432 Missing Username
  • 433 Use TLS
  • 434 Missing Realm
  • 435 Missing Nonce
  • 436 Unknown Username
  • 437 No Binding
• Subsequently since some status codes were removed, response codes for authentication were changed
• Now non-FINGERPRINT attributes are allowed to exist after M-I. Endpoint MUST ignore these attributes, for now.
• added more STUN test vectors in STUN test program

Note that these changes are NOT backward compatible with rfc3489bis-06, meaning new ICE software based on new PJNATH will not be able to negotiate with ICE from previous PJNATH.

Ticket #588 rolled-back Speex AEC to beta3 version which does not support multi-channel EC, so we need to update it to the latest version to support multi-channel.

Testing is done with pjsua on Mac with the following setups: No echo cancellation at all (ec-tail = 0), stereo mode, and mono mode.

For stereo mode, you can clearly observe some echo cancellation compared to the testing without ec, however you can also still notice some uncancelled echo. And this is especially more noticeable after you compare it with mono testing, where the AEC seems to work pretty well and manages to cancel most of the echo.

Note that this ticket only updates the Speex DSP part to version 1.2, but leaves the codec part untouched.

The problematic old pjmedia_format fields used by APS/VAS are 'bitrate' and 'vad'. The 'bitrate' field name is replaced by 'avg_bps' in the new pjmedia_format. While 'vad' should be handled as sound device capability.

Thanks Rubel for the report.

From ​rfc3261:

For each target, the proxy forwards the request following these
   steps:
      1.  Make a copy of the received request
      2.  Update the Request-URI
      3.  Update the Max-Forwards header field
      4.  Optionally add a Record-route header field value
      5.  Optionally add additional header fields
      6.  Postprocess routing information
      7.  Determine the next-hop address, port, and transport
      8.  Add a Via header field value
      9.  Add a Content-Length header field if necessary
      10. Forward the new request
      11. Set timer C

On proxy scenario, Via header required to be added to the message sent. The library will add the header on sip_util_proxy.c without the sent-by field which is updated on sip_util.c.

Unfortunately, #2085 will not update Via header on CANCEL request making the Via header without the sent-by field. Afterwards the message will get ignored/discarded by the receiving end.

This ticket will update the Via header when the sent-by field is not set.

Thanks to Varun Ahluwalia for the report

AES-GCM feature in libSRTP 1.5.4 (the latest 1.x release) has compatibility issue with OpenSSL 1.1.0 (see also ticket #1932). However in the current development source code, it seems to have some work on supporting OpenSSL 1.1.0, so when new version is released, it is better to update our bundled libSRTP.

Some platforms use PortAudio as their default audio device backend, while the PortAudio version we are using is quite old and the effort to update the version is not small. Meanwhile, we already have our own audio device implementations that are considerably lightweight and stable as they have been around and tested for quite long time. So yes, we are considering to update the default audio device backends to our own implementations.

• MacOSX
  Currently the default backend is PortAudio. since MacOSX 10.11, it produces warning message (thank you Martin Ohlsson for the report):

  WARNING:  140: This application, or a library it uses, is using the deprecated
  Carbon Component Manager for hosting Audio Units. Support for this will be
  removed in a future release. Also, this makes the host incompatible 
  with version 3 audio units. Please transition to the API's in AudioComponent.h
  

  So we'll update the default backend to our CoreAudio implementation.

• Linux/*nix
  The default is also PortAudio (ALSA or OSS), we'll use our ALSA implementation (if ALSA header is available).

• MinGW
  The default are both PortAudio and WMME, we'll just use WMME as default.

Reported that on IP change scenario, local contact may not be updated while it should. After investigation, if force_contact is not configured and the account is not registering, call option PJSUA_CALL_UPDATE_CONTACT will not update the contact.

Thanks Marcus Froeschl for the report.

Update the documentations:

• pjsua-API online documentation can be made more extensive.
• some misleading info in conference documentation (it says that it needs audio device while it's not).
• update the documentation on the website.

iOS video capture and simple renderer were actually already implemented, however it has not been maintained nor tested for long time due to lack of video support on iOS. This ticket will check and update the implementations.

Some additional features planned on the capture device implementation:

• native preview
• enumerate all available capture devices, e.g: front and back camera
• fast switch between capture devices

The simple renderer is a CGImage+UIView based renderer.

The pjnath-test needs to be updated to support turn-13.

As stated in ​rfc3261

13.2.2.1 1xx Responses

   Zero, one or multiple provisional responses may arrive before one or
   more final responses are received.  Provisional responses for an
   INVITE request can create "early dialogs".  If a provisional response
   has a tag in the To field, and if the dialog ID of the response does
   not match an existing dialog, one is constructed using the procedures
   defined in Section 12.1.2.

   The early dialog will only be needed if the UAC needs to send a
   request to its peer within the dialog before the initial INVITE
   transaction completes.  Header fields present in a provisional
   response are applicable as long as the dialog is in the early state
   (for example, an Allow header field in a provisional response
   contains the methods that can be used in the dialog while this is in
   the early state).

And ​rfc3311:

   When a UAS compliant to this specification receives an INVITE request
   for a new dialog, and generates a reliable provisional response
   containing SDP, that response SHOULD contain an Allow header field
   that lists the UPDATE method.  This informs the caller that the
   callee is capable of receiving an UPDATE request at any time.  An
   unreliable provisional response MAY contain an Allow header field
   listing the UPDATE method, and a 2xx response SHOULD contain an Allow
   header field listing the UPDATE method.

This patch will update invite options when Allow UPDATE header is included in the provisional response of the INVITE.

Thanks to Pirmin (pirmin@walthert.net) for the patch

Proposed solutions:

1. Shrinking to be based on recent maximum burst level. This will make jitter buffer shrinking a bit less aggressive. Currently shrinking is done based on current burst level (presented by jb_prefetch).
2. Reenable prefetch buffering. This should be able to be configured in run-time, e.g: setting initial-prefetch > 0 will make this feature enabled.

Current bundled libyuv seems to have build issue on older gcc, e.g:

../../yuv/source/row_common.cc: In function ‘void libyuv::YuvPixel(uint8, uint8, uint8, uint8*, uint8*, uint8*, const libyuv::YuvConstants*)’:
../../yuv/source/row_common.cc:1256: error: invalid types ‘const signed char __vector__[int]’ for array subscript
../../yuv/source/row_common.cc:1257: error: invalid types ‘const signed char __vector__[int]’ for array subscript
../../yuv/source/row_common.cc:1258: error: invalid types ‘const signed char __vector__[int]’ for array subscript
../../yuv/source/row_common.cc:1259: error: invalid types ‘const signed char __vector__[int]’ for array subscript
../../yuv/source/row_common.cc:1260: error: invalid types ‘const short int __vector__[int]’ for array subscript

Also in the source code around the compile error location, there is this warning:

// Caveat GCC 4.2 to 4.7 have a known issue using vectors with const.

The issue seem to be fixed already, as described ​here. So let's update our libyuv version.

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.

Ticket #865 introduces a new callback rtp_cb2(), so we need to consider this when implementing our media transport adapter.