Custom Query (2195 matches)

On re-INVITE (e.g: lock codec, ICE update, session refresh), SRTP sends all crypto-suites instead of just the currently active. In the Sipit31 tests, this seems to be just fine (the same current active cryptos were used on both sides, no RTP protect/unprotect error), but this is perhaps risky, e.g: remote may mistakenly see it as SRTP session restart, thus remote will reset its SRTP states (so RTP seq calculation became out of sync, etc). So sending the current active crypto should be safer.

Implement compatibility wrappers for the old sound API.

This ticket introduces pj_enum_ip_interface2() with additional option to omit deprecated IPv6 addresses, however currently it is only implemented for Linux. This ticket also modify behavior of STUN socket in enumerating local IPv6 addresses, it now skips deprecated IPv6 addresses.

Contribution from Sébastien Blin, thanks.

Currently when we reject a media line in SDP offer, we copy the media descriptor from the offer in the answer and set the port to zero.

This works fine. However this may create some confusions when troubleshooting a problem, therefore using simpler structure of media descriptor (m= line with port 0 without any 'a=' lines) may be preferable and perhaps even more efficient.

Ticket #1916 enables on_incoming_call() called from on_create_media_transport() for PJSUA2.

However, after the on_incoming_call() invocation, there is a chance that the call is disconnected by the library (e.g: due to unsupported codec or unsupported SIP capability requirement). Unfortunately, there is a bug in the library that application will not be informed about the call disconnection in such scenario.

The patch will add check for codec and capability support from the SDP before calling on_incoming_call(). In this case, when the check fails then on_incoming_call() will not be called.

However, actually there is still a chance of failure in further step of call verification, so the call may get rejected by the library after incoming call callback is invoked. In this case, call state callback on_call_state() will be invoked to notify application about call disconnection.

Thanks to Ryan Wallach for the report.

Ticket #1107 and #1225, described that iOS will reset UDP socket when app goes to background. The library will then try to recreate the socket by calling replace_udp_sock().

However since iOS11, we see some cases that the method fail and lead to unusable UDP transport or even worst, an unresponsive library state.

Log:

ioq_select !Attempting to replace UDP socket 5 
ioq_select  Error replacing socket: Invalid argument
udp0x127d27e00  Warning: pj_ioqueue_recvfrom: [err 120009] Bad file descriptor

Steps to reproduce:

• run ipjsua
• register to a registrar using UDP
• lock-unlock the phone repeatedly

This ticket will retry the recreate socket/replace_udp_sock() if it fail and add a fallback mechanism (restart transport) from the app callback.

Log:

ioq_select !Attempting to replace UDP socket 5
ioq_select  Error get peer name 120022
ioq_select  Error set qos param 120022
ioq_select  Retry to replace UDP socket 5
ioq_select !Error get peer name 120022
ioq_select  UDP has been replaced successfully!

When mixing hundreds or more ports, the mix loop is one of the bottlenecks. This ticket will reduce the CPU load substantially.

Thanks to Kal Conley (b17c0de) for the patch.

PJMEDIA test result using mips_test with 256 calls:

Clock  Item                                      Time     CPU    MIPS
 Rate                                           (usec)    (%)

without patch:
8KHz conference bridge with 256 calls            7391    0.739   59.88

with patch:
8KHz conference bridge with 256 calls            4888    0.489   39.60

Previously, the DNS resolver (resolver.c) allocates memory for caching DNS answers from the resolver pool, and stores the unused entries in free list. This would cause memory to grow as much as the total number of unique names resolved, and this memory will not be released until the resolver is destroyed.

With the new approach, each DNS answer cache entry will have it's own pool, and when the answer/entry expires, the pool will be destroyed, thus releasing the memory back to the OS.

Also change the pool type used to store the entry. Previously entry uses a fixed size buffer to allocate the memory from, using fixed buffer pool (pool_buf.h. Because of this, entry is created with buffer that must be large enough to parse DNS answer, and if the answer is larger than the buffer size, parsing will fail.

This limitation will be gone when we change the pool type to use normal pool instead.

By default, RTCP SDES/BYE is automatically sent by the stream. By setting the field pjmedia_stream_info.rtcp_sdes_bye_disabled to PJ_TRUE, application can choose to manually send RTCP SDES/BYE by using the API pjmedia_stream_send_rtcp_sdes() and pjmedia_stream_send_rtcp_bye().

By default, echo canceller's delay buffer will make use of WSOLA to expand and shrink audio samples. By setting the option flag in pjsua_set_ec() to contain PJMEDIA_ECHO_USE_SIMPLE_FIFO, application can use simple FIFO mechanism instead.

Add log_file_flags in pjsua_logging_config, where application may specify PJ_O_APPEND to allow appending existing log file.

Some registrar servers are not returning the same URI in the Contact header of REGISTER 200/OK response, and this will cause PJSIP registration client to think that it's being unregistered.

This ticket adds compile time and run-time setting to ignore Contact URIs returned in REGISTER response.

Needed for SDL-1.3 since it's not installed by default on Ubuntu (yet)

Previously the ioqueue always allow multiple callbacks to be called on the same key. This may cause difficulty in programming the application to deal with synchronization between callback calls and key registration (for example see ticket #460 and #469).

This ticket adds an option in the ioqueue to disable parallel/simultaneous callback on the same key.

Please see ​IOQueue Concurrency Rules in PJLIB documentation for more information.

A user likes to have same transfer behaviour as he is used to his old analogue PABX. The user have an active call and wants to transfer it to another extension, but only when the extension is free. So first, the user put the 1st call in hold and invoke a new call, once the alert tone comes up (receiving 180), the user press transfer.

Currently, we will reject such transfer request, in line to ​RFC 3891 section 3:

If the Replaces header field matches an early dialog that was not
initiated by this UA, it returns a 481 (Call/Transaction Does Not
Exist) response to the new INVITE, and leaves the matched dialog
unchanged. Note that since Replaces matches only a single dialog,
the replacement dialog will not be retargeted according to the same
forking logic as the original request which created the early dialog.

Thanks Peter Koletzki for the feedback and the patch.

Accommodate connection reuse for some servers that requires "alias" param in the Via header in the request message sent using connection oriented transports (see ​rfc5923).

By default, hash character will be escaped as per RFC 3261 rule. Unfortunately some endpoints want this character in the user part of a request.

This ticket adds a run-time option to allow hash character to appear in user part of SIP URL of outgoing requests. Sample code:

pjsip_cfg()->endpt.allow_tx_hash_in_uri = 1;

We validate incoming RTP packets to see if they contain correct payload type, as it should. However some people are having problems with broken servers that requires them to disable this checking.

The RTCP RTT calculation algorithm attempts to normalize "unusual" RTT variation, by setting the RTT to three times the current average RTT if the value is larger than this.

This ticket makes this behavior configurable by introducing PJMEDIA_RTCP_NORMALIZE FACTOR, which defaults to 3 and can be disabled by setting it to 0.

Add new option to make ICE stream transport ignore STUN resolution error and continue initialization as normal. This is to make the call behavior in 2.0 comparable to 1.x which silently drop srflx candidate if the STUN server fails after initialization.

The new option and the default value is:

pj_ice_strans_cfg.stun.ignore_stun_error = PJ_FALSE;

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.

New compile configuration option PJ_DEBUG_MUTEX can be used to log all mutex operations. Currently only available in Windows.

Implement handling of call redirection in PJSUA-LIB:

• a callback to notify application that the call is being redirected
• application may accept, reject, or delay the redirection processing later (for example, to ask for user permission)
• when application accepts the redirection, pjsua-lib will try the new destinations sequentially

To maintain backward compatibility with existing applications, pjsua-lib will not follow redirection if the callback is not implemented by application.

Currently, video port has to handle video resizing when video size requested by application is not supported by video device. A raised issue is how to find the closest size from the supported sizes, e.g: should we consider same/closest aspect ratio in the search?

After a discussion, we come to a conclusion that the priority is the closest width, then closest height (when resized with same aspect ratio), and eventually the result may have different aspect ratio. So perhaps we should provide options whether aspect ratio should be maintained and how (crop or pad with black boxes at up&down/left&right sides).

In the beginning of video call, video keyframe may get lost due to NAT hole punching, probing period in auto-switch to RTP port source feature, or normal packet loss. Mechanism to request video keyframe is currently available, however it takes time. So sending video keyframe regularly at some interval in the beginning of video session may reduce the missing keyframe period. It should be configurable at run-time and compile-time (for default setting).

Pjsua option --rtp-port=0 now will select random start port for RTP, in the range of [4000-65535].

When sending INVITE with media offer and receiving multiple 183 responses (early media) with different To tag, currently PJSIP will only process the first received early media response and discard the other.

There is a report that some system may handover the early media handling after some interval, e.g: from one media gateway to another, by sending another 183 response with different To tag, with different codec and this causes a PJSIP-based endpoint hears silence.

Note that this ticket is not a perfect solution to handle such scenario, for example when the first media gateway keeps sending RTP after the handover, there is still possibility that the stream may switch back to the first media gateway RTP (see also #1366).

Updated pjsua_call_reinvite() and pjsua_call_update() API to use bitmask flag in the options parameter, to allow application to request that the invite session be updated with the new Contact URI from the account. This is useful in IP address change situation, to update the invite session with the new account Contact after the account Contact is updated (typically with a registration refresh), and send this new Contact in an re-INVITE or UPDATE request.

Two options/flags are created:

• PJSUA_CALL_UNHOLD
• PJSUA_CALL_UPDATE_CONTACT

Note that this update is backward compatible.

Compile time and run-time options to use SO_REUSEADDR for SIP TCP and TLS transports. The run-time options are pjsip_tcp_transport_cfg.reuse_addr and pjsip_tls_setting.reuse_addr, and pj_ssl_sock_param.reuse_addr for the lower level PJSIP's SSL socket.

The default value for those settings are taken from these new compile time macros: PJSIP_TCP_TRANSPORT_REUSEADDR and PJSIP_TLS_TRANSPORT_REUSEADDR. By default, these macros will be set to 1 on non-Windows platforms, meaning that SO_REUSEADDR will be set to the listener sockets, and zero on Windows platforms (including mobile).

The reason why it's not set by default on Windows is because this option will steal the port from other program even if that program is currently active and the socket has not been closed. See this ​MSDN page for more info.

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.

Currently call redirection will reuse the To header in the original redirected request as recommended by ​RFC3261 8.1.3.4. However, this may lead to this undesirable scenario:

1. B calls A, connected successfully (leg 1)
2. B calls C, C redirects to D, so B is connected to D (leg 2)
3. B transfers A to D (with replaces), but A ends up ringing C (instead of D)

It happens because in leg 2, B sees that it talks with C (reused original To header) and when transferring the call, B will use the remote URI (i.e: To header) for the Refer-To header in call transfer request. Using new URI for To header in processing call redirection will avoid such scenario.

Thanks Peter Koletzki for the report.

If we receive in incoming call and the INVITE has "Supported: 100rel", PJSUA does not send 180 with "Required: 100rel", so reliable provisional responses are not used. This is because pjsua_call_on_incoming() function does not seem to check whether the received INVITE actually contained a "Supported: 100rel", but it just checks the account configuration's pjsua_acc_config::require_100rel before invoking pjsip_inv_verify_request2() :

   if (pjsua_var.acc[acc_id].cfg.require_100rel)
       options |= PJSIP_INV_REQUIRE_100REL;

So even although the partner supports 100rel and PJSUA supports 100rel (both callee and caller support it) it is not being used in this case unless 100rel is explicitly *mandated* by pjsua_acc_config::require_100rel. However enabling pjsua_acc_config::require_100rel has much stronger implications: Not only does it affect behavior as UAS but also as UAC, and it would make communications with partners who not support 100rel impossible, so it does not seem to be a valid solution to achieve the desired result.

pjsua_acc_config.allow_sdp_nat_rewrite:

This option controls whether the IP address in SDP should be replaced with the IP address found in Via header of the REGISTER response, ONLY when STUN and ICE are not used and there is active registration session present. If the value is FALSE (the original behavior, and the default value), then the local IP address will be used. If TRUE, and when STUN and ICE are disabled, then the IP address found in registration response will be used, until the account unregisters, on which the private IP will be used again.

As this SRTP mode is handled by high level library, i.e: PJSUA-LIB, and ticket #1185 causes a lot of modification in handling media transport in PJSUA-LIB, this SRTP mode is 'accidentally' stripped out.

Note: test scenario mod_call.py scripts-call/150_srtp_2_3.py is currently disabled as it depends on optional SRTP with duplicated media line. So don't forget to re-enable the scenario (in runall.py) once this ticket is done.

Passing an incorrect frame size to opus_decode() can cause decode error or recovery failure (log: "Recover failed!").

Locations found:

• in find_pitch()
• in overlap_add()

Found that setting the output volume when the VAS engine hasn't been completely started will be useless (no output volume change).

pjsua_media_subsys_destroy() unnecessarily calls pjmedia_snd_deinit(), while this should've already been done in pjmedia_endpt_destroy(). Because of this, subsequent pjsua restart (within the same process) may fail to initialize sound device.

Thanks Jiandong Ruan for reporting this.

The calculations in this function will overflow for longer call period. Thanks Simon Farmer for reporting this.

Ticket #873 was meant to add PIDF <timestamp> element into the <tuple>, but it didn't do that (it's missing the call to pj_xml_add_node()).

This ticket implements system information API in PJLIB. The purpose of this API is to provide application with various info about the system so that it can decide things to do at run-time.

There two main parts of this ticket:

1) Compile time info about PJLIB version number in <pj/config.h>:

/** PJLIB version major number. */
#define PJ_VERSION_NUM_MAJOR	1

/** PJLIB version minor number. */
#define PJ_VERSION_NUM_MINOR	8

/** PJLIB version revision number. */
#define PJ_VERSION_NUM_REV	10

/**
 * Extra suffix for the version (e.g. "-trunk"), or empty for
 * web release version.
 */
#define PJ_VERSION_NUM_EXTRA	"-trunk"

/**
 * PJLIB version number consists of three bytes with the following format:
 * 0xMMIIRR00, where MM: major number, II: minor number, RR: revision
 * number, 00: always zero for now.
 */
#define PJ_VERSION_NUM	((PJ_VERSION_NUM_MAJOR << 24) |	\
			 (PJ_VERSION_NUM_MINOR << 16) | \
			 (PJ_VERSION_NUM_REV << 8))

2) System information API in <pj/os.h>:

/**
 * These enumeration contains constants to indicate support of miscellaneous
 * system features. These will go in "flags" field of #pj_sys_info structure.
 */
typedef enum pj_sys_info_flag
{
    /**
     * Support for Apple iOS background feature.
     */
    PJ_SYS_HAS_IOS_BG = 1

} pj_sys_info_flag;


/**
 * This structure contains information about the system. Use #pj_get_sys_info()
 * to obtain the system information.
 */
typedef struct pj_sys_info
{
    /**
     * Null terminated string containing processor information (e.g. "i386",
     * "x86_64"). It may contain empty string if the value cannot be obtained.
     */
    pj_str_t	machine;

    /**
     * Null terminated string identifying the system operation (e.g. "Linux",
     * "win32", "wince"). It may contain empty string if the value cannot be
     * obtained.
     */
    pj_str_t	os_name;

    /**
     * A number containing the operating system version number. By convention,
     * this field is divided into four bytes, where the highest order byte
     * contains the most major version of the OS, the next less significant
     * byte contains the less major version, and so on. How the OS version
     * number is mapped into these four bytes would be specific for each OS.
     * For example, Linux-2.6.32-28 would yield "os_ver" value of 0x0206201c,
     * while for Windows 7 it will be 0x06010000 (because dwMajorVersion is
     * 6 and dwMinorVersion is 1 for Windows 7).
     *
     * This field may contain zero if the OS version cannot be obtained.
     */
    pj_uint32_t	os_ver;

    /**
     * Null terminated string identifying the SDK name that is used to build
     * the library (e.g. "glibc", "uclibc", "msvc", "wince"). It may contain
     * empty string if the value cannot eb obtained.
     */
    pj_str_t	sdk_name;

    /**
     * A number containing the SDK version, using the numbering convention as
     * the "os_ver" field. The value will be zero if the version cannot be
     * obtained.
     */
    pj_uint32_t	sdk_ver;

    /**
     * A longer null terminated string identifying the underlying system with
     * as much information as possible.
     */
    pj_str_t	info;

    /**
     * Other flags containing system specific information. The value is
     * bitmask of #pj_sys_info_flag constants.
     */
    pj_uint32_t	flags;

} pj_sys_info;


/**
 * Obtain the system information.
 *
 * @return	System information structure.
 */
PJ_DECL(const pj_sys_info*) pj_get_sys_info(void);

Currently PJLIB lacks a portable function to query what is the DNS server being configured/used in the system. On Windows, this can be done by calling GetNetworkParams(), while on *nix this has to be done by parsing /etc/resolv.conf.

The default file I/O back-end is to use ANSI stream API (fopen(), fread(), etc.), which works great since it is portable across platforms. However it has a limit of number of files that can be opened simultaneously (FOPEN_MAX), causing subsequent opening file to fail.

On Win32, we have alternative back-end of file I/O using Win32 native file operations (CreateFile?(), ReadFile?(), etc.), which doesn't have this limitation, but unfortunately this backend implementation is not being used.

Thanks David Clark for pointing this out.

New PJSIP book

When INVITE contains video line, PJSIP will reject it with 415, while it should accept the INVITE since the INVITE contains audio.

Sample SDP:

v=0
o=root 19999 20001 IN IP4 123.123.123.123
s=session
c=IN IP4 123.123.123.123
t=0 0
m=audio 51788 RTP/AVP 0 3 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
m=video 57688 RTP/AVP 34
a=rtpmap:34 H263/90000

PJSIP will reject incoming call with unknown media in the media line (for example, m=image line), even when the offer contains audio media line.

The correct behavior would be to accept the session and only reject the unsupported media line with zero port.

The PJSIP's DNS resolver is not destroyed, and this causes application to crash upon shutdown on Symbian.

Thanks Martin Peterzon for finding this bug!

See ticket #311

When target URI is an IP address, PJSIP resolver (sip_resolve.c) still tries to resolve it with pj_getaddrinfo(). While this normally is fine (although perhaps slightly inefficient), calling pj_getaddrinfo() does return error if IP address is given on certain Windows Mobile devices.

The solution is to avoid calling pj_getaddrinfo() if the target is an IP address.

This ticket adds a new pjsua callback to allow application use custom media transport for a particular call.

Prototype:

typedef enum pjsua_create_media_transport_flag
{
   /**
    * This flag indicates that the media transport must also close its
    * "member" or "child" transport when pjmedia_transport_close() is
    * called. If this flag is not specified, then the media transport
    * must not call pjmedia_transport_close() of its member transport.
    */
   PJSUA_MED_TP_CLOSE_MEMBER = 1

} pjsua_create_media_transport_flag;

/**
 * This callback can be used by application to implement custom media
 * transport adapter for the call, or to replace the media transport
 * with something completely new altogether.
 *
 * This callback is called when a new call is created. The library has
 * created a media transport for the call, and it is provided as the
 * \a base_tp argument of this callback. Upon returning, the callback
 * must return an instance of media transport to be used by the call.
 *
 * @param call_id       Call ID
 * @param media_idx     The media index in the SDP for which this media
 *                      transport will be used.
 * @param base_tp       The media transport which otherwise will be
 *                      used by the call has this callback not been
 *                      implemented.
 * @param flags         Bitmask from pjsua_create_media_transport_flag.
 *
 * @return              The callback must return an instance of media
 *                      transport to be used by the call.
 */
pjmedia_transport *on_create_media_transport(pjsua_call_id call_id,
                                            unsigned media_idx,
                                            pjmedia_transport *base_tp,
                                            unsigned flags);

According to draft-ietf-mmusic-ice-19 Section 8.1.2 Updating States:

"If any of those candidate pairs differ from the default candidate pairs in the most recent offer/answer exchange, the controlling agent MUST generate an updated offer as described in Section 9."

This ticket will add PJSUA2 Video Codec API and Video Device API

If any capture or playback device ID is set to PJSUA_SND_NULL_DEV (for null audio device), PJSUA will invoke pjsua_set_null_snd_dev() so both device IDs will be reset to PJSUA_SND_NULL_DEV again. Unfortunately PJSUA2 can only configure one audio device (only playback or capture) at one time, so it will never be able to switch over from null device.

Currently PJSUA2 internally maintains some lists of objects, e.g: AudioMedia, Buddy, AudioDevInfo, VideoDevInfo, CodecInfo. Unfortunately some APIs for querying and modifying those lists are not really thread safe. For example Endpoint::mediaEnumPorts() will simply return the internal list, and Endpoint::mediaAdd(), Endpoint::mediaRemove(), Endpoint::mediaExists() may access the internal list without mutex protection. Another example is enumeration function such as Aud/VidDevManager::enumDev(), CodecInfoVector &codecEnum() that returns internal list which always be updated at each call of the function, so if two threads call the same function at the same time, one of the thread will get an invalid list. Thank you Niclas Larsson for the report.

Since those PJSUA2 objects are actually just kind of thin wrapper of PJSUA objects, e.g: PJSUA2 AudioMedia is wrapping PJSUA conference bridge port ID, those object should be easily generated from PJSUA. So instead of maintaining list of objects internally, PJSUA2 can simply generate the requested objects on the fly. For example when enumeration function is called, the function will generate the PJSUA2 objects, generate a new list containing those object, and return the list. This way PJSUA2 can also avoid adding another layer of synchronization as PJSUA already provides the thread safety.

This ticket will deprecate these APIs:

• AudioMedia related: Call::getMedia(), AudioMediaVector, Endpoint::mediaEnumPorts(), Endpoint::mediaAdd(), Endpoint::mediaRemove(), Endpoint::mediaExists(), Endpoint::typecastFromMedia(), AudioMediaPlayer::typecastFromAudioMedia(), AudioMediaRecorder::typecastFromAudioMedia(), Endpoint::registerMediaPort()
• Buddy related: BuddyVector, Account::enumBuddies(), Account::findBuddy()
• Codec enumeration: CodecInfoVector, Endpoint::codecEnum(), Endpoint::videoCodecEnum()
• Audio/video device info: AudioDevInfoVector, VideoDevInfoVector, AudDevManager::enumDev(), VidDevManager::enumDev()

This ticket will introduce new APIs:

• AudioMedia related: Call::getAudioMedia(), AudioMediaVector2, Endpoint::mediaEnumPorts2(), Endpoint::registerMediaPort2()
• Buddy related: BuddyVector2, Account::enumBuddies2(), Account::findBuddy2()
• Codec enumeration: CodecInfoVector2, Endpoint::codecEnum2(), Endpoint::videoCodecEnum2()
• Audio/video device info: AudioDevInfoVector2, VideoDevInfoVector2, AudDevManager::enumDev2(), VidDevManager::enumDev2()

See mailing list discussions:

• ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-January/001408.html
• ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-January/001435.html

PJSIP is not retrying the PRACK request if it is challenged with 401/407 response.

Ruud Klaver reports ​this in pjsip mailing list:

First off, let me describe the scenario that led me to this. I have three endpoints, two of which are my application that is using PJSIP, let's call them endpoint A and B. Endpoint C is a third party SIP UA that sets 100rel in the Required header. I am using endpoint A to send an INVITE to a SIP address to which both endpoint B and C have REGISTERed. This leads to the following sequence of events:

• Endpoint B sends a 180 Trying in response to the INVITE
• Endpoint A records the Contact header of endpoint B as target for the dialog
• Endpoint C is a little slower and also sends a 180 Trying, including Required: 100rel
• Endpoint A sends a PRACK in response to the 180 from endpoint C, but puts as the request URI the target recorded for the dialog, which is the URi in the Contact header of endpoint B.
• The PRACK ends up at endpoint B instead of C, which promptly crashes with an assertion failure, as the PJSIP_INV_REQUIRE_100REL option was not set on pjsip_inv_verify_request().

When presence publication is enabled in pjsua account, pjsua-api sends PUBLISH overlapping with REGISTER, and when the REGISTER is challenged with 401/407, the PUBLISH request will be rejected with 404/Not Found.

Thanks Edward Tian for reporting the problem.

When presence publication is enabled in pjsua account, pjsua-api sends PUBLISH overlapping with REGISTER, and when the REGISTER is challenged with 401/407, the PUBLISH request will be rejected with 404/Not Found.

Thanks Edward Tian for reporting the problem.

This is the duplicate of ticket #90 for the 0.5-stable branch.

The presence publication session is not initialized with account's route set, causing the PUBLISH request to be sent directly to server even when --outbound or --proxy exist.

See ticket #190.

When ioqueue_recv() fails with immediate error in UDP transport, the bytes_read variable is not set properly, causing the stream to incorrectly try to parse the packet.

This causes some "invalid RTP version" error message to be printed. It may cause more serious error too, such as switching transport address to an invalid destination.

pjsua has a packet simulation option (rx-drop-pct and tx-drop-pct option), but this is currently only used by UDP media transport.

Add similar option in ICE media transport.

The NAT detection and STUN mapped address detection routines in PJLIB-UTIL assume that they communicate with old/RFC 3489 compliant server. When they communicate with new/STUNbis STUN server, the server may put some attributes that have padding rule (e.g. SOFTWARE attribute), and this will cause the STUN message decoding routine to fail.

All parsing fails on big endian machines, caused by #206.

Thanks Hozjan Vladimir <hozjan at iskratel si>.

See ticket #232

Consider this scenario, where pjsip acts as UAC:

  UAC            
  ------- INVITE+SDP ------>
  <------- 100 -------------
  <--- 183+SDP, from UAS1 --
  <--- 200+SDP, from UAS2 --

One scenario where the above happens include the use of ringback tone server which generates the 183 response (with SDP), before the call is answered by the destination UAS.

Currently the scenario above is not supported, since pjsip will ignore the second SDP (in the 200/OK response), as it has marked the SDP negotiation as complete when it received the 183 response. This, among other things, would cause pjsip to transmit RTP packets with wrong payload type, if the second SDP has selected different format than the first SDP.

This ticket adds enhancement where pjsip should detect that the second SDP is coming from different call leg, hence it should renegotiate the SDP and call on_media_update().

This is a fatal bug in fixes of ticket #919, missing codec type checking in initializing iLBC parameters.

See ticket #958 for more info.

870d869
<   --disable-alsa          Disable ALSA and use OSS
8552,8561d8550
< if test "${enable_alsa+set}" = set; then
<   enableval="$enable_alsa"
<   if test "$enable_alsa" = "no"; then
<                 ac_pa_use_alsa=0
<               echo "$as_me:4396: Alsa available but disabling ... yes" >&5
< echo "${ECHO_T}Alsa available but disabling... yes" >&6
<   else
<                 ac_pa_use_alsa=1
<   fi
< fi;

Thanks Purna Chandar M.

When building libportaudio fresh from sources, the path of DirectX installation needs to be manually inserted. The attached patch tries to resolve the environment variable DXSDK_DIR which should be added by installation of DirectX SDK.

When the library is shutdown, pending outgoing TCP transmission will be cancelled and callback will be called. Unfortunately, some library components such as transaction layer have already been destroyed and hence it will cause access to already freed memory location, or the transaction layer itself may have not been destroyed (if there is pending tsx), but the stateful util module had been unregistered and hence it will cause access to bad memory location.

Sample stack trace:

Thread 4 Crashed:

0   App                       0x00195294 mod_util_on_tsx_state (sip_util_statefull.c:77)
1   App                       0x001922ee tsx_set_state (sip_transaction.c:1145)
2   App                       0x001933a8 send_msg_callback (sip_transaction.c:1828)
3   App                       0x0018597a stateless_send_transport_cb (sip_util.c:1112)
4   App                       0x001880f4 transport_send_callback (sip_transport.c:625)
5   App                       0x0018c59e on_data_sent (sip_transport_tcp.c:1050)
6   App                       0x0018bc1c tcp_destroy (sip_transport_tcp.c:731)
7   App                       0x0018bb42 tcp_destroy_transport (sip_transport_tcp.c:689)
8   App                       0x00188934 destroy_transport (sip_transport.c:954)
9   App                       0x00188fe8 pjsip_tpmgr_destroy (sip_transport.c:1275)
10  App                       0x00183190 pjsip_endpt_destroy (sip_endpoint.c:587)
11  App                       0x001bec0c pjsua_destroy2 (pjsua_core.c:1503)
12  App                       0x001bef4a pjsua_destroy (pjsua_core.c:1582)
13  App                       0x000d893e -[CallManagerSingleton app_destroy] (CallManagerSingleton.m:961)
14  App                       0x000bbc34 -[SAppDelegate start_app] (SAppDelegate.m:1151)
15  Foundation                0x34ff0a7a -[NSThread main] + 66
16  Foundation                0x3508458a __NSThread__main__ + 1042
17  libsystem_c.dylib         0x3292472e _pthread_start + 314
18  libsystem_c.dylib         0x329245e8 thread_start + 0

Thanks Michael Fortson for the report.

Stream should periodically transmit a silence frame once in a while to keep NAT bindings on and to prevent remote end from tearing down the call when there's no activity on the stream.

​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-April/002513.html after destroyed, wav player port get_frame() returns PJ_SUCCESS to conference, so the conference continue accessing the wav player port.

With sample apps and tests focused on Android only.

With sample apps (pjsua2) and tests focused on Android only.

Seems related to Forum Nokia known issue of VAS on E72, see ​here.

Also reported that the problem was occurred on E52.

The full report can be found ​in this thread.

The problem seems to be caused by modification in ticket #744.

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