Import latest release-7.1 files from old repo

.gitattributes

@@ -0,0 +1,15 @@
+#
+# .gitattributes
+#
+# used to remove files from deployment using `git archive`
+#
+
+.gitattributes  export-ignore
+.gitignore      export-ignore
+
+BUILDCONTROL    export-ignore
+
+contrib         export-ignore
+docs            export-ignore
+mediaengine     export-ignore
+tools           export-ignore

.gitignore

@@ -0,0 +1,50 @@
+*.[oa]
+.*.swp
+*.class
+bin
+gen
+libs
+obj
+local.properties
+*.log
+
+/netprobe
+/verifyd
+/vidloop
+/zcall
+/coin
+/tmp
+/scripts/tmp
+
+/build
+.DS_STORE
+xcuserdata
+xcshareddata
+zcontrib
+ztest
+BUILDCONTROL.local
+artifacts
+version.buildinfo
+*.jnilib
+config.mk
+
+test/audio_test/ios/build/
+tools/zmm/build/
+
+*.aecdump
+*.rtpdump
+
+test/data/near16_out.pcm
+test/data/near32_out.pcm
+test/data/out.pcm
+test/data/out2.pcm
+test/data/rtp.dat
+
+android/java/org/
+
+src/protobuf/proto/
+
+contrib/webrtc
+
+scan/
+

Makefile

@@ -33,25 +33,21 @@ else
 VER_PATCH := $(BUILD_NUMBER)
 endif
 
-VER_BRANCH := $(shell git rev-parse --abbrev-ref HEAD || echo "Fetching branch failed")
+VER_BRANCH := $(shell git rev-parse --abbrev-ref HEAD || echo "")
 
 ifeq ($(VER_BRANCH),master)
 AVS_PROJECT := avsmaster
 AVS_RELEASE := 0
-AVS_VERSION := 0.$(VER_PATCH)
-else ifeq ($(VER_BRANCH),open_source)
-AVS_PROJECT := avsopen
-AVS_RELEASE := 1
-AVS_VERSION := $(VER_MAJOR).$(VER_MINOR).$(VER_PATCH)
+AVS_VERSION := 0.0.$(VER_PATCH)
 else
 AVS_PROJECT := avs
 AVS_RELEASE := 1
 AVS_VERSION := $(VER_MAJOR).$(VER_MINOR).$(VER_PATCH)
 endif
 
-
 MK_COMPONENTS := toolchain contrib avs tools test android iosx dist
 
+
 #--- Configuration ---
 
 -include config.mk
@@ -91,7 +87,7 @@ endif
 
 #--- All My Targets ---
 
-all: test
+all: tools test
 
 ifeq ($(AVS_OS),android)
 wrapper: android

docs/devicepair.md

@@ -0,0 +1,54 @@
+Device Pairing
+==============
+
+
+
+Flow Diagram
+------------
+
+
+```
+      .------.               .-------.             .------.
+      | old  |               |       |             |  new |
+      |device|               |verifyd|             |device|
+      '------'               '-------'             '------'
+         |                       |                     |     [ User start a ]
+         |                       |   POST /create      |     [ new pairing  ]
+         |                       |<--------------------|
+         |                       |   200 OK (id=42)    |
+         |                       |-------------------->|
+devpair  |                       |                     |     [ Show Pairing ID ]
+publish()|                       |                     |
+         |                       |                     |
+         |  PUT /publish?id=42   |                     |
+         |  (SDP Offer)          |                     |
+         |---------------------->|                     |
+         |  200 OK               |                     |  poll
+         |<----------------------|                     +--.
+         |                       |  GET /publish?id=42 | /|\
+         |                       |<--------------------|  |
+         |                       |   200 OK (SDP Offer)|  |
+         |                       |-------------------->|  |
+         |                       |                     +--'
+         |                       |                     | ~~~ devpair_create()
+         |                       |                     | ~~~ devpair_accept()
+         |                       |                     |
+         |                       |  PUT /accept?id=42  |
+         |                       |   (SDP Answer)      |
+         |                       |<--------------------|
+   poll  |                       |      200 OK         |
+      .--+                       |-------------------->|
+     /|\ |  GET /accept?id=42    |                     |
+      |  |---------------------->|                     |
+      |  |  200 OK (SDP Answer)  |                     |
+      |  |<----------------------|                     |
+      '--+                       |                     |
+devpair  |                       |                     |
+ack()    |                       |                     |
+         |                       |                     |
+         |<================= DataChannel =============>|     [  Started]
+
+
+TODO: transfer data (ledger)
+
+```

docs/flowmgr.md

@@ -0,0 +1,145 @@
+Flow Manager
+============
+
+In Zeta, calling is split into two more or less independent parts: call
+state handling and media handling.  Call state handling controls which
+users and devices have joined a call in a conversation.  Media handling
+makes sure that audio and video data is being exchanged between all
+devices that have joined a call.
+
+The flow manager is a component of the AVS library that implements media
+handling for calling.  It takes care of both the network and the AV side
+of call media: it establishes media flows between devices, records audio
+and video from the recording devices present in the system, encodes these
+and sends them over the media flows, it receives encoded media from the
+network, decodes it and plays it back on playback devices.
+
+This document describes both the interface and function of the flow
+manager in great detail.
+
+
+Basics
+------
+
+Calling happens in the context of conversations.  Each conversation has an
+associated call which devices can join.  Whether a device can join a call
+and for how long is being controlled by the service.  This is determined by
+the call state handling component of calling and is not being discussed
+here.
+
+In order to be able to participate in a call, a device needs to be able to
+exchange data with remote locations. Since there can be several devices
+that can potentially join a call, the remote location is not predetermined
+and it can change during a call. However, for each device there is at most
+one such location at any given time. The relationship between exactly two
+devices for exchanging media is called a media flow.
+
+Media flows are controlled by the service. Before starting a call, a device
+asks the service for a set of flows, called 'posting for flows.' The
+service determines any potential other devices in the call and creates a
+media flow the asking devices and each of these. They receive their flows
+without having asked for them through the `call.flow-add` event.
+
+When a device has received a flow, be it by asking or throug an event, it
+starts preparing the flow. This entails an offer/answer exchange for media
+capabilities followed by an ICE exchange to determine and open actual
+network connections.
+
+A call starts once at least two devices have joined call. When this
+happens, the service determines which media flow should be used to
+exchange media over and informs the device by 'activating the flow'
+through a `call.flow-active` event. Only when a flow is active is a device
+allowed to send media over it. However, it does not have to. The device
+can decide to keep the call muted or it can keep it on hold while being in
+the call of another conversation.
+
+Sending and receiving of media ends when the flow is being deactivated by
+the service, yet again by way of a `call.flow-active` event.
+
+Once the device determines that it doesn't want to be in a call anymore,
+it can delete all its flows. If the other side of a flow decides to delete
+it, the device will be informed by the service through a
+`call.flow-delete` event.
+
+
+The Flow Manager API
+--------------------
+
+The flow manager is a single object that provides a number of functions to
+be called by the user and calls a number of callbacks to be registered by
+the user.
+
+There is only one flow manager per application. Functions that operate on
+a per-conversation basis use the conversation ID as an argument.
+
+
+Service Connection
+------------------
+
+The flow manager needs to communicate to the service. It does so both
+through HTTP requests and events.
+
+It emits HTTP requests through a callback registered at creation time.
+This callback will contain all parts of the HTTP request as arguments.
+Additionally, it contains an opaque pointer to a context. It is the user's
+responsibility to create and dispatch an HTTP request. Once a response
+arrives, the user must pass it to the flow manager through the
+`flowmgr_resp()` function, passing the context pointer from the request.
+
+Additionally, all events must be passed to the flow manager through the
+`flowmgr_event()` function.
+
+
+Managing Calls
+--------------
+
+When the API user anticipates that a call might start, it calls the
+`flowmgr_acquire_flows()` function. This will cause the flow manager to
+request flows from the service. The user can now proceed with call states.
+Eventually, the service will activate one of the flows in response to the
+device call state being set to active.
+
+Now there's two options: if setting up media on the activated flow fails,
+an error is emitted allowing the user to alert its user and wind down the
+call. If, however, it succeeds, something called audio categories comes
+into play.
+
+It is also important that flows are released (flowmgr_release_flows()) after
+a call participant has been set to "idle" and response has been received.
+
+Media Categories
+----------------
+
+Media categories describe how recording and playback of media should be
+handled for a conversation. Currently, there are four:
+
+*  _regular_: this is the normal mode where only notification sounds are
+   emitted from the conversation and no recording takes place;
+*  _muted_: the conversation has been muted and no playback or recording
+   should happen (note that this is independent of any muting feature
+   implemented by UI);
+*  _call_: the conversation has actively joined a call, incoming media is
+   being played back and recorded media is being streamed to the network;
+*  _playback_: an embedded media element in the conversation is playing
+   its media.
+
+The media category for each conversation is managed by the user of the
+flow manager. In most cases, it will do so using the media manager.
+
+The flow manager does, however, request a certain media category necessary
+for its operation. When a flow has been activated, it requests the _call_
+category. When an active flow has been deactivated, it requests the
+_regular_ category. It is up to the user to actually set the requested
+category and perform any necessary action for a change.
+
+The flow manager requests a changed through `flowmgr_mcat_h`
+callback. Any change to the media category of a conversation needs to be
+communicated using the `flowmgr_mcat_changed()` function.
+
+So, when a flow is being activated by the service, the flow manager will
+request the _call_ media category for that conversation. It will only
+start playback and recording, however, once it has been notified that this
+change has happened.
+
+Similarly, the user can decide at any time to revoke the _call_ media
+category in which case the flow manager stops playback and recording.

docs/local_avs_on_ios.md

@@ -0,0 +1,52 @@
+
+# Building ZClient-iOS with local AVS
+
+## Requirements
+
+Xcode7
+Cocoa pods: sudo gem install cocoapods
+Carthage: brew install carthage
+
+## Set up xcode_link dir
+
+Make a link to avsball:
+
+```
+mkdir xcode_link
+cd xcode_link
+ln -s ../avs/build/dist/ios/avsball ios
+```
+
+## Getting Zclient dependencies
+
+Get pods and whatever
+
+```
+cd zclient-ios
+pod init
+carthage bootstrap
+```
+
+## Add getcomponents to Build Phases
+
+Open xcworkspace file in Xcode
+Add following line to "Check Pods manifest.lock" in build phases
+
+```
+${HOME}/Library/Python/2.7/bin/getcomponents --verbose --force --build-control ${SRCROOT}/BUILDCONTROL --platform ios
+```
+
+## Fix Buildconfig to get local AVS
+
+Copy BUILDCONFIG to BUILDCONFIG.local, replace avs with local & add the paths section
+
+```
+[libraries]
+avs: local
+
+[paths]
+avs: ../xcode_link
+```
+
+## Profit
+

docs/release-process.txt

@@ -0,0 +1,25 @@
+Release Process for AVS:
+-----------------------
+
+
+Different projects have different release policy:
+
+
+  avs:          master     This is the main development branch
+                release    This is the release branch, only for bugfixes
+                           (commits in release branch are merged back to master)
+
+
+  zcontrib:     master     Should always have production ready code in their master branch
+                           New features are kept in a feature-branch
+
+
+  mediaengine:  master     Should always have production ready code in their master branch
+                           New features are kept in a feature-branch
+
+
+
+NOTE:  The release branch would only need updating if externally relevant stuff has been updated.
+
+
+...