Custom Query (2195 matches)

This will update pjnath-test for IPv6 support.

• Stun sock test : IPv4 and IPv6 test
• Turn sock test : IPv4 and IPv6 test
• ICE test : IPv4, IPv6, IPv4+IPv6 and mixed test (IPv4 controller v IPv6 controlled)

Currently pj_getaddrinfo() in pjsip_resolve will only return the first address.

So this can be useful in situations where that first address has an address family which is unsupported by applications (such as IPv4-only client which receives an IPv6 address when trying to register, hence causing it to fail).

Thanks to Alexander Traud for the report.

In on_snd_dev_operation() callback, sometimes it may be helpful to know which sound device is being opened/closed. This ticket will make sure that if pjsua_get_snd_dev() is called from within the callback, it will provide the desired info.

In relation to #411

The pool's alternative API (pool_alt.h) allows completely different pool back-ends to be used, and in pjlib's distribution, we have malloc() based pool where each pj_pool_alloc() call will call malloc(). This is useful for checking the memory integrity of the library using tools such as Valgrind or Purify.

This alternative API has not been used for long time and needs updating to make it compilable.

A new wiki Media_Transport_Adapter was created to demonstrate how to use transport adapter. The pjsua application contains a sample on how to use the sample adapter, but it needs to be updated to the latest API according to the wiki.

Added support to get and set audio output routing (i.e. loudspeaker and default output) on mobile devices.

Changes from rfc3489bis-15 to rfc3489bis-18:

• Removed SERVER (and CLIENT) attribute, added SOFTWARE attribute

Changed from turn-07 to turn-09:

• BANDWIDTH attribute has been removed
• Format change in REQUESTED-PROPS attribute
• Renamed RELAY-ADDRESS ==> RELAYED-ADDRESS
• New ICMP attribute to indicate that Data indication contains ICMP message
• Changed error code for Wrong Credentials from 438 to 441

Some errors have been reported on building/running PJSIP on MacOS X Snow Leopard:

src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:510: warning: 'AudioDeviceGetProperty' is deprecated (declared at /System/Library/Frameworks/CoreAudio.framework/Headers/AudioHardware.h:2367)
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c: In function 'OpenAndSetupOneAudioUnit':
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:800: error: 'ComponentDescription' undeclared (first use in this function)
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:800: error: (Each undeclared identifier is reported only once
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:800: error: for each function it appears in.)
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:800: error: expected ';' before 'desc'
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:801: error: 'Component' undeclared (first use in this function)
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:801: error: expected ';' before 'comp'
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:866: error: 'desc' undeclared (first use in this function)
src/../../../portaudio/src/hostapi/coreaudio/pa_mac_core.c:872: error: 'comp' undeclared (first use in this function)

Solution provided by Saul Ibarra Corretge can be found ​here.

Since March 2015, a TLS/SSL security vulnerability was revealed, which mandates to disable certain TLS cipher-suites <​https://en.wikipedia.org/wiki/FREAK>. Furthermore since February 2015, RFC 7465 prohibits the cipher-suite RC4. To achieve this with OpenSSL, the cipher-suite list has to be changed from "DEFAULT" to "HIGH". Furthermore, all ciphers which were not included in "DEFAULT" before (like eNULL), should not appear now either. Therefore: HIGH:-COMPLEMENTOFDEFAULT.

Special thanks to Alexander Traud for his excellent suggestion, description, and patch.

This fixes several problems, among other things:

1. Minor bug in PortAudio (about vsprintf vs _vsprintf) cause building to fail on WinCE. See ​http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2008-January/001333.html
2. Default sound backend on Linux is now ALSA instead of OSS

Currently local account is always bound to a transport since r5784 (of 2.8). Unfortunately the current account matching algo in pjsua_acc_find_for_incoming() may select a local account with incompatible transport type, which may cause failure in sending response with error PJSIP_ETPNOTSUITABLE.

Known issues with current configure-android:

• Detected TARGET_HOST 'llvm' is not recognized by config.sub.
• C++ STL backend uses gnustl_static (llvm does not support it?).
• The default TARGET_ABI, i.e: 'armeabi', is removed since NDK r17.

Thank you Ryan Wallach for the feedback.

.. or otherwise (un)PUBLISH will fail either with 403/Unregistered or with authentication failure, since account may have been deleted.

Thanks Babon Frederic and Nicholas Xu for pointing this out.

On iPhone OS, getaddrinfo() is sometimes unable to resolve local hostname returned by gethostname(), causing delay around 2-5 sec during the initialization process.

Previous fix (see ticket #1104) tried to append ".local" for the value returned by gethostname(), however there are cases when the hostname has a "-2" suffix such as "hostname-2.local" which causes this fix ineffective.

Currently, when device EC is available, pjmedia will automatically use it. However, it turns out that there are cases where using software EC is actually preferable, so an option for the application to choose whether to use device/software EC should be introduced.

Replacing PJ_LOG for writing error message log with status code.

Incoming request will be matched to PJSUA accounts by looking at the To URI. And if the To URI contains tel: URI, the default account will be used.

This ticket adds further try, that is to try to use the request URI when the To URI contains tel: URI.

Modify projects to use property sheets, so it will be easier to tweak in the future.

When using SIOCGIFCONF ifreq struct would be filled with the interface address rather than the flags of the interface. Therefore any test against the flags of this interface are not working at the moment. For gaining access to the flags, an additional socketctrl SIOCGIFFLAGS should be used.

At the moment when building android using clang, the build process will use ar/ranlib from host machine's binutils. This is not a problem on linux, however error will be raised on MacOS:

warning: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: warning for library: ../lib/libpj-arm-unknown-linux-androideabi.a the table of contents is empty (no object file members in the library define global symbols)
output/pjlib-test-arm-unknown-linux-androideabi/main.o: In function `main':
pjlib/build/../src/pjlib-test/main.c:(.text.main+0x3c): undefined reference to `PJ_SOCK_DGRAM'
pjlib/build/../src/pjlib-test/main.c:(.text.main+0x4c): undefined reference to `PJ_SOCK_DGRAM'
pjlib/build/../src/pjlib-test/main.c:74: undefined reference to `pj_str'
pjlib/build/../src/pjlib-test/main.c:76: undefined reference to `pj_strtoul'
pjlib/build/../src/pjlib-test/main.c:82: undefined reference to `pj_str'
...

This ticket will check and use the binutils from the android ndk.

For TCP&TLS, we already have ticket #1575, which will use the configured bind address for outgoing messages. However, for UDP, this is not the case. So even though the user has specified the bound_addr when calling pjsua_transport_create(UDP,...), the outgoing messages may still use different Via and Contact addresses.

In registration callback on_reg_state2(), especially in failure cases, sometimes it's difficult to distinguish whether the callback is called for registration or unregistration request.

This ticket will fix it by setting cbparam.expiration field to 0 in case of unregistration and > 0 otherwise.

On B2BUA scenario (with 2 leg/dialog):

1. B2BUA receive a BYE on one leg, while the other leg also receive a BYE.
2. While holding the lock on one leg, the B2BUA will try to forward the BYE it received to the other leg. The same goes for the other leg, however the process will stuck since it's unable to obtain the other's dialog lock.

It will lead to a deadlock scenario.

For this scenario, it is useful for both dialog to use the same lock (e.g: group lock).

The patch will introduce new API which will help for the above scenario.

• pjsip_dlg_create_uac2() and
• pjsip_dlg_get_lock()

Thanks to Peter Koletzki for the report.

Previously, ticket #1644 only allows this to happen upon receiving 183 response only. This ticket will expand it to all 18x responses.

Currently, the library use binary heap tree for timer implementation. However it is difficult to debug when a crash happen. This ticket will use a sorted linked list as an alternative. Note that this implementation is intended for debugging purposes and based on our test, it will hamper performance significantly if used with large number of entries.

sorted linked list:
05:31:25.191 ....random scheduling/cancelling test..
05:31:25.191     test 1 of 1..
05:31:25.191     Entries 0-100: schedule 1,594,896 ent/sec
05:31:25.193     Entries 101-1,000: schedule 624,652 ent/sec
05:31:25.416     Entries 1,001-10,000: schedule 40,300 ent/sec
05:33:24.605     Entries 10,001-100,000: schedule 755 ent/sec
07:48:19.304     Entries 100,001-500,000: schedule 49 ent/sec
07:48:19.305     Entries 500,000-499,900: cancel 3,401,360 ent/sec
07:48:19.319     Entries 499,899-499,000: cancel 5,322,676 ent/sec
07:48:19.326     Entries 498,999-490,000: cancel 8,436,298 ent/sec
07:48:19.337     Entries 489,999-400,000: cancel 8,541,803 ent/sec
07:48:19.374     Entries 399,999-0: cancel 10,727,227 ent/sec
07:48:19.374 ....increment scheduling/cancelling test..
07:48:19.375     test 1 of 1..
07:48:19.377     Entries 0-100: schedule 2,673,796 ent/sec
07:48:19.380     Entries 101-1,000: schedule 2,785,869 ent/sec
07:48:19.385     Entries 1,001-10,000: schedule 2,887,626 ent/sec
07:48:19.408     Entries 10,001-100,000: schedule 3,932,474 ent/sec
07:48:19.521     Entries 100,001-500,000: schedule 3,569,618 ent/sec
07:48:19.521     Entries 500,000-499,900: cancel 7,874,015 ent/sec
07:48:19.522     Entries 499,899-499,000: cancel 13,498,498 ent/sec
07:48:19.526     Entries 498,999-490,000: cancel 8,376,617 ent/sec
07:48:19.535     Entries 489,999-400,000: cancel 10,622,735 ent/sec
07:48:19.565     Entries 399,999-0: cancel 13,477,373 ent/sec

binary heap tree:
13:10:40.284 ....random scheduling/cancelling test..
13:10:40.284     test 1 of 1..
13:10:40.285     Entries 0-100: schedule 967,117 ent/sec
13:10:40.286     Entries 101-1,000: schedule 1,344,399 ent/sec
13:10:40.294     Entries 1,001-10,000: schedule 1,700,716 ent/sec
13:10:40.359     Entries 10,001-100,000: schedule 1,367,398 ent/sec
13:10:40.594     Entries 100,001-500,000: schedule 1,713,635 ent/sec
13:10:40.594     Entries 500,000-499,900: cancel 998,003 ent/sec
13:10:40.596     Entries 499,899-499,000: cancel 1,417,533 ent/sec
13:10:40.602     Entries 498,999-490,000: cancel 2,005,661 ent/sec
13:10:40.643     Entries 489,999-400,000: cancel 2,230,563 ent/sec
13:10:40.783     Entries 399,999-0: cancel 2,858,820 ent/sec
13:10:40.783 ....increment scheduling/cancelling test..
13:10:40.786     test 1 of 1..
13:10:40.787     Entries 0-100: schedule 3,125,000 ent/sec
13:10:40.788     Entries 101-1,000: schedule 2,535,966 ent/sec
13:10:40.791     Entries 1,001-10,000: schedule 2,508,851 ent/sec
13:10:40.820     Entries 10,001-100,000: schedule 3,170,262 ent/sec
13:10:40.940     Entries 100,001-500,000: schedule 3,344,568 ent/sec
13:10:40.940     Entries 500,000-499,900: cancel 358,680 ent/sec
13:10:40.944     Entries 499,899-499,000: cancel 465,296 ent/sec
13:10:40.960     Entries 498,999-490,000: cancel 571,470 ent/sec
13:10:41.069     Entries 489,999-400,000: cancel 820,636 ent/sec
13:10:41.377     Entries 399,999-0: cancel 1,303,636 ent/sec

Currently, coreaudio backend will use the first input/output audio device as the default. It is more preferable if we can use the system's default input/output audio device instead.

.. as part of QA.

Fixes in sample Android application and also other places related to assertion and crashes, due to garbage collection issue (see ​GC issues in PJSUA2 book) or other issues.

• Recent changes may have increased SIP message size (perhaps mainly from increased SDP size) and when the SIP message size exceeds ~1300 bytes, the SIP message will be sent via TCP transport (if TCP transport is available). Unfortunately, some test components, e.g: SIPp, are configured to use UDP only, so some Python script tests will fail.

Bug in pj_strcmp2() will cause pj_strcmp2("1", "12") to return equal.

Checking other string functions reveals that some string comparison functions are not exactly compliant with ANSI. For example, given:

  char *s1 = "2";
  char *s2 = "11";

With ANSI, strcmp(s1, s2) will return 1, while with pj_strcmp(s1, s2) will return -1.

The reason why the result was different was because string comparison in PJLIB was too optimized for speed, so it only cares about the fact that the string was different.

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
     

1. There is a race condition introduced with the IPv6 DNS patch.
   Given
   *) Thread A sending a SIP request that needs DNS resolution.
   *) Thread B handling DNS query responses in pjsip_endpt_handle_events().
   The call to pjsip_resolve() happens under Thread A which sets a dummy query:

   query->object6 = (pj_dns_async_query*)0x1;
   

   and then calls pj_dns_resolver_start_query() with the dns_a_callback().
   However, the dummy query protection is undone because the first thing that pj_dns_resolver_start_query() with the dns_a_callback() does is to set query->object6 to NULL when it is called.
   Then in thread B, the dns_a_callback() sees that there isn't an IPv6 query and attempts to send the request immediately even if there may not be any A records in the response. The pending dns_aaaa_callback() can now attempt to use resources that may be destroyed.

2. In pjsip_resolve() the pj_dns_resolver_start_query() for the AAAA records should be guarded by a status == PJ_SUCCESS check in case the A records query start fails.

3. In both dns_a_callback() & dns_aaaa_callback():
   

   if (srv->count > 0)
      (*query->cb)(PJ_SUCCESS, query->token, &query->server);
   else
      (*query->cb)(query->last_error, query->token, NULL);
   

   However, query->last_error is never set, thus in sip_util.c stateless_send_resolver_callback() it will hit the assertion:

   pj_assert(tdata->dest_info.addr.count != 0);
   

   If assertion in disabled, later in stateless_send_transport_cb() the code line:

   cont = (sent > 0) ? PJ_FALSE :
   (tdata->dest_info.cur_addr<tdata->dest_info.addr.count-1);
   

   can result in an underflow.

4. Fixed bug of premature app callback invocation for SRV resolver by applying the same method in r5369.

5. Remove DNS cache entry from resolver's hash table when app callback has a reference.
   In resolver.c update_res_cache(), if app callback has a reference, we only decrement the reference count of the cache entry. However, since it's not removed from the hash table, later the call to pj_hash_set_np() will overwrite this old entry (instead of using the newly allocated cache->hbuf), which will later be freed.

6. Given
   *) A previous cached A record DNS resolution that contains either no answer records or had an error returned in the query response (PJ_STATUS_FROM_DNS_RCODE() is not PJ_SUCCESS).
   *) The next attempt to send a SIP request under Thread A will cause pj_dns_resolver_start_query() to find the cached entry and immediately call the cb callback. When the callback returns pj_dns_resolver_start_query() cannot update *p_query because where it points to may no longer be valid because the memory could be freed.
   Fixed in r5477

Thank you to Richard Mudgett (Digium) for the report.

This ticket will contain various patches related to FFMpeg.

For example, newer FFMpeg might deprecate API and introduce a new one.

One of the scenario when transmission fails immediately is when memory allocation fails when allocating the contiguous buffer for the message. Another scenario is when a module rejects the transmission by returning non-PJ_SUCCESS in the on_tx_request() callback.

This this occurs, there are some scenarios that are causing the transmit data to leak, or in other cases wrong state to be invoked in the dialog/invite session/pjsua call layer.

A place for any bug fixes or enhancements related to DTLS-SRTP.

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.

Scenario:

1. An account is registered using a TCP/TLS transport, as allow_via_rewrite is set, account's Via is rewritten with public IP.
2. The TCP/TLS transport gets disconnected.
3. INVITE for the account is sent using a new TCP/TLS transport, Via header for this INVITE is local IP address (of the new transport), this is as expected because no re-REGISTER has been sent and the account's Via address is no longer valid.
4. CANCEL is sent, but using current account's Via address while it should use the same Via header as the original INVITE to be cancelled, so this CANCEL is rejected with status code 481 (transaction does not exist).

See also #1996.

Thanks Marcus Froeschl for the report.

Problem Description

Currently outgoing request has its Via sent-by filled in automatically with the address of the SIP transport being used to send the request. Since normally there is only one UDP transport instance that is shared by everything, this causes few problems:

1. when STUN is used in PJSUA-LIB, it overwrites the address of the transport with the STUN resolved address, and everybody will have this public address in their Via sent-by, regardless of where they're sending the request to or whether they want STUN.
2. Similar to above, if the host is multihomed, and different requests are sent to different interfaces, all these requests will use the same address in the Via sent-by, the one that is picked up by the transport when it is created, and causes requests to come to the UAS with Via containing address of the wrong interface.

Solution

This ticket adds allow_via_rewrite option in PJSUA-LIB account config to fix the Via sent-by to use the same interface address as the one in the REGISTER request, as long as the request uses the same transport instance as the previous REGISTER request. By default this option is enabled.

According to ​RFC 3261:

A CANCEL constructed by a
client MUST have only a single Via header field value *matching the
top Via value in the request being cancelled*.  Using the same values
for these header fields allows the CANCEL to be matched with the
request it cancels.

However, in PJSIP, when there is an IP address change situation, the Via header will be updated with the new address, causing the CANCEL's Via header to be different from the original INVITE's Via.

PJSUA-LIB video API specification:

1. Video Device Enumeration API

Specifications:

1. query device count
2. query device names
3. hotswap support?

2. Video Call API

Specifications:

1. enable or disable video when initiating call
2. enable or disable video when receiving call
3. choose which device to use for video call
4. add and remove video media stream during the call
5. change which device to use during the call
6. hide remote video window
7. move and/or resize video window

Notes:

Q: when receiving incoming call or reinvite which adds video, how can the app confirm this to the user?
A: at the moment, incoming video will be accepted automatically, but the app may simply hide the window until it gets user confirmation, if needed.

Q: when receiving incoming call or reinvite with video, should we start sending automatically?
A: at the moment the answer tends to be no, as sending video is an operation that can be initiated independently.

3. Video Capture Preview API

Specifications:

1. start and stop preview for the specified camera device, independent of calls
2. preview more than one capture devices independently
3. move and/or resize preview window

4. Media Info and Statistic API

The new API can be used for both audio and video.

Specifications:

1. query the number of media streams in a call
2. query the media stream info
3. query the media stream statistic
4. query the media transport info/statistic
5. move pjsua function that dumps call statistic (i.e. "dq" command) to a separate size, to reduce footprint for apps that don't use it.

5. Notification API

Nothing special for video. Update in media status is reported in on_media_state() callback as usual. Application may use media status API to query about video status.

Add support for native H264 encoder and decoder for Mac and iOS platform using Apple's Video Toolbox framework.

This ticket will implement video conference using centralized approach which is very similar to the existing audio conference, i.e: there will be an endpoint that act as the conference manager that is capable to establish multiple video calls, mix video from the participants (managed via connecting/disconnecting ports), and then send the mixing result to each participant. The video mixing operation is done by video conference bridge, which will use very similar APIs to the audio conference bridge.

Video conference bridge specifications

• Video timing clock, just like audio, the video conference bridge will have a clock that schedules video flow between ports.
• All registered ports must be in passive mode (at least for now), so the conference bridge will actively pull video frames from source ports and push video frames to sink ports.
• Ports can be bidirectional (they are PJMEDIA ports anyway) and just like in audio, ports connection is unidirectional, from a source port to a sink port.
• A source port may send to multiple sink ports (splitting), and a sink port may receive from multiple source ports (mixing). For splitting, there is no sink port number limitation, but for mixing currently it will only support up to four video sources (actually no limitation, but only the first four will be rendered).
• Video mixing layout. For now it will be static and no customization, e.g:
  • two source ports will be rendered into left/right layout for a landscape sink port, or top/bottom layout for a portrait sink
  • three source ports will be rendered into left+(top/bottom) layout for a landscape sink, or top+(left/right) layout for a portrait sink
  • four source ports will be rendered into 2x2 layout (equally divided slices) for a landscape sink, or four vertically stacked slices for a portrait sink.

Implementation

Basically, the video conference implementation shares the same concept as the audio conference, so for applications that already have audio conference feature, integrating video conference feature should be relatively simple.

For participant, no modification is needed, it will see the video conference as a usual P2P video call, the video from other participants will be rendered into the same video window of the remote side of the video call (the conference manager).

For conference manager, it can setups the video conference using a very similar way as setting up an audio conference (with additional efforts for managing the UI perhaps). A sample code for this can be checked below.

Conference ports in a video window in PJSUA

A video window may be related to two or more conference ports, application should be aware of this so it can manage the conference properly.

A video window represents a video renderer device and is automatically registered to the video conference bridge. The conference slot ID can be queried via pjsua_vid_win_get_info(), the slot ID should be in pjsua_vid_win_info.slot_id. This is a sink port.

As a sink port, it normally has a source, for example a capturer device or a call video stream. The conference slot ID of the source port should be queried separately, for example:

• For capture device, use pjsua_vid_preview_get_vid_conf_port(), the corresponding video window can be queried using pjsua_vid_preview_get_win().
• For call video stream (first video stream), use pjsua_call_get_vid_conf_port(), the corresponding video window can be queried using pjsua_call_get_vid_win(). Alternatively, those info can also be queried via call info, i.e: pjsua_call_info.media[i].stream.vid.enc_slot/dec_slot, the corresponding video window is pjsua_call_info.media[i].stream.vid.win_in.

Sample usage: three parties video conference

Here are steps to setup a three parties video conference:

1. Make two video calls as normal to two other participants.
2. After all calls are established, simply connect those port IDs using pjsua_vid_conf_connect() for PJSUA or VideoMedia::startTransmit() for PJSUA2, e.g:
   • using PJSUA:

     /* Get video ports of call 1, there are two ports as in a video call as
      * encoding and decoding directions may not use the same frame rate or 
      * resolution.
      */
     call_1_dec_port = pjsua_call_get_vid_conf_port(call_1_id, PJMEDIA_DIR_DECODING);
     call_1_enc_port = pjsua_call_get_vid_conf_port(call_1_id, PJMEDIA_DIR_ENCODING);
     
     /* Get video ports of call 2 */
     call_2_dec_port = pjsua_call_get_vid_conf_port(call_2_id, PJMEDIA_DIR_DECODING);
     call_2_enc_port = pjsua_call_get_vid_conf_port(call_2_id, PJMEDIA_DIR_ENCODING);
     
     /* Connect video ports of call 1 and call 2.
      * Note that the source is the stream port in decoding direction,
      * and the sink is the stream port in encoding direction.
      */
     status = pjsua_vid_conf_connect(call_1_dec_port, call_2_enc_port, NULL);
     status = pjsua_vid_conf_connect(call_2_dec_port, call_1_enc_port, NULL);
     

   • using PJSUA2 (exception handling excluded):

     /* Get video ports of call 1 */
     VideoMedia call_1_dec_port = call1->getDecodingVideoMedia(-1);
     VideoMedia call_1_enc_port = call1->getEncodingVideoMedia(-1);
     
     /* Get video ports of call 2 */
     VideoMedia call_2_dec_port = call2->getDecodingVideoMedia(-1);
     VideoMedia call_2_enc_port = call2->getEncodingVideoMedia(-1);
     
     /* Connect video ports of call 1 and call 2 */
     VideoMediaTransmitParam transmit_param;
     call_1_dec_port.startTransmit(call_2_enc_port, transmit_param);
     call_2_dec_port.startTransmit(call_1_enc_port, transmit_param);
     

3. At this point, each participant should be able to see video from the two other participants. The caller will see them in separate windows as it has two video calls (may be combined if preferred, see below), while the other two will only have one incoming video window as usual, just it contains a mixed video (from the caller and the other participant).
4. On the caller side, it may combine video window of call 1 and call 2 into a single window (for simpler UI management perhaps), e.g:
   • using PJSUA:

     pjsua_vid_win_id wid1, wid2;
     pjsua_vid_win_info win2_info;
     
     /* Put incoming video stream from call 1 into call 2 window */
     wid2 = pjsua_call_get_vid_win(call_2_id);
     pjsua_vid_win_get_info(wid2, &win2_info);
     pjsua_vid_conf_connect(call_1_dec_port, wid2_info.slot_id, NULL);
     
     /* Now hide the video window of call 1 */
     wid1 = pjsua_call_get_vid_win(call_1_id);
     pjsua_vid_win_set_show(wid1, PJ_FALSE);
     

   • using PJSUA2:

     /* Function for querying any first video window of the specified call */
     VideoWindow getCallVideoWindow(const Call *call) {
         CallInfo ci = call->getInfo();
         CallMediaInfoVector::iterator it;
         for (it = ci.media.begin(); it != ci.media.end(); ++it) {
     	if (it->type == PJMEDIA_TYPE_VIDEO &&
     	    it->videoIncomingWindowId != PJSUA_INVALID_ID)
     	{
     	    return it->videoWindow;
     	}
         }
         return VideoWindow(PJSUA_INVALID_ID);
     }
     
     /* Put incoming video stream from call 1 into call 2 window */
     VideoWindow wid2 = getCallVideoWindow(call2);
     VideoMediaTransmitParam transmit_param;
     call_1_dec_port.startTransmit(wid2.getVideoMedia(), transmit_param);
     
     /* Now hide the video window of call 1 */
     VideoWindow wid1 = getCallVideoWindow(call1);
     wid1.Show(false);
     

While in general there are only few window events to be exported to application, since video window has no decoration (hence user cannot move, resize, close, etc.), there are events that may be interesting to app:

• if incoming video format/size has changed, and video window is updated. App needs this to move/resize the window to fit the app window.
• mouse click to video area may be interesting to app

As reported ​here, SDL is started-stopped repeatedly after PJMEDIA_EVENT_FMT_CHANGED event is triggered repeatedly. Moreover, the log shows that the incoming video framerate is changed continuously.

This ticket is the continuation of #1234 (missing video keyframe handling) with focus on RTCP-FB PLI for requesting video keyframe.

In PJSUA, this feature is by default enabled and configurable via call setting, i.e: pjsua_call_setting.req_keyframe_method with bitflag PJSUA_VID_REQ_KEYFRAME_RTCP_PLI. When enabled, it will be signaled in SDP offer/answer, which will look like this:

a=rtcp-fb:* nack pli

Application can also monitor incoming RTCP-FB PLI packet via PJSUA callback on_call_media_event() for event PJMEDIA_EVENT_RX_RTCP_FB.

This ticket also introduces some macro settings:

• PJMEDIA_RTCP_FB_INTERVAL: Minimum interval between two consecutive outgoing RTCP-FB packets, such as Picture Loss Indicationc.
• PJMEDIA_VID_STREAM_MIN_KEYFRAME_INTERVAL_MSEC: Specify the minimum interval to send video keyframe.

This is due to failure in setting output window visibility, note that Android renderer doesn't support PJMEDIA_VID_DEV_CAP_OUTPUT_HIDE capability, so pjsua_vid_preview_start() will return PJMEDIA_EVID_INVCAP and video doesn't not show up. Also, the function misses applying window output handle setting.

Thanks Giorgio Alfarano for the report and the patch.

Background

• Mobile devices can be rotated (the rotation angle can be detected), which may lead to wrong video orientation in rendering/playback.

Objective

• The purpose is to allow video rendering in natural orientation (head/sky upside) or the preferred orientation of the capturer.

Notes

• Common video codecs works in predefined allowed sizes/orientation, e.g: CIF, QCIF.
• On iOS, capturing video to a file will store the video data in camera's native orientation, i.e: wide-oriented, the capture orientation info (the device/camera orientation when the capture/record process is done) is stored in video metadata, so in playing back the file, the stored capture orientation info (may be combined with current device orientation info) is used to calculate rotation angle to get natural orientation in video rendering/playback.

Ideas

• The orientation info is readable and read-only in capture.
• The renderer will apply the orientation info provided by the capturer.
• The orientation info is a rotation angle to be applied to a picture/video so it can be displayed naturally (or as the capturer preference).

Issues

• SDP/SIP only offers limited support for orientation, and there is no way for sender to tell receiver about the video orientation of the capture device. The 'a=orient:x' in SDP is not really useful as this is receiver preference/capability, while in practice, the receiver can render any orientations and the capturer cannot really send portrait (codecs limitation, etc).

Specification

Based on the background above, the following API will be implemented by this ticket:

• Add orientation capability to video device with the following specification:
  • it is read-only for capture devices, and
  • it is write-only for renderer devices
• Add pjsua_vid_win_rotate(win, angle) API. The angle is a rotation angle to be applied to a picture/video so it can be displayed naturally (or as the capturer preference).

Known cases:

1. offering multiple H.264, with PT=xx and yy, answered with single H.264 with PT=zz, our H.264 SDP negotiator deduce that "zz" match to "xx", but incoming RTP packets use "yy" instead! Note that this also happened before r3526 (permissive H.264 negotiation).
2. receiving offer with PT=xx, answering with PT=yy, then peer refuse our RTP packets with PT=xx, peer expects our RTP packets using PT=yy instead! (fixed by #1300)

• Change to unidirectional
• Handle the case when converter is needed at run-time due to format change
• Review other possible cases

It's caused by two things:

• Video port's clock thread try to stop its own thread from within itself.
• On some platforms pj_thread_join() do not perform check when called from within itself.

After investigation, the renderer restarts are triggered by multiple frame rate change events. Pjmedia learns remote frame rate by inspecting incoming RTP timestamp interval, when it detects frame rate is increasing, it will send PJMEDIA_EVENT_FMT_CHANGED event to application, in this case it is video port, which eventually will trigger video renderer restart. Unfortunately, some endpoints may send video RTP timestamps not in a fixed interval (even when the fps is fixed).

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

Not always happen, but quite often.

Create a virtual video device for streaming AVI file.

Trunk (Rev. 916) does not compile samples section under VS 2005.

Change first line of pjsip-apps\build\Samples-vc.mak from

TARGET = i386-win32-vc6-$(BUILD_MODE)

to

TARGET = i386-win32-vc8-$(BUILD_MODE)

Cheers,

Roman

Yup, finally I'm committed to support this!

(don't ask about VS7 or VS7.1 as I don't have them :) ).

To support to Visual Studio 2015 (VS 2015), this ticket will introduce these files:

- Solution file : pjproject-vs14.sln
- Project files : *.vcxproj
- Project properties sheet files : *.props
- Project filter files : *.filters

Please note that in VS 2015, VC++ directories settings are available in the user property sheet.

To include them in a global setting, use Microsoft.cpp.<Platform>.users (e.g: Microsoft.Cpp.Win32.user) properties sheet file.

When the WAV player (pjmedia_wav_player_port) is not configured to playback in a loop, it will ignore the last portion of the WAV file if the WAV file size is not aligned to the WAV port's buffer size.

In fill_buffer(), after encountering EOF the rest of the buffer is zeroed, but then it is overridden with the start of WAV data (rewinding).

Original report can be found ​here.

David Clark has contributed support for playing multiple WAV files in a playlist. Need to integrate this with the library.

One user reported that after running application with WMME backend for a while (just over a minute), the application raised an assertion "May be heap corruption caused by your app or some DLL it loaded"

This ticket fixes bug in #768.

According to the following KB:

​http://support.microsoft.com/kb/263823/en-us

a bug in Windows 2000 prior to SP2, and reportedly in Window 2003 as well, will cause error WSAECONNRESET to be returned for the UDP socket until the socket is closed, effectively making the socket unusable. In PJSIP, we handle this by stopping the UDP transport if we have ten (10) consecutive errors from the OS.

This ticket disables WSAECONNRESET for all UDP sockets instantiated from PJLIB, using SIO_UDP_CONNRESET IOCTL as described by the KB. To disable this feature (in other words to revert to the behavior of previous PJSIP versions), declare PJ_SOCK_DISABLE_WSAECONNRESET to 0 in your config_site.h.

Warnings similar to the following may occur on MacOS X when building the Python module:

ld: warning: ignoring file ../lib/libpjsua-x86_64-apple-darwin11.4.2.a, file was built for archive which is not the architecture being linked (i386): ../libpjsua-x86_64-apple-darwin11.4.2.a

ld: warning: ignoring file /Users/bennylp/Desktop/project/pjsip/2.x/pjmedia/lib/libpjmedia-x86_64-apple-darwin11.4.2.a, file was built for archive which is not the architecture being linked (i386): /Users/bennylp/Desktop/project/pjsip/2.x/pjmedia/lib/libpjmedia-x86_64-apple-darwin11.4.2.a

...

These warnings can just be ignored because the module will still be built for the available architecture (x86_64 in this case).

If you want to get rid of the warnings, you can set the ARCHFLAGS to include only architecture that you want to build as follows:

 $ ARCHFLAGS='-arch x86_64' python setup.py build

There is a bug in pjmedia_wav_player_port_set_pos(), the read buffer pointer is not reset after buffer gets updated. This may only noticeable on small wav files (sized around buffer size).

WSOLA is used to speed up or slow down audio playback without changing the pitch. We can use this functionality to get around audio drifts, and also as base implementation for packet lost concealment (PLC).

What pjmedia_vid_param fields are initialized by default_param()? Can app expect all fields will be initialized with default values, and ready to be used?

When call is redirected to a new target by 3xx response, call info may still show old target as the remote info.

The primary host IP is resolved by detecting the default interface. Unfortunately when no NIC is present in the host, the pj_gethostip() function will return error while it really should return 127.0.0.1.

When we send an INFO request in an INVITE initiated dialog and receive back a 481 or 408 response, the stack invokes the on_state_changed() callback of the invite session with the PJSIP_INV_STATE_DISCONNECTED state.

This result in the termination of the dialog and is compliant with section 12.2.1.2 of RFC 3261, however a BYE request is not sent.

Related to r5500 which attempts to restart crypto numbering from 1 on a re-INVITE. Currently, the tag matching is not based on the offer, but the index of the crypto suite setting.

This patch will match the tag using the offer.

Thanks to Colin Morelli for the report.

As specified in ​RFC3261 8.1.2:

   Independent
   of which URI is used as input to the procedures of [4], if the
   Request-URI specifies a SIPS resource, the UAC MUST follow the
   procedures of [4] as if the input URI were a SIPS URI.

   Local policy MAY specify an alternate set of destinations to attempt.
   If the Request-URI contains a SIPS URI, any alternate destinations
   MUST be contacted with TLS.

Setting CXXCFLAGS manually sometimes is needed, e.g: set "-std=c++03" option. However the current build configuration might ignore/overwrite it.

This patch will make sure that the CXXCFLAGS is applied correctly.

Thanks to Alexander Traud for the patch.

Consider the following URI:

sips:host;transport=tcp

With the above URL, currently PJSIP will connect to destination host using TCP transport to port 5060.

The correct behavior is to connect to destination host using TLS over TCP to port 5061.

Before closing a connection, close notify alert must be sent to avoid truncation attack as stated in ​rfc5246:

7.2.1.  Closure Alerts

   The client and the server must share knowledge that the connection is
   ending in order to avoid a truncation attack.  Either party may
   initiate the exchange of closing messages.

Currently, the close notify alert is not sent before the connection is closed.

Thanks to Peter Koletzki for the report.

Changeset r5828 introduced a bug, which allow the library to send 488 response to a Re-INVITE with no SDP when using pjsua2 API.

Currently on_rx_reinvite() will always be set to pjsua_call_on_rx_reinvite() when using pjsua2 API. The callback didn't provide the SDP answer which is expected. If the answer is not set. the library will detect this as an invalid operation and generate the 488 response.

This ticket will avoid the check when no SDP is provided and allow the library to generate the offer instead.

Thanks to Ryan Wallach for the report.

Support Windows 10 / Universal Windows Platform and continue the work for Windows Phone 8 support (#1704).

Build guide: Building for UWP & WP8

Port PJSIP to Windows Phone/WP8 platform.

Zeroing our buffers should be sufficient as we cannot really manage the OpenSSL internal buffers. Moreover, it seems that OpenSSL already does wipe out its internal buffers, i.e: a lot of OpenSSL_cleanse() calls in OpenSSL source code, the function will fill a buffer with garbage or zero. But unfortunately cannot really find official docs about it.

Additionally, SSL socket pool content will be zeroed before released, it is done using a new API pj_pool_secure_release().

Thanks Peter Koletzki for the feedback.