Friday, May 19, 2017

The Economical Entropy Of Inbound And Outbound Dialing


Why are there inbound and outbound boundaries with phones but not with Facebook/Google/Apple voice chats? Can we answer that question by looking at the smallest bits and pieces  ourselves and not relying on unreliable big investment firms analysts? Lets find out.

OK. In my diagram above, when lines, connections touch, it means they are associated. The purple inbound dialings do not touch any trunk lines, which means the inbound dialings are not associated with any particular trunk line. The orange PBX outbound dialing does not touch any phone line and is not associated with any phone protocol. The PBX outbound dialing, however, does touch SIP trunk line, which means it only goes out on the SIP trunk and not H323 protocol. So, all that means is that an inbound dialing does not care what the outbound trunk or protocol will be; an outbound dialing does not care what the inbound phone or protocol is. This is the essence of the PSTN call leg and the essence of VOIP.
For the green VOIP signal dash lines, the corresponding configs are in pjsip.aor.conf ,
[101]
type=aor

[102]

type=aor
[SIP-to-CUCM]
type=aor
contact=sip:10.1.10.76:5060


, and in ooh323.conf ,
[10.1.10.76]
type=friend
context=from-trunk
host=10.1.10.76
port=1720
[ekiga223]
IP=10.1.10.223
port = 1720
type=peer
context=from-external
. The purple inbound dialings are in extensions_additional.conf ,
[ext-did-0002]
exten => 18001231101,1,Set(__DIRECTION=INBOUND)
exten => 18001231101,n(dest-ext),Goto(from-did-direct,101,1)

exten => 18001231102,1,Set(__DIRECTION=INBOUND)
exten => 18001231102,n(dest-ext),Goto(from-did-direct,102,1)

exten => 18004561203,1,Set(__DIRECTION=INBOUND)
exten => 18004561203,n(dest-ext),Goto(from-did-direct,203,1)
, and outbound dialings are also in extensions_additional.conf
[outrt-1] ; siptrunk
exten => _1800321XXXX,1,Macro(user-callerid,LIMIT,EXTERNAL,)
exten => _1800321XXXX,n,Macro(dialout-trunk,2,${EXTEN:7},,off)

[outrt-2] ; h323trunk
exten => _1800654XXXX,1,Macro(user-callerid,LIMIT,EXTERNAL,)
exten => _1800654XXXX,n,Macro(dialout-trunk,1,${EXTEN:7},,off)

. The FreePBX GUI generates the entire extensions_additional.conf and pjsip_aor.conf . ooh323.conf is entirely manually created. All configurations are downloadable here, https://drive.google.com/file/d/0B2NfHoyfFf1aTWR6QUxQQVhkQWc .
The GUI dialogs are







The voice-vlan enabled router configuration is as  https://drive.google.com/file/d/0B2NfHoyfFf1aNXRhMnJyU01Zb0E .
The CUCM GUI screenshots are 


So, a call leg is basically a protocol proxy in the TCP/IP world. It provides some isolation("does not care") of parts of the network while demanding the border routers to have the insights into the protocol. This is what the future of engineering wants to avoid. From economy's point of view, the demanding of many border routers adds cost. To save money, borders need to be dumb down. However, when all intelligence are at the end server/clients, isolation is thinned down as well. So, people division is reduced. This is unavoidable because it is simply the nature's tendency of increasing physical and economical entropy. 


Sunday, May 7, 2017

Watching The Branch Office Traffic


The branch office is on the far side of the WAN, and predictably the SCCP phones are on the branch router's EtherSwitch ports. So, how to find the actual voice packets that we want to know how much network bandwidth is utilized?

  1. Easy, just browse the flow exports pcap. But the number of voice flows is actually a very small fraction of the number of signaling flows. Just look at this screenshot of pcap search, 
    , the first actual voice flow is at packet 280. The IP source/destination is indistinguishable between small, frequent signaling flows and actual voice flow. It turns out, among the thousands of packets, only 3 are actual voice traffic flow exports. Browsing is out of the question. The real C1900's flow pcap is at https://drive.google.com/file/d/0B2NfHoyfFf1aMzlNbnM0SkhpQTg/view?usp=sharing . You can try it yourself. 
  2. Easy, just search the TOS on the flow exports pcap, right? The problem is that the hardware phone is subject to change without notice, so the TOS number is unknow. 
  3. Why not search for flow packet size? The size is actually unknown as well. In above screenshot, there is a roughly 36MB sized packet every half an hour of 1800 seconds. The string "Octets: 360" seems very unique. However,  how do you get this number? Intranet voice runs at the common 64kbps for u/alaw 8kps sample,  8 bits quantization. (64+16overhead)kbps * 1800 seconds / 8bit/Byte . It should be 18MB. It turns out, the counting is done twice for each packet while ingress to the router and at the egress interface. There is no certain way to foresee the search string "Octets: 360".
It turns out, ELK search is necessary to figure out what search strings we want! And that search is performed by ranking all flow size(bytes), and the 36MB stands out in the crowd of 1KB short signaling flows.

The ELK graphing is as below picture after taking out all signaling flows,
. Notice, that straight ELK can't handle niche fields like VLAN ID. When VLAN ID is present, ELK may simply discard the whole flow. That is why we need to alter the flow content in an editor in the terminal.

Now, after going through so much, are we sure that modern phone voice indeed is with 8kps sampling rate? According to Math, 8 kHz sampling rate can only transmit 4kHz sound, and that seems too low for high human hearing. The answer is that modern SD phone speech is defined as from 300 to 3400 Hz. We can hear a lot wider range of sounds than we can make. And the speech encoding is not meant to transmit Hi-Fi music, waves, etc.

Saturday, May 6, 2017

Mind In The Data Center Zone


Zoning out on a compact setup that has everything.


The MQTT logs come from the Internet, sourced from a ARM mosquitto program. And the Kibana display of the MQTT traffic flow is this,

, notice TOS is marked down to precedence 1 (TOS 32 decimal), by T-Mobile. And a hundred of these IoT sensors looks like the picture at the top.

Rehabilitate The Tarnished Drone Image

OK, This is how to fly the helicopter with a joystick on any computer with LibrePilot ground control station. This is a discussion continuation from librepilot.org forum. Materials needed are,

Extra battery 150mAH 45C with connector4.3 grams
CC3D Revolution board8 grams
6mm pillars , 4 pcs0.8 grams
Thin wire as 433 MHz antenna0.0? grams
Clear tape0.0? grams
ESC for tail motor with power wire0.7 grams
Total 13.8 grams

Taking out the original board and canopy that are 2.8 grams and 4 grams respectively. So, total weight gain is 7 grams. The original v977 can lift payload of about 15 grams.

The extra battery only powers Revo board. All servos and all motors are powered by original ESC-BEC. The extra battery shares ground with original ESC-BEC. 
















And the ground control station setting is as below.



















Notice that the last picture is OPLink viewed from vehicle's perspective while ground OPLink unit is off the computer.