Custom Query (2195 matches)

This patch changes the BSD sockets implementation of QoS to use IPV6_TCLASS for IPv6 sockets instead of IP_TOS.

Summary of changes:

• new constant PJ_IPV6_TCLASS, wrapper of IPV6_TCLASS (if defined) or 0xFFFF, because there is no sane default - all operating systems that implement the IPV6_TCLASS option assign a different value to it, and no RFC standardizes it
• pj_IPV6_TCLASS() wrapper for PJ_IPV6_TCLASS constant
• pj_sock_set_qos_params and pj_sock_get_qos_params now check for the socket address family before trying to set or get the socket's QoS: if the socket is IPv4, they will use pj_IP_TOS() as before, if the socket is IPv6 they will use pj_IPV6_TCLASS() instead. Before, using QoS on an IPv6 socket would unconditionally fail with PJ_STATUS_FROM_OS(EINVAL), now it will succeed if the OS supports IPV6_TCLASS (or fail with PJ_STATUS_FROM_OS(ENOPROTOOPT) if it doesn't)

Thanks to Michele Cicciotti for the patch.

The latest XNU kernel, shipped with iOS 10, Mac OS 10.11, AppleTV OS 10, etc. supports a new socket option, SO_NET_SERVICE_TYPE, a high level API for configuring a socket's QoS, which the OS will appropriately and transparently map to a DSCP or WMM priority depending on the network connection.

This patch introduces a new implementation of the socket QoS functions specifically for the Darwin platform, that makes use of SO_NET_SERVICE_TYPE when available, and falls back to IP_TOS/IPV6_TCLASS elsewhere.

Changes introduced by this patch:

• build system and configuration script changes, so that the BSD sockets implementation of QoS is no longer the default on all platforms, but only on non-Darwin platforms. On Darwin platforms, the new Darwin-specific QoS implementation is used instead
• new PJ_QOS_TYPE_SIGNALLING in pj_qos_type which corresponds to NET_SERVICE_TYPE_SIG
• new PJLIB constant OSERR_ENOPROTOOPT, that maps to ENOPROTOOPT (WSAENOPROTOOPT for Winsock)
• new configuration constant PJ_QOS_DARWIN, that can be used as the value of PJ_QOS_IMPLEMENTATION
• new, Darwin-specific implementations of pj_sock_set_qos_params, pj_sock_set_qos_type, pj_sock_get_qos_params and pj_sock_get_qos_type, based on SO_NET_SERVICE_TYPE, and falling back to IP_TOS/IPV6_TCLASS

Backwards/forwards compatibility considerations: on older Darwin platforms, the SDK doesn't define SO_NET_SERVICE_TYPE, and QoS functions always use IP_TOS/IPV6_TCLASS instead. Running code compiled with an old SDK on a new operating system has the same behavior as it had before, and like before with the caveat that, at some point in the future, the OS may start ignoring the value set with IP_TOS/IPV6_TCLASS on newer Darwin platforms, SO_NET_SERVICE_TYPE is always used.

Running code compiled with a new SDK on an old operating system makes attempts to get/set SO_NET_SERVICE_TYPE fail with ENOPROTOOPT, which the QoS function translate to PJ_ENOTSUP, which is handled with a runtime fallback on the old IP_TOS/IPV6_TCLASS code.

For future reference, mapping of pj_qos_type might be changed according to the new standard. Please have a look at the draft: ​https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-00

Thanks to Michele Cicciotti for the patch.

This feature could be useful for specifying PN (Push Notification) information to the server, such as the one described in the draft ​Push Notifications in the Session Initiation Protocol (SIP)

For example:

Contact: <sip:alice@alicemobile.example.com;
     pn-type=acme;pn-methods="INVITE";
     pn-uri="https://pn.acme.example.com/ZTY4ZDJlMzODE1NmUgKi0K">

Steps to reproduce the problem with pjsua:

1. Set ipv6_media_use = PJSUA_IPV6_ENABLED
2. Start 2 pjsua, pjsua A use --use-ice, pjsua B doesn't.
3. Make call (from A to B or B to A)

After starting and stopping ICE, pjsua will eventually answer with 488 (IPv6 media will work fine if both disable ICE or both enable ICE).

Log snippet:

12:28:57.443        icetp00  Stopping ICE, reason=No ICE found in SDP offer
12:28:57.443        icetp00  Destroying ICE session 0x7fd2d485ae28
12:28:57.443   pjsua_call.c  Answering call 0: code=200
12:28:57.443  pjsua_media.c  ...Call 0: updating media..
12:28:57.443  pjsua_media.c  ....pjmedia_stream_info_from_sdp() failed for call_id 0 media 0: Unsupported address family (PJ_EAFNOTSUP)

Analysis:

1. In pjsua_media_channel_create_sdp():
* pjmedia_transport_get_info(call_med->tp, &tpinfo);
 - in transport_ice.c: transport_get_info() will set:
 - info->sock_info.rtp_addr_name -> pj_ice_strans_get_def_cand()-> pj_ice_strans_get_valid_pair(), which is IP4 address
* pjmedia_endpt_create_audio_sdp() will create media with IP4 conn

2. In pjsua_media_channel_update():
* pjmedia_stream_info_from_sdp() will fail:
    /* Local and remote address family must match, except when ICE is used
     * by both sides (see also ticket #1952).
     */
    if (local_af != rem_af) {
....
        return PJ_EAFNOTSUP;
    }

This ticket adds the function pjsip_tdata_get_dlg() which is similar to the pjsip_rdata_get_dlg(), but for tdatas. This is very useful to use from inside a module to know if a particular outgoing request/response should be modified based on it belonging to a dialog.

Thanks to Kal (b17 c0de) for the patch.

Starting NDK r13, Android NDK has set NDK_TOOLCHAIN_VERSION default value to Clang. This will result the configure-android to fail with this error:

configure-android error: compiler not found, please check environment 
settings (TARGET_ABI, etc)

Furthermore, r13 release notes states that:

GCC is no longer supported. It will not be removed from the NDK just yet, 
but is no longer receiving backports. 
It cannot be removed until after libc++ has become stable enough to be the default, 
as some parts of gnustl are still incompatible with Clang. 
It will likely be removed after that point.

So, the same issue should be expected on r14 and later.

At the moment (on r13), you can force the ndk to use gcc by specifying the NDK_TOOLCHAIN_VERSION to 4.9.

e.g:

NDK_TOOLCHAIN_VERSION=4.9 TARGET_ABI=armeabi-v7a ./configure-android --use-ndk-cflags

Update:

Since r5620. configure-android have been modified to support clang, hence user wouldn't need to specify NDK_TOOLCHAIN_VERSION.

Known Issue when building with clang:

When building for older android device, it is needed to specify APP_PLATFORM.

e.g: APP_PLATFORM=android-17

The build might fail with these error:

In file included from ../../yuv/source/compare.cc:14:
/app/android-ndk-r13b//sources/cxx-stl/llvm-libc++/include/math.h:661:91: error: use of undeclared identifier 'acosl'
inline _LIBCPP_INLINE_VISIBILITY long double acos(long double __lcpp_x) _NOEXCEPT {return acosl(__lcpp_x);}
                                                                                          ^
/app/android-ndk-r13b//sources/cxx-stl/llvm-libc++/include/math.h:673:91: error: use of undeclared identifier 'asinl'
inline _LIBCPP_INLINE_VISIBILITY long double asin(long double __lcpp_x) _NOEXCEPT {return asinl(__lcpp_x);}

The error is described in detail in ​here.

To handle it user need to include $(NDKRoot)/sources/android/support/include in the CFLAGS (user.mak).

On heavy loaded system with TLS, one thread could destroy the ssl socket on SSL_ERROR_SYSCALL while another thread still uses this socket which was already freed, so we get segfault.

Stack trace:

Stack trace of thread 6110:
#0  0x00007f2f6497a914 __memcpy_sse2_unaligned (libc.so.6)
#1  0x00007f2f6601adc6 mem_write (libcrypto.so.10)
#2  0x00007f2f66019d6c BIO_write (libcrypto.so.10)
#3  0x00007f2f6638b652 ssl3_write_pending (libssl.so.10)
#4  0x00007f2f6638d833 ssl3_dispatch_alert (libssl.so.10)
#5  0x00007f2f66389432 ssl3_shutdown (libssl.so.10)
#6  0x00007f2ed6b154cf destroy_ssl (libpj.so.2)
#7  0x00007f2ed6b169f7 asock_on_data_read (libpj.so.2)
#8  0x00007f2ed6b0c018 ioqueue_on_read_complete (libpj.so.2)
#9  0x00007f2ed6b07af2 ioqueue_dispatch_read_event (libpj.so.2)
#10 0x00007f2ed6b08ee0 pj_ioqueue_poll (libpj.so.2)
#11 0x00007f2ed86551d5 pjsip_endpt_handle_events2 (libpjsip.so.2)
#12 0x00007f2ed46206c8 monitor_thread_exec (res_pjsip.so)
#13 0x00007f2ed6b09e06 thread_main (libpj.so.2)
#14 0x00007f2f656a261a start_thread (libpthread.so.0)
#15 0x00007f2f649de59d __clone (libc.so.6)

#0  0x00007f66058ca1c0 in ?? ()
#1  0x00007f66b10307bb in BIO_write () from /lib64/libcrypto.so.1
#2  0x00007f66b1363142 in ssl3_write_pending () from /lib64/libssl.so.1
#3  0x00007f66b1363a20 in ssl3_write_bytes () from /lib64/libssl.so.1
#4  0x00007f664df7d806 in ssl_write (ssock=ssock@entry=0x7f663187a858, send_key=send_key@entry=0x7f6630543040, 
    data=data@entry=0x7f662c4e0768, size=421, flags=flags@entry=0) at ../src/pj/ssl_sock_ossl.c:2499
#5  0x00007f664df7f62d in pj_ssl_sock_send (ssock=0x7f663187a858, send_key=send_key@entry=0x7f6630543040, data=0x7f662c4e0768, 
    size=size@entry=0x7f6646f0b5d8, flags=flags@entry=0) at ../src/pj/ssl_sock_ossl.c:2643
#6  0x00007f664f04d410 in tls_send_msg (transport=0x7f66304b9348, tdata=0x7f6630542fe8, rem_addr=<optimized out>, 
    addr_len=<optimized out>, token=<optimized out>, callback=<optimized out>) at ../src/pjsip/sip_transport_tls.c:1460
#7  0x00007f664f047b8a in pjsip_transport_send (tr=0x7f66304b9348, tdata=tdata@entry=0x7f6630542fe8, 
    addr=addr@entry=0x7f66305431d8, addr_len=addr_len@entry=16, token=token@entry=0x7f6630543c10, 
    cb=cb@entry=0x7f664f043614 <stateless_send_transport_cb>) at ../src/pjsip/sip_transport.c:839
#8  0x00007f664f04395d in stateless_send_transport_cb (token=token@entry=0x7f6630543c10, tdata=tdata@entry=0x7f6630542fe8, 
    sent=<optimized out>, sent@entry=-70002) at ../src/pjsip/sip_util.c:1251
#9  0x00007f664f043b91 in stateless_send_resolver_callback (status=<optimized out>, token=0x7f6630543c10, addr=<optimized out>)
    at ../src/pjsip/sip_util.c:1352
#10 0x00007f664f046883 in pjsip_resolve (resolver=<optimized out>, pool=<optimized out>, target=target@entry=0x7f6646f0b9f0, 
    token=token@entry=0x7f6630543c10, cb=cb@entry=0x7f664f0439a0 <stateless_send_resolver_callback>)
    at ../src/pjsip/sip_resolve.c:348
#11 0x00007f664f0430b7 in pjsip_endpt_resolve (endpt=endpt@entry=0x1c0b5c8, pool=<optimized out>, 
    target=target@entry=0x7f6646f0b9f0, token=token@entry=0x7f6630543c10, 
    cb=cb@entry=0x7f664f0439a0 <stateless_send_resolver_callback>) at ../src/pjsip/sip_endpoint.c:1158
#12 0x00007f664f04537f in pjsip_endpt_send_request_stateless (endpt=0x1c0b5c8, tdata=tdata@entry=0x7f6630542fe8, 
    token=token@entry=0x0, cb=cb@entry=0x0) at ../src/pjsip/sip_util.c:1396
#13 0x00007f664f056dc3 in pjsip_dlg_send_request (dlg=0x7f66a02f3b18, tdata=0x7f6630542fe8, mod_data_id=mod_data_id@entry=-1, 
    mod_data=mod_data@entry=0x0) at ../src/pjsip/sip_dialog.c:1290
#14 0x00007f664f48fbb1 in inv_send_ack (inv=inv@entry=0x7f66a02f4b68, e=e@entry=0x7f6646f0bb60) at ../src/pjsip-ua/sip_inv.c:442
#15 0x00007f664f491eae in inv_on_state_early (inv=0x7f66a02f4b68, e=0x7f6646f0bb60) at ../src/pjsip-ua/sip_inv.c:4392
#16 0x00007f664f48cf79 in mod_inv_on_tsx_state (tsx=0x7f66a030f4f8, e=0x7f6646f0bb60) at ../src/pjsip-ua/sip_inv.c:677
#17 0x00007f664f0574bd in pjsip_dlg_on_tsx_state (dlg=0x7f66a02f3b18, tsx=0x7f66a030f4f8, e=0x7f6646f0bb60)
    at ../src/pjsip/sip_dialog.c:2056
#18 0x00007f664f05833a in mod_ua_on_tsx_state (tsx=<optimized out>, e=<optimized out>) at ../src/pjsip/sip_ua_layer.c:178
#19 0x00007f664f052a0c in tsx_set_state (tsx=tsx@entry=0x7f66a030f4f8, state=state@entry=PJSIP_TSX_STATE_TERMINATED, 
    event_src_type=event_src_type@entry=PJSIP_EVENT_RX_MSG, event_src=0x7f6605933e28, flag=flag@entry=0)
    at ../src/pjsip/sip_transaction.c:1233
#20 0x00007f664f053f30 in tsx_on_state_proceeding_uac (tsx=0x7f66a030f4f8, event=0x7f6646f0bc20)
    at ../src/pjsip/sip_transaction.c:2930
#21 0x00007f664f0552ac in pjsip_tsx_recv_msg (tsx=tsx@entry=0x7f66a030f4f8, rdata=rdata@entry=0x7f6605933e28)
    at ../src/pjsip/sip_transaction.c:1787

There are some issues we identified:

• Race condition : write method was called on an already destroyed SSL.
• Race condition : write_mutex destroyed before the call to send.

These issues can be resolved by using the group lock and moving the cleanup code (destroy_ssl() and pj_lock_destroy()) to the group lock destroy method handler.

Note that we can't move the close_sockets() operation to the destroy handler, since we need the pj_grp_lock_dec_ref() be called from pj_activesock_close(). However, we cannot set the ssock->asock to NULL since it will raise asock == NULL assertion.

Thanks to Alexei Gradinari for the report and original patch.

This ticket will introduce pjmedia_rtp_decode_rtp2() which is similar to pjmedia_rtp_decode_rtp() but adds additional out parameter to return the additional RTP header in the packet if any. Currently the additional RTP header will point to RTP header extension. It would be useful to other people who need to parse the RTP header extension.

Thanks to Kal (b17 c0de) for the original patch.

Revision r5342 (of ticket #422) misses IPv6 in TURN settings.

Thanks Bing Huan Chio for the report.

• ICE initialization hangs when using DNS SRV and unresolvable TURN server.

When making call with IPv6, ICE/TURN, and DNS SRV enabled, the media initialization seems to get stuck and no INVITE message is not generated/sent.

After investigation it turns out that ICE transport does not update TURN candidate status from PJ_EPENDING when the asynchronous TURN server name resolution fails, so that ICE initialization never reaches state PJ_ICE_STRANS_STATE_READY and callback on_ice_complete() never gets invoked.

• Assertions when trying to access other components/candidates.

Failure in the process of creating a component/candidate, such as connection failure to a TURN server, could also lead to other problems, such as assertions when trying to access other components/candidates, which have not been initialized yet.

• Crash when accessing the failed component.

Failure in creating a TURN candidate would result in crash when trying to access the already-destroyed TURN socket.

Thanks to Bing Huan, Chio for the report.

1. There is a race condition introduced with the IPv6 DNS patch.
   Given
   *) Thread A sending a SIP request that needs DNS resolution.
   *) Thread B handling DNS query responses in pjsip_endpt_handle_events().
   The call to pjsip_resolve() happens under Thread A which sets a dummy query:

   query->object6 = (pj_dns_async_query*)0x1;
   

   and then calls pj_dns_resolver_start_query() with the dns_a_callback().
   However, the dummy query protection is undone because the first thing that pj_dns_resolver_start_query() with the dns_a_callback() does is to set query->object6 to NULL when it is called.
   Then in thread B, the dns_a_callback() sees that there isn't an IPv6 query and attempts to send the request immediately even if there may not be any A records in the response. The pending dns_aaaa_callback() can now attempt to use resources that may be destroyed.

2. In pjsip_resolve() the pj_dns_resolver_start_query() for the AAAA records should be guarded by a status == PJ_SUCCESS check in case the A records query start fails.

3. In both dns_a_callback() & dns_aaaa_callback():
   

   if (srv->count > 0)
      (*query->cb)(PJ_SUCCESS, query->token, &query->server);
   else
      (*query->cb)(query->last_error, query->token, NULL);
   

   However, query->last_error is never set, thus in sip_util.c stateless_send_resolver_callback() it will hit the assertion:

   pj_assert(tdata->dest_info.addr.count != 0);
   

   If assertion in disabled, later in stateless_send_transport_cb() the code line:

   cont = (sent > 0) ? PJ_FALSE :
   (tdata->dest_info.cur_addr<tdata->dest_info.addr.count-1);
   

   can result in an underflow.

4. Fixed bug of premature app callback invocation for SRV resolver by applying the same method in r5369.

5. Remove DNS cache entry from resolver's hash table when app callback has a reference.
   In resolver.c update_res_cache(), if app callback has a reference, we only decrement the reference count of the cache entry. However, since it's not removed from the hash table, later the call to pj_hash_set_np() will overwrite this old entry (instead of using the newly allocated cache->hbuf), which will later be freed.

6. Given
   *) A previous cached A record DNS resolution that contains either no answer records or had an error returned in the query response (PJ_STATUS_FROM_DNS_RCODE() is not PJ_SUCCESS).
   *) The next attempt to send a SIP request under Thread A will cause pj_dns_resolver_start_query() to find the cached entry and immediately call the cb callback. When the callback returns pj_dns_resolver_start_query() cannot update *p_query because where it points to may no longer be valid because the memory could be freed.
   Fixed in r5477

Thank you to Richard Mudgett (Digium) for the report.

This ticket will add the following enhancements to TLS:

1. selection of elliptic curve
2. selection of signature algorithm
3. reseeding of random with other entropy sources.

which may be useful to conform to ​NIAP protection profile.

Add support to generate a synthesized IPv6 address from IPv4 address. The ability to synthesize IPv6 addresses was added to getaddrinfo in iOS 9.2 and OS X 10.11.2 (reference: ​Apple's doc).

Thanks to Jamil Abdullayev for the patch.

This patch adds a attach2() member function to pjmedia_transport_op and the corresponding pjmedia_transport_attach2() function.

These new functions take an additional parameter for the media stream and type. This allows all transport adapters in the chain to have access to the media stream and type.

Thanks to Kal (b17 c0de) for the original patch.

This patch will add function to get RTP session information (pjmedia_stream_rtp_sess_info) from pjmedia_stream and pjmedia_vid_stream.
It will be useful for app with custom transport adapter to inject/filter some proprietary packets into audio/video RTP traffics. However, generally it is not advisable to modify them.

Thanks to Kal (b17 c0de) for the original patch.

For string addresses with scope IDs, which can be useful to specify interface names, such as "fe80::1234%intf1", inet_pton() will simply ignore the scope ID. The solution would be to use getaddrinfo(), which can correctly parse the scope ID.

After remote removes some media lines in previous SDP negotiations, when trying to create an offer, PJSIP will trigger an assertion:

Assertion failed: mi < s_->media_count, file pjsip\trunk\pjsip\src\pjsua-lib\pjsua_media.c

Scenario:

• Receive incoming call with 2 medias, 1 audio and 1 unsupported media (such as video for PJSIP compiled with audio only)
• Receive re-invite with only one media (audio)
• Try to send re-invite from PJSIP

Thanks to Eize Slange for the report.

When session timer is disabled and we receive 422 (Session Interval Too Small) response, PJSIP will assert when trying to hangup the call:

15:59:23.242   pjsua_call.c  .Call 0 hanging up: code=0..
Assertion failed: (req_tdata->msg->type == PJSIP_REQUEST_MSG && req_tdata->msg->line.req.method.id == PJSIP_INVITE_METHOD), function pjsip_endpt_create_cancel, file ../src/pjsip/sip_util.c, line 713.

Thanks to Andrey Kovalenko for the report and the patch.

The ticket will add pjsua_call_flag PJSUA_CALL_REINIT_MEDIA, which will deinitialize and recreate media, including media transport. It is useful in IP address change situation, if the media transport address (or address family) changes, for example during IPv4/IPv6 network handover.

To use this feature, call the API pjsua_call_reinvite()/reinvite2(), or pjsua_call_update()/update2(). The only drawback of using this option is that if the re-INVITE/UPDATE fails, the old media will not be reverted.

Update the invite session's Via address. Similar to the flag PJSUA_CALL_UPDATE_CONTACT, this flag is useful in IP address change situation, after the local account's Via has been updated (typically with re-registration).

Currently PJ_HASH_USE_OWN_TOLOWER is only used in pj_hash_calc_tolower(). However, it could cause hash key mismatch (such as when trying to find a SIP transaction key) since find_entry() doesn't seem to take into account of this and try to find key based on the calculation of not using own tolower().

The proposed solution would be to remove PJ_HASH_USE_OWN_TOLOWER since it doesn't offer much efficiency improvement and the implementation only assumes that the string is alphanumeric.

Thanks to Richard Mudgett for the report.

In the example of the ​RFC 3515:

Refer-To: <sip:dave@denver.example.org?Replaces=12345%40192.168.118.3%3B
          to-tag%3D12345%3Bfrom-tag%3D5FFE-3994>

The character @ in the Replaces parameter of Refer-To header in a Refer request is escaped, so we also wish to do the same in order to avoid interoperability issues (it's reported that some servers reject unescaped @).

Thanks to Dan Feryance for the patch.

Thanks to Eize Slange as well for reporting and providing a patch in ​PJSIP mailing list.

Tasks:

1. Convert pjsua and pjsua2 app sample projects.
2. Adjust PJSIP build configs (Makefile, etc).
3. Update wiki.

Scenario:

1. Make call with default call flags where PJSUA_CALL_INCLUDE_DISABLED_MEDIA is set, so SDP offer contains 2 m= lines: audio and disabled video
2. After call is established, initiate re-INVITE with call option flag set to only PJSUA_CALL_REINIT_MEDIA (PJSUA_CALL_INCLUDE_DISABLED_MEDIA is cleared). This time SDP offer also contains 2 m= lines: audio and disabled video.
3. Assertion raised:

   Assertion failed: (call->med_prov_cnt >= local_sdp->media_count),
           function pjsua_media_channel_update, file ../src/pjsua-lib/pjsua_media.c, line 2857.
   

   with call->med_prov_cnt==1, call->med_cnt==2, local_sdp->media_count==2.

After investigation, we found that pjsua_media_channel_init() with PJSUA_CALL_REINIT_MEDIA causes call->med_prov_cnt==1 due to PJSUA_CALL_INCLUDE_DISABLED_MEDIA flag is not set, but pjmedia_sdp_neg_modify_local_offer2() adds a new m= line (i.e: disabled video from current active local SDP) to the SDP to maintain the media count (as mandated by standard). Eventually as call->med_prov_cnt is less than the number of m= line, assertion is raised.

Thanks Nadia Lapkovskaya for the report.

Reported that the crash happened because an outstanding read operation key is reset by udp_on_read_complete() so socket read list gets corrupted. When there is incoming packet, ioqueue will try to deliver the packet to application by accessing the corrupted socket read list.

After investigation, possible scenario is:

1. Spinning loop inside read callback udp_on_read_complete() is somehow still running while another thread is is executing UDP restart (pjsip_udp_transport_restart()).
2. The UDP restart reinitiates read operation, so some op_key are queued to socket read list.
3. Unfortunately the still spinning udp_on_read_complete() may wipe out those op_key.

The solution idea is to make sure that there is no read callback execution before reinitiating read operation in UDP restart. However, such synchronization is not simple (note: ioqueue may release key/socket lock before invoking read callback to avoid deadlock). A possible workaround is to wait for any active spinning loop in read callback to complete before reinitiating read operation in UDP restart.

Thanks Kinsey Moore for the report.

This ticket will implement new APIs:

• pj_strspn() / pj_strspn2()
• pj_strcspn() / pj_strcspn2()
• pj_strtok() / pj_strtok2()

They are used as a replacement to strtok() which is not thread safe.

Log indication

pjsua_call.c  Answering call 1: code=200
pjsua_call.c  Pending answering call 1 upon completion of media transport
...
pjsua_call.c  Answering call 1: code=200
pjsua_call.c  Pending answering call 1 upon completion of media transport
... (and so on)

Scenario

After investigation, the blocking part turns out to be TURN allocation which seems to take forever.

1. DNS resolver is configured and the TURN server hostname is in the DNS resolver cache
2. ICE is trying to create TURN candidate, it creates TURN transport and starts TURN allocation by invoking pj_turn_sock_alloc()
3. pj_turn_session_set_server() starts resolving TURN server IP address by invoking pj_dns_srv_resolve()
4. as DNS entry is in the cache, DNS resolver callback is invoked in the same context which triggers TURN allocation
5. the TURN allocation fails synchronously too, so TURN transport destroys itself, DNS resolver callback returns, and then pj_dns_srv_resolve() also returns with PJ_SUCCESS return value as the resolution was successful
6. alas, the PJ_SUCCESS return value is propagated upstream, so ICE sees that pj_turn_sock_alloc() returns PJ_SUCCESS and TURN candidate is added
7. as the failure happens prematurely before TURN candidate is added, the candidate status remains PJ_EPENDING forever.

The idea is to add check for possibility of premature failure in pj_turn_sock_alloc() after pj_turn_session_set_server() returns PJ_SUCCESS.

Thanks Bing Huan Chio for the report.

We can adjust audio device volume using ALSA mixer, such as shown ​here.

However, more study is needed before it's implemented:

• are the required components/APIs always available and supported by default?
• make sure to find the correct sound card name and id, if not using the default master sound card

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.

Miscellaneous updates and fixes

The currently existing API pjsip_transport_shutdown() will perform a graceful shutdown, which typically will wait until a timeout occurs before disconnecting and destroying the transport. However sometimes it is desirable to disconnect a transport immediately, such as in the event of an IP address change.

According to ​RFC 3261:

A CANCEL constructed by a
client MUST have only a single Via header field value *matching the
top Via value in the request being cancelled*.  Using the same values
for these header fields allows the CANCEL to be matched with the
request it cancels.

However, in PJSIP, when there is an IP address change situation, the Via header will be updated with the new address, causing the CANCEL's Via header to be different from the original INVITE's Via.

With the new API pjsip_transport_shutdown2(), ongoing session refresh transaction can immediately end with transport error (503). However, it will also trigger call disconnection by sending BYE.

This ticket adds a compile-time configurable setting PJSIP_SESS_TIMER_RETRY_DELAY for retrying session refresh request upon receiving 503 error. User can set it to -1 if they prefer the old behavior (immediate disconnection).

A UAS which needs to recreate incoming subscriptions from a persistent store can call pjsip_dlg_create_uas_and_inc_lock() and pjsip_evsub_create_uas() as long as they've persisted the correct data but since the timer is triggered by an incoming subscribe, it's never set and the subscription never expires.

This ticket:

• Adds API pjsip_evsub_set_uas_timeout(), which is just a wrapper around evsub.c:set_timeout(sub, TIMER_TYPE_UAS_TIMEOUT, seconds)

• Also, fixed a copy-paste error in pjsip_sub_state_hdr_print() when printing retry-after parameter.

Thanks to George Joseph for the patch.

OpenSSL 1.1.0 seems to deprecate quite a lot of APIs and backward compatibilities are mostly maintained when using default settings (e.g: OPENSSL_API_COMPAT==OPENSSL_MIN_API==0). In #1932, PJLIB SSL socket does not handle the deprecated APIs when backward compatibility settings are turned off, so there will be linking errors such as:

"_SSL_library_init", referenced from:
      _init_openssl in libpj-armv7-apple-darwin_ios.a(ssl_sock_ossl.o)
  "_SSL_load_error_strings", referenced from:
      _init_openssl in libpj-armv7-apple-darwin_ios.a(ssl_sock_ossl.o)
  "_TLSv1_method", referenced from:
      _create_ssl in libpj-armv7-apple-darwin_ios.a(ssl_sock_ossl.o)
  "_TLSv1_server_method", referenced from:
      _init_openssl in libpj-armv7-apple-darwin_ios.a(ssl_sock_ossl.o)
  "_X509_get_notAfter", referenced from:
      _get_cert_info in libpj-armv7-apple-darwin_ios.a(ssl_sock_ossl.o)
  "_X509_get_notBefore", referenced from:
      _get_cert_info in libpj-armv7-apple-darwin_ios.a(ssl_sock_ossl.o)

Thanks Arslan Pervaiz for the report.

There is a bug in pj_generate_unique_string() from guid_android.c which lead to overflow/leak with this error:

JNI ERROR (app bug): local reference table overflow (max=512)
local reference table dump:
  Last 10 entries (of 512):
      511: 0x12ec2f80 java.util.UUID
      510: 0x6fc02f38 java.lang.Class<java.util.UUID>
      509: 0x130a7e20 java.lang.String "4cb26510-cdfb-4a... (36 chars)
      508: 0x12ec2f40 java.util.UUID
      507: 0x6fc02f38 java.lang.Class<java.util.UUID>
      506: 0x12fcdd00 java.lang.String "22383c0c-14e7-46... (36 chars)
      505: 0x12ec2e80 java.util.UUID
      504: 0x6fc02f38 java.lang.Class<java.util.UUID>
      503: 0x12fcd880 java.lang.String "9f6a1bfc-06b4-46... (36 chars)
      502: 0x12ec2e40 java.util.UUID
  Summary:
      170 of java.lang.Class (1 unique instances)
      169 of java.lang.String (169 unique instances)
        1 of byte[] (533 elements)
        1 of byte[] (753 elements)
        1 of byte[] (1217 elements)
      170 of java.util.UUID (170 unique instances)

This error will be raised after multiple calls to pj_generate_unique_string().

Thanks to Esed Alihodzic for the report and patch.

Sample scenario:

• PJSIP receives a re-INVITE and send 200 OK.
• The ACK is delayed and received at the same time the timeout timer fires.

Thread 1 receives the delayed ACK:

- pjsip_dlg_on_rx_request() -> pjsip_dlg_inc_lock(dlg)
- pjsip_tsx_terminate() -> pj_grp_lock_acquire(tsx->grp_lock)

Thread 2 handles the timeout:

- tsx_timer_callback() -> pj_grp_lock_acquire(tsx->grp_lock) then (*tsx->state_handler)(tsx, &event);
- tsx_on_state_completed_uas()
- tsx_set_state() -> (*tsx->tsx_user->on_tsx_state)(tsx, &e),
- pjsip_dlg_on_tsx_state() -> pjsip_dlg_inc_lock(dlg);

Thread 1's stack trace:

#5  0x00007f4748aac5a2 in pj_grp_lock_acquire (grp_lock=<optimized out>) at ../src/pj/lock.c:478
#6  0x00007f4749be20cd in pjsip_tsx_terminate (tsx=0x7f466ee29bb8, code=408) at ../src/pjsip/sip_transaction.c:1636
#7  0x00007f474a021dc6 in mod_inv_on_rx_request (rdata=0x7f46c4074c38) at ../src/pjsip-ua/sip_inv.c:586
#8  0x00007f4749be4b01 in pjsip_dlg_on_rx_request (dlg=dlg@entry=0x7f466eacb138, rdata=rdata@entry=0x7f46c4074c38) at ../src/pjsip/sip_dialog.c:1694
#9  0x00007f4749be6147 in mod_ua_on_rx_request (rdata=0x7f46c4074c38) at ../src/pjsip/sip_ua_layer.c:699
#10 0x00007f4749bccf77 in pjsip_endpt_process_rx_data (endpt=<optimized out>, rdata=rdata@entry=0x7f46c4074c38, p=p@entry=0x7f46d0004c40 <param>, p_handled=p_handled@entry=0x7f466155ecf4) at ../src/pjsip/sip_endpoint.c:887

Thread 2's stack trace:

#4  0x00007f4749be3b57 in pjsip_dlg_inc_lock (dlg=0x7f466eacb138) at ../src/pjsip/sip_dialog.c:885
#5  0x00007f4749be4dd6 in pjsip_dlg_on_tsx_state (dlg=0x7f466eacb138, tsx=0x7f466ee29bb8, e=0x7f46cf18dc10) at ../src/pjsip/sip_dialog.c:2047
#7  0x00007f4749be06b0 in tsx_on_state_completed_uas (tsx=0x7f466ee29bb8, event=0x7f46cf18dce0) at ../src/pjsip/sip_transaction.c:3198
#8  0x00007f4749bdfa86 in tsx_timer_callback (theap=<optimized out>, entry=0x7f466ee29d70) at ../src/pjsip/sip_transaction.c:1171
#9  0x00007f4748ab7207 in pj_timer_heap_poll (ht=0x7f47504b8d80, next_delay=next_delay@entry=0x7f46cf18de00) at ../src/pj/timer.c:643

Thanks to Alex Hermann for the report and the stack trace.

Deadlock when the following three events occur simultaneously:

1. Hangup call using pjsua_call_hangup().
2. The same call is also receiving a CANCEL message.
3. An INVITE is being received for a new separate call.

Thread 1 holds transaction lock in pjsip_tsx_send_msg() then attempts to obtain PJSUA lock.

#4  PJSUA_LOCK () at ../include/pjsua-lib/pjsua_internal.h:575              /* blocked on PJSUA_LOCK() */
#5  pjsua_call_on_state_changed () at ../src/pjsua-lib/pjsua_call.c:3807
#6  inv_set_state () at ../src/pjsip-ua/sip_inv.c:317
#7  inv_on_state_incoming () at ../src/pjsip-ua/sip_inv.c:4310
#8  mod_inv_on_tsx_state () at ../src/pjsip-ua/sip_inv.c:717
#9  pjsip_dlg_on_tsx_state () at ../src/pjsip/sip_dialog.c:2064
#10 mod_ua_on_tsx_state () at ../src/pjsip/sip_ua_layer.c:178
#11 tsx_set_state () at ../src/pjsip/sip_transaction.c:1235
#12 tsx_on_state_proceeding_uas () at ../src/pjsip/sip_transaction.c:2819
#13 pjsip_tsx_send_msg () at ../src/pjsip/sip_transaction.c:1751            /* obtained pj_grp_lock_acquire(tsx->grp_lock) */
#14 pjsip_dlg_send_response () at ../src/pjsip/sip_dialog.c:1529
#15 pjsip_inv_send_msg () at ../src/pjsip-ua/sip_inv.c:3227
#16 pjsua_call_hangup (code=606) at ../src/pjsua-lib/pjsua_call.c:2407

Thread 2 holds mod_ua.mutex and attempts to obtain transaction lock

#6  pj_grp_lock_acquire () at ../src/pj/lock.c:478
#7  pjsip_tsx_layer_find_tsx () at ../src/pjsip/sip_transaction.c:672    /* blocked on pj_grp_lock_acquire(tsx->grp_lock) */
#8  find_dlg_set_for_msg () at ../src/pjsip/sip_ua_layer.c:554
#9  mod_ua_on_rx_request () at ../src/pjsip/sip_ua_layer.c:615           /* obtains pj_mutex_lock(mod_ua.mutex) */
#10 pjsip_endpt_process_rx_data () at ../src/pjsip/sip_endpoint.c:887

Thread 3 holds PJSUA lock and attempts to obtain mod_ua.mutex

#4  pjsip_ua_register_dlg () at ../src/pjsip/sip_ua_layer.c:298            /* blocked on pj_mutex_lock(mod_ua.mutex) */
#5  create_uas_dialog () at ../src/pjsip/sip_dialog.c:533
#6  pjsip_dlg_create_uas_and_inc_lock () at ../src/pjsip/sip_dialog.c:590
#7  pjsua_call_on_incoming () at ../src/pjsua-lib/pjsua_call.c:1386        /* obtained PJSUA_LOCK() */
#8  mod_pjsua_on_rx_request () at ../src/pjsua-lib/pjsua_core.c:577
#9  pjsip_endpt_process_rx_data () at ../src/pjsip/sip_endpoint.c:887

This may be related to ticket #1464.

Thank you to David Richards for the report and the stack trace.

Some SIP applications/servers need to get the raw body of a multipart message body, as otherwise it has to manually print the multipart body (while the original raw body is still available in rdata).

Thanks Peter Koletzki for the suggestion.

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.

If video capture device fails to open, with the log, such as:

10:06:23.470          pjsua_media.c  .......pjsua_vid_channel_update() failed for call_id 0 media 1: Invalid video device (PJMEDIA_EVID_INVDEV)
10:06:23.470          pjsua_media.c  .......Error updating media call00:1: Invalid video device (PJMEDIA_EVID_INVDEV)

Later, when hanging up the call, pjsip will crash:

* thread #11: tid = 0x15b187, 0x00000001001d3c5c pjsua-x86_64-apple-darwin16.4.0`pjmedia_transport_send_rtcp(tp=0x0000000105014428, pkt=0x00000001020757f0, size=72) + 28 at transport.h:792, stop reason = EXC_BAD_ACCESS (code=1, address=0x20)
  * frame #0: 0x00000001001d3c5c pjsua-x86_64-apple-darwin16.4.0`pjmedia_transport_send_rtcp(tp=0x0000000105014428, pkt=0x00000001020757f0, size=72) + 28 at transport.h:792
    frame #1: 0x00000001001d1acf pjsua-x86_64-apple-darwin16.4.0`send_rtcp(stream=0x0000000102817e28, with_sdes=1, with_bye=1) + 527 at vid_stream.c:533
    frame #2: 0x00000001001d26de pjsua-x86_64-apple-darwin16.4.0`pjmedia_vid_stream_send_rtcp_bye(stream=0x0000000102817e28) + 158 at vid_stream.c:2031
    frame #3: 0x000000010010e85f pjsua-x86_64-apple-darwin16.4.0`pjsua_vid_stop_stream(call_med=0x00000001005481a0) + 207 at pjsua_vid.c:1146

The crash is caused because when pjsua_vid_channel_update() fails, it will stop the media stream and close media transport. However, stop_media_stram() is essentially no-op for new provisional medias. Thus, later, during hangup, when stop_media_stream() is called again to destroy the media, it will cause crash since media transport has been closed.

Since #1961 pjsip use ANDROID_ALARM_GET_TIME for timestamp. However NDK r14 no longer support this by removing android_alarm.h. This patch will detect the android_alarm.h, and if it wasn't found ,timestamp will use CLOCK_BOOTTIME instead.

There is a possible issue in the sip_timer.c::timer_cb(), more specifically, in the last log call made in that method.

This since the dialog that corresponds to the pjsip_inv_session object is unlocked, and the dialog may be destroyed in the consecutive call to pjsip_inv_send_msg(). Since the invite session object’s memory pool simply points to the dialog’s memory pool (and the invite session object itself is allocated from the same pool), this memory may thereby already have been freed once the log call is executed.

The issue was encountered when testing the session expiration timeout: after a call has been established from A to B, B’s network connection is cut, and the session expiration timeout is awaited. Once the timer timeouts, the case above seems to occur.

Thanks to Christoffer Lauri and Fredrik Hansson for the report.

Reproducing steps:

• Call from device A to device B.
• When device B starts ringing, wait until display goes off so the running application is switched to background after a while.
• Then unlock device B and try answering the call. Error 488 is returned on device B, call fails.

Log:

17:01:43.099 utsx0x128ac32e  .....STUN client transaction created
17:01:43.099 utsx0x128ac32e  .....STUN sending message (transmit count=1)
17:01:43.099 udprel0x12804f  ......socket send(): Destination address required
17:01:43.099 utsx0x128ac32e  ......STUN error sending message: Destination address required
17:01:43.099 stun_session.c  .....tdata 0x128ac30a8 destroy request, force=0, tsx=0x128ac32ec
17:01:43.099 utsx0x128ac32e  .....STUN transaction 0x128ac32ec schedule destroy
17:01:43.099 udprel0x12804f  .....Error sending STUN request: Destination address required
17:01:43.099        icetp00  ....Destroying ICE session 0x1281b1828
17:01:43.099 stuse0x1281320  ....STUN session 0x128132428 destroy request, ref_cnt=25
17:01:43.099 stuse0x1280c50  ....STUN session 0x1280c5428 destroy request, ref_cnt=24
17:01:43.099        icetp00  ....ICE restart failed (status=120039)!
17:01:43.099  pjsua_media.c  ....pjmedia_transport_media_start() failed for call_id 2 media 0: Destination address required

TURN socket (UDP) is somehow in a bad state after a while of ringing in the background mode (see also #1107 and #1225). Unfortunately TURN socket uses only pj_activesock_send() which is not equipped with UDP socket replacement procedure (while pj_activesock_sendto() is). In this case, the attempt of sending with the bad state UDP socket fails with EDESTADDRREQ. After testing using pj_activesock_sendto(), the issue seems to disappear.

Thanks Dusan Klinec for ​the report, the analysis and the patch (and sorry, somehow we missed the bug report). Thanks Ryan Callens for re-reporting and pointing this out.

There are two synchronization issues in ICE:

1. ICE objects are destroyed while DNS resolution of TURN server is on progress, so crash will happen when the resolution callback is invoked. Stack trace:

   Exception Type:  SIGSEGV
   Exception Codes: SEGV_MAPERR at 0x321e07eb52803ca1
   Thread 17 Crashed:
   0   0x30303363 null
   1   0x10124bb40 sess_init_update + 528
   2   0x10124f9d8 turn_on_state + 1520
   3   0x101262374 turn_on_state + 112
   4   0x10125ef74 set_state + 216
   5   0x10125f74c dns_srv_resolver_cb + 64
   6   0x1011ae078 dns_callback + 3272
   7   0x1011a698c on_read_complete + 1308
   

2. Race condition between PJMEDIA transport ICE's pjmedia_transport_close() and ICE stream transport's sess_init_update():
   1. sess_init_update() thread is suspended after evaluating destroy_req that is equal to PJ_FALSE
   2. pjmedia_transport_close() is invoked (from another thread, e.g: SIP or UI thread), then transport ICE is destroyed
   3. when sess_init_update() thread is resumed and invoking callback to transport ICE, crash occurs as transport ICE is destroyed already.

Thanks Qinxi Chen and Alexei Kolomiets for the report.

When adding account (using pjsua_acc_add()) with an escaped account ID, e.g: "user%40@some.domain", the account will be successfully added, but soon the registration will fail in initialization stage and unfortunately application will not be informed about this registration failure, i.e: pjsua_acc_add() returns PJ_SUCCESS and PJSUA callback on_reg_state is not invoked.

After investigation, we found that PJSUA will internally store the user part unescaped, e.g: "user@", and later when user part is used for generating Contact header (which is done without escaping), the Contact header will be invalid, e.g: "user@@some.domain".

Thanks Nils Lichtenfeld for the report.

The dynamic allocation for media format vector in audio/video device info creates unnecessary complexity such as memory leak and premature/double deletion. In this particular instance, once getDevInfo() returns, the dynamically allocated formats would have already been deleted in the destructor, causing crash when trying to access the info.

The call->incoming_data() will get reset (set to NULL) on reset_call(), which lead to memory leak since it's not properly released.

One example of this case is when rejecting a call from on_incoming_call() callback.

Thanks to Alexandre Beaulieu for the report.

Scenario:

This is the situation:
1. User places a call
2. The call is connected
3. After 2.5 minutes PJSIP sends re-INVITE (session refresh) [twice]
4. partner terminal cannot send RTP because partner terminal's network connection is lost
5. partner terminal's network connection recovers and partner sends re-INVITE
6. After 2.5 minutes PJSIP sends re-INVITE (session refresh)
7. PJSIP receives 200 OK for re-INVITE (session refresh) but there is an "unsupported crypto suite" error
8. The call continues without any media (MEDIA_DIR_NONE)
9. After 2.5 minutes the crash happens (around the time of the next session refresh)

The callstack:

pjsua-i386-Win32-vc14-Debug.exe!pjmedia_transport_media_start(pjmedia_transport
* tp, pj_pool_t * tmp_pool, const pjmedia_sdp_session * sdp_local, const
pjmedia_sdp_session * sdp_remote, unsigned int media_index) Line 903    C
     pjsua-i386-Win32-vc14-Debug.exe!pjsua_media_channel_update(int call_id,
const pjmedia_sdp_session * local_sdp, const pjmedia_sdp_session * remote_sdp)
Line 3057    C
    
pjsua-i386-Win32-vc14-Debug.exe!pjsua_call_on_media_update(pjsip_inv_session *
inv, int status) Line 3996    C
     pjsua-i386-Win32-vc14-Debug.exe!inv_negotiate_sdp(pjsip_inv_session * inv)
Line 1942    C
    
pjsua-i386-Win32-vc14-Debug.exe!inv_check_sdp_in_incoming_msg(pjsip_inv_session
* inv, pjsip_transaction * tsx, pjsip_rx_data * rdata) Line 2153    C
     pjsua-i386-Win32-vc14-Debug.exe!inv_on_state_confirmed(pjsip_inv_session *
inv, pjsip_event * e) Line 5098    C

Because of this:

22:36:03.114  pjsua_media.c  ......pjmedia_transport_media_start() failed for
call_id 0 media 0: Unsupported SRTP crypto-suite (PJMEDIA_SRTP_ENOTSUPCRYPTO)

call_med->tp will be destroyed, resulting the next refresh when calling pjmedia_transport_media_start() will pass NULL and crash.

Thanks to Marcus Froeschl for the report.

Related to r5500 which attempts to restart crypto numbering from 1 on a re-INVITE. Currently, the tag matching is not based on the offer, but the index of the crypto suite setting.

This patch will match the tag using the offer.

Thanks to Colin Morelli for the report.

Add multicast option for providing the capability to send IP datagrams from a single source to more than one receivers.

A crash can happen if PJSIP receives a message with a specific CSeq header and a Via header with no branch parameter. The issue is that the PJSIP RFC 2543 transaction key generation algorithm does not allocate a large enough buffer. By overrunning the buffer, the memory allocation table becomes corrupted, leading to an eventual crash.

Thanks to George Joseph and Asterisk team for the report.

The multi-part body parser in PJSIP contains a logical error that can make certain multi-part body parts attempt to read memory from outside the allowed boundaries. This can trigger invalid reads and potentially induce a crash.

Thanks to George Joseph and Asterisk team for the report.

DTLS-SRTP is an SRTP keying method that uses media channel for SRTP key negotiation which is secured using TLS. As SRTP key negotiation is done in media channel, confidentiality in SIP signaling is not required, but it needs SIP message integrity for authentication. Peer authentication is done by matching TLS certificate fingerprint (sent via SIP signaling) to actual TLS certificate received in DTLS-SRTP handshake (sent via media channel), so SIP message integrity will guarantee that the TLS certificate fingerprint is not altered from end to end.

DTLS handshake in DTLS-SRTP is basically very similar to TLS handshake, it is just done on UDP socket so it has retransmission mechanism and using a TLS extension for attaching SRTP keying materials (e.g: SRTP crypto profile and key).

Specification

• SDES (the only SRTP keying mechanism currently available in PJMEDIA) and DTLS-SRTP may coexist, any of them may be disabled (at run-time or compile-time).
• As currently best effort media encryption via SDP capability negotiation is not supported yet, it should be configurable which SRTP keying method to be used in generating offer. And for generating answer, it should detect and use the keying method used by the offer.
• Support DTLS-SRTP handshake before SDP answer is sent/received.

How to build

Requirement

1. OpenSSL version 1.1.0 or newer. DTLS with SRTP extension seems to be available since OpenSSL 1.0.1, but we haven't tried it ourselves.

Build

1. Set macro PJMEDIA_SRTP_HAS_DTLS to 1 in config_site.h:

   #define PJMEDIA_SRTP_HAS_DTLS 1
   

   To disable DTLS-SRTP, just set macro PJMEDIA_SRTP_HAS_DTLS to 0 (by default it is currently disabled). To disable SDES, set macro PJMEDIA_SRTP_HAS_SDES to 0 (by default it is currently enabled).

1. Build PJSIP with TLS enabled using OpenSSL backend.

Sample code for PJSUA app

Update: sample codes below have been deprecated in 2.8, please check #2100 for more info.

In generating SDP answer, SRTP will automatically detect and match the keying method to the SDP offer's, e.g: if remote sends offer using DTLS-SRTP, we will start DTLS nego immediately and answer using DTLS-SRTP too. However, in generating SDP offer, SRTP will use SDES by default. So to generate SDP offer using DTLS-SRTP, application needs to implement PJSUA callback on_create_media_transport_srtp and sets the priority of DTLS-SRTP higher than SDES from that callback, e.g:

void on_create_media_transport_srtp(pjsua_call_id call_id,
                                    unsigned media_idx,
                                    pjmedia_srtp_setting *srtp_opt)
{
    srtp_opt->keying_count = 2;
    srtp_opt->keying[0] = PJMEDIA_SRTP_KEYING_DTLS_SRTP;
    srtp_opt->keying[1] = PJMEDIA_SRTP_KEYING_SDES;
}

To enable only one keying method at run-time, just set keying_count to 1 and keying[0] to the preferred keying method from the same PJSUA callback, e.g:

void on_create_media_transport_srtp(pjsua_call_id call_id,
                                    unsigned media_idx,
                                    pjmedia_srtp_setting *srtp_opt)
{
    srtp_opt->keying_count = 1;
    srtp_opt->keying[0] = PJMEDIA_SRTP_KEYING_DTLS_SRTP; /* enable only DTLS-SRTP */
}

Limitation

This ticket will only implement the core part of DTLS-SRTP, i.e: SRTP key negotiation via DTLS, while DTLS-SRTP itself also depends on other features that we haven't supported yet:

1. SIP signaling integrity protection, this may be provided by any of these extensions:
   1. SIP Identity, specified by ​RFC4474 and ​RFC4916, only Authentication Service is needed.
   2. S/MIME, specified by ​RFC3261 section 23.
   3. SIPS, actually we already support this, but as SIPS can't guarantee that all proxies are trusted, the security provided by SIPS is considered weaker.
2. Best effort media encryption via SDP capability negotiation, to offer media channel with multiple configurations (e.g: offering SRTP but also accept plain RTP), this seems to be a ​MUST.

Behavior change

1. Media transport UDP can now be attached multiple times, any old attachment will be silently replaced by the latest. This change is done because DTLS nego needs to access the real transport (UDP/ICE) before stream is created (or SDP nego is completed). After SDP nego is completed, stream will invoke media transport attach() again.
2. Media transport UDP & ICE is equipped with auto-switching RTP/RTCP target address to the address it receives RTP/RTCP from, and there is probation period (i.e: 10 packets) before switching to the new target address, during this probation period all packets from the candidate target address will be discarded. Now those packets will be no longer discarded as long as we have not received any packet from the current known source address (if any). Without this change, any incoming 'TLS hello' will be discarded until probation period is reached or SDP answer is received (which tell us about remote RTP address).

Reference

• DTLS-SRTP framework: ​https://tools.ietf.org/html/rfc5763
• DTLS extension for SRTP: ​https://tools.ietf.org/html/rfc5764

On g++ 5.4.0, when using locale_facets.h there is this definition:

#if __cplusplus >= 201103L
  /// Convenience interface to ctype.is(ctype_base::blank, __c).
  template<typename _CharT>
    inline bool
    isblank(_CharT __c, const locale& __loc)
    { return use_facet<ctype<_CharT> >(__loc).is(ctype_base::blank, __c); }
#endif

Resulting a conflict with isblank Macro definition in pjlib/include/pj/compat/ctype.h.

This patch will remove the Macro definition and use it directly to pj_isblank().

Example scenario:

1. Received INVITE with branch=z9hG4bK%999999f
2. Respond with 100
3. Respond with 180
4. Received CANCEL
5. Respond with "481 Call/Transaction Does Not Exist"

By default, sip_transaction.c enabled PRECALC_HASH which calculated the hash value using pj_hash_calc_lower().

char lower = (char)pj_tolower(key->ptr[i]);

When setting the hash, the value was calculated using

const pj_uint8_t *p = (const pj_uint8_t*)key,*end = p + keylen;
hash = hash * PJ_HASH_MULTIPLIER + pj_tolower(*p);

The branch/key contain %99, which will be stored as 0x99, the calculated hash value will differ.

Thanks to Fredrik Hansson for the report.

Call info structure (pjsua_call_info) uses internal buffer for storing contact info, unfortunately the buffer may be insufficient for a very long Contact header and so local_contact/remote_contact field has negative length value (as pjsip_uri_print() returning negative value when buffer is insufficient). Unfortunately, pj2Str() util in PJSUA2 does not check for such negative length and it causes crash.

So there are 3 issues here:

1. pjsua_call_get_info() does not check negative length of local contact, while it checks remote contact and normalize the length to zero when it is negative.
2. Docs of pjsip_uri_print() only says "Returns: Length printed", while on error it actually returns negative value.
3. pj2Str() does not check for negative pj_str_t.slen.

Thanks Nick Dowell for the report and the patch. Original report and patch can be found ​here.

Add support for native H264 encoder and decoder for Mac and iOS platform using Apple's Video Toolbox framework.

When URI is set with header parameter without value, ( e.g: sip:1.1.1.1?111 or sip:1.1.1.1?111= )

the library will crash on pjsip_dlg_create_uac().

c = param->value.ptr[param->value.slen];

In ticket #1953: Fail to create resolver when library built with IPv6 but run on system without IPv6

If the send count is zero, then transmit_query() will return PJLIB_UTIL_EDNSNOWORKINGNS, however it does so without cancelling the timer, which then will be put back in the list of free timer entries.

    status = transmit_query(resolver, q);
    if (status != PJ_SUCCESS) {
                pj_list_push_back(&resolver->query_free_nodes, q);
                goto on_return;
    }

Thus, it could later result in timer heap corruption and crash after this uncancelled timer is reused and invalidated.

Thanks to Chris Tserng for the fix and Balamurugan Ramajeyam for the report.

Related to ticket #1535 (https://trac.pjsip.org/repos/ticket/1535): "Pending outgoing TCP transmission may cause crash if the library is shutdown"

However ticket #1859 (https://trac.pjsip.org/repos/ticket/1859): "Possible crash due to transaction premature destroy while message send operation is on progress" may have unintentionally brought back the problem by trying to decrease the pending send counter without checking if the transaction layer has been shutdown.

​RFC3268 recommends that the version must be increased when there's a change in the SDP.

Currently, subsequent offer/answer will always have its origin version incremented. The reason for this is that we believe it will be safer to force answerer to check things by increasing the session version (just in case some changes is not explicitly modify SDP string, for example, some H264 param updates such as resolution will not change SDP).

This patch will introduce new compile time setting PJMEDIA_SDP_NEG_COMPARE_BEFORE_INC_VERSION to allow the stack compare the SDP of the subsequent offer/answer to the previous one.

It is disabled by default for performance reason and to maintain backward capability.

Reported that when calling pj_gethostip() on a system whose empty hostname, pj_getaddrinfo() will raise assert at this line:

    PJ_ASSERT_RETURN(nodename->ptr && nodename->slen, PJ_EINVAL);

Thanks Denis Poltorak for the report.

Scenario:

1. A calls B
2. B send ringing/180 response
3. A changes IP address, so it shutdowns transport, unregisters and reregisters.
4. A tries to update its Contact header via UPDATE without SDP, but fails, log lines:

   pjsua_call.c  ....Sending UPDATE on call 0
   pjsua_call.c  .....Unable to send UPDATE because another media operation is in progress
   

In this case, i.e: there is pending SDP offer/answer, UPDATE without SDP should not be stopped as it won't change the media session.

Thanks Michael Ayles for the report.

Support for G729 backend implementation from ​bcg729.

Requirement:

• Source code to bcg729, (download ​here).

Notes:

• The source code of bcg729 is licensed under GPLv2.

Below are the steps to use the codec:

For GNU targets:

1. Build the bcg729 library as specified by the their doc.
2. Run PJSIP's configure by specifying the location to bcg729 library using --with-bcg729 option. E.g.:

   ./configure --with-bcg=/home/user/opt
   

3. Make sure that the library is usable and correctly configured by looking at the configure output. The check is applicable for iOS and android build as well.

   Using bcg729 prefix... /Users/riza/src/bcg729/ios
   checking bcg729 usability... ok
   

For Visual Studio:

1. Build the bcg729 library using Visual Studio, by generating the project using cmake.
2. Add bcg729 include and library installation paths (folder that contains libbcg729.dll.a) to Visual Studio search path settings.
3. Add this to your config_site.h:

   #define PJMEDIA_HAS_BCG729		1
   

For iOS:

1. Build the bcg729 library as specified by the their doc.
2. Run PJSIP's configure with --with-bcg729 option. E.g.:

   ./configure-iphone --with-bcg729=/Users/teluu/bcg729/iphone
   

3. Copy libbcg729.a to your XCode project directory. Create a folder ios_local/lib inside your XCode project directory (example: for our ipjsua sample app, the directory will be: (PJPROJECT_DIR)/pjsip-apps/src/pjsua/ios/ios_local/lib). Then copy bcg729 dynamic library files to the folder. E.g:

   cp bcg729/lib/libbcg729.a pjproject-iphone/pjsip-apps/src/pjsua/ios/
   cp bcg729/lib/*.dylib pjproject-iphone/pjsip-apps/src/pjsua/ios/ios_local/lib
   

4. Add libbcg729.a to your application project in XCode.

For Android:

1. Patch Android.mk in the bcg729 source root directory, just append src/cng.c, src/dtx.c, src/vad.c to LOCAL_SRC_FILES.
2. Build the bcg729 library, e.g:

   cd [bcg729-source-path]
   $ANDROID_NDK_ROOT/build/ndk-build APP_ABI=arm64-v8a \
           NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=Android.mk
   

3. Create directory lib under bcg729 library source, and copy the libbcg729.a from [bcg729-source-path]/obj/local/[ABI] to it.
4. Run PJSIP's configure with --with-bcg729 option. E.g.:

   ./configure-android --with-bcg729=/Users/teluu/bcg729/android
   

• Added more logging and more detailed error determination.
• Ignore SSL_ERROR_SYSCALL errors when the detailed openssl error code is zero and errno is zero. This greatly improves ssl/tls connection stability.

Patch contribution by Ian Gilmour.
Submitted by George Joseph

By default, disable some L16 codec clock rates, to free up some dynamic payload type.

Add support for clients on IPv6-only NAT64 environment to communicate with IPv4 servers and endpoints.

Please refer to the NAT64 wiki.

As specified in ​rfc5245 8.1.1:

If its peer has a lite implementation, an agent MUST use a regular
nomination algorithm.

ICE media transport should automatically switch to regular nomination when remote signals lite implementation, regardless the nomination algo setting set by application.

Thanks Sanjoy Ghosh for the report.

Currently we've been able to generate SWIG binding to java and python 2 using PJSUA2 API.

This ticket will add support to generating python 3 binding and enable it as the preferred python binding.

To change it back to python 2 binding, you need to modify pjsip-apps/src/swig/python/Makefile to:

USE_PYTHON3=0

and regenerate the SWIG binding afterwards.

Note that when generating python 3 binding, you would require the similar packages used when generating python 2 binding.

e.g: python3-dev instead of python2.7-dev package

From srtp doc (srtp.h)

/**
 * SRTP_MAX_TRAILER_LEN is the maximum length of the SRTP trailer
 * (authentication tag and MKI) supported by libSRTP.  This value is
 * the maixmum number of octets that will be added to an RTP packet by
 * srtp_protect().
 *
 * @brief the maximum number of octets added by srtp_protect().
 */
#define SRTP_MAX_TRAILER_LEN (SRTP_MAX_TAG_LEN + SRTP_MAX_MKI_LEN)

...
 * @warning This function assumes that it can write SRTP_MAX_TRAILER_LEN 
 * into the location in memory immediately following the RTP packet.   
 * Callers MUST ensure that this much writable memory is available in 
 * the buffer that holds the RTP packet.
...
srtp_err_status_t srtp_protect(srtp_t ctx, void *rtp_hdr, int *len_ptr);

Currently, transport SRTP use hardcoded value to check if the space is sufficient.

This ticket will use SRTP_MAX_TRAILER_LEN instead to check the required buffer space.

Thanks to Chris Panayis for the report.

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.

The new callback, variant of on_rx_offer(), will have additional info, rdata, which contains the received request. This can be helpful in determining whether the incoming request is an INVITE or an UPDATE.

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).

pj_sockaddr_parse() is using pj_sockaddr_in_set_str_addr() which is using pj_gethostbyname() which is using gethostbyname() which is not reentrant. So pj_sockaddr_parse() is practically not thread-safe.

Thanks Pirmin Walthert for the investigation and the initial patch.

This patch will implement new CodecParam class which is a for pjmedia_codec_param use to configuring audio codec and in querying the capability of audio codec factories.

IP address change and/or access point disconnection and reconnection are scenarios that need to be handled in mobile applications. Few issues or scenarios related to this for example are:

• user moves outside the range of a Wi-Fi access point (AP) and lost the connection
• user moves outside the range of one AP and reconnect to another
• the handset may get new IP address if user reconnects to different AP

This ticket will introduce a new API pjsua_handle_ip_change()/Endpoint::handleIpChange() to handle IP address change. This way, application only needs to detect for IP address change event, and let the library handle the IP address change based on the configuration.

When invoked, the stack will:

1. Restart the SIP transport listener
   This will restart TCP/TLS listener no matter whether they are enabled or not when the transport were created. If you don't have any use of the listener, you can disable this. However, if you do need this, then on some platform (e.g: on IOS), some delay is needed when restarting the the listener.
   

   pjsua_ip_change_param.restart_listener
      IpChangeParam::restartListener
   pjsua_ip_change_param.restart_lis_delay
      IpChangeParam::restartListener
   

2. Shutdown the SIP transport used by account registration
   On some platform (e.g: iOS), it is necessary to shutdown the transport used by registration, since presumably the socket is already in a bad state.
   

   pjsua_acc_config.ip_change_cfg.shutdown_tp
      AccountIpChangeConfig::shutdownTp
   

3. Update contact URI by sending re-Registration
   The server needs to be updated of the new Contact URI when the IP address changed. Set it to PJ_TRUE to allow the stack update contact URI to the server.
   

   pjsua_acc_config.allow_contact_rewrite
      AccountNatConfig::contactRewriteUse
   pjsua_acc_config.contact_rewrite_method
      AccountNatConfig::contactRewriteMethod
   

4. Hangup active calls or continue the call by sending re-INVITE
   You can either hangup or maintain the ongoing/active calls. If you intend to maintain the active calls, updating dialog's contact URI is required. This can be done by specifying PJSUA_CALL_UPDATE_CONTACT to the reinvite flags.

   pjsua_acc_config.ip_change_cfg.hangup_calls
      AccountIpChangeConfig::hangupCalls
   pjsua_acc_config.ip_change_cfg.reinvite_flags
      AccountIpChangeConfig::reinviteFlags
   

To monitor the progress of IP change handling, application can use on_ip_change_progress()/Endpoint::onIpChangeProgress() callback. The callback will notify application of these events:

• restart SIP transport listener
• shutdown SIP transport
• update contact (re-registration process)
• hangup calls
• re-INVITE calls

Symptom

Log line:

Transport send_rtp() error: replay check failed (index too old) [err:259809]

Analysis

In updating media in both call hold and unhold, stream (or video stream) is destroyed and recreated. Before stream is destroyed, pjsua always saves last transmitted RTP seq number & timestamp, and pass them back to the new stream, so outgoing RTP will have continued seq number & timestamp.

Unfortunately for video, when call is on hold, currently no RTP frame will be sent, so both values last transmitted RTP seq number & timestamp are zero, and pjsua saves them when video stream (of a call hold) is destroyed. When a new video stream is created (for call unhold), the zero values will be used to initiate it. This will make outgoing RTP seq number restarted/discontinued, and a restarted RTP seq number will upset SRTP.

In audio stream, normally there are still some outgoing RTPs (for keep-alive) when call is on hold, so the issue may not appear on audio stream.

When executing pjnath-test (windows), crash happen when on concur_test() : "ice test a: immediate destroy".

Stacktrace:

pjnath-test-i386-Win32-vc14-Debug.exe!on_ice_complete(pj_ice_sess *ice, int status) Line 1642      C
pjnath-test-i386-Win32-vc14-Debug.exe!on_timer(pj_timer_heap_t * th, pj_timer_entry * te) Line 1175  C
pjnath-test-i386-Win32-vc14-Debug.exe!pj_timer_heap_poll(pj_timer_heap_t* ht, pj_time_val * next_delay) Line 643        C
pjnath-test-i386-Win32-vc14-Debug.exe!worker_thread_proc(void * p) Line 148        C
pjnath-test-i386-Win32-vc14-Debug.exe!thread_main(void * param) Line 464     C

Calling:

(*ice_st->cb.on_ice_complete)(ice_st, PJ_ICE_STRANS_OP_NEGOTIATION, status);

The callback and user_data was reset from this line:

    /* Reset callback and user data */
    pj_bzero(&ice_st->cb, sizeof(ice_st->cb));
    ice_st->user_data = NULL;

To avoid the crash due to the reset, then the callback is stored in a var and use that to call the callback.

Since version 2.6, QoS on Darwin OS (e.g: iOS, MacOS) is implemented using SO_NET_SERVICE_TYPE (see also ticket #1964). However, for some reasons, some applications may prefer to use the BSD style IP_TOS/IPV6_TCLASS, this can be done by adding this line in pjlib/include/pj/config_site.h:

#define PJ_QOS_IMPLEMENTATION PJ_QOS_BSD

Miscellaneous updates and fixes

Last time, during our implementation, we relied on the RFC 5245, which was still in ​draft stage, which said:

The Indication MUST NOT utilize
   any authentication mechanism, and SHOULD NOT contain any attributes.

However, in the ​published version:

The Indication MUST NOT utilize any authentication
   mechanism.  It SHOULD contain the FINGERPRINT attribute to aid in
   demultiplexing, but SHOULD NOT contain any other attributes.

So we need to update our implementation.

Thanks to Sean Bright for the patch and George Joseph for the report.

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

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.