Custom Query (2195 matches)

Implement a new callback to notify application that sound device is about to be opened or closed. This is useful if application wants to keep track whether the sound device is currently active or idle, and also will be very useful if application manages the sound device by itself since this callback notifies the application when the library needs to use the sound device and when it's safe to close it, taking into account the sound device idle timer.

Prototype of the callback:

    /**
     * Callback when the sound device is about to be opened or closed.
     * This callback will be called even when null sound device or no
     * sound device is configured by the application (i.e. the
     * #pjsua_set_null_snd_dev() and #pjsua_set_no_snd_dev() APIs).
     * This API is mostly useful when the application wants to manage
     * the sound device by itself (i.e. with #pjsua_set_no_snd_dev()),
     * to get notified when it should open or close the sound device.
     *
     * @param operation	The value will be set to 0 to signal that sound
     * 			device is about to be closed, and 1 to be opened.
     *
     * @return		The callback must return PJ_SUCCESS at the moment.
     */
    pj_status_t (*on_snd_dev_operation)(int operation);

Bug in the acquire_call() function in pjsua_call.c:

the timeout variable is not fully initialized. The msec is set, but sec is not set to any value, so it may contain random value. This will cause program to block for random time when soft deadlock is detected.

The pjsua_call_hangup_all() may freeze the app for few seconds since it is not protected by the deadlock prevention code. Note that the pjsua_call_hangup() is not affected by this bug.

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

Detail scenario:

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

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.

A new option is added to pjsua_acc_config to control whether REGISTER should be sent as soon as the account is added:

    /**
     * Specify whether the account should register as soon as it is
     * added to the UA. Application can set this to PJ_FALSE and control
     * the registration manually with pjsua_acc_set_registration().
     *
     * Default: PJ_TRUE
     */
    pj_bool_t         register_on_acc_add;

The default is PJ_TRUE to be compatible with current behavior.

A new callback is added to pjsua_callback to allow application to be notified when the library has started or stopped registration:

    /**
     * Notify application when registration or unregistration has been
     * initiated. Note that this only notifies the initial registration
     * and unregistration. Once registration session is active, subsequent
     * refresh will not cause this callback to be called.
     *
     * @param acc_id	    The account ID.
     * @param renew	    Non-zero for registration and zero for
     * 			    unregistration.
     */
    void (*on_reg_started)(pjsua_acc_id acc_id, pj_bool_t renew);

Useful for application to track the active renderer devices.

Some newly added account settings may haven't been handled properly by pjsua_acc_modify() (and also perhaps other API such as pjsua_acc_config_dup()), e.g: outbound stuffs (rfc5626) and call_hold_type.

Sample cases (note that video is disabled and max_audio_cnt is 1/default):

1. Rejected all media offer while it should accept one (scripts-sendto/125_sdp_with_multi_audio_2.py and scripts-sendto/320_srtp_with_unknown_transport_2.py).
   • offer:

     m=audio 4000 UNKNOWN 0
     m=audio 5000 RTP/AVP 0
     

   • answer generated:

     m=audio 0 UNKNOWN 0
     m=audio 0 RTP/AVP 0
     

   • answer should be:

     m=audio 0 UNKNOWN 0
     m=audio 4000 RTP/AVP 0
     

2. Selected unsecured media over secured media in SRTP optional mode (scripts-sendto/330_srtp_prefer_rtp_savp.py).
   • offer:

     m=audio 4000 RTP/AVP 0
     m=audio 5000 RTP/SAVP 0
     a=crypto:1 aes_cm_128_hmac_sha1_80 inline:WnD7c1ksDGs+dIefCEo8omPg4uO8DYIinNGL5yxQ
     

   • answer generated:

     m=audio 4000 RTP/AVP 0
     m=audio 0 RTP/SAVP 0
     

   • answer should be:

     m=audio 0 UNKNOWN 0
     m=audio 4000 RTP/AVP 0
     

3. Rejected both unsecured media and secured media offered in SRTP disabled mode (scripts-sendto/331_srtp_prefer_rtp_avp.py).
   • offer:

     m=audio 4000 RTP/SAVP 0
     a=crypto:1 aes_cm_128_hmac_sha1_80 inline:WnD7c1ksDGs+dIefCEo8omPg4uO8DYIinNGL5yxQ
     m=audio 5000 RTP/AVP 0
     

   • answer generated:

     SIP/2.0 406 Not Acceptable
     

   • answer should be:

     m=audio 0 RTP/SAVP 0
     m=audio 5000 RTP/AVP 0
     

Tested with quitting vidgui without turning off preview.

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

Known symptoms:

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

It crashed upon receiving re-INVITE or UPDATE. This problem is to be fixed by #1358

Crash on receiving UPDATE or re-INVITE.

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.

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

A soft deadlock will occur in the following scenario:

Ticket #1044 adds pjsua_acc_config.reg_retry_interval to control account interval to retry registration in case it failed. However when the registration is disconnected because of transport failure (e.g. TCP transport closure), the initial retry would happen immediately.

This ticket adds new setting, pjsua_acc_config.reg_first_retry_interval, to control the interval of the first retry. The default value is zero, which means registration retry will be done immediately after failure.

Note that in case there are calls active when the TCP transport is disconnected, these calls will be hung up only after the first registration retry fails, hence it is recommended to set pjsua_acc_config.reg_first_retry_interval to low value.

This ticket also adds random +/- 10 seconds to the interval, so that clients wouldn't re-register at the same time thus causing high load to server.

#1371 has caused crash if pjsua_call_get_info() is called with call ID that is within range but points to a disconnected call.

Thank you Marcus Froeschl for the report!

New API is added to allow application to quickly check if a particular video stream is currently running (i.e. has been created and started and not currently being paused):

PJ_DECL(pj_bool_t) pjsua_call_vid_stream_is_running(pjsua_call_id call_id,
                                                    int med_idx,
                                                    pjmedia_dir dir);

PJ_DECL(pj_bool_t) pjmedia_vid_stream_is_running(pjmedia_vid_stream *stream,
                                                 pjmedia_dir dir);

When TURN is configured with bad server name, couple of error scenarios will occur. For example, configure pjsua with the following:

--use-ice
--use-turn
--turn-srv turn.baddomain.com

Scenario 1:

Crash will occur with the above config.

Scenario 2:

if nameserver is configured (i.e add --nameserver cmdline option containing your local router IP address), the crash will not happen, but the application is not notified that the call has failed (i.e on_call_state() callback is not called).

Crash when adding new media.

Unknown media types may be introduced by previous remote offer and those unknown media types are not handled correctly in generating re-offer.

Add candidates info in pjmedia ICE transport's specific info, and output it in pjsua dump. It will look something like this:

    Call time: 00h:00m:35s, 1st res in 3301 ms, conn in 3305ms
    #0 audio PCMU @8kHz, sendrecv, peer=10.0.0.178:46930
       SRTP status: Not active Crypto-suite: (null)
       ICE role: Controlled, state: Negotiation Success, comp_cnt: 2
          [0]: L:1.1.1.1:32838 (h) --> R:1.2.2.2:46930 (h)
          [1]: L:1.1.1.1:37090 (h) --> R:1.2.2.2:33720 (h)

Deadlock may occur when trying to resolve and test the STUN servers in pjsua-lib.

With #539 it is now possible to configure STUN, ICE, and TURN settings on per account basis. This is needed for example when application is supporting multiple accounts where one is connecting through Internet and the other is through VPN. The specification is as follows.

Enable/disable STUN per account

The STUN server settings are still in the global pjsua_config. New settings are introduced in the account config to disable or enable STUN for either SIP or media transports: sip_stun_use and media_stun_use:

/**
 * This enumeration controls the use of STUN in the account.
 */
typedef enum pjsua_stun_use
{
    /**
     * Follow the default setting in the global \a pjsua_config.
     */
    PJSUA_STUN_USE_DEFAULT,

    /**
     * Disable STUN. If STUN is not enabled in the global \a pjsua_config,
     * this setting has no effect.
     */
    PJSUA_STUN_USE_DISABLED

} pjsua_stun_use;

struct pjsua_acc_config
{
    ...

    /**
     * Control the use of STUN for the SIP signaling.
     *
     * Default: PJSUA_STUN_USE_DEFAULT
     */
    pjsua_stun_use 		sip_stun_use;

    /**
     * Control the use of STUN for the media transports.
     *
     * Default: PJSUA_STUN_USE_DEFAULT
     */
    pjsua_stun_use 		media_stun_use;

    ...
};

ICE and TURN settings per account

New ICE and TURN configurations in the account config to override the global config in the pjsua_media_config:

/**
 * This enumeration controls the use of ICE settings in the account.
 */
typedef enum pjsua_ice_config_use
{
    /**
     * Use the default settings in the global \a pjsua_media_config.
     */
    PJSUA_ICE_CONFIG_USE_DEFAULT,

    /**
     * Use the custom \a pjsua_ice_config setting in the account.
     */
    PJSUA_ICE_CONFIG_USE_CUSTOM

} pjsua_ice_config_use;

/**
 * This enumeration controls the use of TURN settings in the account.
 */
typedef enum pjsua_turn_config_use
{
    /**
     * Use the default setting in the global \a pjsua_media_config.
     */
    PJSUA_TURN_CONFIG_USE_DEFAULT,

    /**
     * Use the custom \a pjsua_turn_config setting in the account.
     */
    PJSUA_TURN_CONFIG_USE_CUSTOM

} pjsua_turn_config_use;

/**
 * ICE setting. This setting is used in the pjsua_acc_config.
 */
typedef struct pjsua_ice_config
{
    /**
     * Enable ICE.
     */
    pj_bool_t		enable_ice;

    /**
     * Set the maximum number of host candidates.
     *
     * Default: -1 (maximum not set)
     */
    int			ice_max_host_cands;

    /**
     * ICE session options.
     */
    pj_ice_sess_options	ice_opt;

    /**
     * Disable RTCP component.
     *
     * Default: no
     */
    pj_bool_t		ice_no_rtcp;

} pjsua_ice_config;

/**
 * TURN setting. This setting is used in the pjsua_acc_config.
 */
typedef struct pjsua_turn_config
{
    /**
     * Enable TURN candidate in ICE.
     */
    pj_bool_t		enable_turn;

    /**
     * Specify TURN domain name or host name, in in "DOMAIN:PORT" or
     * "HOST:PORT" format.
     */
    pj_str_t		turn_server;

    /**
     * Specify the connection type to be used to the TURN server. Valid
     * values are PJ_TURN_TP_UDP or PJ_TURN_TP_TCP.
     *
     * Default: PJ_TURN_TP_UDP
     */
    pj_turn_tp_type	turn_conn_type;

    /**
     * Specify the credential to authenticate with the TURN server.
     */
    pj_stun_auth_cred	turn_auth_cred;

} pjsua_turn_config;

struct pjsua_acc_config
{
    ...

    /**
     * Control the use of ICE in the account. By default, the settings in the
     * \a pjsua_media_config will be used.
     *
     * Default: PJSUA_ICE_CONFIG_USE_DEFAULT
     */
    pjsua_ice_config_use	ice_cfg_use;

    /**
     * The custom ICE setting for this account. This setting will only be
     * used if \a ice_cfg_use is set to PJSUA_ICE_CONFIG_USE_CUSTOM
     */
    pjsua_ice_config		ice_cfg;

    /**
     * Control the use of TURN in the account. By default, the settings in the
     * \a pjsua_media_config will be used
     *
     * Default: PJSUA_TURN_CONFIG_USE_DEFAULT
     */
    pjsua_turn_config_use	turn_cfg_use;

    /**
     * The custom TURN setting for this account. This setting will only be
     * used if \a turn_cfg_use is set to PJSUA_TURN_CONFIG_USE_CUSTOM
     */
    pjsua_turn_config		turn_cfg;

    ...
};

Contact header generation

The initial value of Contact header will take into account whether STUN is enabled or disabled in the account. If it is disabled, local IP will be used. More over, for UDP transport, if STUN is not used or disabled for the account, an attempt will be made to use the correct IP interface to be placed in the Contact URI.

No change for TCP; the correct IP has already been selected in the Contact URI.

Subsequent update to the Contact header doesn't change.

Via sent-by generation

Initial Via sent-by value now will be affected by STUN setting in the account. If it is disabled, local IP will be used. More over, for UDP transport, if STUN is not used or disabled for the account, an attempt will be made to use the correct IP interface to be placed in the Contact URI.

No change for TCP; the correct IP has already been displayed in the Via sent-by.

Subsequent update of the value doesn't change; it follows the rules in #1537.

Media transports

STUN, ICE, and TURN setup of the media transports now will follow the account config settings instead.

pjsua

New option --disable-stun is added.

This is to handle hypothetical situation when pj_thread_join() calls in pjsua_destroy2() fail to wait for the worker thread to terminate. In this case, we would expect the worker thread to crash because things would have been cleaned up by pjsua_destroy2().

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.

Currently, media count setting is configurable via account setting only, which not really ideal for application, e.g: need to modify the account setting just for enabling video in an audio only session. So, media count manipulation should be done per call basis rather than per account basis.

Sending a re-offer with new call setting will modify call media states, and the call media states need to be reverted back when the re-offer is rejected by peer.

Currently, any incoming re-offer will be auto answered with 200/OK and the SDP answer is generated based on the current call setting. With this new callback, application will have a chance to reject the re-offer (so the existing media session will remain active), or accept the re-offer with updated call setting.

Lack of mutex protection in auto-closing and auto-opening of the sound device may cause incorrect closing or opening of the sound device.

Steps to reproduce:

• start pjsua w/ video disabled, i.e: omit '--video'
• receive incoming call w/ video
• accept the call
• enable video, e.g: 'vid call enable 1'

Assertion raised in pjsua_media_channel_update() in pjsua_media.c:2689:

PJ_ASSERT_RETURN(neg && !pjmedia_sdp_neg_was_answer_remote(neg),
			 PJMEDIA_SDPNEG_EINSTATE);

Even there is no matching codec in all media, pjsua will always respond 200/OK with all media disabled (no active media), this occurs in initial and subsequent offers.

Potential issue with such behaviour:

• initial offer: incoming call callback is invoked, so user may answer the call but suddenly the call got hung up (by remote pjsua as it detects no active media).
• subsequent offer: existing media streams may get updated to disabled mode (as the 200/OK response).

Note:

• the behaviour of 1.x seems okay:
  • initial offer: auto reject with 488/500, so no incoming call callback is invoked.
  • subsequent offer: auto reject with 488/500, so existing the media session remain active.
• need to check the behaviour when no active media is caused by all media are originally disabled in the offer?

The crash happened when a dialog usage for OPTIONS is added at the end of making a call.

When ICE transport initialization is to be done in synchronized mode, currently PJSUA always releases PJSUA lock first to let other thread use the lock while waiting for the transport initialization, however if the lock is actually not being held by this thread, it will trigger assertion.

PJSUA call accesses account config after the call initialization is done (e.g: media update gets srtp setting, default video device setting directly from account config), this causes problem as account can be deleted without hanging up its calls.

When making call using the flag PJSUA_CALL_INCLUDE_DISABLED_MEDIA with video being disabled, call initialization will get stuck because we are waiting for all media (including disabled) to finish media transport creations.

It turns out that video capture port is not connected to anywhere when video capture device uses native preview.

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.

The original report can be found ​here.

When I make a call to a SIPS URI with a host part that resolves to an
IP address, albeit one with nobody listening for SIP connections on it,
the program fails in the appropriate manner. However, when I make a call
with a SIPS URI that does not resolve in DNS (i.e., there's no A or any
other type of record for it), the program instead dies due to an ABRT
(6) signal, which appears to be due to the following assertion failure:

 ../src/pj/os_core_unix.c:1201: pj_mutex_lock: Assertion `mutex' failed.

Easily reproduced by making a call to any unresolved destination or via unresolved proxy without specifying DNS server and without STUN/ICE (synchronous media channel init).

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.

This ticket implements support for integrating third party media stack into PJSUA-LIB. By following these steps below, application can use third party media stack to perform audio and video functionality while still making use of the full SIP, NAT, and security (including SRTP) features provided by PJSUA-LIB API.

By disabling PJMEDIA, the following features will not be available in PJSUA-LIB (unless the equivalent implementation is provided by the third party media library):

• sound device management
• echo cancellation
• codecs
• jitter buffer
• RTP and RTCP
• WAV playback and recording
• conference bridge
• DTMF with RFC 2833
• and so on, except explicitly mentioned below

The following features will still be available:

• all SIP features, including SIP registration, etc.
• SDP and SDP negotiation
• NAT traversal features (including ICE)
• security features including TLS and SRTP
• media transports

Follow these steps to integrate third party media library with PJSUA-LIB:

1. Declare this in pjlib/include/pj/config_site.h:

   #define PJSUA_MEDIA_HAS_PJMEDIA    0
   

   to exclude PJMEDIA specific implementation from PJSUA-LIB library. Understandably you will loose all media features in PJSUA-LIB (this will be handled by your third party media stack).
2. Also copy suggested settings from pjsip-apps/src/3rdparty_media_sample/config_site.h into pjlib/include/pj/config_site.h. These settings are mostly used to exclude unneeded media components from the link process.
3. Build the libraries, but this time using

   $ make lib
   

   instead of just make or make all. This is because most samples will no longer build due to missing media in PJSUA-LIB, hence normal make will fail on these apps. The make lib command only builds the libraries and unit tests for the libraries.
4. Go to directory pjsip-apps/src/3rdparty_media_sample. This is a sample application with hook points to integrate third party media library. Fill in the media implementation in the alt_pjsua_xxx.c files, following the "TODO" notes. Run make to build the application. Once it's built, run alt_pjsua just as you run the usual pjsua application (it's essentially the same app!).

Deadlock scenario:

Thread 1 (audio playback thread):

1. play_cb() calls conference get_frame()
2. conference mutex is acquired, and conf starts collecting frames from ports
3. wav player (a conf port member) triggers EOF callback to application
4. application calls pjsua_conf_disconnect()
5. check_snd_dev_idle() in pjsua_conf_disconnect() tries to acquire PJSUA LOCK that is being held by thread 2.

Thread 2 (pjsua worker thread):

1. pjsua_call_on_state_changed() invoked
2. PJSUA LOCK is acquired
3. pjsua triggers on_call_state() callback to application
4. application calls pjsua_conf_connect()
5. pjsua_conf_connect() waits for conference mutex that is being held by thread 1.

Assertion (and sometimes access violations) when calling pjsua_destroy2(PJSUA_DESTROY_NO_NETWORK) in response to a network change (e.g. WiFi? to 3G or vice versa), if an incoming call happens to ring at that moment.

Assertion:

Assertion failed: (mutex->owner == pj_thread_this()),
function pj_mutex_unlock, file ../src/pj/os_core_unix.c, line 1256.

Crash callstack trace:

#0	0x00081410 in pjmedia_conf_get_connect_count ()
#1	0x00054dbe in check_snd_dev_idle ()
#2	0x00055f3a in pjsua_media_channel_deinit ()
#3	0x00057be8 in pjsua_media_subsys_destroy ()
#4	0x000510e4 in pjsua_destroy2 ()

The regc keeps a reference to the last transport being used in order to prevent it from being destroyed. In some situation however, such as when the transport is disconnected, it is necessary to instruct the regc to release this reference so that the transport can be destroyed.

Modifying account config settings, i.e: via pjsua_acc_modify(), is not supposed to always trigger re-registration, for example modifying call or media settings such as SIP session timer, SRTP settings. However, such unexpected re-registration case has been found.

After investigation, it seems to be caused by that proxy setting is mistakenly detected as being modified. The proxy change detection is done using CRC comparison, and the initial CRC calculation in pjsua_acc_add() is performed before the proxy URI normalization.

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.

Both the EC options (ec_options) field in the media config and in pjsua_set_ec() argument are ignored and don't have any effect to the echo cancellation setting.

The UDP keep-alive on the account is still running even after the account is deleted with pjsua_acc_del(). Updating the ka_interval with pjsua_acc_modify() also has no effect on the keep-alive.

Crash occurs in pjsua_media_prov_clean_up() as it tries to close (mistakenly detected as unused) transports which actually already closed by pjsua_media_subsys_destroy().

Easily reproducible with python tests: scripts-recvfrom/300_timer_good.py, scripts-recvfrom/301_timer_good_retry_after_422.py, scripts-sendto/360_non_sip_uri.py, scripts-sendto/362_non_sip_uri.py

The call is terminated prematurely (before 100 response is sent), in a normal way (remote session timer value is too small than the minimum value specified), but call->inv pointer is not resetted to NULL. When pjsua is being destroyed, any access to the bad pointer call->inv, e.g: by pjsua_call_hangup_all(), will trigger crash.

Reproducible with python test scripts-sendto\174_timer_se_too_small.py.

When an account is already registered, modifying id or reg_uri via pjsua_acc_modify() does not works as expected. The new parameter are stored, but not used for the following REGISTER.

Use cases (identified so far):

• applying codecs priorities per account/call basis
• adding proprietary SDP attributes
• ...

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 assertion line:

Assertion failed: (!"Currently no media transport reuse"), function 
pjsua_call_media_init, file ../src/pjsua-lib/pjsua_media.c, line 1260.

Scenario:

1. call established with audio and video (two "m=" lines)
2. receive SDP re-offer with one "m=" line, i.e: audio only, answered with one "m=" line too, and media is updated fine
3. receive another SDP re-offer with two "m=" lines, i.e: audio and video.

There are two problems:

1. When media transport initialization fails, it looks like PJSUA-LIB ignores this and continue with the call, causing assertion that looks like this:

   pjsua-x86_64-unknown-linux-gnu: ../src/pjmedia/endpoint.c:770: 
   pjmedia_endpt_create_base_sdp: Assertion `!"Invalid address family"' failed.
   

2. When the above is fixed, the call gets disconnected as expected. But during disconnection callback via on_call_state() callback, call state is reported as NULL instead of DISCONNECTED.

The sound device is opened when call is initiated. When the call fails to connect, the sound device is not closed by the library.

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

Reproducing steps with pjsua:

1. build pjsua with video feature
2. run the pjsua without --video param, so video is deactivated
3. send INVITE to pjsua without SDP
4. answer the call, e.g: "a" then "200", there will be video in the SDP (which should not!)
5. send ACK to pjsua with SDP answer with video in the answer is enabled too

After investigation, after receiving incoming call, PJSUA will immediately start media channel init and create SDP with default call setting, i.e: audio and video count both set to 1, and when application call pjsua_call_answer() with different call setting, e.g: video count set to 0, the media channel update doesn't like such inconsistency when we are as SDP offerer and will trigger an assertion.

The solution should consider the requirements below:

• be able to initialize media with the settings based on user confirmation
• should avoid excessive/repeated initialization (e.g: multiple SDP or transport creation)
• simple and minimal changes is prefered

ICE media transport creation completes asynchronously. Deadlock may occur when this even happens simultaneously with an incoming request (such as CANCEL), due to different mutex locking order that the two flows use.

Since #1423, the media info in the call info corresponds to active media, so in call setup, it will remain empty/unset until the media channel update is done. While some applications may need to retrieve the provisioning media info, e.g: for setting up media transport adapter based on media type from on_create_media_transport() callback.

Modifiable settings to be implemented:

• pjsua_acc_config.mwi_expires: subscription expiration interval (compile-time default & run-time)
• pjsua_acc_config.mwi_enabled: to enable or disable MWI subscription. It can be updated via pjsua_acc_modify() to start or stop MWI subscription.

When there is a MWI subscription state change, pjsua callback on_mwi_state() will be called.

MWI subscription will be terminated when deleting the associated account.

Thanks Peter Koletzki and Matynka Bartosz for the feedbacks.

PJSUA auto-registration is not invoked unless the application is listening for the PJSUA on_transport_state() callback.

Original report and the proposed fix can be found ​here.

Thanks Gustavo Garcia Bernardo for the report and fix.

When remote sends SDP answer containing more than one formats or codecs in the media line, PJSUA-LIB sends re-INVITE or UPDATE with just one codec to lock which codec to use.

This behavior can now be disabled by setting pjsua_acc_config.lock_codec to zero.

If allow_via_rewrite option is enabled and the account is deleted with pjsua_acc_del(), the unregistration will send a via address with weird characters or without address at all.

This is because the account's via address is already deleted while the unregistration process is not finished yet.

To reproduce: run pjsua with --stun-server <IP-ADDRESS> without network connectivity.

Currently pjstun_get_mapped_addr() is using old STUN format (RFC3489). While some STUN servers may not like STUN request with old STUN format and will not respond to such requests.

Thanks Marcus Froeschl for the report.

Always re-initializing the media on call refresh can be annoying, especially for a call with video as video re-init may take several seconds.

Thanks Matynka Bartosz for the feedback.

When pjsua_vid.c's call_modify_video() is called, the current SDP will be cloned then the media transport attributes will be added to the SDP by calling pjmedia_transport_encode_sdp(). This can cause duplicate attributes if the current SDP already has media transport attributes.

To reproduce using pjsua: Enable ICE, establish a call, modify the video stream (such as "vid call rx off 1")

Related to the fix of ticket #1526, when answering call using pjsua_call_answer()/answer2() with opt set to NULL, the media channel is never initialized because the condition:

(call->opt_inited || (code==183 && code/100==2))

can never be TRUE.

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

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

Thanks Itay Bianco for the report!

Reproducing steps:

1. Start pjsua with --srtp-secure 0 --use-srtp 2
2. Send INVITE to the pjsua with SDP offer such as:

   v=0
   o=- 518818627584 526334820353 IN IP4 127.0.0.1
   s=Audio call
   c=IN IP4 127.0.0.1
   t=0 0
   m=audio 7016 RTP/SAVP 0
   c=IN IP4 127.0.0.1
   a=crypto:1 AES_CM_128_HMAC_SHA1_80 
     inline:qgQj9Tl/cb2VQxxDAkoy6CATjPrlsqtGJU7DYST/
   m=audio 7016 RTP/AVP 0
   

Thanks Peter Koletzki for the report.

Steps to reproduce: First, create a call that doesn't use custom med tp. Then disconnect the call and make a call again (that is assigned to the same call id), custom media transport creation callback will not be called since call->med_orig is not NULL.

When sending initial INVITE fails due to network failure (for example, setting iPhone iOS to AirPlane mode, or network is down), the on_call_state() callback will be called twice: first with PJSIP_INV_STATE_DISCONNECTED, then followed by PJSIP_INV_STATE_NULL.

This may cause unexpected state transition in the application. With pjsua for example, it causes the call to be set as active call when there is no other call.

Thanks Kees van der Bent for the report.

Currently for outgoing call, app has to wait until media transport creation is completed before it can hang up the call. This ticket allows call hangup request at any time, when media transport creation hasn't finished, PJSIP will queue the request and process it once media tp completes.

Normally UDP socket operations will fail with "Broken pipe" or "Socket is not connected" error after the app is woken up from background mode. This has been handled automatically by the ioqueue. However the STUN resolution in PJSUA-LIB does not use ioqueue hence this will cause media transport initialization (and ultimately the call) to fail.

Reproducing steps:

1. A makes a video call to B, with vid_cnt == 1 in the call setting.
2. B rejects the video
3. A tries to enable video by sending re-INVITE with vid_cnt == 1 in the new call setting.
4. The SDP offer sent by A still has video media line disabled (port zero).

After investigation, the SDP generation for the re-INVITE doesn't initialize the video media, technically because the pjsua_media_channel_init() is skipped due to "no update" on media count setting (vid_cnt in this case). So it is the check of media-count-update that is actually buggy.

Thanks Itay Bianco for the report.

For UDP, the spec says that server MUST send the response from the same address where the request was received (​RFC 3581 Section 4). However, in case the server is violating this spec, PJSIP would send the UDP keep-alive to the source address of the response instead.

This ticket fixes this behavior so that the keep alive will be sent to the original request address instead.

Thanks Fredrik Hansson for the report.

When remote sends re-INVITE with less media, it will cause subsequent outgoing re-INVITE to produce an assertion: (mi < s_->media_count) in pjsua_media_channel_create_sdp().

When a call is disconnected, SIP invite module will call on_call_state(DISCONNECTED) first before on_tsx_state_changed(). However, in PJSUA, the on_call_state(DISCONNECTED) will reset PJSUA call states and the next incoming on_tsx_state_changed() will not be forwarded to the application, as it will not make sense for the application to still receive on_tsx_state_changed() after the call is disconnected (and the PJSUA call states are resetted).

An easy or low-risk workaround will be 'manually' invoking on_tsx_state_changed() from on_call_state(DISCONNECTED).

According to RFC 3428: MESSAGE requests do not initiate dialogs. User Agents MUST NOT insert Contact header fields into MESSAGE requests.

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

Hanging up call quickly after making call may cause media transport to leak. This media transports will not get destroyed forever.

Normally pjsua-lib would add "+sip.ice" media feature tag to account Contact parameters if ICE is enabled. However wrong initialization sequence in initialize_acc() function in pjsua_acc.c has caused this parameter to be omitted.

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.

Scenario to reproduce:

1. A calls B.
2. B rejects with 406 (not acceptable here) due to no matching audio codec available.
3. Repeat the above two steps for about four more times (or as many as max calls setting).
4. Now the B will reject with 486 (busy here), instead of 406.
5. Any future making/incoming call will fail due to unavailable call slot until the stack is restarted.

After investigation, when PJSUA terminates a call due to media channel init error, the pointer to dialog (for async media transport creation), i.e: pjsua_call.async_call.dlg, is not nullified, while the call slot allocation will inspect this pointer (along with the INVITE session pointer) to check the call slot availability.