VOIP Traffic Segregation Should Be App Developers' Work, Phone-To-Phone

To achieve highest possible VOIP quality, it seems obvious that phones should generate IP UDP packets with the proper markings to segregate the traffic. The problem is that IP network is a cloud of many competing routing protocols, each with its own forwarding algorithm, each is bent on dominating the market for monetary gains. Civilizations come and go; protocols pop and burst throughout history. How can the Internet work worldwide is a mystery, let alone ensuring the highest quality, right?


People's will makes the roads, VOIP is no exception. The competing protocols need to come together to make ways for the greater good. The evidence is in an experiment with this 2-leg setup, . And the netflow collection export shows that, indeed, legitimate hardware developers faithfully copy DSCP field from different vendors into MPLS labels and out onto phones.

I first checked with freeware Kibana Elk collector, which omits MPLS flow exports, but I hold out the hope that the actual packet have faithful replications.

I used the common flow exporting configuration,

, and I see tell-tale signs of MPLS packet markings in the "experimental bits" fields with the VPN label as well as the transport label,

, then I turn to commercial grade Plixer netflow collector, and bang, CS3 marking for SCCP control packets (TCP port 2000) is in the rainbow graphing,

, and further inspection of all the flows between phones and CUCM shows TCP non-SCCP-control packets that have common DSCP 0 in the MPLS labels. 

Internet As A Community Needs To Be Practiced - Enter Proxy Security

You are looking at my site as if it belongs to blog.mpls-phone.com and hosted by MPLS-Phone Inc's hardware, but you are also aware that this site looks just like a google blogger's page. So, we assume that google is aware that its server is being used by blog.mpls-phone.com server IP 34.225.89.249, or is it? Does google think that 34.225.89.249 is just another browser on the net, not knowing that google's application servers, counter tracker servers, warehouse rental fees, property tax, etc, are diverted to serve MPLS-Phone Inc's interest? This is different from google's authorized custom domain, which allows only 1 custom domain for a particular blog. Here the proxy allows any number of sites with different domain names simultaneously.

From the agriculture revolution of mankind, everything can be traced to its owner, and ownership can be protected. It will be very surprising if the Web is an exception, and laws of economy needs to be changed. The Web can be protected even though it appears counter intuitive. Most people think that no one is in charge of the Internet, no regulation, no borders, no laws. But, all the routers, servers, modems are business properties of different commercial entities or states. If the hardware's ownership is traceable, so is the content of the Internet, right? We need to dig a little deeper.

So, lets first look at the hardware setup,

And look at the software uses Amazon's AMI IDamzn-ami-hvm-2017.03.0.20170417-x86_64-gp2 (ami-c58c1dd3)
uname -a shows
Linux ip-10-201-1-124 4.9.20-11.31.amzn1.x86_64 #1 SMP Thu Apr 13 01:53:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

The steps to install the proxy is

- yum intall httpd mod24_ssl

- yum install httpd24
- yum install mod_ssl
- yum install mod_proxy
- yum install mod_proxy_html
- vim conf.d/proxy_html.conf , content be as https://drive.google.com/open?id=1e7BV4v601tDlNUF6GMNUkgjMQC1zC5mm
- vim conf/httpd.conf , content be as https://drive.google.com/open?id=1uMXr6mh7exlmwkiVxgjSKYW2WAIe3kD-
   30  vim conf.d/ssl.conf ,  content be as https://drive.google.com/open?id=1rF42jeLTxovGBqkRwN4q1aMnlB81FW_g
- service httpd enable
- service httpd start
- mkdir /var/www/nonexisting/ , content of index.html inside it be one bogus line.

So, the SSL PKI facility does not protect google. What went wrong? Please stay tuned for the update of this post for answer.