Custom Query (2195 matches)

Modify the echo cancellation framework as follow to make it easier to integrate with new echo cancellation backends, and to generally improve it. These changes should be backward compatible.

• Support for multi-channel echo cancellation:
  • Add new API to specify channel count
  • Modify EC backends to support multi-channel EC (latest Speex AEC supports this)
• Change the semantic of options flag when creating the EC, to allow application to choose which EC backend to use when there are multiple backend algorithm.
• Move the latency compensation functionality from Speex EC (echo_speex.c) to the generic EC framework (echo_common.c) so that it can be reused by other backends.
• Since the common EC framework now does the buffering, remove the ec_playback() and ec_capture() internal API from the backends. The backends now only need to supply ec_cancel() API, which is simpler, and this opens support for more backends.
• Add new reset API.
• Modify the aectest.c to work with WAV files instead of live recording. This would make it easier to test.

In the TURN client sample application, when STUN server is specified (with -S option), previously the application will contact the STUN server using the port that is specified for the TURN server.

When the destination URI of pjsua_call_make_call() is not valid, an error is printed:

  09:46:56.216   pjsua_call.c Unable to generate Contact header: Invalid URI 
(PJSIP_EINVALIDURI) [status=171039]

This is misleading since the invalid URI is in the destination URI, not the Contact URI.

Several enhancements on the presence body handling:

• include the full parsed XML tuple in pjsip_pres_status structure, as it may contain additional information for the application
• include pjsua_pres_status in pjsua_buddy_info so that this information is accessible by PJSUA-LIB application.
• add timestamp info in the outgoing PIDF. There may be case when subscriber receives PIDF with multiple tuples, and in this case it can use the timestamp to decide which tuple to use.
• also when we receive NOTIFY with empty body, notify the application about the event, keep the presentity status unchanged, but set the tuple pointer in pjsip_pres_status structure to NULL.

Incoming CANCEL request currently is not reported in any callbacks, not even on_tsx_state() (or on_call_tsx_state() in pjsua). This makes it impossible for application to review some headers in the request, most notably the Reason header (RFC 3326).

This happens because CANCEL is responded automatically by the INVITE session (including generation of 487 to INVITE), and due to how the flow is arranged, application will see the 200/OK response to CANCEL first in the callback, and then 487 to INVITE, before the CANCEL request itself. But pjsua application will not see the CANCEL request at all because by the time the CANCEL request is reported, call has been disconnected and further events from the INVITE session has been suppressed.

When an OPTION request arrives while PJSUA-LIB is being shutdown, it may trigger assertion error depending on the timing of the request. This is because the media endpoint has been destroyed.

The assertion:

*** ASSERTION FAILED in ..\src\pjmedia\endpoint.c(304):
endpt && pool && p_sdp && stream_cnt

Thanks Johan Lantz for the report.

When SDES is configured with higher priority (which is the default setting), it will have the first chance to process the incoming SDP. Unfortunately when SDES cannot find SDP a=crypto line in the remote offer, it will disable the SDP media line.

Thanks to Jeff Anderson for the report.

Scenario:

1. In SRTP mandatory mode, call established with 2 media: active audio with SRTP enabled and inactive video (port 0).
2. Remote send re-offer with three SDP media lines: audio with RTP/SAVP+crypto, deactivated video (port 0) with RTP/SAVP without crypto, audio with RTP/AVP without crypto.
3. We reject the re-INVITE with 488 (actual error code PJMEDIA_SRTP_ESDPREQCRYPTO).

It should not be rejected as the first media in the reoffer is actually acceptable.

From accept() manual: There may not always be a connection waiting after a SIGIO is delivered or select(2) or poll(2) return a readability event because the connection might have been removed by an asynchronous network error or another thread before accept() is called.

In iOS4, the problem is reproducible by putting the app to BG and locking the device, hence causing iOS4 to close all connections. When application is brought back to the FG, select() always returns a readability event while accept() always fails with EAGAIN error.

There was a report that the problem happened in Sun Solaris OS as well.

An incoming re-INVITE request will be ignored/unhandled if it is received while the invite session is in CONNECTING state (i.e. waiting for ACK from peer).

The correct behavior according to RFC 5407 (section ​3.1.4) is as follows:

• if the current offer-answer has completed, the re-INVITE should be accepted with 200/OK.
• if the current offer-answer is still pending (i.e. we're waiting for an answer in the ACK), the re-INVITE must be answered with 491/Request Pending.

Unfortunately if we answer the re-INVITE with 200/OK, we will have two pending invite transactions, and we don't support that. Hence the solution that this ticket implements is to always answer with 491 for such re-INVITE.

The pjsip sip_dialog.c correctly updates the dialog target URI upon receiving 2xx response of an outgoing target refresh request, but it does not update the dialog target URI upon receiving the incoming target refresh request.

Modifying pjmedia_vid_codec_param.enc_mtu should not affect video quality in the decoding direction.

The implementation problem is related to different perceptions of TX & RX direction between pjsua-lib and pjsua2. In pjsua-lib, TX & RX directions are seen from conference bridge point of view, while in pjsua2, they are seen from media port point of view.

For example in AudioMedia::adjustRxLevel(), the "Rx" there means audio flow from conference bridge to AudioMedia object, and it actually corresponds to pjsua_conf_adjust_tx_level() in pjsua-lib (notice the "tx").

Decoding fmtp is not removed even though Opus config has been changed.

After app calls pjmedia_codec_get_default_param() which will generate default decode fmtp as well, changing the config by calling pjmedia_codec_opus_set_default_param() currently can only add/change the fmtp, but not remove the ones that are not necessary. For example, enabling CBR, then disabling it, will still have the fmtp "cbr=1".

Several bugs with DTMF event/RFC 2833 packet generation:

1. PJSIP fails to set the SDP Marker flag to TRUE on the very first packet of each sequence as requested by RFC 2833 section 3.4.
2. RTP time stamp in the RTP EVENT packets should remain the same for a single event, according to RFC 2833 section 3.6:

"If an event continues for more than one period, the source generating the events should send a new event packet with the RTP timestamp value corresponding to the beginning of the event and the duration of the event increased correspondingly."

Currently, pjsua will answer such call unhold request with "inactive" attribute, regardless the direction specified in the offer. While the expected answer should maintain the local hold and be also based on the direction specified in the offer:

For devices with back cameras (which face away from the user), the direction of the rotation will differ from the user's perspective (for example, a 90 degree clockwise rotation of the back camera will be perceived by the user as a 270 degree clockwise rotation). So we need to make sure that the spec and behaviour are consistent.

Also, when fast switching video capture (normally done between front and back cameras), make sure that the correct orientation is set. Thanks to Mayur Joshi for the report on the second problem.

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

Thanks to George Joseph and Asterisk team for the report.

The table based CRC32 calculation is incorrect, and this error is detected by pjlib-util.

The duplicated ticket for 1.0 branch is ticket #752

This is duplicate of ticket #751 for 1.0 branch.

From ​https://tools.ietf.org/html/rfc5245#section-15.4

This means that the ice-ufrag
  attribute will be at least 4 characters long, and the ice-pwd at
  least 22 characters long

This ticket will also separate the compile time settings for ice-ufrag length (default still 8) and ice-pwd length (default is 24).

The existing default (2000) is no longer enough for most things.

Please see Socket operation send/receive returning PJ_ECANCELLED/KErrServerBusy entry in the FAQ for the description of the problem.

Application should follow the solution as described by the FAQ. However, often applications still rely on the default initialization done by PJLIB, causing the problem to emerge.

This ticket increases the aMessageSlots value when calling RSocketServ::Connect(aMessageSlots) to 32, via a configurable compile time constant PJ_SYMBIAN_SOCK_MSG_SLOTS.

Ticket #277 had pointed out that guid_simple.c can only generate 2¹⁶ bit of randomness in the GUID values. Although there is a workaround to use libuuid to replace it, this may not be available on all platforms, hence it needs to be fixed.

Also reported that some devices may not support all APS codecs, e.g: 6120 only supports AMR-NB and the initialization failure was caused by the usage of unsupported codec.

Steps to reproduce with pjsua sample app:

1. run pjsua (that uses switchboard) with option "--ptime=60 --clock-rate=8000"
2. connect ring/ringback port to sound device port, e.g: "cc 2 0"
3. make call with codec that uses 8000Hz/20ms/mono

TURN session will not destroy itself after TURN allocation request fails immediately (e.g: due to network unreachable), instead it will just revert back the TURN session state to PJ_TURN_STATE_RESOLVED. While in this state, the TURN socket will simply restart the TURN allocation (so the TURN session state becomes PJ_TURN_STATE_ALLOCATING). Unfortunately this TURN allocation will fail immediately (the same way as described initially, due to network unreachable), and that is how the infinite loop of RESOLVED-ALLOCATING happens.

Thanks Nir Lavi for the report.

Adding new media, for example adding video, will take some time if ICE and STUN are enabled because it needs to wait for STUN resolution to complete. The waiting takes place in pjsua_handle_events() loop in create_ice_media_transport() in pjsua_media.c

If a re-INVITE arrives during this period, it will reset the call media states, thereby preventing the loop above from completing.

PJSIP periodically transmit "ping" packet with TCP/TLS, and relies on socket failure to detect failed connection with the server. However it has been reported that some firewall doesn't forward data to PJSIP, but at the same time it also doesn't terminate the connection.

Some applications want to be able to monitor incoming packet statistics in order to determine if the connection is still good.

Thank you Johan Lantz for the suggestion.

Initial support for BlackBerry 10 (BB10) platform. Patches donated by ​TruPhone

In OpenSSL 1.1.0 the ephemeral ECDH is already initialized in automatic mode, so there is really no need to do anything explicit about it.

=== begin citation ===
*) SSL_{CTX_}set_ecdh_auto() has been removed and ECDH is support is
     always enabled now.  If you want to disable the support you should
     exclude it using the list of supported ciphers. This also means that
the
     "-no_ecdhe" option has been removed from s_server.
https://www.openssl.org/news/changelog.html#x10
=== end citation ===

The code in ssl_sock_ossl.c falls to branch initializing only prime256v1 (aka secp256r1) elliptic curve in the context, after the call SSL_CTX_ctrl(ctx,94,1,NULL) is unsuccessful with OpenSSL 1.1.0x. When using server certificate with EC key based on any other curve, the listener fails TLS negotiation with misleading alert "no shared cipher", because the context's curve set applies to both EECDH and ECDSA. (Certificates with RSA keys work well.) Also, the EECDH itself is limited to use the only (from today's perspective the weakest acceptable) curve for key negotiation.

Thanks to Tzafrir Cohen for the patch.

With default H264 codec settings, i.e: level=3.0 and size=720x480, when receiving video with resolution 704x576, there will be no incoming video shown and repeated error messages in the log:

Error: not enough buffer for decoded frame (supplied=x, required=y)
codec decode() error: Size is too short (PJ_ETOOSMALL) [err:70019]

Initially, it is the application that should set the expected maximum size of the incoming video via H264 codec param, as described in this wiki. However, since #1622, the lib is equipped with such auto-adjust mechanism if the configured size is too small, unfortunately there is a bug in the auto-adjustment code, as described in ​the original report, this ticket should fix this bug.

Thanks Bill Gardner for the report.

​RFC 3261 20.19 specifies the Expires header field to be between 0 and 2³²-1 seconds, but currently in sip_msg, we use the value of (signed) int. This is also applicable for Min-Expires header field, and Expires parameter of Contact header.

The following struct fields and APIs will change (all changes are from signed 32-bit integer to unsigned):

• pjsua2:
  • AccountInfo.regExpiresSec
  • OnRegStateParam.expiration

• pjsua:
  • pjsua_acc_info.expires

• pjsip:
  • pjsip_contact_hdr.expires
  • pjsip_generic_int_hdr.ivalue/ pjsip_expires_hdr.ivalue/ pjsip_min_expires_hdr.ivalue/ pjsip_max_fwd_hdr.ivalue
  • pjsip_regc_info.interval
  • pjsip_regc_info.next_reg
  • pjsip_regc_cbparam.expiration
  • pjsip_generic_int_hdr_create()/ pjsip_generic_int_hdr_init()/pjsip_expires_hdr_create()/ pjsip_expires_hdr_init()/ pjsip_min_expires_hdr_create()/ pjsip_min_expires_hdr_init()/ pjsip_max_fwd_hdr_create()/ pjsip_max_fwd_hdr_init()

• pjsip-simple:
  • pjsip_sub_state_hdr.expires_param
  • pjsip_publishc_cbparam.expiration
  • pjsip_pres_initiate()
  • pjsip_mwi_initiate()
  • pjsip_evsub_initiate()

IMPORTANT! Backward compatibility issue:

• Any sign comparison of the above expiration fields MUST be modified, for example: expires < 0 should be changed to expires == PJSIP_EXPIRES_NOT_SPECIFIED.
• Direct setting/comparison with -1 should still work, for example: pjsip_pres_inititate(sub, -1, ...) or expires == -1. This is because PJSIP_EXPIRES_NOT_SPECIFIED == (unsigned) -1. Nevertheless, for future compatibility, it is recommended to change any -1 to PJSIP_EXPIRES_NOT_SPECIFIED.

Integrate tables based G.711 encoding/decoding

Based on ITU-T Recommendation G.722.1 (05/2005) C fixed point implementation including its Annex C.

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

Stack trace:

14 X11_SetWindowGammaRamp() /home/bennylp/Desktop/opt/src/SDL-git/src/video/x11/SDL_x11window.c:930 0x00007ffff7baf8e4	
13 SDL_OnWindowFocusLost() /home/bennylp/Desktop/opt/src/SDL-git/src/video/SDL_video.c:1897 0x00007ffff7b9c377	
12 SDL_SendWindowEvent() /home/bennylp/Desktop/opt/src/SDL-git/src/events/SDL_windowevents.c:157 0x00007ffff7b45193	
11 SDL_SetKeyboardFocus() /home/bennylp/Desktop/opt/src/SDL-git/src/events/SDL_keyboard.c:612 0x00007ffff7b42833	
10 X11_DispatchEvent() /home/bennylp/Desktop/opt/src/SDL-git/src/video/x11/SDL_x11events.c:190 0x00007ffff7bab3c5	
9 X11_PumpEvents() /home/bennylp/Desktop/opt/src/SDL-git/src/video/x11/SDL_x11events.c:546 0x00007ffff7bab3c5	
8 SDL_PumpEvents() /home/bennylp/Desktop/opt/src/SDL-git/src/events/SDL_events.c:302 0x00007ffff7b3fe27	
7 SDL_WaitEventTimeout() /home/bennylp/Desktop/opt/src/SDL-git/src/events/SDL_events.c:335 0x00007ffff7b4031d	
6 handle_event() /home/bennylp/Desktop/project/pjsip/2.x/pjmedia/src/pjmedia-videodev/sdl_dev.c:328 0x00000000004d194c	
5 job_thread() /home/bennylp/Desktop/project/pjsip/2.x/pjmedia/src/pjmedia-videodev/sdl_dev.c:1246 0x00000000004d32a7	
4 thread_main() /home/bennylp/Desktop/project/pjsip/2.x/pjlib/src/pj/os_core_unix.c:512 0x000000000058b6ac	
3 start_thread()  0x00007ffff78f09ca	

Source code:

int
X11_SetWindowGammaRamp(_THIS, SDL_Window * window, const Uint16 * ramp)
{
    SDL_WindowData *data = (SDL_WindowData *) window->driverdata;
    Display *display = data->videodata->display;
    Visual *visual = data->visual;
    Colormap colormap = data->colormap;
    XColor *colorcells;
    int ncolors;
    int rmask, gmask, bmask;
    int rshift, gshift, bshift;
    int i;

    if (visual->class != DirectColor) {  <<<<==== CRASH HERE
        SDL_SetError("Window doesn't have DirectColor visual");
        return -1;
    }

Variables:

_this	0x0000000001786d30	
window	0x0000000001fd3a00	
ramp	0x00007fff0000000b	
data	0x0000000000000000	
display	0x0000000000000000	
visual	0x00004c45434e4143	
colormap	140737243578624	
ncolors	32767	
rmask	0	
gmask	0	
bmask	0	
rshift	0	
gshift	0	
bshift	0	

Currenly the cnonce value for SIP authentication is setup using GUID generator, i.e: pj_create_unique_string(), and the GUID string may contain hyphen character ("-").

Some SIP servers don't like this GUID format, so an option to enable digits only GUID is required.

This ticket will introduce new compiler setting PJSIP_AUTH_CNONCE_USE_DIGITS_ONLY to allow digits only used for cnonce.

Thank you to Dan Cropp for the report.

PJSUA-LIB will emit invalid (i.e. non-standard) Contact URI if the display name of the AOR contains reserved characters. For example, if this is the AOR:

"Lastname, Firstname" <sip:joe@example.com>

then the following Contact URI will be generated:

Lastname, Firstname <sip:joe@example.com>

Note the missing enclosing double quotes in the display name, which makes the URI invalid since the display name contains reserved character (i.e. comma).

The solution is to always enclose the display name of the generated Contact URI with double quotes.

See this mailing list archive: ​http://pjsip.org/pipermail/pjsip/2006-December/001608.html

According to this post, PortAudio? expects error codes to have negative values.

For example, we send and offer

v=0
o=- 234 123 IN IP4 192.168.1.1
s=-
c=IN IP4 192.168.1.1
t=0 0
m=audio 8510 RTP/AVP 111 0 101
a=rtpmap:111 SPEEX/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv

Then answer arrives:

v=0
o=user1 53655765 2353687637 IN IP4 192.168.1.2
s=-
t=0 0
c=IN IP4 192.168.1.2
m=audio 5000 RTP/AVP 112
a=rtpmap:112 dpeex/8000
a=sendrecv

This obviously is an invalid answer, but this answer is accepted by the SDP negotiator, i.e. the negotiation status is returned as PJ_SUCCESS.

Having said that, with PJSUA-LIB, this would still cause the call to be terminated, as the invalid SDP answer would cause other failure to occur further down the processing chain.

Running simpleua.c and siprtp.c samples on MacOS X give the following error:

 00:07:47.017     simpleua.c Unable to create media transport: Invalid argument [code=120022]

This was caused by invalid value in the address length argument given to pj_sock_bind().

It hasn't been updated to conform to the new audio device framework.

Scenario:

• we receive INVITE
• we send 200/OK with G.722.1 (pt=119) as the selected codec
• call is confirmed, media is OK
• we disabled all codecs except G.722 (pt=9)
• we send UPDATE
• we receive 401, we resend UPDATE
• we receive 200/OK for UPDATE, with G.722 codec (pt=9) in the answer
• at this point, we should be using G.722 codec (pt=9) in the media, but it looks like we're still expecting G.722.1:

  09:29:01.429  strm0x12ebca8  Bad RTP pt 9 (expecting 119)
  

In pjsua, when account ID is set to use name-addr format, it will cause the presence PIDF document to have "<" character in XML entity attribute, causing it to be rejected by server.

Example:

<?xml version="1.0" encoding="UTF-8"?>
<presence entity="<sip:user@domain>">
 <tuple id="72e49cd62c4943108f05fa2666a95a96">
  <status>
   <basic>open</basic>
  </status>
 </tuple>
</presence>

This is duplicate of ticket #135 for main trunk.

Thank you Jure Erznožnik for the suggestion.

AEC info will be added in pjsua_call_dump(). There's also a new API pjsua_get_ec_stat() to query the AEC statistics.

When an incoming SDP re-offer gets rejected by application in the on_rx_offer() callback so there is no SDP answer supplied by application and 488 response is generated, the SDP negotiator state will stay in REMOTE_OFFER, hence the subsequent re-offers will always be responded by 491 (request pending).

Reported that it is caused by the bug in handling error events in ioqueue epoll so the error events will never be cleared, and when the number of the unhandled error events reaches MAX_EVENTS_IN_SINGLE_POLL, any future events will never been processed/delivered to app by ioqueue epoll.

The issues occurs when:

• Proxying a message that contains a WWW-Authenticate header.
• The WWW-Authenticate header contains a digest challenge.
• The challenge includes parameters that fall into PJSIP’s definition of "other_params", and these are quoted.

In this case, when the header is proxied, the quoted "other params" will be unquoted.

This is happening because parse_digest_challenge unquotes all the parameters it finds before storing them on the pjsip_digest_challenge. However print_digest_challenge does not re-quote them (if the "other_params" are required to be quoted, they must be stored as quoted values in the pjsip_digest_challenge before calling print_digest_challenge).

The fix is for parse_digest_challenge to not unquote "other_params". This seems better than the alternative of having print_digest_challenge add the quotes, as the latter approach does not allow the application to use "other_params" but avoid having them quoted.

Thanks to Alex Hockey for the patch.

Reported issues:

• The timer TIMER_TYPE_UAS_TIMEOUT is not scheduled after receiving initial SUBSCRIBE, the timer will only be scheduled after receiving refresh SUBSCRIBE.

• Callback on_server_timeout() should not be invoked when subscription has already been terminated, sample scenario:
  1. receive SUBSCRIBE with an Expires header of 0
  2. the subscription state shifts to terminated, but the subscription destroy is delayed due to pending subscription transaction
  3. meanwhile, timer callback is called for TIMER_TYPE_UAS_TIMEOUT and on_server_timeout() callback is invoked.

Known issues:

• Memory pool alignment, usually we use 8 bytes alignment for 64 bit archs, while for iOS and Android, it still uses 4 bytes. Note that this 4 bytes alignment has been reported to cause crash on 64-bit iPhone running iOS 9 beta 3.
• Need to update config.sub for arm64 arch.
• Library/application file naming, e.g: currently iOS uses arm-apple-darwin9 for all archs.

Issues with Windows Unicode build:

• pjlib assumes that Win32 can't be Unicode. Setting PJ_NATIVE_STRING_IS_UNICODE to 1 if UNICODE is defined fixes this.

• GetProcAddress always takes a char *, even if UNICODE is defined, so use char * instead of pj_char_t * (and accordingly omit PJ_T on string literals)

Thanks Michele Cicciotti for the patch.

Suspected Issues with Windows Vista:

• Audio quality: audio stutters on Vista. This may not be PortAudio's problem but rather general Vista problem as there seems to be lots of users complaining about this on the net.
• AcceptEx() returns WSAENOTSOCK: to be verified.

If the jitter buffer is currently empty, it will accept a new frame even though it is a duplicate of previous frame.

The corresponding ticket for 1.0 branch is ticket #745.

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

Currently jitter buffer doesn't return length information, which causes decoder to unable to distinguish between normal frame and SID frame

Add keep-alive mechanism for UDP transports in order to reduce registration interval.

TCP and TLS transports should periodically transmit packet to keep the connection and NAT binding open.

Once the wav player returns EOF, the internal mixing buffer of the port will never get resetted/zeroed, this causes annoying noise as the last frame of the wav file is played continuously.

This bug seems to be introduced by #1532, which only reset/bzero the mixing buffer if the port has more than one transmitters.

Thanks Arkadiusz Wronski for the report.

It has been reported that latency between two pjsip instances on Windows Mobile.

Restarting the library may fail with PJLIB_UTIL_ESTUNNOTRESPOND error, after the library has been restarted several times. The only way to fix is to close and restart the application.

This is mainly observed on Android platform when ICE is disabled and STUN is enabled.

This isssue was first discussed in ​the discussion in csipsimple issue tracker.

On on_rx_rtp()/on_rx_rtcp() there's a loop to call pj_ioqueue_recvfrom(). The loop will stop until pj_ioqueue_recvfrom() return PJ_EPENDING/PJ_ECANCELLED. If pj_ioqueue_recvfrom() return Error besides PJ_EPENDING/`PJ_ECANCELLED the loop will continue non stop.

This patch will introduce new setting (PJMEDIA_IGNORE_RECV_ERR_CNT) to limit the number of identical consecutive error return from pj_ioqueue_recvfrom().

Thanks to Guy Mininberg for the report.

There are a couple of issues in the current spec and implementation of pj_ice_strans_sendto():

1. The function will return PJ_SUCCESS even if the lower level send operations return PJ_EPENDING. However, the application doesn't know this so if the application overwrites the send buffer before the send completes, then the data sent will be overwritten.
2. Application cannot know the status of the send operation. There's no callback to tell the application, thus even if the function returns PJ_SUCCESS, the data can actually fail to be sent.

Therefore, this ticket will deprecate this function and replaces it with the new API pj_ice_strans_sendto2(), which can return PJ_EPENDING, and notify the application of the sending status via callback on_data_sent().

Ticket #883 added compile time configuration for selecting keep-alive mechanism of the media streams. Some applications want more flexibility by configuring this at run-time, ideally by making this part of account settings.

This ticket will add run-time configuration for activating/deactivating stream keep-alive only (no keep-alive packet type and interval settings).

Activating/deactivating stream keep-alive mechanism in run-time

• Make sure that stream keep-alive mechanism is enabled:
  • define PJMEDIA_STREAM_ENABLE_KA to PJMEDIA_STREAM_KA_EMPTY_RTP or PJMEDIA_STREAM_KA_USER in config_site.h
  • optionally, update default keep-alive settings (user packet content and interval) via compile-time macros PJMEDIA_STREAM_KA_USER_PKT and PJMEDIA_STREAM_KA_INTERVAL.
• If you are using PJSUA, configure this via account config:
  • set pjsua_acc_config.use_stream_ka
  • use the account config for adding (pjsua_acc_add()) or modifying (pjsua_acc_modify()) account, so all media streams for that account will use this setting.
• If you are using PJMEDIA level, set stream info pjmedia_stream_info.use_ka and use the stream info for creating stream (pjmedia_stream_create()).

Quoting Jim's email:

The major difference is the dynamic explicit run-time linking to the IpHlpApi.DLL, instead of the implicit linking that would normally be used with import libraries. The new version of the file will only load the DLL if it is actually used. Currently, the DLL is loaded and mapped into the program executable space at startup of the application, even though the DLL is never used by my application. Since there are only two functions that are needed from this DLL, it makes sense to only load it if they are needed.

I made this change because my application was crashing during shutdown. The crash was occurring deep within the shutdown code of the IpHlpApi.DLL. Since there wasn’t a clear way of debugging this, and my code didn’t actually need any of the functions from that DLL, I made the changes to the source file to explicitly link to it.

The following configure options:

--disable-g711-codec --enable-l16-codec --disable-g722-codec --disable-g7221-codec

will cause link errors in pjmedia-test:

../lib/libpjmedia-codec-i686-pc-linux-gnu.a(l16.o): In function `l16_recover':
l16.c:(.text+0x60e): undefined reference to `pjmedia_plc_generate'
../lib/libpjmedia-codec-i686-pc-linux-gnu.a(l16.o): In function `l16_decode':
l16.c:(.text+0x6d6): undefined reference to `pjmedia_plc_save'
../lib/libpjmedia-codec-i686-pc-linux-gnu.a(l16.o): In function
`l16_alloc_codec':
l16.c:(.text+0x966): undefined reference to `pjmedia_plc_create'
../lib/libpjmedia-codec-i686-pc-linux-gnu.a(gsm.o): In function
`gsm_dealloc_codec':
gsm.c:(.text+0x40d): undefined reference to `pjmedia_plc_save'
gsm.c:(.text+0x42d): undefined reference to `pjmedia_plc_save'
../lib/libpjmedia-codec-i686-pc-linux-gnu.a(gsm.o): In function
`gsm_codec_recover':
gsm.c:(.text+0x4fe): undefined reference to `pjmedia_plc_generate'
../lib/libpjmedia-codec-i686-pc-linux-gnu.a(gsm.o): In function
`gsm_codec_decode':
gsm.c:(.text+0x5e1): undefined reference to `pjmedia_plc_save'
../lib/libpjmedia-codec-i686-pc-linux-gnu.a(gsm.o): In function
`gsm_alloc_codec':
gsm.c:(.text+0x9f3): undefined reference to `pjmedia_plc_create'
collect2: ld returned 1 exit status

This problem was originally reported in ​http://bugs.gentoo.org/show_bug.cgi?id=364249

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

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

Thanks Arslan Pervaiz for the report.

After setting local_hold to PJ_FALSE, if there is a subsequent failure (status != PJ_SUCCESS), it's never reset back.

When outgoing hold request failed (e.g. rejected with 488 for some reason), the library still put the call state to local hold.

When PJSUA-LIB account is locked to a specific TCP or TLS listener, re-registration will occur in a loop. This happens because when specific listener is requested, TCP/TLS listener will always create a new transport for each registration request, and PJSUA-LIB will keep detecting IP address changed for the account, causing continuous reregistration.

Note:

while the issue occurs in PJSUA-LIB, the bug is in PJSIP because it keeps creating new transport.

The log level setting in pjsua_logging_config in PJSUA-LIB is not applied to logging at all.

Thanks Simon Farmer for reporting this.

The pj_log() function, the main implementation of logging functionality in PJLIB, calls some other PJLIB APIs such as pj_gettimeofday(). The implementation of these other APIs may in turn call back the pj_log() function, causing infinite recursive calls.

This happens especially on Windows Mobile platform where PJLIB emulates the millisecond resolution of the time function (this feature was added in version 1.2 by ticket #764), depending on the timing when the logging was called.

The corresponding ticket for 1.0 branch is ticket #932

Delays up to several seconds are observed on certain iPhone systems.

Sample: iPhone OS-4.2.1/arm/iOS-SDK-4.1, no STUN.

 16:03:33.863   pjsua_core.c  pjsua version 1.8.10-trunk for iPhone OS-4.2.1/arm/iOS-SDK-4.1 initialized
 16:03:38.881   pjsua_core.c  SIP UDP socket reachable at 10.0.0.1:6000
 16:03:38.883    udp0xa4a600  SIP UDP transport started, published address is 10.0.0.1:6000
 16:03:43.898  pjsua_media.c  RTP socket reachable at 10.0.0.1:4000
 16:03:43.898  pjsua_media.c  RTCP socket reachable at 10.0.0.1:4001

Changeset r773 updated the media transport so that it does not stop listening the socket when it encounters error. Unfortunately this introduced a new problem, that is when the socket is closed/unregistered while the on_rx_rtp() callback is running, the callback will loop indefinitely.

Thanks Phil Torre for reporting this.

Previously the loop media transport only sends packets back to the same stream, which is not very flexible.

This ticket allows the same loop media transport instance to be attached to more than one streams, and allow application to control which stream(s) receives the reflected packets. The new behavior should be backward compatible with the previous behavior (when there is only one stream attached and application does not specify which stream to receive packet, since by default all streams receive packets).

Warnings:

../../g7221/common/basic_op.h:42: warning: âL_macNsâ declared âstaticâ but never defined
../../g7221/common/basic_op.h:44: warning: âL_msuNsâ declared âstaticâ but never defined
../../g7221/common/basic_op.h:48: warning: âL_add_câ declared âstaticâ but never defined
../../g7221/common/basic_op.h:49: warning: âL_sub_câ declared âstaticâ but never defined
../../g7221/common/basic_op.h:66: warning: âL_satâ declared âstaticâ but never defined

This is a placeholder for minor/miscellaneous fixes on this milestone.

This is a placeholder for minor/miscellaneous fixes on this milestone.

On Mac OS X 10.6, when audio input/output callback thread is changed (such as when plugging/unplugging headphone), the input/output callback will trigger an assertion when calling pj_thread_register().

Endianness detection fails on OSX universal build.

The duplicate ticket for 1.0 branch is ticket #750.

This is duplicate of ticket #749 for 1.0 branch.

Currently pjsua_start() will automatically start NAT type detection, it may block the application UI/main thread (the thread calling pjsua_start(), usually it is the UI/main thread), when the configured STUN server is down.

So, let's just perform NAT type detection only after STUN server resolution is succeeded. Also, make the library starting NAT type detection only when pjsua_config.nat_type_in_sdp is set to non-zero.

Overview

Many problems and workarounds have been applied in PJNATH in attempt to fix synchronization issues, such as:

• #1610 (v2.0.5): Workaround for reported crash on stun_sock's on_data_recvfrom() callback
• #1604 (v2.0.5): Crash caused by double destructions of ICE stream transport
• #1594 (v2.0.5): Deadlock between TURN and ioqueue locks
• #1557 (v2.0.5): Assertion when TURN session is already destroyed
• #1551 (v2.0.5): Assertion in TURN code when shutdown or destroy is called more than once
• #1548 (v2.0.5): Crash due to racing condition in timer when call is disconnected quickly

This ticket contains works to fix various synchronization issues in PJNATH. This ticket depends on #1616.

The overview of works to be/being done by this ticket are as follow:

• Modify all STUN objects to use group lock (see Group Lock).
• Use single group lock for all objects in the same group (e.g. within the ICE strans object). These include the ICE strans, ICE session, STUN socket and session, TURN socket and session, and down to ioqueue key and timer heap entry.
• Carefully construct the proper shutdown routine for each object. For some objects, this means to split the destroy process into two stages: the shutdown routine to stop the operation of the object (this is done by the object's destroy() API), and the actual release of the pool (this is done in the group lock's destructor handler).
• Create new concurrency stress test routine in PJNATH-TEST program.

API Changes

Some APIs have been "enhanced" and some have been changed. These API changes were considered necessary to make the group lock usage more explicit. However since these only occur in PJNATH, it should only affect applications that directly use them (typical PJSUA-LIB apps will not be affected). The details are as follow.

STUN Session

• pj_stun_session_create() has been changed; new group lock parameter added.

STUN Socket

• new group lock field in pj_stun_sock_cfg. If the STUN socket is created by ICE, ICE will fill this value itself.

STUN Transaction

• pj_stun_client_tsx_create() has been changed; new group lock parameter added.
• pj_stun_client_tsx_destroy() was renamed to pj_stun_client_tsx_stop() to more reflect the fact that the operation doesn't destroy anything but rather just stop it from operating.

TURN Socket

• new group lock field in pj_turn_sock_cfg. If the TURN socket is created by ICE, ICE will fill this value itself.

According to RFC 4028 section 9, table 2, if the UAC doesn't support timer, but a proxy inserts a Session-Expires header, then UAS (instead of UAC, which is the current behavior) has to be the refresher.

When a new audio device is plugged in after Pjsip is initialised it is not seen by the sound device enumeration function.

Solution: Create a refresh audio devices function that updates the newly available devices.