Custom Query (2195 matches)

All work on the sample apps please put here.

This is placeholder ticket for all works related to video devices.

Application should really handle forking dialog, but it's quite complicated to do that, so currently even pjsua-api cannot handle forked dialog. But there seems to be a simpler workaround to solve this problem.

We're taking the fact that in most cases only one 2xx response will ever get back to the dialog. Several 1xx responses will get through and these will affect dialog/session state and mess around with SDP negotiation if the response carries SDP body, but this is not as fatal as having incorrect To tag recorded by the dialog.

Currently the dialog takes the first To tag seen and set it as the remote tag. If the tag in 2xx response is different than this tag, ACK will be sent with wrong To tag and incoming request with this tag will be rejected with 481.

The workaround for this is to take the last To tag received in the response and set it as remote tag.

This is the duplicated ticket for the main branch.

See ticket #111 for details.

Problem 1: Audio burst:

Most audio devices will call record and playback callbacks in burst, rather than in perfect interleave (for example, burst of record callbacks, followed by burst of playback callbacks, and so on). Because of this, audio buffering needs to be implemented in few pjmedia components (conference bridge, splitcomb, echo canceller, etc.), and the maximum buffering is controlled by PJMEDIA_SOUND_BUFFER_COUNT macro.

This is not ideal, because:

1. it adds audio latency of up to PJMEDIA_SOUND_BUFFER_COUNT frames, while theoretically the delay should be limited to the maximum burst level of the device.
2. it will add even more end to end latency when the sound device is connected directly to the stream (rather than via conference bridge), because of how the jitter buffer is implemented.
3. pjmedia components need to handle the burst, while this problem should have been localized and fixed in sound device.

Problem 2: Audio drifts:

Somehow related to this problem, it's common for sound devices on PC to have clock drifts (see some of our test results in Audio Device Test page). Because of this drifts, the buffering mechanism above will ultimately underflow or overflow, and this will cause a clicks noise to be generated.

The Solution:

This ticket solves the problem in several ways:

• introduce delaybuf.[hc] as a generic buffering mechanism. The delaybuf automatically learns the optimal buffering to be applied to audio flow, and shrinks or expands the audio in the buffer as necessary (for example, upon overflow or underflow situation) without degrading the audio quality by much or producing the clicks noise. This is done by using WSOLA algorithm, implemented in ticket #497
• use delaybuf in soundport, so that now recording and playback callbacks are called in perfect interleave.
• also install delaybuf in splitcomb and conference bridge since they need the same buffering mechanism.

Crash has been reported in call to PJ_ERROR below when trying to access stun_sock->obj_name:

stun_sock.c:756:

/* Callback from active socket when incoming packet is received */
static pj_bool_t on_data_recvfrom(pj_activesock_t *asock,
                                  void *data,
                                  pj_size_t size,
                                  const pj_sockaddr_t *src_addr,
                                  int addr_len,
                                  pj_status_t status)
{
    pj_stun_sock *stun_sock;
    pj_stun_msg_hdr *hdr;
    pj_uint16_t type;

    stun_sock = (pj_stun_sock*) pj_activesock_get_user_data(asock);

    /* Log socket error */
    if (status != PJ_SUCCESS) {
        PJ_PERROR(2,(stun_sock->obj_name, status, "recvfrom() error"));
        return PJ_TRUE;
    }

It is suspected that the stun_sock may no longer be valid when the callback is called, possibly because it has been destroyed. A more general synchronization fix is currently being developed, therefore this is considered as a workaround.

Thank you Itay Bianco for the report.

According to this report:

There seems to be a deadlock between destroy_transport() in sip_transport.c and tcp_init_shutdown() in sip_transport_tcp.c. In destroy_transport() the mutex tp->lock is acquired but not released until it’s destroyed in tp->destroy(tp)

On the other hand tcp_init_shutdown() is calling to pjsip_transport_shutdown() which acquires that same mutex which will never get released.

Maybe tcp_init_shutdown() shouldn’t do anything if the transport is already being destroyed?

The proper solution for this problem is to replace the locking mechanism in the SIP transport with group lock. For now, we just implemented the workaround by checking if destroy is currently in progress as suggested above.

The PJLIB's Win32 version of platform_strerror() may write data outside the buffer (on buffer[-1] location to be precise) when the function is unable to retrieve the error string using FormatMessage function.

This is caused by the function naively assumes that snprintf will never return negative value:

 len = pj_ansi_snprintf(buffer, bufsize, ...);
 buffer[len] = '\0';

Using IoCompletionPort (IOCP) ioqueue backend, which is the default backend on Win32 on Release build, may lead to write access to memory area that has been freed before. This potentially could crash the application, or random memory corruption.

This symptom can be detected with Visual Studio 2005 (but not with Visual Studio 6).

Explanation about this bug is as follows.

1. When socket is closed, Windows automatically unregisters the socket from the IOCP. Any pending operations to the socket are also cancelled.
2. But when the next time the IOCP is polled with GetQueuedCompletionStatus(), Windows would still report an event to the pending operations that have been cancelled above.
3. If the memory that corresponds to the WSAOVERLAPPED structure that was registered for the asynchronous operation has been freed (for example, the pool is released), Windows will write some values to these area that was previously occupied by the WSAOVERLAPPED structure.

There are few problems with the Contact URI generated by PJSUA-LIB when TLS transport is used:

• the URI uses sips scheme, which is not right, and some servers also have problems with dealing with this URI scheme
• the "transport=tls" parameter is missing

When strict route is used in the INVITE request, the CANCEL request will be sent with wrong Route and request URI (it contains Route and request URI that are already swapped).

There are some implementations that put no format list on disabled/rejected media, e.g:

m=audio 0 RTP/AVP
m=audio 2000 RTP/AVP 0

The SDP parser will return RTP/AVP\nm=audio for the transport of the first SDP media.

The internal SDP negotiator state will be in bad state if outgoing UPDATE or re-INVITE containing SDP is challenged with authentication, causing subsequent SDP negotiation mismatch (such as SDP is sent in ACK, or SDP in remote's response is mistakenly treated as offer).

In pjsip_calculate_branch_id() function in sip_util_proxy.c:335, the branch parameter for outgoing request is generated by calculating MD5 hash of the branch parameter of the incoming request. But unfortunately, the user agent being RTC, it does not conform to RFC 3261, and it leaves the branch parameter empty, causing the branch generation to always produce the same value.

When the PCM signal is in the rage -7 to -1 inclusive, wrong alaw value will be generated by the non-table version of pjmedia_linear2alaw() function.

Note that the table version of the function, which is the default implementation used by pjmedia, is not affected by this bug.

Currently, the bytes_per_frame in stream port info contains encoded frame size info, regardless if data flow from/to stream (via get_frame()/put_frame()) is encoded or raw data.

This may cause problem as any pjmedia ports may use bytes_per_frame info, e.g: resample port uses bytes_per_frame info of down stream port to calculate dynamic buffer size, and lesser buffer size may cause buffer overrun.

The original report can be found ​here.

Wrong call media state is reported if hold request is challenged with authentication. In this case, pjsua will report call media status as ACTIVE even if the call is successfully put on hold after the authentication retry. This is because the call's local_hold state is cleared the first time 401/407 response is received.

Thanks Bogdan Krakowski for the fix.

YV12 is defined as YUV planar 16bpp, while it should be YUV planar 12bpp, similar to IYUV/I420 just the U and V planes order is switched.

The stream should convert the jitter buffer parameters in the pjmedia_stream_info when calling pjmedia_jbuf_set_adaptive(). The parameters in pjmedia_stream_info are in milliseconds, while pjmedia_jbuf_set_adaptive() expect values in counts.

This is duplicate of ticket #730 for the 1.0.x branch. Please see ticket #730 for more info.

Reported that when an unregistration fails with 408, pjsua_reg_info.renew in on_reg_state2() callback is PJ_TRUE, while it should be PJ_FALSE. After investigation, it turns out that pjsua_reg_info.renew is evaluated by checking whether the current active registration interval value (of a successful registration) is non-zero. As the unregistration has just failed, the inteval value is still a possitive number, hence pjsua_reg_info.renew value in the unregistration callback is PJ_TRUE.

Thanks Nadia Lapkovskaya for the report.

When only host candidates are used, PJNATH may select the wrong IP interface to be used as the default candidate address. This may cause some problem with media, for example on Symbian (3rd edition MR or plain), IP 169.x.x.x is selected.

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

This is duplicate of ticket #757 for the 1.0 branch.

Quoting Guido's post on the list:

"There seems to be a bug in "rtcp.c". The rtt-time was faulty at some point and a few times, when enabling the trace in rtcp.c, I got "Internal RTCP NTP clock skew detected"-failures (time now < time of lsr).

In my understanding the problem is in pjmedia_rtcp_get_ntp_time:

   /* Calculate seconds fractions */
   ts.u64 %= sess->ts_freq.u64;
   pj_assert(ts.u64 < sess->ts_freq.u64);
   ts.u64 = (ts.u64 << 32) / sess->ts_freq.u64;

When calculating ntp->hi, this is done hooked on its base (ts.u64 - sess->ts_base.u64). I think this should also be done when calculating the fractions.

   /* Calculate seconds fractions */
   ts.u64 = (ts.u64 - sess->ts_base.u64) % sess->ts_freq.u64;
   pj_assert(ts.u64 < sess->ts_freq.u64);
   ts.u64 = (ts.u64 << 32) / sess->ts_freq.u64;

Worked fine for me. No more clock skews and noticeable rtt-time failures."

Kudos Guido Fischer for fixing this two and half year old bug!

This is duplicate of ticket #696 for the 1.0 branch. Please see ticket #696 for more info.

This is a duplicate of ticket #753 for 1.0 version branch.

The report can be found ​here.

Windows Mobile devices when hooked to ActiveSync uses IP address 169.254.2.x for the hostname and default route (implicitly this means that this address is also returned by IP interface enumeration function).

This would cause this address to be returned by PJLIB's pj_gethostip() even when there is another valid and better IP address returned by the interface enumeration function (for example, valid Wi-Fi address).

Bug in pjsua_call_update() API causes is to behave differently than pjsua_call_reinvite() in relation to call hold. With pjsua_call_update(), the default flags will cause call hold to be released, while with pjsua_call_reinvite() application has to explicitly specify PJSUA_CALL_UNHOLD to release hold.

This ticket changes the behavior of pjsua_call_update() to make it behave uniformly as pjsua_call_reinvite().

Unfortunately this breaks compatibility with existing application. Now if application wants to release call hold with pjsua_call_update(), it must specify PJSUA_CALL_UNHOLD in the options argument.

Note: This was created in android branch and has never been ported to the trunk. This app was superseded by pjsua for android cli app.

• Move the AVI playback from pjmedia-test to new aviplay.c sample application
• Take the input file from cmdline
• Synchronize audio and video
• Remove all codecs related hardcodes from the file

When contact_use_src_port option (see #1677) is enabled, pjsua will try to acquire transport in order to get the source port. However, since tdata is not passed for the transport acquire, later TLS server certificate matching will be done based on the IP address, instead of remote host name. This results in server certificate verification failure.

The iLBC codec provided by third party is very CPU-intensive on iPhone devices, so we need to implement iLBC codec framework using iPhone OS' supplied iLBC codec.

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

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

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

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

Thanks to Christian Hoff for the report and patch.

Important: The proper fix for this ticket is available in ticket #1893, which belonged to release 2.5.

This is related to #1482 point 2 (spurious wakeups problem after TCP disconnection).

Scenario:

1. Registration for account A is in progress, and DNS is in the process of resolving the hostname, hence TCP transport is not created yet and account transport (pjsua_acc.auto_rereg.reg_tp) is set to NULL.
2. Transport eventually gets created, but account transport is not updated.
3. Transport disconnection occurs, normally pjsua will release the disconnected transport from the account, however as transport pointer of account A is NULL, pjsua fails to detect and release it immediately.
   • Note that the transport stays not released/destroyed until a new registration by account A (using a new transport) is issued or the account is deleted.

This is related to #1482 point 2 (spurious wakeups problem after TCP disconnection).

Scenario:

1. Registration for account A is in progress, and DNS is in the process of resolving the hostname, hence TCP transport is not created yet and account transport (pjsua_acc.auto_rereg.reg_tp) is set to NULL.
2. Transport eventually gets created, but account transport is not updated.
3. Transport disconnection occurs, normally pjsua will release the disconnected transport from the account, however as transport pointer of account A is NULL, pjsua fails to detect and release it immediately.
   • Note that the transport stays not released/destroyed until a new registration by account A (using a new transport) is issued or the account is deleted.

Log:

14:14:35.020    pjsua_acc.c  .Acc 2: setting registration..
14:14:35.022     resolver.c  ...Transmitting 41 bytes to NS 0 (8.8.8.8:53): DNS SRV query for _sip._tcp.sip.pjsip.org: Success
14:14:35.022    pjsua_acc.c  ..Setting acc 2 reg_tp to NULL
14:14:35.022    pjsua_acc.c  ..Acc 2: Registration sent
...
14:14:35.102 tcpc0x1694de14  TCP client transport created
14:14:35.103 tcpc0x1694de14  TCP transport 192.168.1.2:51801 is connecting to 208.109.222.137:5060...

Which will cause this to happen:

10:51:40.669     ioq_select  Attempting to replace UDP socket 4
10:51:40.671     ioq_select  UDP has been replaced successfully!
10:51:40.671     resolver.c  DNS resolver read error from 8.8.8.8:53: Socket is not connected
10:51:40.671 tcpc0x15b99614  TCP connection closed
10:51:40.672    pjsua_app.c  SIP TCP transport is disconnected from [208.109.222.137:5060]: End of file (PJ_EEOF) [status=70016]
10:51:40.672    pjsua_acc.c  Disconnected notification for transport tcpc0x15b99614
10:51:50.694     ioq_select  Attempting to replace UDP socket 4
10:51:50.694     ioq_select  UDP has been replaced successfully!
10:51:50.694     resolver.c  DNS resolver read error from 8.8.8.8:53: Socket is not connected
...
10:52:00.707     ioq_select  Attempting to replace UDP socket 4
10:52:00.708     ioq_select  UDP has been replaced successfully!
10:52:00.708     resolver.c  DNS resolver read error from 8.8.8.8:53: Socket is not connected

[it will go on, and on, ....., and eventually, it will crash below]

10:54:00.840     ioq_select  UDP has been replaced successfully!
10:54:10.843     ioq_select  Attempting to replace UDP socket 4
10:54:10.845     ioq_select  UDP has been replaced successfully!
10:54:10.845     resolver.c  DNS resolver read error from 8.8.8.8:53: Socket is not connected
10:54:10.845     ioq_select  Attempting to replace UDP socket 7
10:54:10.845     ioq_select  UDP has been replaced successfully!
(lldb)

If the transport is released correctly, what you should be seeing in the log is:

12:58:14.836 tcpc0x153b4214  TCP connection closed
12:58:14.836    pjsua_app.c  SIP TCP transport is disconnected from [208.109.222.137:5060]: End of file (PJ_EEOF) [status=70016]
12:58:14.836    pjsua_acc.c  Disconnected notification for transport tcpc0x153b4214
12:58:14.847 tcpc0x153b4214  TCP transport destroyed with reason 70016: End of file (PJ_EEOF)

Notice the log saying that the TCP transport has been destroyed. If such message is missing from the log, the first step is to check whether app is still holding a reference to the particular transport.

This ticket creates OpenGL 2 framework to be used by other platforms and provides implementation for iOS with OpenGL ES version 2.

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.

If application is brought back from background mode while network connectivity (3G and WiFi) is down, sending UDP packets will fail with "No route to host" error. This will cause subsequent calls to have no audio, even after restoring network connectivity before establishing the call.

The solution for this is to restart PJSIP once network connectivity is established.

The ability to execute code in the background is not supported on all iOS-based devices. Even devices running iOS 4 or later may not have the hardware to support multitasking. To determine whether the feature is available, we need to use the multitaskingSupported property of the UIDevice class.

Apple iOS4 has added new feature to put application in "background mode", where the state of the application is suspended but it's able to record&play audio and receive TCP frames.

This ticket adds support for this feature.

There were a couple of reports saying that echo cancellation works fine using SDK 3.x but doesn't work properly when using SDK 4.x. (on devices running iOS 3.x and 4.x).

This ticket investigates whether there is a problem with EC using SDK 4.x, and if possible, finds a way to solve it.

Note: using speaker mode is recommended to test the EC.

When compiling using iOS SDK 4.x, the echo cancellation and support for Bluetooth input do not work properly. This is related to ticket #1113.

Call to AudioConverterNew() for the iLBC codec may take long time to complete, causing timeout in acquiring pjsua lock (when doing get call info on incoming call).

This happens on iPhone 3GS with iOS 4.0.2 and SDK 4.0.

As has been reported in ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-November/013692.html, iOS 5 will kill an application if it wakes up more than 15 times in 300 seconds. Below is a typical stack trace for the "crash" event:

Exception Type:  00000020
Exception Codes: 0xbad22222
Highlighted Thread:  1

Application Specific Information:
SBUnsuspendLimit myapp[346] exceeded 15 wakes in 300 sec

There are several other discussions on the Apple's developer forum:

• ​https://devforums.apple.com/message/574557
• ​https://devforums.apple.com/message/566555
• ​https://devforums.apple.com/message/565667

This ticket provides several tips that may help avoiding the situation.

1. Use a background task to ensure that the app doesn't suspend immediately after being waken up. App most likely will need to send something when it is waken up, for example some requests or TCP keep-alive data. Chances are these data will be responded by the server. If the app immediately gets suspended after sending them, it will be waken up again when the response arrives, hence adding to the wake up count. The app should delay as much as iOS allows before it goes to suspended state again, to take care the fact that some requests do take a while to complete, for example due to authentication.

2. Fixing spurious wakeups problem. It has been reported that iOS may wake up the application every 10 seconds even when there is no activity in the network. This has been correlated to TCP transport disconnection, i.e. once the TCP transport is disconnected the app starts to get waken up every 10 seconds even when Wireshark shows no activity at all. This issue seemed to have been fixed by #1465 and #1481, which now immediately close (or to close sooner) the TCP socket when it gets disconnected. If the app also holds a reference to the TCP transport, it should also release this reference once it gets the TCP disconnection notification (on the on_transport_state() callback), because the transport will only be destroyed once it's reference goes to zero.

UDP sockets are reset by iOS when the app goes into background mode. PJLIB handles this by detecting the error when receive event is set and recreating the sockets accordingly. This feature was added by ticket #1107.

Unfortunately sometimes it's the sending operation that comes first after the app is woken up, and since the UDP socket is in a bad state, this will cause the sending operation to fail. This will cause errors similar to these:

17:35:40.120 stuntsx0x9de55  STUN error sending message: Broken pipe
17:35:40.120 stuntp0x33b920  Error sending STUN request: Broken pipe
17:35:40.121 stuntp0x33b920  Session failed because STUN Binding request failed: Broken pipe
17:35:40.121        icetp00  STUN binding request failed: Broken pipe
17:35:40.121 stuntsx0xa17b5  STUN error sending message: Broken pipe
17:35:40.122 stuntp0x33af00  Error sending STUN request: Broken pipe
17:35:40.122 stuntp0x33af00  Session failed because STUN Binding request failed: Broken pipe

This ticket will fix the sending error by recreating the UDP sockets if the sending operation fails after waking up from background mode.

Add native support for ipjsua on Ipad so that ipjsua does not need to run in compatibility mode on iPad.

Create a GUI frontend for pjsua application on iPhone OS

Create a GUI frontend for pjsystest on iPhone OS

on_create_media_transport() callback can be called prior to on_incoming_call().

If this happen on PJSUA2 API, onCreateMediaTransport() will not be called since the call is not created yet.

This ticket will call on_incoming_call() first when on_create_media_transport() is executed on PJSUA2 API.

When call has been disconnected, the Call object is no longer associated with the call id. Thus, the onStreamDestroyed callback will not be called.

Scenario:

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

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

Thanks to Joshua Elliott for the report.

Currently if IP address is inputted, it will simply return back the IP address. This behaviour is introduced by ticket #458 for tackling issues on Windows Mobile with no network connection.

Unfortunately, the behaviour may cause IPv4 -> IPv6 address resolution fails on Apple platforms:

If your app needs to connect to an IPv4-only server without a DNS hostname,
use getaddrinfo to resolve the IPv4 address literal. If the current network
interface doesn’t support IPv4, but supports IPv6, NAT64, and DNS64,
performing this task will result in a synthesized IPv6 address.

Thanks Johan Lantz for the report.

This is copy of ticket #150 for trunk.

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.

This is because pj_getsockname() is called without checking first if the "local" parameter is specified.

On Linux, when pjsip_endpt_handle_events() is given NULL as the timeout parameter, it will cause pj_ioqueue_poll() to block forever even when there is incoming packet on the socket.

This happens because select() is given a large or probably negative usec value in timeval argument.

Thanks Igor S for spotting the problem.

This is copy of ticket #144 for trunk.

The common pattern to release pool:

  pj_pool_t *tmp_pool = obj->pool;
  obj->pool = NULL;
  pj_pool_release(tmp_pool);

should go into an API:

  pj_pool_safe_release(pj_pool_t **p_pool);

Thanks Bogdan Krakowski for suggestion.

See the discussion in ​http://www.pjsip.org/pipermail/pjsip/2007-August/004183.html

Error log:

pjlib-test error:
 19:24:28.914 Running select_test()...
 19:24:28.916 ...Testing simple UDP select()
 19:24:28.917 ..ERROR(-70)

The select() returns immediately with *only* write-fdset is set (while the test also expects that read-fdset is set). So perhaps it is just that the system hasn't got time/context to deliver the packet, since select(), with write-fdset included, is called directly after sendto().

Experiments:

• inserting pj_thread_sleep(1) between sendto() & select(): OK
• inserting pj_thread_sleep(0) between sendto() & select(): failed
• inserting PJ_LOG() between sendto() & select(): OK

The corresponding ticket for 1.0.x is #908

This is a duplicate of ticket #890 for 1.0.x branch

Test log:

pjlib-test (exception and pool tests are disabled), error:
 01:04:12.744 Running timer_test()...
 01:04:22.615 ERROR: 27 timers left
 01:04:22.629 ..ERROR(1)

(after few more tries, timer test always failed, timer left was around 30)

The corresponding ticket for 1.0.x branch is #900

This is duplicate of ticket #893 for 1.0.x branch

QA report:

only run pjlib-test, found problem:

first run:
---
 23:32:28.571 Running udp_ioqueue_unreg_test()...
 23:32:28.571 ..testing with concurency=1
 23:32:28.571 ...ioqueue unregister stress test 0/3 (select)
 23:32:29.587 ....repeat 0/10: done (210 KB/s)
 23:32:30.613 ....repeat 1/10: done (207 KB/s)
 23:32:31.640 ....repeat 2/10: done (207 KB/s)
 23:32:32.657 ....repeat 3/10: done (209 KB/s)
 23:32:33.682 ....repeat 4/10: done (206 KB/s)
 23:32:34.709 ....repeat 5/10: done (206 KB/s)
 23:32:35.720 ....repeat 6/10: done (213 KB/s)
 23:32:36.731 ....repeat 7/10: done (209 KB/s)
Bus error
---

second try, it seemed to stuck (more than 12 minutes) at:
---
 23:36:14.558 Running udp_ioqueue_unreg_test()...
....
 23:36:55.235 ..testing with concurency=0
 23:36:55.235 ...ioqueue unregister stress test 0/3 (select)
 23:36:56.262 ....repeat 0/10: done (207 KB/s)
 23:36:57.272 ....repeat 1/10: done (207 KB/s)
----

third try, error (same as first try)
 23:52:39.335 Running udp_ioqueue_unreg_test()...
 23:52:39.335 ..testing with concurency=1
 23:52:39.335 ...ioqueue unregister stress test 0/3 (select)
 23:52:40.363 ....repeat 0/10: done (207 KB/s)
 23:52:41.373 ....repeat 1/10: done (209 KB/s)
 23:52:42.390 ....repeat 2/10: done (208 KB/s)
 23:52:43.406 ....repeat 3/10: done (207 KB/s)
 23:52:44.423 ....repeat 4/10: done (206 KB/s)
 23:52:45.432 ....repeat 5/10: done (209 KB/s)
 23:52:46.440 ....repeat 6/10: done (209 KB/s)
 23:52:47.450 ....repeat 7/10: done (208 KB/s)
Bus error

The corresponding ticket for 1.0.x is #899

This is duplicate of #891 for 1.0 branch

Creating pjmedia_clock always create background thread, regardless the PJMEDIA_CLOCK_NO_ASYNC options set or not.

A thin wrapper for codec operations to make the API slightly cleaner.

to save:

• the jitter buffer
• RTCP stat

Log:

pjnath-test error (tried few times, same errors):
 21:55:11.891   draft-denis-behave-rfc3489bis-test-vectors-02
 21:55:11.891     Running test 0/3
 21:55:11.891     Running test 1/3
 21:55:11.891     Running test 2/3
 21:55:11.891     Message mismatch at byte 42
 21:55:11.891 ..ERROR(-1060)

Test log:

pjnath: 14:22:57.065 Running ice_test()...
 14:22:57.065     Basic with host candidates
 14:22:58.186     Basic with host candidates, 4 components
 14:22:58.199     err: pj_ice_strans_start_ice(): [pj_status_t=70010] Too many objects of the specified type (PJ_ETOOMANY)
 14:22:58.699 ..ERROR(-120)

PJSIP tries to unescape the SIP message component that is declared by the test program in read-only segment, causing bus-error and core dump.

Thanks Michael Broughton for the report.

This is duplicate of ticket #704 for the 1.0 branch.

The pjsip_ctype_hdr_clone() doesn't duplicate the media subtype.

Thanks Igor S for reporting.

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

The correct behavior should be for pjsip_regc_unregister() to unregister only contact(s) that was registered by this endpoint only.

pjstun_get_mapped_addr() is the function to resolve the mapped STUN address for given sockets. This is an old/simple STUN implementation in pjlib-util, and is different than the STUN implementation in pjnath.

When pjstun_get_mapped_addr() is called to resolve local SIP socket, and when at the same time other SIP endpoint sends SIP request to pjsip, this function will fail with WSAEMSGSIZE error, because the SIP request is larger than the expected STUN response.

A new pjsua application with command line interface (CLI) framework. This one application will be able to run on ALL platforms.

Integrate pjsua2 works on SVN pjsua2 branch into SVN trunk.

A new object oriented (C++) API on top of PJSUA-LIB. Currently lives in pjsua2 branch.

A sample case is when modifying SIP account ID with very long ID, pjsua_acc_modify() will try to re-register the account, however the re-registration initiation fails:

Unable to generate suitable Contact header for registration: Size is too short (PJ_ETOOSMALL) [status=70019]
Unable to create registration: Size is too short (PJ_ETOOSMALL) [status=70019]

while pjsua_acc_modify() still returning PJ_SUCCESS.

Thanks Alexander Fatyanov for the report.

When user makes calls pretty rapidly, he will get:

The problem happens because if a call hasn't created an invite session, its call id can still be allocated to another call.

Issues reported:

• No re-registration after updating registration timeout.
• If manual re-registration is performed, still the SIP REGISTER message doesn't use the new timeout setting.

Original report can be found ​here.

The pjsua_transport_close() function in PJSUA-API doesn't handle TLS transport case. Thanks Alain Totouom <alain.totouom at gmx de> for reporting this.

Reported that the implementation doesn't support SIP TLS transport (PJ_EINVALIDOP is returned and it may trigger assertion). This is specially needed as pjsua_transport_get_info() is automatically invoked when creating the transport using the python wrapper.

Original report+patch can be found ​here.

The ioqueue->default_concurrency (boolean) is never initialized for socket ioqueue. This shouldn't be a major problem, since if application wants to explicitly disable concurrency it will set the setting manually.

Some problems were reported on Windows platforms on various PJ_SOL_xxx constants that is used by pj_setsockopt() and pj_getsockopt() functions:

1. PJ_SOL_IP is initialized with 0xffff if SOL_IP is not defined, for the reason that we thought it is not supported on Windows. A better alternative is to use IPPROTO_IP.

1. Similarly PJ_SOL_TCP and PJ_SOL_UDP are also initialized with 0xffff if IPPROTO_TCP/IPPROTO_UDP are not defined. Some users reported that on some Platform SDKs these constants are not declared as macro but rather as enum values, causing them to be reverted back to 0xffff value.

sipecho application loops back peer's media (audio and/or video), and supports call hold too. It also works as a simple registrar, if peer needs it.

When -1 is specified as device ID, sndtest will correctly select the default device on the platform but it doesn't display the correct device in the log.

When a new render window (either preview or stream) is created and currently another render window is active, sometime both rendering processes got stuck. After manually resizing main window, all rendering processes continue normally.

The problem only occurred on Windows, Mac is unaffected.

Stopping capture preview may cause main window to get hidden unexpectedly. Reported to happen on Mac only.

• Either extend existing stream.c to support video, or create a new vstream.c.
• Use vstreamutil.c as demo.

There is already video stream implementation in the stream.c and sample in the vstreamutil.c, however it's just proof-of-concept version, so the to do/consider list will be:

• proper picture bitstream generation from RTP packet, currently the video stream will just 'concatenate' incoming RTP to get a complete picture bitstream, and everytime it got end-of-picture flag, RTP header m==1, push the picture into jitter buffer, so in case of unordered RTP the picture bitstreams will be truncated
• perhaps jitter buffer frame content/granularity should be RTP payload instead of a picture bitstream (picture bitstream will be generated right before decoding, instead of inline with incoming RTP packets), however current jitter buffer only has RTP sequence (no RTP timestamp), so need to research if the current jitter buffer fits this requirements along with optimization consideration (e.g: frame size, minimal memcpy)
• audio-video sync
• encoder & decoder size can be different, e.g: remote endpoint, which is an embedded/mobile, only supports QCIF while local endpoint, which is desktop, prefers CIF, so the issues will be:
  • which size should be put in the stream info (as currently it only has one 'format info' field)?
  • the decoder output format (e.g: format id & size) can only be ensured after a successful picture decoding (the format setting in opening the decoder is rather unusable and the local SDP may offer multiple sizes), need a way to notify application about the active format.