Custom Query (2195 matches)

Assertion:

../src/pjsip/sip_transaction.c: 3246: tsx_on_state_confirmed: Assertion `event->body.timer.entry == &tsx->timeout_timer'

The scenario is as follows:

1. ACK arrives late, at the same time with retransmit timer event.
2. The ACK is processed, causing transaction to move to CONFIRMED state.
3. The retransmit timer is processed in CONFIRMED state, causing assertion.

Example:

m=video 55894 RTP/AVP 31 123
a=rtpmap:123 H264/90000
a=fmtp:123 profile-level-id=42801f;packetization-mode=0;level-asymmetry-allowed=1

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.

Scenario:

1. Make call with default call flags where PJSUA_CALL_INCLUDE_DISABLED_MEDIA is set, so SDP offer contains 2 m= lines: audio and disabled video
2. After call is established, initiate re-INVITE with call option flag set to only PJSUA_CALL_REINIT_MEDIA (PJSUA_CALL_INCLUDE_DISABLED_MEDIA is cleared). This time SDP offer also contains 2 m= lines: audio and disabled video.
3. Assertion raised:

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

   with call->med_prov_cnt==1, call->med_cnt==2, local_sdp->media_count==2.

After investigation, we found that pjsua_media_channel_init() with PJSUA_CALL_REINIT_MEDIA causes call->med_prov_cnt==1 due to PJSUA_CALL_INCLUDE_DISABLED_MEDIA flag is not set, but pjmedia_sdp_neg_modify_local_offer2() adds a new m= line (i.e: disabled video from current active local SDP) to the SDP to maintain the media count (as mandated by standard). Eventually as call->med_prov_cnt is less than the number of m= line, assertion is raised.

Thanks Nadia Lapkovskaya for the report.

Reported that when calling pj_gethostip() on a system whose empty hostname, pj_getaddrinfo() will raise assert at this line:

    PJ_ASSERT_RETURN(nodename->ptr && nodename->slen, PJ_EINVAL);

Thanks Denis Poltorak for the report.

See ​this post on PJSIP mailing list.

It is suspected that this may be caused by a race condition.

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:

• 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);

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

Transport loop don't like to be detached twice. Firstly at stream destroy(), secondly at transport destroy() (transport SRTP destroy() calls detach() of member transport).

Reported that a segmentation fault occurs after upgrading to PJSIP 2.5.5 and the investigation leads to deinitialization of uninitialized client auth session when dialog creation fails.

Note that pjsip_auth_clt_deinit() has this validity check:

PJ_ASSERT_RETURN(sess && sess->endpt, PJ_EINVAL);

and in dialog creation, sess->endpt should be NULL when client auth session is uninitialized. So the deinitialization of uninitialized session will raise assertion on debug mode, or return error on NDEBUG mode, or crash when accessing NULL pointer when PJ_ENABLE_EXTRA_CHECK is turned off.

Thanks to Pirmin Walthert for the report and the analysis. Original report can be found ​here.

This is caused by a bug in samples-per-frame calculation PJMEDIA_SPF(). So applications that use PJMEDIA_SPF() for allocating buffer will get "too small buffer size" error or assertion from codec.

onIncomingCall() callback may be simulated by onCreateMediaTransport() (see #1916). And if app happens to answer the call from the callback, assertion is raised:

Assertion failed: inv->last_answer, file pjsip/src/pjsip-ua/sip_inv.c, line 2321

Call stack:

abort()  Line 59 + 0x7 bytes	C
_wassert(const wchar_t * expr=0x00820b4c, const wchar_t * filename=0x0081fc60, unsigned int lineno=2321)  Line 212	C
pjsip_inv_answer(pjsip_inv_session * inv=0x02ac9244, int st_code=200, const pj_str_t * st_text=0x00000000, const pjmedia_sdp_session * local_sdp=0x00000000, pjsip_tx_data * * p_tdata=0x034ae44c)  Line 2321 + 0x2b bytes	C
pjsua_call_answer2(int call_id=0, const pjsua_call_setting * opt=0x00000000, unsigned int code=200, const pj_str_t * reason=0x00000000, const pjsua_msg_data * msg_data=0x00000000)  Line 2261 + 0x1a bytes	C
pj::Call::answer(const pj::CallOpParam & prm={...})  Line 498 + 0x1f bytes	C++
MyAccount::onIncomingCall(pj::OnIncomingCallParam & iprm={...})  Line 91	C++
pj::Endpoint::on_incoming_call(int acc_id=0, int call_id=0, pjsip_rx_data * rdata=0x02ac5b84)  Line 622	C++
pj::Endpoint::on_create_media_transport(int call_id=0, unsigned int media_idx=0, pjmedia_transport * base_tp=0x02acdbc4, unsigned int flags=1)  Line 1247 + 0x1a bytes	C++
media_channel_init_cb(int call_id=0, const pjsua_med_tp_state_info * info=0x00000000)  Line 1646 + 0x19 bytes	C
pjsua_media_channel_init(int call_id=0, pjsip_role_e role=PJSIP_ROLE_UAS, int security_level=0, pj_pool_t * tmp_pool=0x02ac0f90, const pjmedia_sdp_session * rem_sdp=0x02ac39a0, int * sip_err_code=0x034af564, int async=1, int (int, const pjsua_med_tp_state_info *)* cb=0x005e0a70)  Line 2029 + 0xb bytes	C
pjsua_call_on_incoming(pjsip_rx_data * rdata=0x02ac1fe4)  Line 1492 + 0x29 bytes	C

An idea is to delay the call-answer until initial answer is sent and some other call initializations are done.

Reported that while destroying pjsua, on_call_state() callback is called (for call disconnection), and from the callback app tries to disconnect conference bridge ports, but unfortunately media subsystem, including the conference bridge, has been destroyed at that point, so assertion is raised.

Assertion will be raised for the titled scenario, with the following stack trace:

8 __assert_fail()
7 send_refresh() pjnath/src/pjnath/turn_session.c:886
6 sess_shutdown() pjnath/src/pjnath/turn_session.c:424
5 pj_turn_session_shutdown() pjnath/src/pjnath/turn_session.c:457
4 pj_turn_sock_destroy() pjnath/src/pjnath/turn_sock.c:238

The assertion line:

Assertion failed: mod_tsx_layer.endpt==((void *)0),
file pjsip\src\pjsip\sip_transaction.c, line 436

This assertion doesn't always happen, however it is reproducible with a special test app containing a loop of: pjsua create+init+start, register, making call, call hold/unhold, call hangup, pjsua destroy. Supplying non-zero flag to the pjsua_destroy2() will lead to the assertion faster.

Assertion in function start_nominated_check() in ice_session.c when regular nomination is being used.

This can be reproduced by limiting host candidate to one with "media_cfg.ice_max_host_cands = 1", and setting the STUN server in the same LAN.

This bug was introduced by changeset r4133 for ticket #1512 for milestone:release-2.0.

Also fix another assertion caused by ICE strans that is allowed to run without any candidates. This happens in two situations:

1. during creation, with host candidates disabled and no STUN/TURN enabled.
2. during initialization, with host candidates disabled, and STUN resolution yields error, and cfg.stun.ignore_stun_error is set.

This happens when STUN is not used, and remote sends Binding Request when the ICE session has not been created.

Assertion is raised for the sample scenario in the title.

This seems to be related to changeset r4652, timer was always cancelled, but now it is not when mod_count==TRUE.

Reproducing step:

1. run 2 pjsua with --use-ice param, no STUN/TURN
2. make call from one to another, and just accept the call on the receiving side
3. assertion happens on both sides once ICE connectivity check is started.

Assertion line:

Assertion failed: (tsx->retransmit_timer.id == 0 || !tsx->require_retransmit), function tsx_transmit_msg, file ../src/pjnath/stun_transaction.c, line 204.

With Visual Studion 2005 and possibly later, the ctype.h functions such as isdigit() will raise assertion error if given input with ASCII > 127 character. This is because the functions takes int argument, and ASCII character > 127 will be represented as negative value.

Assertion is triggered when 200/OK is received with strict Record-Route, while the original INVITE request doesn't contain the corresponding Route request.

Please see attachment for the log.

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

After remote removes some media lines in previous SDP negotiations, when trying to create an offer, PJSIP will trigger an assertion:

Assertion failed: mi < s_->media_count, file pjsip\trunk\pjsip\src\pjsua-lib\pjsua_media.c

Scenario:

• Receive incoming call with 2 medias, 1 audio and 1 unsupported media (such as video for PJSIP compiled with audio only)
• Receive re-invite with only one media (audio)
• Try to send re-invite from PJSIP

Thanks to Eize Slange for the report.

To reproduce:

• We send INVITE with video
• RX 200 OK without m=video
• call is established
• RX re-INVITE, without m=video
• assertion in transport_srtp.c:1299 “pj_assert(sdp_remote && m_rem);”

Ref: voxeo

Assertion will be raised if remote offers new media during call.

As reported by Brian Walker. Stack trace:

pjsip_100rel_end_session (in MobileClient) + 91
inv_set_state (in MobileClient) + 211
inv_on_state_early (in MobileClient) + 685
mod_inv_on_tsx_state (in MobileClient) + 69
pjsip_dlg_on_tsx_state (in MobileClient) + 109
tsx_timer_callback (in MobileClient) + 227
pj_timer_heap_poll (in MobileClient) + 159
pjsip_endpt_handle_events2 (in MobileClient) + 47
worker_thread (in MobileClient) + 65
thread_main (in MobileClient) + 67

Similar report can be found in the mailing list (March 2014): ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2014-March/017290.html

Assertion will be raised when calling pjsip_tsx_set_timeout() in sip_inv.c:3698, if BYE is received while callee is still in early state.

This bug may also cause the UAS INVITE transaction to be alive forever.

The pjsua_destroy() function performs event polling during the shutdown sequence. If a 200/OK INVITE response is received during this process, an assertion will be raised:

pjsua-x86_64-unknown-linux-gnu: ../src/pjmedia/session.c:604: pjmedia_session_info_from_sdp: Assertion `pool && endpt && si && local && remote' failed.

The assertion happens when negotiating the SDP and calling media update, which causes pjmedia_session_info_from_sdp() to be called. Unfortunately at this point the media endpoint has been destroyed and set to NULL, causing the assertion.

Break point:

PJ_DEF(pj_status_t) pjsip_evsub_terminate( pjsip_evsub *sub,
					   pj_bool_t notify )
{
    PJ_ASSERT_RETURN(sub, PJ_EINVAL);



Call stack:

	htmlview.exe!_wassert(const wchar_t * expr=0x006f93c4, const wchar_t * filename=0x0071b380, unsigned int lineno=878)  Line 384

        htmlview.exe!pjsip_evsub_terminate(pjsip_evsub * sub=0x00000000, int notify=0)  Line 878 + 0x1e bytes	C
 	htmlview.exe!pjsip_pres_terminate(pjsip_evsub * sub=0x00000000, int notify=0)  Line 332 + 0xd bytes	C
 	htmlview.exe!unsubscribe_buddy_presence(unsigned int index=0) Line 1050 + 0xe bytes	
 	htmlview.exe!refresh_client_subscriptions()  Line 1072 + 0x9 bytes	C
 	htmlview.exe!pjsua_pres_refresh()  Line 1120	C
 	htmlview.exe!pjsua_pres_shutdown()  Line 1145	C
 	htmlview.exe!pjsua_destroy()  Line 666	C

Thanks Edward Tian for reporting this.

When a buddy is added with the URL containing invalid or unreachable host, pjsip will raise assert upon trying to destroy the subscription with pjsip_pres_terminate, since the subscription has already been destroyed thus NULL is given.

Symptom:

Assertion pj_assert(tdata == check->tdata) in on_stun_request_complete() function in ice_session.c:1771, because STUN client transaction completes while the connectivity check doesn't have record for this transaction.

Assertion will occur if bad TURN server name is given and nameserver is configured. This is because the DNS error is not propagated to the ICE error.

Stack trace:

30 __assert_fail()  0x00007ffff5aeb941	
29 pj_sockaddr_get_len() /home/bennylp/Desktop/project/pjsip/2.x/pjlib/src/pj/sock_common.c:386 0x0000000000571248	
28 pj_sockaddr_cp() /home/bennylp/Desktop/project/pjsip/2.x/pjlib/src/pj/sock_common.c:409 0x00000000005712f2	
27 transport_get_info() /home/bennylp/Desktop/project/pjsip/2.x/pjmedia/src/pjmedia/transport_ice.c:1504 0x00000000004cc5b8	
26 pjmedia_transport_get_info() /home/bennylp/Desktop/project/pjsip/2.x/pjmedia/include/pjmedia/transport.h:577 0x00000000004cd3b5	
25 transport_get_info() /home/bennylp/Desktop/project/pjsip/2.x/pjmedia/src/pjmedia/transport_srtp.c:698 0x00000000004cea7d	
24 pjmedia_transport_get_info() /home/bennylp/Desktop/project/pjsip/2.x/pjmedia/include/pjmedia/transport.h:577 0x0000000000432a3f	
23 pjsua_media_channel_create_sdp() /home/bennylp/Desktop/project/pjsip/2.x/pjsip/src/pjsua-lib/pjsua_media.c:1889 0x0000000000435de9	
22 on_make_call_med_tp_complete() /home/bennylp/Desktop/project/pjsip/2.x/pjsip/src/pjsua-lib/pjsua_call.c:365 0x0000000000424324	

This ticket is for backporting of ticket #1399 which belongs to release-2.0-beta.

Assertion in sip_transaction.c when the transaction layer is being unloaded and a transaction is still pending/waiting for transport operation to complete, for example when TCP/TLS transport is connecting to the destination.

Typical stack trace:

17 pj_thread_local_get()  ..\pjlib\src\pj\os_core_symbian.cpp:699 0x789f0dd4
16 lock_tsx()             ..\pjsip\src\pjsip\sip_transaction.c:902 0x78973914
15 send_msg_callback()    ..\pjsip\src\pjsip\sip_transaction.c:1642 0x7897543c
14 stateless_send_transport_cb() ..\pjsip\src\pjsip\sip_util.c:1074 0x78987c40
13 transport_send_callback() ..\pjsip\src\pjsip\sip_transport.c:610 0x78978e60
12 on_data_sent()         ..\pjsip\src\pjsip\sip_transport_tls.c:1009 0x78981204
11 tls_destroy()          ..\pjsip\src\pjsip\sip_transport_tls.c:662 0x7898067c
10 tls_destroy_transport() ..\pjsip\src\pjsip\sip_transport_tls.c:621 0x78980578
9 destroy_transport()     ..\pjsip\src\pjsip\sip_transport.c:941 0x78979878
8 pjsip_tpmgr_destroy()   ..\pjsip\src\pjsip\sip_transport.c:1258 0x7897a250
7 pjsip_endpt_destroy()   ..\pjsip\src\pjsip\sip_endpoint.c:595 0x789643bc
6 pjsua_destroy()         ..\pjsip\src\pjsua-lib\pjsua_core.c:1596 0x7892c4f8

When application is doing reregistration with pjsua_acc_del() followed by pjsua_acc_add(), it may trigger the following assertion:

pjsua-i686-pc-linux-gnu: ../src/pjsua-lib/pjsua_acc.c:591:
acc_check_nat_addr: Assertion `uri != ((void *)0)' failed.
Aborted (core dumped)

Thanks Dan Åberg and Salahuddin Ahmed for the report.

Scenario (pjsua as UAC):

 pjsua                  UAS
-----------------------------
  INVITE          -->
  200/OK (INVITE) <--
  BYE             -->
  ACK             -->
  200/OK (BYE)    <--
  200/OK (INVITE) <--
  ACK             -->

This scenario happens when the SDP in 200/OK is not acceptable hence pjsua sends BYE to disconnect the call.

Upon sending ACK for the 200/OK retransmission, pjsip incorrectly sets the invite session state back to CONFIRMED after it has been DISCONNECTED, causing assertion and possibly crash.

Thank you Dan Åberg for the report.

To reproduce the error

Sample scenario: pjsua is configured with mandatory SRTP, and the SDP in 200/OK answer doesn't contain valid SRTP description.

• run pjsua with:

  --null-audio --local-port 0 --use-srtp 2 --srtp-secure 0
  

• run SIPp as UAS with the attached scenario

See ticket #300

When pjsua account is removed while the network is disconnected, assertion will be triggered when calling pjsip_regc_destroy() since the regc variable has been set to NULL.

Stack trace:

pjsua_call_on_incoming()
pjsip_dlg_respond(dlg, rdata, sip_err_code, NULL, NULL, NULL);
pjsip_dlg_create_response()
pjsip_endpt_create_response()

There is a possibility, when media initialization fails, that sip_err_code is never set (the value is still zero), hence resulting in the assertion in pjsip_endpt_create_response():

PJ_ASSERT_RETURN(st_code >= 100 && st_code <= 699, PJ_EINVAL);

A stray timer may be emitted in UAC transaction completed state (tsx_on_state_completed_uac()) due to concurrency. This happens when state transmission occurs simultaneously when the timer is being fired.

We could safely ignore this.

The assertion info is as follows:

(gdb) frame 4
#4  0x00007fffb7368eba in tsx_on_state_completed_uac
    at ../src/pjsip/sip_transaction.c:3177
3177		pj_assert(event->body.timer.entry == &tsx->timeout_timer);

Thank you Joshua Colp for the report.

Scenario (thanks to Fredrik Hansson for the report):

1. In pjsua_call_on_incoming() function, after pjsua_media_channel_init() call returns PJ_SUCCESS, on_incoming_call_med_tp_complete() is called.
2. on_incoming_call_med_tp_complete() returns !PJ_SUCCESS
3. pjsip_dlg_respond() is entered.
4. The response is created without problem and the pjsip_dlg_send_response() is called.
5. We end up on the call to pjsip_dlg_dec_lock_().
6. In the pjsip_dlg_dec_lock() function the session_count == 0 and tsx_count == 0 and we call the unregister_and_destroy_dialog() function.
7. Then the destroy_dialog() is called which destroys the dlg->mutex_ if it exists.
8. After the mutex is destroyed we returns all the way back from the pjsip_dlg_respond() call.
9. After returning from pjsip_dlg_respond() the pjsip_inv_terminate() function is called.
10. In the pjsip_inv_terminate() function the dialog is locked which will lead to an assert since the mutex is already destroyed

Symptom:

When pjsua is run with ICE, STUN, and TURN, and pjsua is not behind NAT, the following assertion will be triggered when making a call:

On v0.9:

  ./src/pjnath/ice_strans.c:826: pj_ice_strans_get_def_cand: Assertion 
`comp->default_cand>=0 && comp->default_cand<comp->cand_cnt' failed.

On v1.0-rc1 (only the line number is different):

  ./src/pjnath/ice_strans.c:853: pj_ice_strans_get_def_cand: Assertion 
`comp->default_cand>=0 && comp->default_cand<comp->cand_cnt' failed.

How to reproduce:

This can be reproduced by using the following pjsua command-line arguments:

--use-ice --use-turn --stun-srv=192.168.0.2 --turn-srv=192.168.0.2:34780 \
--turn-user=100 --turn-passwd=100

Note that the STUN server is on the same LAN as the client.

Description:

When ICE stream transport (ice_strans)is initialized, it selects a default candidate to be used as the primary address in the SDP. The default candidate is TURN candidate if TURN is used.

During the address resolution process, the STUN candidate will be removed from the candidate list if the mapped address matches one of the host addresses (i.e. when the client is not behind NAT). This process is called pruning in pjnath.

Unfortunately, the default candidate index is not updated when a candidate is removed, hence the assertion.

Assertion line:

amr_helper.h:922: pjmedia_codec_amr_pack: Assertion `FT <= SID_FT || FT == 14 || FT == 15' failed.

After investigation, a fatal bug is found in ipp_codecs.c pack_amr() in setting up AMR-WB frame size, i.e: using AMR-NB frame size table instead of AMR-WB's.

This will cause wrong AMR-WB data pointers returned by the encoder (only the first frame gets the correct pointer) and the RTP payload generated (by AMR packetizer) will contain corrupted bitstream. So even if assertion is not raised, e.g: release mode or accidentally packetizer always read valid frame types in the wrong data pointer, this will definitely cause noise.

Note that in single frame per packet this issue is never raised as the first frame pointer always points to correct AMR bistream and the AMR packetizer doesn't really read the frame size info supplied by encoder (it uses AMR frame size lookup table instead).

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.

Output buffer size of stream is calculated based on codec bandwidth, so when a very low bandwidth codec is used, e.g: MELP 2.4kbps, the calculation result will be too small to hold RTCP SR packet containing SDES.

Reported scenarios:

Scenario 1 - assertion of "Currently no media transport reuse"

1. receive offer with 2 media lines, RTP/SAVP and RTP/AVP, both active
2. accept with 2 media lines in answer, RTP/SAVP gets port zeroed and RTP/AVP active (SRTP mode is set to disabled)
3. receive reoffer with only 1 media line, RTP/AVP
4. accept the reoffer
5. receive reoffer with 2 media lines as in no 1, and assert occurs

It is caused by improper stopping and clean up of the removed media.

Scenario 2 - crash after accessing invalid call_med->tp pointer

1. receive offer with 2 media lines, RTP/SAVP and RTP/AVP, both active
2. send answer with 2 media lines, RTP/SAVP gets port zeroed and RTP/AVP active (SRTP mode is set to disabled)
3. receive reoffer with only 1 media line, RTP/AVP
4. reject the reoffer (e.g: because of no matching codec)
5. receive reoffer with 2 media lines as in no 1, crash occurs

This seems to be a bug in r5124 (initial fix of scenario 1), it stops the removed media stream and cleans up its media transport right after receiving reoffer with less media lines (no 3), so when the SDP nego fails (the re-offer is rejected), call media states become inconsistent. Note that in SDP reoffer/answer, we shouldn't modify the media streams before SDP nego is done, as if SDP nego fails, the media streams should be maintained as if there is no SDP reoffer.

Also revisiting a related ticket #1626, where it modifies the media streams before SDP nego: the assertion happens because it gets into unknown media type block handler, while it should never do. So we need to update the fix, e.g: only set the media type when it is undefined.

Thanks to Brian Walker for the reports.

(Lack of) array bounds checking in various SDP parse functions may cause memory corruption.

The OpenH264 decoder may return non-dsErrorFree and still produce a frame usually with some noise. This ticket will filter the frame quality by inspecting the return code of the decoder, i.e: drop the frame if some specific error codes are returned (dsRefLost dsNoParamSets, dsDepLayerLost).

Here are the RTCP related enhancements to be applied into video stream:

• #1268 (Option for automatic/manual sending of RTCP SDES/BYE for the stream)
• #1440 (Proper set up of RTCP compound packet)

Related issue:

• when sending resolution in default codec param is higher for remote profile-level, scale it down but try to maintain the aspect ratio
• when decoding resolution in default codec param is lower than local profile-level, adjust it, note that this param is used by rendering video device to allocate buffer, so it must be set to the maximum
• normalize encoding/decoding bitrate.

In <pj/pool.h>:

     /**
      * Internal pool.
      */
    char	    pool_buf[256];

This caused problem on 64bit machines.

This feature will be auto detected and enabled by configure script.

The implementation is using android.hardware.Camera class.

Port PJSIP to Android platform. Note that this task excludes the creation of JNI API for PJSUA-LIB, which will be noted on separate ticket (see #1123).

Android build for Intel breaks with these error:

/android-ndk//sources/cxx-stl/gnu-libstdc++/4.8/include/ext/atomicity.h: In function '_Atomic_word __gnu_cxx::__exchange_and_add(volatile _Atomic_word*, int)':
/android-ndk//sources/cxx-stl/gnu-libstdc++/4.8/include/ext/atomicity.h:50:45: error: '__ATOMIC_ACQ_REL' was not declared in this scope
/android-ndk//sources/cxx-stl/gnu-libstdc++/4.8/include/ext/atomicity.h:50:61: error: '__atomic_fetch_add' was not declared in this scope
/android-ndk//sources/cxx-stl/gnu-libstdc++/4.8/include/ext/atomicity.h: In function 'void __gnu_cxx::__atomic_add(volatile _Atomic_word*, int)':
/android-ndk//sources/cxx-stl/gnu-libstdc++/4.8/include/ext/atomicity.h:54:38: error: '__ATOMIC_ACQ_REL' was not declared in this scope
/android-ndk//sources/cxx-stl/gnu-libstdc++/4.8/include/ext/atomicity.h:54:54: error: '__atomic_fetch_add' was not declared in this scope

The suspect is the wrong libs used (armeabi) specified in the configure-android script.

Since #1961 pjsip use ANDROID_ALARM_GET_TIME for timestamp. However NDK r14 no longer support this by removing android_alarm.h. This patch will detect the android_alarm.h, and if it wasn't found ,timestamp will use CLOCK_BOOTTIME instead.

Integrate android works on SVN android branch into SVN trunk.

Currently, pjsua will do asymmetric iLBC mode when SDP offer answer specify different iLBC mode.

RFC 3952 Section 5:

   It is important to emphasize the bi-directional character of the
   "mode" parameter - both sides of a bi-directional session MUST use
   the same "mode" value.

   The offer contains the preferred mode of the offerer.  The answerer
   may agree to that mode by including the same mode in the answer, or
   may include a different mode.  The resulting mode used by both
   parties SHALL be the lower of the bandwidth modes in the offer and
   answer.

   That is, an offer of "mode=20" receiving an answer of "mode=30" will
   result in "mode=30" being used by both participants.  Similarly, an
   offer of "mode=30" and an answer of "mode=20" will result in
   "mode=30" being used by both participants.

Some UAs (non-compliant UAs, I might say) have a bad habit of adding whitespaces at the end of SDP lines. This is non-conformant, of course, but in the spirit of "be lenient on what you receive", the SDP parser should probably forgive this.

Thanks Briac Hardouin for pointing this out.

Currently, media transport info only return socket info, this is considered to be insufficient since specific transport info could not be fetched.

This enhancement will also answer a feature request about SRTP status retrieval. ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-February/001700.html (thanks Klaus Darilion)

It would be nice if PJSIP allows not only to load certificate from a file, but also from a memory, for example if the certificate is embedded in the application or if it's retrieved from Windows certificate store. Also it may improve performance, especially for server app, because currently the same certificate may be read again and again from disk.

Thanks Klaus Darilion and Peter Koletzki for the suggestion.

Some application wants to be able to use PJLIB before pjsua_create() and after pjsua_destroy() is called, or to continue using PJLIB objects while PJSUA-LIB is being restarted. This was not possible because when application is utilizing PJSUA-LIB, the PJLIB library is initialized in pjsua_create() and shutdown in pjsua_destroy().

The solution that this ticket implements is to allow pj_init() and pj_shutdown() to be called multiple times, and PJLIB should use internal reference counting to determine when it needs to actually be initialized or shutdown. Hence if application wants to use PJLIB before pjsua_create(), it should call pj_init() manually beforehand, and call pj_shutdown() when it's finished with using PJLIB.

Note that there MUST be equal number of calls to pj_shutdown() for every call to pj_init(), or otherwise PJLIB won't get shutdown!

Also note that this solution calls for moving some pj_atexit() use in higher library layers into a new equivalent functionality. This task will be implemented by this ticket too.

Add --playback-dev and --capture-dev options in pjsua to select sound devices to use.

Thanks Michael Smith (msmith at cbnco.com) for the patch!

Add --playback-dev and --capture-dev options in pjsua to select sound devices to use.

Thanks Michael Smith (msmith at cbnco.com) for the patch!

Patch:

Allow single quotes in XML attributes, and also added pj_scan_get_quotes().

Thanks much Tory Patnoe <tpatnoe at jabber com> for the patch!

See ticket #206.

Video codec framework employs SDP fmtp attribute for specifying codec specific parameters, e.g: MPI in H263, profile-level in H264. When SDP fmtp is not supplied, the codec will apply default values and this may override the 'standard' video parameters, such as size and frame rate, specified in pjmedia_format.

While application may want to specify the 'standard' video parameters only (no SDP fmtp) and don't want them overridden by default values because of empty/unsupplied SDP fmtp.

To allow app to set the output window, the video device wrapper needs to support PJMEDIA_VID_DEV_CAP_OUTPUT_WINDOW capability and can be set using pjsua_vid_win_set_win() or VideoWindow::setWindow().

This ticket will add the support for SDL.

This ticket adds support for SDP negotiator which allows to respond an offer with multiple codecs.

Currently, wenerating new offer, in case that media lines do not match the active SDP, the negotiator will fix the new offer by reordering and adding the missing media lines.

This ticket will allow new media line to replace the existing media at the same position.

Currently PJSUA-LIB rejects incoming MESSAGE request with 488/Not Acceptable Here if the MESSAGE request doesn't contain message body.

In some OMA specification, under Push-to-Talk/PoC, there is a feature called IPA (Instant Personal Alert), where peer requests for ringback using MESSAGE request with empty body.

So we probably don't need to check for the message body.

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.

Currently if STUN server is down, PJSUA-LIB initialization will fail. Having more than one STUN servers will increase the robustness of the application in this case.

Also it may be desirable to allow application startup to continue when STUN servers fail to be contacted. Some firewall with SIP ALG (notably Microsoft Forefront Threat Management Gateway) may decidedly block STUN traffic, since it can manipulate private address in SIP packet into public address.

Currently the pjnath ICE session and transport do not allow data transmission to pass once negotiation has failed. Some applications may want to proceed with sending data anyway, hence the ICE session and transport need to change their behavior to allow this. The data will be sent using the default candidate to the desired destination address. Applications who do not wish to use this feature can just disconnect the call after ICE negotiation fails as usual.

Please see "3PCC call transfer implementation" thread on PJSIP mailing list archive for discussion (​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2007-November/000713.html)

When using PJSIP and a SIP packet containing Via "received" with an IPv6 address delimited by [ and ] is received, PJSIP drops such a packet complaining about the [ and ]. No calls can be established.

Via: SIP/2.0/UDP [2001:db8::9:1];received=[2001:db8::9:255];branch=z9hG4bKas3-111"

From RFC 5118 section 4.5:

While it would be beneficial if the same non-terminal ("IPv6reference") was used for both the "sent-by" and "via-received" production rules, there has not been a consensus in the working group to that effect. Thus, the best that can be suggested is that implementations must follow the Robustness Principle [RFC1122] and be liberal in accepting a "received" parameter with or without the delimiting [ and ] tokens. When sending a request, implementations must not put the delimiting [ and ] tokens.

References: ​https://issues.asterisk.org/jira/browse/ASTERISK-26955 ​https://gerrit.asterisk.org/c/asterisk/+/13599/1/third-party/pjproject/patches/0040-brackets-in-via-received-params.patch

Thanks to Sean Bright for the patch.

Some UAs don't put SDP c= line (in media/session level) when rejecting the media with port zero.

Currently call id allocation is done by searching for empty slot from zero, so it will most likely to reuse call id of previous calls. This may cause problem when application defer call disconnection processing to an application worker thread, since when the application worker thread is handling the event, it's possible that another call arrives and uses the same call ID as the previously disconnected call.

Although approach of using worker thread like this is probably not a good idea, PJSUA-LIB can help avoiding this problem a bit (not completely!) by allocating the call id in round robin fashion. Note that even with the round robin call id allocation, application will still encounter the same problem when there is only one call id slot left in PJSUA-LIB. So the only way to get rid of this problem completely is by solving this problem in application code.

In 1.2 we added STUN SOFTWARE attribute in all outgoing STUN requests, as required by RFC 5389. This may cause compatibility problem with older STUN servers (compliant to RFC 3489) as this attribute is not part of the older RFC, and the padding rule for string attribute is different in both RFC's.

Offering the ability for application to provide a directory where CA certificate files could be found.

Thanks James Cloos and Mark Michelson for the patch.

Parsing DNS A response is a bit tricky, especially when CNAME record is present. Since this functionality is needed by both PJLIB-UTIL's DNS SRV and PJSIP's DNS resolution, move this functionality into a utility function pj_dns_parse_a_response() in pjlib-util/resolver.h.

Added the capability to attach user data to account and buddy objects.

With current implementation, it is rather hard to troubleshoot ICE negotiation failure. Having information about NAT type will help debugging such failure.

Add a sample media transport in PJMEDIA on how to create a simple transport adapter. A transport adapter is an object to be placed between the stream and the actual transport, and this is how the SRTP media transport is implemented.

A new sample file, mix.c (under pjsip-apps/src/samples directory, can be used to mix several input WAV files into an output WAV file.

Added recording of incoming RTP stream into WAV file in streamutil.

.. to convert string to integer with 10 or 16 base and when the string may not contain all numeric characters.

See ticket #222

.. and changed pjsua-lib to flush the file whenever it writes the log.

See ticket #184 for details.