Custom Query (2195 matches)

This is a duplicate of ticket #762 for 1.0 branch.

Sample case:

• Some functions in basic_op.h of libg7221codec are reported to crash with VA AMR, i.e: linking errors of redefined symbol.

When creating DNS query packet, the pj_dns_make_query() function typecasts the packet buffer into pj_dns_hdr struct and write 16bit values to it. This will raise alignment error when the buffer is not 16bit aligned.

Also changed various pj_ntohs() to pj_htons() and char* to pj_uint8_t* for packet buffer, for better semantics.

ICE component count may decrease, e.g: remote doesn't have RTCP component while we are initialized with RTCP, at some point we will destroy the RTCP component, but somehow it may still receive STUN packet which will raise assertion in find_comp() function:

pj_assert(comp_id > 0 && comp_id <= ice->comp_cnt);

The corresponding test scenario is tests/pjsua/scripts-call/305_ice_comp_1_2.py.

Scenario:

1. tsx1: send re-INVITE with offer, rejected with 491, the SDP offer gets cancelled normally
2. tsx2: immediately send again re-INVITE with offer
3. tsx1: state changes from "completed" to "terminated" before final response for tsx2 is received, problem starts here: the latest SDP offer (in tsx2) wrongly gets cancelled
4. tsx2: receive 200 response with SDP answer, but as local offer has been cancelled, this is treated as remote offer
5. tsx2: send ACK with SDP "answer".

Caused by bad usage of PJ_ARRAY_SIZE() on pointer (or array as function param). Fortunately this should not affect systems that store pointer in 32 bit space or higher.

If RTCP packet length is invalid (contains a large number), there is a potential buffer overread, which may lead to crash when parsing the packet.

The problem is caused because when parsing, we pass the invalid length as the packet size in pjmedia_rtcp_rx_rtcp() (rtcp.c), for example:

	len = (pj_ntohs((pj_uint16_t)common->length)+1) * 4;
	....
        parse_rtcp_report(sess, p, len);

There is no protection for premature destroy of a transaction while a sending operation is on progress (the message is delivered, but the sent notification is delayed). This is similar to ticket #1646 problem no 2, just this case may occur when sending operation doesn't have transport yet and needs to resolve the server first. Also, it is unlikely to happen when the SIP endpoint has only one worker thread.

Scenario:

1. Thread A gets told by the resolver of addresses to send an INVITE to. INVITE is sent, sent notification callback send_msg_callback() is partially executed, context switch occurs right before acquiring transaction group lock.
2. Thread B receives an incoming 200 OK for the outbound INVITE. We send an ACK on this thread. The transaction for the outbound INVITE gets destroyed.
3. Thread A then attempts to acquire the group lock on the transaction, there is a crash because the transaction has already been destroyed by Thread B.

Notes to reproduce/simulate:

1. Send operation should be an async operation (not complete immediately) to make sure that tsx group lock is not being held when send_msg_callback() is called.
2. It needs at least two worker threads, e.g: run pjsua with "--thread-cnt 2" param, we need a worker thread to handle the incoming 200 OK and send ACK, while another worker thread handles the INVITE request sent notification.
3. Put sleep(~5 seconds) before acquiring tsx group lock in the send_msg_callback().

Thanks to Mark Michelson for the report.

This is because pj_ice_strans_stop_ice() is called with NULL argument.

Stack trace:

  0009efa8  pj_ice_strans_stop_ice        src/pjnath/ice_strans.c:1147
  00090e5e  set_no_ice                    src/pjmedia/transport_ice.c:288
  00090ebc  transport_media_stop          src/pjmedia/transport_ice.c:1485

Crash in event publication framework (publishc.c), if network connectivity is lost between two consecutive PUBLISH requests (such as when the PUBLISH request is retried for authentication, or when second PUBLISH request was in the queue (because another one is in progress when application requests the second publication)).

Note that this does not happen when there is only one PUBLISH request to be sent.

To reproduce:

1. Put breakpoint in 401/407 handler in tsx_callback() in publishc.c
2. Send PUBLISH
3. Receive 401/407
4. Disconnect network
5. tsx_callback() will resend PUBLISH
6. pjsip_publishc_send() fails, a nested tsx_callback is called, pubc is destroyed
7. pjsip_publishc_send() returns back to tsx_callback() which will destroy the pubc once again.

Validation of account registration object in the registration callback is not protected by pjsua lock. This may cause race condition that lead to crash.

Detail scenario:

1. when entering registration callback, the account registration object validation passes and about to get pjsua lock
2. context switch, application deletes the account, pjsua_acc_del(), until the deleting account finished,
3. context switch back to registration callback, from this point, any access to the just deleted account will lead to crash!

There is an application requirement for connected line support. It is the ability to send an INVITE or UPDATE request which updates caller-id/connected-id information. A GUI developer actually uses it to update the display to show what your external caller-id is when placing outgoing calls. The normal scenario:

1. Caller send INVITE
2. Callee send 180 INVTE Resp
3. Caller send UPDATE (no SDP)
4. Callee send 200 UPDATE Resp

At the moment, the stack will try to cancel the offer and lead to a crash. This ticket will cancel the offer upon receiving the UPDATE response, only when the UPDATE request include SDP offer.

Thanks to Joshua Colp for the report.

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.

The locking order of PJSUA_LOCK() and dialog's mutex in presence framework in PJSUA-API is not uniform, and this may cause deadlock.

Deadlock may happen if call is adding new media (e.g. adding video) with ICE enabled and more than one worker threads are used. The flow is below:

1. Call is established with audio only.
2. Re-INVITE with video is received, on_call_rx_offer() is called, which eventually calls create_ice_media_transport() which works synchronously. The dialog mutex is held by current thread at this point. The current thread then runs pjsua_handle_events() in a loop.
3. on_ice_complete() is called called with PJ_ICE_STRANS_OP_INIT, which posts the job as timer event.
4. another thread picks up the timer event, med_tp_timer_cb() is called, which calls acquire_call() and got stuck when acquiring dialog mutex which is being held by the polling thread above.

Thanks Itay Bianco for the report!

Here is quoted report:

We ran into a intermittent problem with memory corruption on the Windows version of the application, that we traced to sound stream handling in "pasound.c".

For each call, the application is calling "pjmedia_snd_port_create()" at the start of the call and "pjmedia_snd_port_destroy()" at the end of the call. After the second call, the application got corrupted heap sections.

We noticed that after the second call, the thread that is receiving sound frames by PortAudio? through "PaPlayerCallback?()" had an invalid structure in it's TLS when calling pj_thread_this(). On the second call, the thread was not being registered, so the initial thread register was referencing the memory pool of the first call.

So, basically callback's thread cases to be handled are:

• The thread may be changed in the middle of a session, e.g: in MacOS it happens when plugging/unplugging headphone.
• The same thread may be reused in consecutive sessions. The first session will leave TLS set, but release the TLS data address, so the second session must re-register the callback's thread.

This is duplication of ticket #701 for version 1.0. See ticket #701 for more info.

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

The pjsua_acc_modify() function sets acc->display, acc->user_part, and acc->srv_domain directly from the supplied arguments without cloning them first, which cause the value to be invalid if the original arguments are destroyed.

Various symptoms of this bug include:

• crash in pjsip_contact_hdr_print()
• assertion on pjsua_acc.c:1189: "pj_assert(contact_hdr != NULL);" because the function failed to parse the account's Contact header.

The optimization proposed is in the conference bridge get_frame() function, brief desc:

• remove the redundant loop at the beginning (trivial) Note: basically this loop is iterating listeners, while the next loop is iterating transmitters, so they can't really be merged.
• the mixing step can be replaced with just copying the samples when there is only one transmitter for the listening port.

Original report can be found ​here.

Reported that there is possibility of caching pool capacity, which is represented with unsigned value, getting 'below zero'/wrapped around on releasing the pools after memory allocations exceeds the current configured cache limit via multiple pools.

Thanks Joshua Colp for the report and the patch.

Scenario:

• peer sends STUN Binding Request inside TURN Data Indication
• the STUN Binding Request has wrong Fingerprint calculation
• the pj_stun_msg_check() in ice_session.c:2901, causing the ICE session to treat the Data Indication payload as non-STUN packet
• this will cause "RTP decode error: Invalid RTP version (PJMEDIA_RTP_EINVER) [err:220122]"

In unicode_win32.c the pj_ansi_to_unicode function uses MultiByteToWideChar to do character conversion which could result in a buffer overflow.

PJ_DEF(wchar_t*) pj_ansi_to_unicode(const char *s, pj_size_t len,
                                    wchar_t *buf, pj_size_t buf_count)
{
    PJ_ASSERT_RETURN(s && buf, NULL);

    len = MultiByteToWideChar(CP_ACP, 0, s, len, buf, buf_count);
    buf[len]=0;
    return buf;
}

Under most circumstances the above won't have a problem however if the value in len and buf_count are the same then doing "buf[len]=0" is going to overflow the buf buffer.

The same issue also exists in pj_unicode_to_ansi(), and in Symbian port.

The issue was found using Helgrind.

Although different, there's a degree of similarity with ticket #2260 and #1247, which is that holding a lock before calling pjsip_regc_send() may potentially lead to deadlock, since any send operation will later acquire transport's lock. While during incoming message, the transport's lock will be held when calling the callbacks of the upper layer to process the message, which may then also need to hold the (upper layer's) lock, thus violating the lock ordering and potentially cause a deadlock between rx and tx.

In this case, the two locks involved are pjsua lock and sip transport's lock. PJSUA_LOCK()->pjsip_regc_send()->acquire transport's lock ioqueue_dispatch_read()->acquire transport's lock->regc_tsx_callback()->PJSUA_LOCK()

Below is the stack trace reported by Helgrind:

Thread #4: lock order "0x645E888 before 0x64E3B88" violated

Observed (incorrect) order is: acquisition of lock at 0x64E3B88
   by 0x5A154D: pj_grp_lock_tryacquire (lock.c:483)
   by 0x5960CF: pj_ioqueue_trylock_key (ioqueue_common_abs.c:1366)
   by 0x594CC9: ioqueue_dispatch_read_event (ioqueue_common_abs.c:439)
   by 0x597314: pj_ioqueue_poll (ioqueue_select.c:1069)
   by 0x479D40: pjsip_endpt_handle_events2 (sip_endpoint.c:745)
   by 0x433808: pjsua_handle_events (pjsua_core.c:2156)

 followed by a later acquisition of lock at 0x645E888
   by 0x418DD9: PJSUA_LOCK (pjsua_internal.h:593)
   by 0x41F02F: regc_tsx_cb (pjsua_acc.c:2221)
   by 0x4592EA: regc_tsx_callback (sip_reg.c:1104)
   by 0x49A71C: mod_util_on_tsx_state (sip_util_statefull.c:81)
   by 0x496816: tsx_set_state (sip_transaction.c:1272)
   by 0x499EBC: tsx_on_state_proceeding_uac (sip_transaction.c:3115)
   by 0x4991D4: tsx_on_state_calling (sip_transaction.c:2599)
   by 0x4978F7: pjsip_tsx_recv_msg (sip_transaction.c:1832)
   by 0x495CA5: mod_tsx_layer_on_rx_response (sip_transaction.c:893)
   by 0x47A11C: pjsip_endpt_process_rx_data (sip_endpoint.c:938)

Required order was established by acquisition of lock at 0x645E888
   by 0x418DD9: PJSUA_LOCK (pjsua_internal.h:593)
   by 0x420188: pjsua_acc_set_registration (pjsua_acc.c:2689)

 followed by a later acquisition of lock at 0x64E3B88
   by 0x5A1533: pj_grp_lock_acquire (lock.c:478)
   by 0x596092: pj_ioqueue_lock_key (ioqueue_common_abs.c:1358)
   by 0x595D35: pj_ioqueue_connect (ioqueue_common_abs.c:1220)
   by 0x59D915: pj_activesock_start_connect (activesock.c:936)
   by 0x489832: lis_create_transport (sip_transport_tcp.c:1053)
   by 0x484CEB: pjsip_tpmgr_acquire_transport2 (sip_transport.c:2457)
   by 0x47A7CD: pjsip_endpt_acquire_transport2 (sip_endpoint.c:1246)
   by 0x47D3D0: stateless_send_transport_cb (sip_util.c:1181)

 Lock at 0x645E888 was first observed
   by 0x598F8C: pj_mutex_create_recursive (os_core_unix.c:1258)
   by 0x4310E7: pjsua_create (pjsua_core.c:950)

 Lock at 0x64E3B88 was first observed
   by 0x5A1435: pj_grp_lock_create (lock.c:438)
   by 0x5A14D2: pj_grp_lock_create_w_handler (lock.c:463)
   by 0x4889EC: tcp_create (sip_transport_tcp.c:684)
   by 0x4897D9: lis_create_transport (sip_transport_tcp.c:1045)
   by 0x484CEB: pjsip_tpmgr_acquire_transport2 (sip_transport.c:2457)

A potential deadlock between sip_transaction and sip_reg. This issue is found using Helgrind.

Although not exactly similar, but this is related to ticket #1247.

In that ticket, the fix in was to release the lock before calling pjsip_endpt_send_request(), which worked because as the stack trace showed, the flow was: regc_refresh_timer_cb(), which doesn't lock->pjsip_regc_send()->pjsip_endpt_send_request().

But if the lock is held more than once, then deadlock can still occur (for example: regc_tsx_callback(), which holds regc lock->pjsip_regc_send()->pjsip_endpt_send_request()).

For complete stack trace reported by Helgrind, refer to below:

Thread #4: lock order "0x64DD5A8 before 0x64E80C8" violated

Observed (incorrect) order is: acquisition of lock at 0x64E80C8
   by 0x5A1533: pj_grp_lock_acquire (lock.c:478)
   by 0x4978DC: pjsip_tsx_recv_msg (sip_transaction.c:1831)
   by 0x495CA5: mod_tsx_layer_on_rx_response (sip_transaction.c:893)
   by 0x47A11C: pjsip_endpt_process_rx_data (sip_endpoint.c:938)
   by 0x47A406: endpt_on_rx_msg (sip_endpoint.c:1080)
   by 0x484620: pjsip_tpmgr_receive_packet (sip_transport.c:2182)
   by 0x48A3F8: on_data_read (sip_transport_tcp.c:1430)
   by 0x59CD3C: ioqueue_on_read_complete (activesock.c:504)

 followed by a later acquisition of lock at 0x64DD5A8
   by 0x5A0D31: pj_lock_acquire (lock.c:180)
   by 0x459127: regc_tsx_callback (sip_reg.c:1071)
   by 0x49A71C: mod_util_on_tsx_state (sip_util_statefull.c:81)
   by 0x496816: tsx_set_state (sip_transaction.c:1272)
   by 0x499D58: tsx_on_state_proceeding_uac (sip_transaction.c:3016)
   by 0x4991D4: tsx_on_state_calling (sip_transaction.c:2599)
   by 0x4978F7: pjsip_tsx_recv_msg (sip_transaction.c:1832)
   by 0x495CA5: mod_tsx_layer_on_rx_response (sip_transaction.c:893)
   by 0x47A11C: pjsip_endpt_process_rx_data (sip_endpoint.c:938)
   by 0x47A406: endpt_on_rx_msg (sip_endpoint.c:1080)

Required order was established by acquisition of lock at 0x64DD5A8
   by 0x5A0D31: pj_lock_acquire (lock.c:180)
   by 0x4592FD: regc_tsx_callback (sip_reg.c:1105)
   by 0x49A71C: mod_util_on_tsx_state (sip_util_statefull.c:81)
   by 0x496816: tsx_set_state (sip_transaction.c:1272)
   by 0x499EBC: tsx_on_state_proceeding_uac (sip_transaction.c:3115)
   by 0x4991D4: tsx_on_state_calling (sip_transaction.c:2599)
   by 0x4978F7: pjsip_tsx_recv_msg (sip_transaction.c:1832)
   by 0x495CA5: mod_tsx_layer_on_rx_response (sip_transaction.c:893)
   by 0x47A11C: pjsip_endpt_process_rx_data (sip_endpoint.c:938)
   by 0x47A406: endpt_on_rx_msg (sip_endpoint.c:1080)

 followed by a later acquisition of lock at 0x64E80C8
   by 0x5A1533: pj_grp_lock_acquire (lock.c:478)
   by 0x497314: pjsip_tsx_set_transport (sip_transaction.c:1636)
   by 0x49A815: pjsip_endpt_send_request (sip_util_statefull.c:109)
   by 0x459D65: pjsip_regc_send (sip_reg.c:1434)
   by 0x459636: regc_tsx_callback (sip_reg.c:1193)
   by 0x49A71C: mod_util_on_tsx_state (sip_util_statefull.c:81)
   by 0x496816: tsx_set_state (sip_transaction.c:1272)
   by 0x499EBC: tsx_on_state_proceeding_uac (sip_transaction.c:3115)

 Lock at 0x64DD5A8 was first observed
   by 0x5A0BA7: pj_lock_create_recursive_mutex (lock.c:96)
   by 0x456F4E: pjsip_regc_create (sip_reg.c:140)

 Lock at 0x64E80C8 was first observed
   by 0x5A14D2: pj_grp_lock_create_w_handler (lock.c:463)
   by 0x4960FF: tsx_create (sip_transaction.c:1035)
   by 0x496ADD: pjsip_tsx_create_uac2 (sip_transaction.c:1365)
   by 0x496975: pjsip_tsx_create_uac (sip_transaction.c:1329)
   by 0x49A7DE: pjsip_endpt_send_request (sip_util_statefull.c:103)
   by 0x459D65: pjsip_regc_send (sip_reg.c:1434)

session.c line 519:

    /* Copy stream info (this simple memcpy may break sometime) */
    pj_memcpy(session->stream_info, si->stream_info,
          si->stream_cnt * sizeof(pjmedia_session_info));

while it should be:

session.c line 519
    /* Copy stream info (this simple memcpy may break sometime) */
    pj_memcpy(session->stream_info, si->stream_info,
          si->stream_cnt * sizeof(pjmedia_stream_info));

Thanks David Clark for reporting!

This is duplicate of ticket #137 for main trunk.

Currently there's no check if the number of pending writes in UDP media transport is greater than MAX_PENDING_WRITE. Hence, when it occurs, the send buffers will simply be overwritten without any log/warning. This can potentially introduce sound issues due to the missing&duplicate packets.

DirectSound has much better latency than WMME, so PJMEDIA should use this by default.

Sample stack trace:

(1) resolve_stun_entry() -> 
pj_stun_sock_start() ->  
get_mapped_addr() -> 
sess_fail() -> 
test_stun_on_status() -> 
(2) resolve_stun_entry()

The problem is caused if get_mapped_addr() fail, then test_stun_on_status() will destroy the (failed) STUN socket, and calls resolve_stun_entry no (2), which will then try another STUN candidate. However, after returning, the resolve_stun_entry no (1) will destroy the STUN socket again, incorrectly, for the new candidate being tried.

Thanks to Dusan Klinec for the report and the patch.

Scenario:

1. A calls B.
2. B transfer to C.
3. C reject the incoming call.
4. immediately, B transfer to C again.
5. B will see log line that REFER subscription is terminated, and any NOTIFY messages from A will be responded with 481 (Subscription already terminated). Note: A will send BYE to B after receiving 481/NOTIFY response from B, so if C rejects the transfer again, the original call A-B will be gone, but if C accepts the transfer, call A-C will be established (call transfer succeeds).

After investigation, the new subscription for the second REFER is actually created, while the old one has not been destroyed, but the Event Subscription module somehow sees the old and terminated subscription (instead of the new one) for the second REFER.

Scenario:

1. run pjsua with one nameserver configured, the library uses the nameserver fine for sometime and it successfully stores some entries in the cache, until somehow the nameserver is down and the library marks it as bad
2. a registration refresh is about to be done, DNS SRV resolver is used for resolving the SIP registrar address and the DNS server returns two entries from the cache, say server1 and server2
3. the resolver then tries to resolve the A record of those two entries, which eventually the server1 cannot be resolved due to no working nameserver and the server2 is successfully resolved from the cache
4. then assertion happens with the following call stack trace:

   #4  0x006edea6 in __assert_fail () from /lib/libc.so.6
   #5  0x082d7281 in pj_mutex_unlock (mutex=0xf0e3ee70) at ../src/pj/os_core_unix.c:1287
   #6  0x082d6c7e in pj_atomic_inc_and_get (atomic_var=0xf0e3ee68) at ../src/pj/os_core_unix.c:918
   #7  0x082d6c94 in pj_atomic_inc (atomic_var=0xf0e3ee68) at ../src/pj/os_core_unix.c:928
   #8  0x082ab7c0 in pjsip_tx_data_add_ref (tdata=0xf0e3eb0c) at ../src/pjsip/sip_transport.c:463
   #9  0x082ac370 in pjsip_transport_send (tr=0xa57fad4, tdata=0xf0e3eb0c, addr=0xf0e3fb98, addr_len=16, token=0xf0e3fb14, cb=0x82ba0cf <transport_callback>) at ../src/pjsip/sip_transport.c:827
   #10 0x082ba40c in tsx_send_msg (tsx=0xf0e3fb14, tdata=0xf0e3eb0c) at ../src/pjsip/sip_transaction.c:2037
   #11 0x082baab9 in tsx_retransmit (tsx=0xf0e3fb14, resched=1) at ../src/pjsip/sip_transaction.c:2270
   #12 0x082baebf in tsx_on_state_calling (tsx=0xf0e3fb14, event=0xf4bfe188) at ../src/pjsip/sip_transaction.c:2401
   #13 0x082b8a72 in tsx_timer_callback (theap=0xa5800c4, entry=0xf0e3fc10) at ../src/pjsip/sip_transaction.c:1153
   #14 0x082e3a7a in pj_timer_heap_poll (ht=0xa5800c4, next_delay=0xf4bfe238) at ../src/pj/timer.c:643
   #15 0x082a588c in pjsip_endpt_handle_events2 (endpt=0xa57fefc, max_timeout=0xf4bfe294, p_count=0x0) at ../src/pjsip/sip_endpoint.c:712
   

After investigation, we found a bug in DNS SRV resolver, there is possibility of the application callback being called twice, this is quite fatal as when the application is transaction module, a transaction may be destroyed prematurely (as transaction ref counter gets decremented twice while it should be once only!).

Thanks Andrey Kovalenko for the report.

PJSIP's generated PIDF presence document may be rejected by presence servers that implement strict XML checking. This is due to the 'id' attribute of <tuple> element does not strictly comply with XML 'xs:ID' specification, which prohibits it from having number as the start of the character.

(Such presence server is Ericsson presence server)

Thanks Johan Lantz for the fix!

This would cause the subscriber to not get the extended/RPID status in the initial notification.

Symptom:

Pressing 'H' (to put the call on hold) twice will cause SDP with a=sendrecv to be sent, hence causing the remote call to set the media state to active, but the local media state is still set to local hold.

How to reproduce:

• establish the call
• press 'H' to put the call on-hold
• press 'H' again

The corresponding ticket for 1.0 branch is #905

This is duplicate of ticket #880 for 1.0 branch

The PJSIP_INV_STATE_CALLING state will be reported more than once if the INVITE is challenged with authentication.

#2204 added the capability to add remote certificate on OpenSSL. However the change introduce new bug which allow memory being allocated continuously without being released when TLS transport is used.

Thanks to George Joseph for the report.

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

Thank you George Joseph for the patch.

1. In pjsua_acc_del(), it calls pjsua_acc_set_registration(acc_id, PJ_FALSE), which calls pjsua_pres_unpublish(&pjsua_var.acc[acc_id], 0);
2. And then, it will call pjsua_pres_delete_acc() which also calls pjsua_pres_unpublish(acc, flags);
3. It's possible that publish_cb() in (1) is called at the same time as (2) and the callback is in the process of destroying the publish session, hence resulting in a crash.

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.

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

Scenario:

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

Internal flow:

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

Thank you to Denis Poltorak for the report.

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.

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.

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.

pj_grp_lock_add_handler() will lock the group lock first, which has a side effect of potentially establishing an incorrect lock ordering when using thread detector tool such as Helgrind.

We should use pj_grp_lock_create_w_handler() instead that adds the handler during creation and doesn't require acquiring the lock.

Also see ticket #1821

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

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

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

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

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

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

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

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

For emulator/WINSCW build settings, there seems an inconsistency between application projects (e.g: symbian_ua.mmp) and bld.inf regarding sound device lib. The bld.inf by default doesn't build null audio implementation, while the app's mmp by default uses null audio.

Reported that pjmedia_aud_dev_refresh() will not work properly after unregistering an audio device factory, i.e: via pjmedia_aud_unregister_factory(). Also there could be some problems with internal function lookup_dev() as drv->dev_idx and drv->rec_dev_idx and drv->play_dev_idx are all set to zero by pjmedia_aud_unregister_factory().

Thanks Alexander Klyushin for the report and the patch.

• E32USER-CBase 66
• undeinited stdlib

The maximum port count of video tee in video preview (for capture device sharing) is currently hardcoded to 2, while it should be set to at least (PJSUA_MAX_CALLS+1) so a capture device can be shared among multiple calls.

Known symptoms:

• some calls send no video packet even the video direction is send-receive,
• crash on hanging up calls.

Setting window's position when the window is hidden also sets the window's flag to shown (while the window is, actually, still hidden). This causes problems later when setting/querying the window's visibility.

It has been reported that there is problem with receiving data with TCP socket/transport on Symbian.

The corresponding ticket for 1.0 branch is ticket #759

This is duplicate of ticket #758 for 1.0 branch.

Reported in ​this post:

There is a problem with getting default ip interface on FreeBSD: in function pj_getdefaultipinterface() the socket length passed to pj_sock_connect() seems to be incorrect (although in works fine on Windows, Linux and Max, I checked). The following patch fixes the problem:

Index: trunk/softphone/contrib/pj/pjlib/src/pj/sock_common.c
===================================================================
--- a/trunk/softphone/contrib/pj/pjlib/src/pj/sock_common.c
+++ b/trunk/softphone/contrib/pj/pjlib/src/pj/sock_common.c

@@ -915,5 +915,5 @@
    }

-    status = pj_sock_connect(fd, &a, sizeof(a));
+    status = pj_sock_connect(fd, &a, pj_sockaddr_get_len(&a));
    if (status != PJ_SUCCESS) {
        pj_sock_close(fd);

Roman Grachev

In call media initialization, if ICE media transport completes immediately, we will directly proceed to finish the call media initialization process. If it doesn't, we will mark the call media to resume call media initialization when the ICE media transport completes, i.e. in the on_ice_complete() callback.

However, if subsequently, during re-invite/media reinitialization, ICE media transport completes immediately, then on_ice_complete() callback will still follow the same path, i.e. directly resuming call media initialization in its on_ice_complete() callback. The behaviour is undesired since it will cause call media initialization to be called twice.

When the server sends a large (INVITE) request towards the Android client via TCP, PJSIP does not seem to process this request. Looking at the log there seems to be no activity regarding the incoming data. The OS may not notify us at all about the incoming data. Wireshark capture shows that server sent the INVITE request as TCP fragments and instead of receiving acknowledgement, it gets error from the client instead (see the attached capture).

This has been tested with different wi-fi routers and 3G providers and the issue remains. Smaller SIP requests towards the client work as expected.

Update:

The same problem also occurs in the sending direction. PJSIP sends large (INVITE) request, the log shows it, but nothing actually gets transmitted. After this the TCP socket seems to be disfunctional until it is closed.

PJLIB assumes that FD_SETSIZE is always set-able in every OS, so <pj/config.h> always override this macro and set set it to PJ_IOQUEUE_MAX_HANDLES.

While this assumption is correct for Windows (or Visual C rather), this is wrong for GLIBC. On GLIBC, FD_SETSIZE specifies the maximum number of file descriptors in fd_set, and the value is constant (see (1)). If we set this in PJLIB, we will get warning about macro being redefined when including GLIBC headers.

So PJLIB should detect if FD_SETSIZE is indeed changeable, and only set it if it is.

(1) ​http://www.gnu.org/software/libc/manual/html_node/Waiting-for-I_002fO.html#Waiting-for-I_002fO

PJSIP assumes that an snprintf of "%.*s" will nicely print nothing if the supplied arguments are 0 and NULL. Unfortunately some Libc library (such as uClibc) would print "(null)" instead.

It has been suggested that PJSIP should be changed so that it uses empty string ("") instead of NULL when the string length is zero, but this would require modifications in too many places. And I feel that this is not the right solution anyway since I believe we comply with ANSI C.

We suggest that uClibc should be fixed instead. The offending lines are in libc/stdio/_vprintf.c, just search for "(null)" and replace it with an empty string.

Thanks Alfonso Ortega for the info.

Known issues:

1. Multiple definition of pj_time_decode/pj_time_encode.
2. Missing LDFLAGS on some components.
3. pjmedia-audiodev depends on pjmedia/format.c.

Thanks Brian White for the report.

Several problems with IPv6 SIP transport:

• segfault when it is enabled in simpleua.c (to reproduce, just replace pj_AF_INET() with pj_AF_INET6())

This is duplicate of ticket #755 for 1.0 branch.

Symbian looks to having troubles when there are too many big blocks allocated by application, and unfortunately PJ likes to allocate memory in big blocks (4000 bytes or so) for the pool.

The solution is to have the block size configurable during compile time.

Problem:

We are having problems with STUN in Symbian. It seems like STUN request packets do not have the correct format. When using Windows Mobile, STUN data starts with 0x0001 (Binding Request); when using Symbian, STUN data starts with 0x0100 - which does not seem correct.

Presently, pj_htons() is a no-op (pj/sock_symbian.cpp:219):

/*
 * Convert 16-bit value from host byte order to network byte order.
 */
PJ_DEF(pj_uint16_t) pj_htons(pj_uint16_t hostshort)
{
  /* There's no difference in host/network byte order in Symbian */
  return hostshort;
}

We have a deeper problem here. While it's true that the integers in TInetAddr are in host order (therefore pj_ntohx() and pj_htonx() can be made no-op), the pj_ntohx()/pj_htonx() are used by other functions so they must convert the host/network orders correctly.

For now, a quick fix is to replace pj_htonx()/pj_ntohx() calls in STUN with something like swap16() and swap32(). Apart from this, unnfortunately pj_ntohx/pj_htonx are used in RTP and RTCP as well..

There have been some problems with using the splitter/combiner port (splitcomb) with PJSUA-LIB. Splitcomb typically is used on these scenarios:

1. when the application wants to support multiple sound devices connected to the conference bridge
2. in one case, one user uses splitcomb even with one sound device to avoid the jitter in RTP transmission.

For case a) above, one user has reported that when three audio devices are used (one connected directly to port 0 of the bridge and the other two via splitcombs), then there won't be any audio coming/going through the third sound device. Checking the log revealed that there are many overflow/underflow messages printed on the log. This only happens when C-Media USB Audio driver is used; if the generic USB audio driver is used, audio seems to be working fine.

For case b), the user reported that audio was also broken, and there were lots of underflow/overflow messages printed to the log as well.

Currently padding bit in incoming RTP packets are ignored, potentially causing incorrect RTP payload processing.

Also investigate if the padding bit should be used in outgoing RTP transmission.

Some errors seems to be just trapped as assertion.

make install:

• adhere to --prefix option
• copy public header files to $prefix/include
• copy all generated libraries to $prefix/lib
• create pkgconfig file in $prefix/lib/pkgconfig

Limitations:

• only --prefix works for now; other configure options such as --libdir=DIR or --includedir=DIR are ignored.

Original report can be found ​here.

The problems reported:

• an RTCP compound packet contains a SDES only. No RR, not even an empty RR.
• sends SR without attaching an SDES packet
• sends a BYE packet without an RR and an SDES.

RFC 3550 6.1:

• all RTCP packets MUST be sent in a compound packet of at least two individual packets.
• The first RTCP packet in the compound packet MUST always be a report packet to facilitate header validation as described in Appendix A.2. This is true even if no data has been sent or received, in which case an empty RR MUST be sent, and even if the only other RTCP packet in the compound packet is a BYE.
• An SDES packet containing a CNAME item MUST be included in each compound RTCP packet, except as noted in Section 9.1 (about confidentiality/encryption).
• Other RTCP packet types, including those yet to be defined, MAY follow in any order, except that BYE SHOULD be the last packet sent with a given SSRC/CSRC.

The original idea of not using mutex in regc was because operations should be serialized by 8-bit boolean flags, and (I heard) operation to 8-bit variables should be atomic. But it seems that with recent modifications/bug fixes in regc, this rule may not hold anymore (such as the timer, which I think was added only quite recently).

Copy of #1254 for 1.x

Non-100 provisional response retransmission interval setting, PJSIP_TSX_1XX_RETRANS_DELAY, is currently not published/documented.

Python GUI Application based on pjsua2+SWIG API

On Linux (or at least my Linux), pjsua_app.py application will block forever on sys.stdin.readline(), and somehow this is related to the other thread calling py_pjsua.handle_events() (if this is commented, the keyboard input will function properly).

As the title says..

As the title says. Thanks Niels Klaas for the patch!

As the title says. Note that only msg_info_info (pjsip_rx_data_get_info()) and msg_info_buffer (rdata.msg_info.msg_buf) attributes are implemented.

Thanks Niels Klaas for the patch!

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.

• Migrate qt_dev.m and ios_dev.m from private repository to this branch
• Migrate sdl_dev.m too
• Fix the configure and build system to use these on MacOS X and iOS

After call transfer is complete, normally transferee should terminate the subscription caused by REFER by sending NOTIFY with Subscription-State: terminated.

When transferee doesn't do that, transferer should terminate it by sending SUBSCRIBE with Expires: 0.

We don't do that, but instead we maintain the subscription, and when it is about to expire, we will send REFER again to refresh the subscription.

If the encoder channel is paused and only decoding allowed, then RTCP RR reports are not being generated.

Some application uses the RTCP RX statistic to detect whether remote call has disappeared, i.e. when no packet is received for some time then application assumes that remote call has gone missing.

Some user agents (X-Lite in this case) send a one byte packet when the call is on-hold to keep the call running. So the receipt of such packet can be used to prevent application from deleting the call.

Unfortunately, this one byte packet will not count on any RX statistic since it was not an RTP packet, so it doesn't pass the rtp_decode() function.

The correct behavior (probably) is to count this invalid RTP packets as the discarded packets.

The RTCP setting samples_per_frame/frame length in video stream should be calculated from frame-per-second and clock-rate setting, currently it is hardcoded to one.

The report can be found ​here.

Updates suggested:

1. Currently the RFC 3550 compliant jitter calculation is used in generating RTCP RR packet, however the jitter statistics is calculated from "raw jitter" (referring to "different D" of RFC 3550), so changes to be done:
   • jitter statistics should use RFC 3550
   • add "raw jitter" statistics (calculated from absoluted RFC 3550 diff D), compile-time configurable, disabled by default.
   • also add IPDV (calculated from RFC 3550 diff D), compile-time configurable, disabled by default.
2. Add feature to reset RTCP statistics.

The RTP port number uses a static variable to keep track next available port to use, and the value is not cleared on pjsua_destroy().

This would cause next pjsua_init() after pjsua_destroy() to not use the RTP starting port setting.

Thanks Binu K S <binuks at gmail> for reporting this.

See ticket #176 for details.

Currently RTP timestamp is incremented based on number of samples processed, while this is considered to be incorrect for multichannel audio, as specified by RFC 3551 Section 4.1:

The RTP clock rate used for generating the RTP timestamp is independent of the number of channels and the encoding; it usually equals the number of sampling periods per second. For N-channel encodings, each sampling period (say, 1/8,000 of a second) generates N samples. (This terminology is standard, but somewhat confusing, as the total number of samples generated per second is then the sampling rate times the channel count.)

Issues:

1. Currently, when pjsip sends offer with RTP/AVP with a=crypto attribute (SRTP mode optional), and when remote answers with RTP/SAVP, SDP negotiation will fail and media will not be created, but the call is not terminated.
2. When pjsip sends offer with RTP/SAVP (SRTP mode mandatory), and remote answers with RTP/AVP, SDP negotiation will fail and media will not be created, but the call is not terminated.

Case:

• Caller is using RTP/SAVP, callee is using RTP/AVP
• Call establishment should be okay, callee will adjust to RTP/SAVP
• But when callee sends UPDATE, it sends it with RTP/AVP, which will be rejected by caller since it expects RTP/SAVP

Race condition between pj_ice_strans_stop_ice() and pj_ice_strans_sendto()

Example scenario:

45:31.546   28834 D PJSIP: 45:31.556  pjsua_media.c  .....Call 1: updating media..
45:31.546   28834 D PJSIP: 45:31.563  pjsua_media.c  ......Call 1: stream #0 (audio) unchanged.
45:31.546   28834 D PJSIP: 45:31.563        icetp00  ......Stopping ICE, reason=Remote answer doesn't support ICE
45:31.546   28834 D PJSIP: 45:31.563        icetp00  ......Destroying ICE session 0x76595fd4

Called from transport_ice.c: transport_media_start() -> set_no_ice() -> pj_ice_strans_stop_ice()

Then there's a call to pj_ice_strans_sendto(), backtrace below:

45:31.996  1064  1064 I DEBUG   :     #00  pc 00329e6e  /system/lib/PJSIP.so (pj_ice_sess_send_data+25)
45:31.996  1064  1064 I DEBUG   :     #01  pc 0032b371  /system/lib/PJSIP.so (pj_ice_strans_sendto+76)
...
45:31.996  1064  1064 I DEBUG   :     #06  pc 0033f33f  /system/lib/PJSIP.so (ioqueue_dispatch_read_event+290)
45:31.996  1064  1064 I DEBUG   :     #07  pc 0033fd9f  /system/lib/PJSIP.so (pj_ioqueue_poll+448)

pj_ice_strans_sendto() tries to access the already destroyed ice session, hence resulting in crash.

Fix race condition which may cause the transaction to be destroyed before we have chance to lock the group lock.

10:19:57.797 (52608) [PJ:5] -  tsx0x6d9db88c        pjsua  .State changed from Terminated to Destroyed, event=TIMER
10:19:57.797 (44440) [PJ:4] -   pjsua_core.c        media  .RX <-- 1329 bytes Response msg 200/INVITE/cseq=26892 (rdata0x69dcc1cc) from TCP 216.115.27.170:5090:
10:19:57.798 (44440) [PJ:5] -  tsx0x6d9db88c        media  .Incoming Response msg 200/INVITE/cseq=26892 (rdata0x69dcc1cc) in state Destroyed
10:19:57.818 (52608) [PJ:5] -  tsx0x6d9db88c        pjsua  ..Transaction destroyed!

The problem seems to happen because the transaction lock is destroyed after the first line, and then the media thread tries to lock it in the retransmitted response.