Custom Query (2195 matches)

We don't use PortAudio's configure script for building PortAudio, and it seems that endianness is not properly set by our build system.

Reported that application crashes on releasing its memory pool after pjsua_init returning error. After investigation, we found that pjsua_destroy() is automatically called by pjsua_init() upon failure, so calling any PJ API after that may lead to crash.

This ticket will fix the following issues:

• pjsua_init() shouldn't call pjsua_destroy() upon failure
• also pjsua_create() should reset all pjsua states (including pjlib's) upon failure.

Thanks Yeffry Zakizon for the report.

Some client (Gnome ekiga 2.0.3) sends SDP with telephone-event as the first format in SDP m= line, and this causes pjmedia to raise assertion error in pjmedia_stream_info_from_sdp in pjmedia/session.c:

pj_assert(PJMEDIA_RTP_PT_TELEPHONE_EVENTS==0 ||
          pt != PJMEDIA_RTP_PT_TELEPHONE_EVENTS);.

See ticket #202.

Currently it is possible with the current algorithm to return zero as the highest resolution, causing the video call to fail. This ticket is to fix this.

1. Send 500 with Retry-After header set randomly between 0 and 10 if we receive UPDATE while we haven't sent answer.

2. Change "If UPDATE doesn't contain SDP" test to be the earliest check. From RFC 3311: If an UPDATE is received _that contains an offer_, and the UAS has generated an offer (in an UPDATE, PRACK or INVITE) to which it has not yet received an answer, the UAS MUST reject the UPDATE with a 491 response.

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

Thanks to Marcus Froeschl for the report.

See ticket #237.

Couple of minor defects with logging:

• pjsua_logging_config.decor was never applied in pjsua-lib
• Wrong month is printed with PJ_LOG_HAS_MONTH (it should be mon+1, not mon)

When using GnuTLS, tls_init() will save cipher suite info to local array and might raise out of bound error if GnuTLS has more supported cipher suite then the maximum array size (MAX_CIPHERS=100).

This patch will not allow adding more cipher once the local array is full.

Thanks to Hugo Lefeuvre for the report and initial patch.

There is a possibility that STUN server resolution can get stuck if it is called from the only available worker thread. The fix will address the issue.

For packets with NALU type 7 or 8 (SPS or PPS), we copy the whole data to the buffer, but for invalid packets, the data can be larger than the buffer, hence causing buffer overflow.

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

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.

The issue is caused by two things:

• Due to #2097, pjmedia_transport_media_stop() for UDP transport will call pj_ioqueue_post_completion(). This will trigger on_read_complete() callback, i.e. on_rx_rtp() which will call pj_ioqueue_recvfrom(). So the read operations never really stop.
• Ioqueue itself never checks when an op_key is already in the list. Thus, when the media transport is restarted, it will call pj_ioqueue_recvfrom() again. Calling recv() with the same op_key will cause the list to be in a bad state (i.e. the element's next and prev pointers will lose track of its neighbours, hence causing the list to be uniterable). Thus, when later calling pjmedia_transport_detach(), and UDP media transport calling pj_ioqueue_post_completion() for its pending write_op, the function may get stuck when iterating the read list.

PJSIP should support multiple (event) subscriptions in a single dialog, but it has been reported that this does not work. See this report: ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2010-January/010035.html

When using -NDEBUG -Wunused-but-set-variable build option, some unused-variable warnings will be generated. This is mainly because pj_assert will not be evaluated when -NDEBUG is used.

Although harmless, eliminating compiler warning is a good practice.

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

error LNK2001: unresolved external symbol

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

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

If one connectivity check fails, the checklist periodic check will not continue, hence resulting the ICE negotiation to make no progress.

2016-08-22 12:07:00.391 icetp00 Starting checklist periodic check
2016-08-22 12:07:00.393 icetp00 Sending connectivity check for check 0: [1] 192.168.100.10:56958-->192.168.100.20:51136
2016-08-22 12:07:00.394 utsx0x163a8570 STUN client transaction created
2016-08-22 12:07:00.394 utsx0x163a8570 STUN sending message (transmit count=1)
2016-08-22 12:07:00.394 utsx0x163a8570 STUN error sending message: Network is unreachable
2016-08-22 12:07:00.395 stun_session.c tdata 0x163a8464 destroy request, force=0, tsx=0x163a8570
2016-08-22 12:07:00.395 utsx0x163a8570 STUN transaction 0x163a8570 schedule destroy
2016-08-22 12:07:00.396 stuse0x15c2e00 Error sending STUN request: Network is unreachable
2016-08-22 12:07:00.397 icetp00 Error sending STUN request: Network is unreachable
...
[no ICE progress after this]

According to the doc of pjsua_transport_config:

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

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

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

Scenario:

• Make call, callee answers with 302 and redirects it to another target.
• Caller makes a call to the new target. When the new target answers with 200, it will trigger an assertion in the caller:

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

The reason is because provisional media has been cleaned up on the caller side.

Scenario:

1. REGISTER without authorization is being sent
2. It’s retransmitted once, because response isn’t received yet
3. 401/407 response is received (response to packet in step 1)
4. PJSIP sends REGISTER with Authorization header
5. 401/407 is received again as a response to packet retransmitted in step 2
6. PJSIP tries to send REGISTER with authorization again and it hit an assertion:

   pj_assert((tsx->transport_flag & TSX_HAS_PENDING_TRANSPORT) == 0);
   

stack trace:

#4  0x002deea6 in __assert_fail () from /lib/libc.so.6
#5  0x082cc658 in tsx_resched_retransmission (tsx=0xeb94446c) at ../src/pjsip/sip_transaction.c:2219
#6  0x082cbc32 in send_msg_callback (send_state=0xe3bad828, sent=767, cont=0xf4bfdfcc) at ../src/pjsip/sip_transaction.c:1857
#7  0x082ba2fe in stateless_send_transport_cb (token=0xe3bad828, tdata=0xe3a0f2d4, sent=767) at ../src/pjsip/sip_util.c:1126
#8  0x082bdee2 in transport_send_callback (transport=0x8bcf6e4, token=0xe3a0f2d4, size=767) at ../src/pjsip/sip_transport.c:757
#9  0x082c09d9 in udp_on_write_complete (key=0x8bd7c50, op_key=0xe3a0f310, bytes_sent=767) at ../src/pjsip/sip_transport_udp.c:306
#10 0x082e33a8 in ioqueue_dispatch_write_event (ioqueue=0x8bd79a0, h=0x8bd7c50) at ../src/pj/ioqueue_common_abs.c:399

The assertion is caused because in sip_transaction.c, if there is pending send and reschedule, the pending send may cause the flag TSX_HAS_PENDING_TRANSPORT to be set when sending the pending message (in tsx_send_msg()).

When TURN client is connected to a Wifi network with network access control through web authentication/payment, this will happen:

• the turn_on_state function (turn_sock.c) enters in PJ_TURN_STATE_DESTROYING state.
• After that, it enters in on_connect_complete function, calling the pj_turn_session_alloc function with the attribute "sess" equal to NULL (due to last action).

Thus, the pj_turn_session_alloc function itself has an invalid PJ_ASSERT_RETURN(sess, PJ_EINVAL) statement in its beginning.

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

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

PJSIP is throwing an assertion at sip_util.c when during executing pjsua_start(), an incoming call is received.

This is caused by:

1. pjsua_call.c / pjsua_call_on_incoming():

sip_err_code is uninitialized

2. pjsua_media.c / pjsua_media_channel_init()

when pjsua_get_status() != RUNNING, the function will return without setting the sip_err_code. This creates a response with random sip error code and an assertion is thrown.

Some dependencies are not set properly, causing either stale build (application is not rebuilt when libraries changed) or unnecessary rebuild.

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.

If one of the medias gets disabled, the codec param of stream info is not set (i.e. NULL), causing the crash

It happens because there is a race condition when two threads try to destroy CFStream in activesock. The stack trace of the crash will look like this:

Thread 17 Crashed:
0   0x0000000183ba95a8 CFRelease + 1084
1   0x000000010045f81c activesock_create_iphone_os_stream (activesock.c:139)
2   0x000000010045a7fc ioqueue_dispatch_write_event (ioqueue_common_abs.c:280)
3   0x000000010045c4c8 pj_ioqueue_poll (ioqueue_select.c:966)
4   0x00000001004777ac worker_proc (endpoint.c:350)
5   0x000000010045d300 thread_main (os_core_unix.c:523)
 
Thread 18:
0   0x00000001953eb0c0 __psynch_mutexwait + 8
1   0x000000010045d1e4 pj_mutex_lock (os_core_unix.c:1243)
2   0x00000001004623ac pj_grp_lock_acquire (lock.c:180)
3   0x000000010045c094 pj_ioqueue_unregister (ioqueue_common_abs.c:1323)
4   0x0000000100460004 pj_activesock_close (activesock.c:305)
5   0x00000001004b679c tcp_destroy (sip_transport_tcp.c:830)
6   0x00000001004b6c1c tcp_destroy_transport (sip_transport_tcp.c:784)
7   0x00000001004b3c20 destroy_transport (sip_transport.c:1153)
8   0x00000001004b39cc transport_idle_callback (sip_transport.c:1232)
9   0x000000010046a1fc pj_timer_heap_poll (timer.c:762)
10 0x00000001004afbb8 pjsip_endpt_handle_events2 (sip_endpoint.c:723)
11 0x00000001004de5fc worker_thread (pjsua_core.c:1982)
12 0x000000010045d300 thread_main (os_core_unix.c:523)

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.

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.

Program received signal SIGSEGV, Segmentation fault.

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

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

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

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

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

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

Thanks to Håkan Berg for the report.

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

Thank you George Joseph for the report and the patch.

When IOCP is used as ioqueue backend, the unregistration will cause deadlock if the unregistration is called on the callback.

This can be reproduced with ioqueue unregister test in pjlib-test.

As detected by Helgrind tool

Destroying a locked mutex may cause an undefined behaviour in some platforms. For example, see pthread_mutex_destroy() manual ​here (search for "locked mutex").

For example, parsing quoted text "\"DisplayName\"" should return \"DisplayName\" (begin & end quote excluded), currently it returns \.

Identified issues:

1. The PA callbacks implementations contains wrong assertion, because of samples_per_frame misinterpretation (thanks Rodrigo Vega, ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-March/001974.html):
   • Soundport's samples_per_frame is total samples number per frame of ALL channels.
   • While PA's frameCount refers to number of samples for EACH channel.
2. Lack of channel_count multiplication in samples_per_frame calculation in some parts of stream causing silence in stereo audio call.
3. STEREO_DEMO in pjsua causing crash in PortAudio without call (perhaps because of some pointer to PA buffer get overwritten)
4. Add channel_count field in pjsua_media_config to configure number of channels for both sound device and conference bridge. Add --stereo option in pjsua to change set this channel_count field to 2.
5. Create two utility functions to:
   1. convert one mono channel audio frame to N-channel audio frame. Just duplicate the sample to all channels.
   2. convert N-channel audio from to mono audio frame. The function should have an option to either mix sample from all the channels into one channel, or to just take audio samples from one of the channel. To make the implementation simpler, we can just implement these two functions as inline functions in a new header file (e.g., stereo.h) rather than a media port.
6. Use these channel conversion functions in the conference bridge, to convert audio samples from media ports when the media port has different channel number with the conference bridge.

Several bug fixes to the TURN client library and icedemo sample application:

1. ICE stream transport reports ICE initialization/candidate gathering stage as successful even when TURN client TCP connection has failed.
2. Bad ChannelData framing when TCP is used. PJNATH did not properly add padding to the TURN ChannelData packet if TCP is used and the data is not aligned to four bytes boundary. Similarly incoming ChannelData with padding (over TCP) may not be handled correctly.
3. Incoming data over TCP may be delayed. PJNATH only processed one frame (be it request, indication, or ChannelData) on an incoming stream, so if the stream contains more than one frames, the processing of subsequent frames will be delayed until more stream is received on the TCP transport.
4. The icedemo sample application overwrites the incoming packet buffer with NULL character ('\0') before printing the message to console. If there is another packet after current packet (as often happens when TCP is used), the subsequent packet will get corrupted.

The combinations of bugs above may cause PJNATH to return "Invalid STUN message length (PJNATH_EINSTUNMSGLEN)" error when processing incoming TURN ChannelData message over TCP.

And a small enhancement:

1. Add logging to file option to icedemo sample.

Thanks Sarun Nandakumar for the report.

​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2009-November/009561.html

The original timer heap design is based on passive object principle, where the timer heap requires polling to make it run. This is not the case with Symbian implementation, where it is implemented with Active Objects thus requires no polling.

The timer heap doesn't keep record on currently active timer entries that have been scheduled by application. As the result, it is possible that an Active Object is still running even after the timer heap is destroyed, causing stray callback to be called. This most likely will crash the application.

This ticket implements record keeping in the timer heap, to enable it to cancel the currently running Active Objects when the timer heap is destroyed.

This ticket fixes some bugs on the via_rewrite feature. The via_rewrite feature was introduced in pjsip version 2.0.1 by #1537.

With this ticket, the behavior regarding changing the Via sent-by is as follows:

If allow_via_rewrite is enabled, we save the Via "received" address from the response, if either of the following condition is met:

• the Via "received" address differs from saved one (or we haven't saved any yet)
• transport is different
• only the port has changed, AND either the received address is public IP or allow_contact_rewrite is 2

Add couple of logging flags in PJSUA-LIB logging configuration:

• flag to make PJSUA-LIB append to existing log file instead of overwriting it
• flag to control the log filename, for example add date time to the filename

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

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

Thanks George Joseph for the feedback and the patch.

Currently secure scheme is only configurable via compile time setting (PJSUA_SECURE_SCHEME), and this may cause problem, for example when PJSUA_SECURE_SCHEME is set to "sips", any call over a POTS gateway will be refused.

Reported that when calling a video echo server and video is switched off and on repeatedly every ~10s, sometimes there are issues like:

• taking a while for incoming video echo to be shown after video restart,
• frame rate hiccups after video restart, e.g: a video frame is shown, but then stopped still for sometime, then resumed with higher frame rate (catching up the delay), and eventually played at normal frame rate.

Log file showed strange frame rate change events:

Decoding format changed: 352x288 I420<- 90000/431010(~0)fps
Decoding format changed: 352x288 I420<- 90000/365760(~0)fps
...or..
Decoding format changed: 352x288 I420<- 90000/2610(~34)fps
Decoding format changed: 352x288 I420<- 25/1(~25)fps

Currently the video stream continuously performs frame rate detection, and it should only publish a format-changed event when frame rate is increasing. But the log shows that it also publishes a format-changed event even when it sees frame rate down to zero, which should not happen.

Thank you Giorgio Alfarano for the report.

The encoder framerate is currently calculated from local H263 SDP fmtp, which actually specifies decoder settings, it should be calculated from pjmedia_vid_codec_param.enc_fmt.det.vid.fps.

The timestamp of outgoing media is always generated by the sound device, and it should be propagated throughout the components until the last downstream component, the media transport.

Unfortunately some components doesn't seem to propagate this information properly to downstream. Example of such components are conference bridge (there may be more).

In addition, the conference bridge should adjust the timestamp when the frame is going through a resampling algorithm (i.e. the timestamp should be adjusted according to sample rate conversion).

The publish session may try to read the session after it has been destroyed by the callback.

See ticket #291

This is useful when creating a new call as the result of redirection, as RFC 3261 recommends that the same Call-ID should be used. Thanks P.J.Cast for the suggestion.

Implement an experimental G.722 codec in pjmedia-codec. We'll just concentrate on having it done for now, and optimize it later.

Basically there will be no compile or run time error. Just that both implementations will coexist and it may cause payload types duplications problem in SDP.

The GSM codec factory refuses to shutdown itself when there are outstanding codecs in the cache, but this would always be the case if the GSM codec has ever been used! This would cause the factory to fail to unregister itself from the codec manager, and it will cause next call to get "Invalid RTP PT" error.

See this thread for reference: ​http://www.pjsip.org/pipermail/pjsip/2007-March/002523.html

Thanks Binu KS <binuks at gmail> for reporting and fixing this.

See ticket #174 for details.

Add GSM codec support in Symbian port.

Toni reported that a GUI program crashes occasionally after it's running for some time. Not sure what's causing this, could be application issue.

The default GUID generation backend for Linux/Posix? (guid_simple.c) cannot generate more than 2^{14 unique numbers, and this causes failures with large number of calls.}

See ticket #277

Currently, on Android, due to unavailability of native UUID support, we use guid_simple.c which relies on simple rand(). Unfortunately, this may cause ID collision, such as for Call-ID. The proper implementation is to use java.util.UUID API instead.

Thanks to Johan Lantz for the report and the patch.

Garbage character will be printed if tel: URI is used in Authorization and Proxy-Authorization header. This is because the sip_auth_client.c relies on undocumented NULL termination in pjsip_uri_print(). Unfortunately the NULL termination was not added for tel: URI.

This ticket adds two fixes:

• remove the reliance on NULL termination in sip_auth_client.c
• add the NULL termination when printing tel: URI just in case other components use it

Thanks Bart Klin / Arkadiusz Wronski for the report.

Use analysis tools for detecting bugs and report the fixes here.

To be continued in 2.3.

Currently PJMEDIA will only generate and answer SDP with one telephone-event format, i.e: telephone-event/8000. But in the stream session, it will send DTMF using timestamp correctly according to the audio codec clock rate.

This ticket will update the PJMEDIA behavior in SDP offer/answer:

• in generatig SDP offer, it will generate one or more telephone-event formats, one for each clock rate, in accordance with the clock rates of the offered audio codecs.
• in generating SDP answer, it will select telephone-event clock rate based on the clock rate of the selected audio codec.

Add generic URI scheme to handle non-SIP/non-tel URI such as http or email that might appear in Contact URI.

Thanks Juri Glaß for the contribution.

The report could be found ​here.

While doing 1.2 QA, we found this issue, reproducing steps are still unknown, just sometimes happens (as reported).

The corresponding ticket for 1.0.x branch is #896.

Issues:

• PJSUA-LIB should re-register automatically on transport disconnection or registration failure (temporal failure).
• Calls disconnection after a re-registration attempt fails.

Thanks Klaus Darillion and Fabio Pietrosanti for the request.

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

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

This ticket contains works to be/that have been done in PJLIB to lay foundation for fixing various synchronization issues in upper layers such as PJNATH (see #1617). The details of the work are as follow.

Group Lock

Implement Group Lock, a new synchronization object for dealing with deadlock and session management. Please see the link for more info.

More robust timer heap

• Integration of group lock to the timer heap. A new API is introduced: pj_timer_heap_schedule_w_grp_lock(), which adds reference counter to the group lock when timer is scheduled, and automatically decrements it after the timer expires or cancelled, to prevent the group lock from being destroyed when a timer callback is about to be executed. This API also sets the timer "id" automatically and atomically.
• New convenience API: pj_timer_heap_cancel_if_active() to cancel a timer without having to firstly check if it is active or not.

Changes is ioqueue and active socket

• New API pj_ioqueue_register_sock2() that takes group lock argument. The group lock would be incremented before callback is called to prevent it from being destroyed while callback is about to run.
• Added grp_lock in pj_activesock_cfg, to specify which group lock to use by the ioqueue key.

Miscellaneous

• New PJ_EGONE error code. It is used when pj_grp_lock_dec_ref() or pj_grp_lock_release() causes the group lock to be destroyed.
• New PJ_RACE_ME(x) macro which can be inserted in various strategic locations. During testing, the macro can be replaced with pj_thread_sleep(x) in order to trigger race condition to happen.
• Event object (similar to Windows event) implementation for os_core_unix.c based on Pthread condition variable. This is used by the pjnath-test testing program to synchronize the tests.

Still some operations in PJSUA-LIB use the global pool which will not be destroyed until the application quits.

Topics such as:

• How to perform native debugging
• How to setup and retrieve log files
• How to debug crashes

The guide will be written to Getting-Started/Android

SIP and RTP traffic tunneling inside HTTP.

There may be a workaround though: Getting Around Blocked, Filtered, or Mangled VoIP Network. This is available now.

Some codecs need to be treated special:

• G.722, because of erroneously assigned in RFC 1890, its actual sampling rate is 16kHz but need to be defined as 8kHz in the SDP and also affecting its RTP timestamp clock rate. (RFC 3551 4.5.2)
• MPEG audio, for compatibility with other MPEG systems, MPEG Audio uses 90kHz RTP timestamp clock rate separate from the audio sampling clock rate. (RFC 3551 4.5.13 & RFC 3119)

Description can be found ​here.

Ticket #733 is the corresponding ticket for 1.0 version.

Description can be found ​here.

This is a duplicate of ticket #732.

It has been observed that on some NAT router, after some time (in this case, 8-10 hours of idle), NAT may assign different binding even when STUN keep alive packets have been sent periodically. In this case, ICE transport should update the srflx candidate accordingly.

Thanks Ravin Suri for reporting this.

The incoming RFC 2833 DTMF handler does not handle the case where RTP packets arrive out of order. In this case, the packets may cause stream.c to detect them as multiple DTMF events.

For uncompressed RGB formats, dshow will produce a bottom-up image (instead of top-down) if the biHeight is positive.

Sound sound device backend (such as OSS) may return audio frame that is shorter or longer than a full frame, and this currently is not handled (it will trigger assertion in pasound.c).

The specification does not allow callee to send UPDATE before 101-199 provisional response with a tag is sent. This is because the dialog has not been established before a tag is response, and UPDATE can only be sent on an established dialog (early or confirmed).

Reference: ​RFC 3261 Section 12.1 and ​RFC 3311 Section 3

But we receive this anyway. Since we already handle the case when NOTIFY arrives before SUBSCRIBE response, we should tolerate this scenario as well.