What is G722.1 and G722.2

G.722.1 or SIREN 7

G.722.1 or SIREN 7 describes a digital wideband coder algorithm that provides an audio bandwidth of 50 Hz to 7 kHz, operating at a bit rate of 24 kbps or 32 kbps. G.722.1 is useful for hands-free operation in HD VoIP systems with low frame loss.

It exists also the G.722.1 Annex C or SIREN 14 that provides an audio badwith up to 14 Khz operating at a bir rate of 24, 32, y 48 kbit/s.

G.722.2 o AMR-WB ("Adaptive Multirate Wideband")

The Adaptive Multi-Rate Wideband Codec (AMR-WB) is a speech coder standard introduced by the 3rd Generation Partnership Project (3GPP), The AMR-WB Codec has been approved by the ITU-T standards body and is referred to as G.722.2.This speech coder is mainly used for speech compression in the 3rd generation mobile telephony.

This codec has nine basic bit rates, 23.85, 23.05, 19.85, 18.25, 15.85, 14.25, 12.65, 8.85 and 6.6 kbit/s. This codec works on the principle of Algebraic Code Excited Linear Prediction (ACELP) for all bit rates. To reduce average bit rate, this codec supports the discontinuous transmission (DTX), using Voice Activity Detection (VAD) and Comfort Noise Generation (CNG) algorithms.

The coder works with a framesize of 20 msec and the algorithmic delay for the coder is 25 msec.

references:

http://www.en.voipforo.com/codec/new-codecs-g7111-g7291.php

Port Audio and OpenCore

Port Audio is a free open source, cross platform audio I/O library. It lets a developer to write simple audio programs in C or C++ that will compile and run on many platforms including Windows, Mac and Unix. 

PortAudio provides a very simple API for recording and/or playing sound using a simple callback function or a blocking read/write interface. Example programs are included that play sine waves, process audio input (guitar fuzz), record and playback audio, list available audio devices, etc.

This library provides functions that allow software to acquire and output real-time audio streams from a computers hardware audio interfaces. It is designed to simplify writing cross platform audio applications and also simplify the development of audio software in general hiding the complexities of dealing directly with each native audio API. PortAudio is used to implement sound recording, editing and mixing application software synthesisers, effects processors, music players, internet telephony applications, software defined radios and more. Supported platforms include MS windows, Mac OS X and Linux. Third party language bindings make it possible to call PortAudio from other programming languages including Java, C++, C#, Python, PureBasic, FreePascal and Lazarus.  

references:

https://www.codeproject.com/Articles/332109/AMR-Audio-Encoding

http://www.portaudio.com

http://portaudio.com/docs/v19-doxydocs/index.html

Understanding SDP

Below is a sample SDP captured from one of the clients am using. 

v=0  (version)

o=prettybaby 1795756 0 IN IP4 10.238.78.209 (Owner/creator = username, session ID, version, network type, address type, owner address)

s=- (subject/session name)

c=IN IP4 10.238.78.209 (network type, address type, address)

t=0 0 (time description, start time, end time) 

m=audio 8540 RTP/AVP 9 0 8 18 120 100 (media description : audio, port, protocol, Media Format G722, PCMU, PCMA, G729, dynamic RTP type 120, dynamic RTP type 100) 

a=sendrecv (Media flow attribute sendrecv) 

a=rtpmap:9 G722/8000 (field name rtpmap 9 corresponds to G722) 

a=rtpmap:0 PCMU/8000

a=rtpmap:8 PCMA/8000

a=rtpmap:18 G729/8000

a=fmtp:18 annexb=no (field name fmtp, format 18 (G729), media specific parameter annexb=no)

a=rtpmap:120 opus/48000/2 (Media format 120, media type opus, sampling rate 48000)

a=rtpmap:100 telephone-event/8000 (media format 100, media type telephone-event, sampling rate 8000)

Session ID will be generated by each client and the version number will be generated by each client as well. With each INVITE initiated from the client, the version number will be incremented. 

the media attribute a=sendonly indicates from sender end, he want to put the media on hold. The receiver responds back with a=receiveonly. If not specified, by default, it is assumed to be sendrecv. a = sendonly, receiveonly, sendrecv are used by modern RFC. Old RFC, to put the connection on hold, c=0.0.0.0 was used. 

references

https://www.dialogic.com/webhelp/IMG1010/10.5.3/WebHelp/media_flow_attribute.htm

https://tools.ietf.org/html/rfc4317

Protocol Buffers

Intention is to grab some knowledge on below items

- Define message formats in .proto file 

- Use the protocol buffer compiler 

- Use the C++ Protocol buffer API to write and read messages 

With protocol buffers, developer write .proto description of the data structure one wish to store. From that the protocol buffer compiler creates a class that implements automatic encoding and parsing of the protocol buffer data with an efficient binary format. The generated class provides getters and setters for the fields that make up a protocol buffer and take care of the details of reading and writing the protocol buffer as a unit. The protocol buffer format supports the idea of extending the format over time such a way that the code can still read and encode the data with the old format. 

The syntax for the protocol buffer is similar to the Java or C++. In protnbuf terms, individual fields are called messages. Message is just an aggregate containing a set of fields. Many standard simple data types are available as field types, including bool, int32, float, double, and string. Tag numbers are used in each field to that is identifier during binary encoding. Tag numbers 1-15 require one less byte to encode than higher numbers, so as an optimization you can decide to use those tags for the commonly used or repeated elements, leaving tags 16 and higher for less-commonly used optional elements. Each element in a repeated field requires re-encoding the tag number, so repeated fields are particularly good candidates for this optimization.

Each field must be annoted with one of the following modifiers 

1. required: A value for the field must be provided, otherwise message will be considered as initialised. If protnbuf compiled in debug mode, uninitialised required value if met will result in assertion failure. 

2. Optional: This field may or may not be set. IF optional value is not set, default will be used. 

3. repeated : the field may be repeated any number of times. The order of repeated values will be preserved in the protocol buffer. 

The required is non reversible. this means that if we want to change the field type to non required later, then old messages cannot be read successfully. 

Sample message is as below. the protocol buffer message must be saved in a file with .proto extension. 

package tutorial;

message Person 

{

required string name = 1;

required string int32 id  = 2;

optional string email = 3; 

enum PhoneType {

MOBILE = 0; 

HOME = 1; 

WORK = 2;

}

message PhoneNumber 

{

required string number = 1; 

optional PhoneType type = 2 [default = HOME];

}

repeated PhoneNumber phone = 4;  

}

message AddressBook

{

repeated Person person = 1;

}

references:

https://developers.google.com/protocol-buffers/docs/cpptutorial