Archive | Voice RSS feed for this section

Combating Unwarranted Phone Surveillance with Biometrics and Voice Control

1 Mar

Amidst the introduction of a new mobile tracking bill, targeting the existence of warrants— there has been a sudden rise in the number of frightened consumers. Most handset owners are dealing with skepticism, concerning lack of mobile security and other malicious activities.

In this post, we will be talking about the possible security loopholes in the existing arena in addition to certain methodologies or rather technologies for combating the same. Before we move any further into this post, it is fitting enough to understand how phone surveillance works, regardless of the legalities associated with the same.

Decoding Mobile Tracking

Phone Surveillance

In simpler terms, mobile tracking is an undesirable act of sabotaging someone’s privacy. While many government organizations have already resorted to these methods for averting security threats, more often than not phone surveillance is an unwarranted and unauthorized affair— leading to catastrophic outcomes.

Existent of Consumer Spyware

When it comes to malware targeting mobile tracking, consumer spyware is the latest fad. This is one of the most effective techniques— used by fraudulent organizations for getting inside the handset of any user. Usually, this form of malware comes as a mobile application or a separate, downloadable entity. Once allowed access, the spyware easy takes control of images, data, phone log and everything that’s inside the device.

The worst part about consumer spyware is that it can be installed within a few seconds and starts working in the background. While physical access to the handset is required, a skilled hacker can easily install the bug without the owner even noticing the instantaneous sabotage. That said, malicious applications can also embed the spyware with minimal hassles.

Lastly, consumer spyware can even access the phone audio and microphone, allowing hackers gain complete access to every word spoken.

This form of malware is mostly used by firms with nefarious intentions who look to sell over the acquired details to other parties for financial perks.

‘Stingrays’

stingrays and Phone Surveillance

While malicious applications and malware can be detected by being vigilant, there are certain newly devised techniques which are nearly impossible to identify. Stingrays are the newest techniques used by hackers for getting unwarranted access to any mobile. These entities sit on the mobile towers or act as authorized establishments— luring users into addressing them as legit ones. Mobile users, unknowingly, send data via these towers and allow malicious sources right into the device.

Safeguarding Handsets with Biometrics

Biometrics are some of the more desirable techniques, targeting mobile safety and privacy. While the existing solutions are great, we are expecting a more granular approach towards secured devices. The concept of biometric protection has already been taken seriously by several authorities— across the globe— integrated with global bank statements and other confidential documents. Some of the developing nations have also identified the importance of biometric solutions— integrating the likes of national cards and associated details with the respective handsets.

However, the amalgamation of identity card biometrics with mobile solutions need to be country-specific as different nations have different rules regarding their ID segregations. We have country-specific biometric-spruced ID proofs for the developed and even developing nations— biding the likes of retina scans, fingerprints and even digital signage with the smartphones.

biometrics and Phone Surveillance

This is a more granular approach towards biometric solutions and is expected to curb the inadvertent growth of unwarranted phone surveillance.

Certain AI empowered smartphones are also being considered for amalgamating biometrics with voice and other kinds of authentication schemes.

Combating Fraud with Voice Control

Although getting access to the phone mic isn’t as hard as it seems, consumer spyware can still be kept at bay via authorized voice control. While accessing any electronic device via voice seems to be a far-fetched idea, it seems scientists have already established certain measures leading to the same.

Quite recently, scientists have developed a low-cost chip which could change the way we handle our electronic gadgets— especially the mobiles.

Closing in on the chip, it is a great tool for automatic voice recognition— featuring a low-power console, courtesy the adaptable form factor. If used in a cellphone, the existing chip requires a mere 1W to get activated. Moreover, the usage pattern actually determines the amount of power needed to keep the chip activated.

When it comes to safety, the existing chip can sit on any given cellphone and prevent unauthorized access. This feature is one aspect of looking at Internet of Things for mobiles— instrumental in safeguarding the same from unwarranted surveillance.

The reason why we are upbeat for voice recognition as a pillar of safety is that speech input, in years to come, is expected to be a natural interface for more intelligent devices— making hacking a less-visited arena.

In the upcoming years, voice recognition chips are expected to make use of neural architecture and other aspects of human intelligence— making safety an obvious concept and not a selective one. However, power consumption remains to be one of the major limitations. At present one chip works on a single neural node of a given network— passing 32 increments of 10-milliseconds each.

Bottom-Line

Unethical tracking isn’t going to stop with the introduction of voice recognition techniques and biometrics. However, perfect application of the same seems to have lowered down the instances and we can just be hopeful of a more transparent future. There has been a lot of work going on in the field of speech recognition for every smartphone and we might soon see a pathbreaking innovation in the concerned field.

That said, biometrics have found their way into our lives, documents and even smartphones and their usage has also skyrocketed. There were times when users hardly made use of a fingerprint scanner but the current scenario suggests that iPhone’s Touch ID is used at least 84 times a day— on an average. This shows users are slowly adopting technology as their weapon towards safety and privacy.

Source: http://fundesco.net/combating-unwarranted-phone-surveillance-with-biometrics-and-voice-control/

Advertisements

VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)

17 Feb

Voice over LTE or VoLTE has many problems to solve. One of the issues that did not have a clear solution initially was Roaming. iBasis has a whitepaper on this topic here, from which the above picture is taken. The following is what is said above:

The routing of international calls has always been a problem for mobile operators. All too often the answer—particularly in the case of ‘tromboning’ calls all the way back to the home network—has been inelegant and costly. LTE data sessions can be broken out locally, negating the need for convoluted routing solutions. But in a VoIMS environment all of the intelligence that decides how to route the call resides in the home network, meaning that the call still has to be routed back.

The industry’s solution to this issue is Roaming Architecture for Voice over LTE with Local Breakout (RAVEL). Currently in the midst of standardisation at 3GPP, RAVEL is intended to enable the home network to decide, where appropriate, for the VoIMS call to be broken out locally.

Three quarters of respondents to the survey said they support an industry-wide move to RAVEL for VoLTE roaming. This is emphatic in its enthusiasm but 25 per cent remains a significant share of respondents still to be convinced. Just over half of respondents said they plan to support VoIMS for LTE roaming using the RAVEL architecture, while 12.3 per cent said they would support it, but not using RAVEL.

Until RAVEL is available, 27.4 per cent of respondents said they plan to use home-routing for all VoLTE traffic, while just under one fifth said they would use a non-standard VoLTE roaming solution.

Well, the solution was standardised in 3GPP Release-11. NTT Docomo has an excellent whitepaper (embedded below) explaining the issue and the proposed solution.

In 3GPP Release 11, the VoLTE roaming and interconnection architecture was standardized in cooperation with the GSMA Association. The new architecture is able to implement voice call charging in the same way as circuit-switched voice roaming and interconnection models by routing both C-Plane messages and voice data on the same path. This was not possible with the earlier VoLTE roaming and interconnection architecture.

Anyway, here is the complete whitepaper

Source: http://blog.3g4g.co.uk/2014/02/volte-roaming-with-ravel-roaming.html

Cisco 3850 switch sample QOS Configuration for Voice and Video

4 Nov

The Voice Initiate

HINT: If you have soft-phones or Soft Video clients  on your network then this is not for you.  You might want to explore the use of access list instead. 

 

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Catalyst 3850 Configuration samples 

:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

This configuration was designed to optimize a network that generates 30% Voip and Video  traffic whilst the remaining is bulk data.  This solution is currently  working perfectly in  an extremely busy network. The brief was that the configuration be kept simple yet effective

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

Steps:: 

Create two class maps: The first class maps matches the DSCP  and COS markings of Audio and Video traffic:

class-map rtp_audio_and_video
match dscp af32 af33 cs4 af41 af42 af43 ef
match cos 4 5

class-map signal
description voip signal traffic
match dscp cs3 af31 af32 af33
match cos 3

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

One of the cool features of the 3850 switch is that it allows for the creation of…

View original post 661 more words

Calculating Bandwith for Video Calls

25 Oct

A few weeks ago I wrote a blog on determining the bandwidth used by voice calls in Calculating Bandwidth for SIP Trunks.  Now, while voice is an extremely important aspect of SIP communications, the beauty of SIP is that it isn’t limited to strictly voice.  On my various PC and smart phone clients I do voice, presence, instant message, and video.  While communications forms such as instant message and presence do consume some network bandwidth, it’s extremely low and neither is of a real-time nature.   However, video is very real-time in nature and will typically consume far more data than even the most data intensive wide band voice codec.

Video codecs have a number of distinguishing characteristics, but in terms of bandwidth utilization we are concerned with two major factors – resolution and frame rate.  Resolution is expressed by the pixel height and pixel width of the rendered image.  Frame rate is expressed in image frames per second.  Clearly, more pixels sent more often produces the best image.  This, of course, leads to greater bandwidth consumption and possibly less video calls on your network.

It is my experience that the following five video codes are the ones you will most often encounter with video calls – Divx, H.263, H.263+, H.264, and MPEG-4.  Each of these codes offer different resolution and frame rate values that ultimately create different quality experiences and bandwidth requirements.

For DviX codecs you will commonly find the following variations:

Client Setting

Resolution

Frames / sec

Quality

Bandwidth (kbps)

Average (kbps)

Very low bandwidth

160 x 120

2

Very low

10 – 20

15

Low bandwidth

160 x 120

10

Low

60 – 120

80

Medium bandwidth

320 x 240

10

Medium

150 – 300

200

High bandwidth

352 x 288

15

High

400 – 800

600

For H.263, H.263+, H.264, and MPEG-4 it looks like this:

Client Setting

Resolution

Frames / sec

Quality

Bandwidth (kbps)

Very low bandwidth

176 x 144

2

Very low

10

Low bandwidth

176 x 144

10

Low

64

Medium bandwidth

352 x 288

10

Medium

192

High bandwidth

352 x 288

15

High

512

Very high bandwidth

640 x 480

30

Very high

768

At this point you need to determine the number of simultaneous video calls and the quality level of those calls.  Unlike your voice traffic, these numbers might not be as easy to determine.  Video is still a relatively new form of communication and you may not have the empirical knowledge required to do a full analysis.  This means that you will have to take your best guess and be prepared to add or remove bandwidth as users become more comfortable with making and receiving video calls.

However, I will take a stab at a few estimates that may form the basis of your best guess approach.

Expected Video Sessions:

Subscribers

Sessions

10

8

25

12

50

17

75

23

100

27

250

54

500

95

750

134

1000

171

1250

210

Your number may vary quite a bit from these.  The important thing is to do the best job you can in determining the number of sessions.

Next, you need to translate those sessions into bandwidth requirements.  Given the above data I come up with the following video requirements in Mbit/sec.

Sessions

Very Low

Low

Medium

High

Very High

8

0.1

.6

1.6

4.8

6.1

12

0.2

1.0

2.4

7.2

9.2

17

0.3

1.4

3.4

10.2

13.1

23

0.3

1.8

4.6

13.8

17.7

27

0.4

2.2

5.4

16.2

20.7

54

0.8

4.3

10.8

32.4

41.5

95

1.4

7.6

19.0

57.0

73.0

134

2.0

11

27.0

80.0

103.0

171

2.6

14

34.0

103.0

131.0

210

3.2

17

42.0

126.0

161.0

To determine your particular bandwidth needs, I suggest the following:

  • Estimate the total number of SIP video subscribers that will be using each video quality level.
  • From this estimate, determine the number of video sessions using the above table.
  • Using the bandwidth requirements table, determine the bandwidth for each expected codec.  Sum those numbers.
  • Note.  Rather than trying to estimate for each video codec type, pick an average codec and multiply by the expected number of video sessions.

You then need to ensure that your switches, routers, queues, and uplinks are sized to meet the expected video traffic.  Also, make sure that you apply the proper QoS settings to ensure the best video experience possible.

I hope this helps you understand what you need in terms of bandwidth for your video roll-out.  It’s important to realize that video is not going away and the demand for quality, well-behaved video calls will be growing every year.  Do it right and your users will be happy.  Fail to plan and configure your network appropriately and you risk a help desk nightmare.

 

Source: http://andrewjprokop.wordpress.com/2013/10/24/calculating-bandwidth-for-video-calls/?blogsub=confirmed#blog_subscription-2

How FreedomPop is separating voice from data on its new VoIP phone service

24 Oct
Road splits forks divides

SUMMARY:Thanks to Telespree’s technology, FreedomPop is tracking VoIP traffic within its data stream. That not only allows FreedomPop to charge separately for communications services, but opens the door to much more sophisticated features in the future.

FreedomPop launched one of the country’s first all IP mobile services this month. Consequently, it has to deal with an interesting problem facing all future IP mobile operators: If all your traffic is running over the same data connection, how do you distinguish between voice, SMS and internet traffic so you can charge accordingly?

The company is solving that problem by working with Telespree, which provides a cloud-based monetization service for carriers. Basically Telespree is picking apart all of the CDMA and WiMAX (and eventually LTE) data traffic that traverses FreedomPop’s phones. That way it knows not to count a VoIP call or an IP SMS message against a customer bucket of megabytes. Telespree can also track that voice and data traffic – translating kilobytes into minutes and messages consumed – which allows customers to monitor their data, voice and SMS usage.

That all seems rather simple, but teasing voice out of the data stream is just a first step. FreedomPop is a ‘freemium’ operator: it’s giving away 500 MB, 200 voice minutes and 500 text messages to its customers for free, but it plans to offer value-added services on top of those core communications apps. And Telespree’s services architecture is tailor-made for that kind of business model.

FreedomPop smartphone

As an all VoIP provider, FreedomPop can layer things like video chat, group messaging and conference calling on top of standard voice and messaging much more easily than any carrier. In a recent conversation, FreedomPop CEO and co-founder Stephen Stokols said that was exactly the direction FreedomPop is heading: offering core communications services for free and charging for premium featureslayered on top of them. Stokols, however, didn’t reveal any specific details about what those services would be.

Using voice and data as currencies

FreedomPop isn’t just looking at mobile data, minutes and texts as commodities, it sees them as virtual currencies. Customers today can trade megabytes with friendsand earn bigger data buckets by referring customers or viewing advertising content. Other companies like Aquto have also latched on to that concept, attempting to turn the megabyte into the mobile equivalent of the frequent flier mile. Over-the-top communications provider Rebtel is letting its international calling customersexchange voice minutes with one another, letting them move value — if not actually cash — across borders.

Free Stuff

FreedomPop will eventually start letting its customers trade and earn minutes and texts like they can data, Stokols confirmed. But the more interesting idea is how it could combine those freemium and currency models using Telespree’s technology. Here’s one possible example: If you’re calling another FreedomPop customer using your free minutes, perhaps you could get an option to upgrade to a video chat call. You might then get a choice on how to pay for that video session. You could buy video chat minutes or you could deduct double the amount of voice minutes you would consume for a normal voice call. Or you might even get the option to view a video advertisement, which would make the video call free.

Eventually, the big operators will be able to offer similar kinds of enhanced communications services when they launch their voice-over-LTE networks. But it’s doubtful they will adopt the same kind of pricing models that carriers like FreedomPop is experimenting with. FreedomPop and competitors like TextNow andScratch Wireless are mobile virtual network operators (MVNOs) meaning they’re only renting time on another carrier’s network (in all three cases Sprint’s). To them, mobile megabytes and minutes are the expenses of doing business. For the network operators, selling data and voice plans is core to their business strategies.

 

Source: http://gigaom.com/2013/10/22/how-freedompop-is-separating-voice-from-data-on-its-new-voip-phone-service/

Frame Relay Traffic Fragmentation | Complete Lab Included

12 Sep

Cisco’s Frame Relay Traffic Fragmentation scheme supports the transport of mixed voice and data traffic across the same interface without the longer data frames causing excessive delay to the normally smaller-sized voice packets. The longer frames are fragmented by the router into a sequence of shorted frames at the sending end. Then the smaller fragmented data frames can be interleaved with the real-time delay-sensitive voice frames.

In this lab, we’ll configure frame relay traffic fragmentation over the link between R1 and R2. Network administrator has determined that 150 bytes is the optimal transmission size over this line.

Frame Relay Traffic fragmentation

 

Network Diagram: Frame Relay Traffic Fragmentation

Trap: Frame relay traffic-shaping can be configured one-way, but fragmentation cannot. If one side is not configured for fragmentation, it will not know what to do with a fragmented frame and therefore will discard it.

We enable frame relay fragmentation on the link by configuring both routers with fragmentation commands.

Download the Qmap to get detailed configuration guide, commands, outputs and map of the lab. You will need NetBrain Qmap Reader to view this Qmap.

Download Qmap

Source: http://blog.netbraintech.com/2013/09/10/frame-relay-traffic-fragmentation/

CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 2

9 Sep

continuing the CSFB vs. SRVCC, or how to “sudo make me Voice over LTE” – take 1

I was thinking the other day and I realized that CSFB is meant to be used only if VoLTE cannot be used for some reason. That sounded strange to me as in order to be able to use CSCF you need the special combined EPS/IMSI attach but in some cases you may find yourself unable to use VoLTE after you attach. On example of such case is when the network prefers VoLTE and the UE is able to do VoLTE but IMS voice is not available (for example the registration to the IMS network fails).  To find the answer to my questions I turned to TS 23.221, maybe it can help in some way.

What I found is than an UE can be either voice centric or data centric. This usage setting basically tells the network what’s more important for that UE (voice or data). For example a voice centric UE will disconnect from E-UTRAN and try GERAN/UTRAN if it is not able to obtain voice service in E-UTRAN while a data centric UE will not do that.

Now, there’s another setting on the UE which is called voice domain preference and has one of four values CS Voice only, IMS PS Voice only, CS voice preferred, IMS PS Voice as secondary, IMS PS voice preferred, CS Voice as secondary.  Based on these 2 settings and what happens in the network the UE will prefer one of the following 4 states:

 

Voice centric UE

Data centric UE

CS Voice preferred/ CS Voice only

CS/PS mode 1

CS/PS mode 2

IMS PS Voice preferred/ IMS PS Voice only

PS mode 1

PS mode 2

* an IMS PS Voice preferred UE may still be connected to both systems.

* an IMS PS Voice Only UE will not use combined attach or CSFB

*TS 23.221 Annex A gives guidance on how a CS and IMS capable UE should behave.

On the other hand, the network has its settings and preferences too. When an UE attempts to do a combined attach, the network may inform the UE of its settings, like CS Fallback not preferred, SMS-only (the CS network is to be used to SMS over SGs only, not for CSFB) or IMS voice not available. The UE may transition between these states if its settings or the network’s settings change. Also an UE in a PS mode state will transition to the corresponding CS/PS mode state if IMS is unavailable for some reason.

Now, in order to do CSFB or SMS over SGs one needs to be in one of the CS/PS modes. To be in one of these modes the UE needs to do a combined EPS/IMSI attach. Now let’s say our UE is set to prefer the IMS for voice calls but its registration to the IMS network fails for some reason or the network indicates to the UE it does not support PS voice. In this case the UE is already connected to the EPS network but most likely not to the CS network and in order to use CSFB it needs to transition to a combined EPS/IMSI attach situation. To do this the UE will do a Combined TA/LA Update Procedure (TS 23.272 section 5.4.1).

Later edit:

Relevant specs for the UICC side:

TS 24.008 – Layer 3 specifications, Core network protocols

TS 31.102 – USIM Applications

Why? : Because I would like to see in more detail how this entire CSFB/SRVCC story happens at the UE+UICC(SIM) level.

Source: http://windancersth.wordpress.com/2013/09/07/csfb-vs-srvcc-or-how-to-sudo-make-me-voice-over-lte-take-2/

Circuit Switched Fallback Falls Short

24 Jul

One of the hottest topics right now in Telecoms is Voice over LTE, or VoLTE as it’s more commonly known. This technology will enable Mobile Service Providers (MSPs) to finally deliver voice calls across their entire IP, access and core network. This capability will help create a more efficient end-end network infrastructure, and also take advantage of the policy rules now available to ensure optimum customer call Quality of Service (QoS).

Read: Give VoLTE a Voice

But despite the benefits for an MSP in implementing VoLTE, to date, rollout of the technology has been slow. The cause for this lies in a number of reasons, with one of the most significant being the availability of an alternative approach to delivering voice services: Circuit Switched Fallback (CSFB).

Why Circuit Switched Fallback May Not Be the Answer

The theory behind CSFB is simple. The LTE device essentially registers and connects to the LTE network, enabling the customer to utilise the high bandwidth and high speed packet network for all data-related services. However, when it comes to either making or receiving calls, the device then “falls back” to the legacy circuit switched 2G/3G network. Sounds simple, but in practice, implementation has uncovered a number of challenges for MSPs.

When a device performs the fallback procedure, initial tests have shown that it can take 3-6 seconds longer for a call to be set up. This delay exposes what in actual fact is a complex procedure, which involves successful initiation of the legacy radio network, including channel measurements, in order to determine the correct cell and frequency for the associated device. Such a delay in call setup of course results in a poor experience for the customer.

For outgoing calls that experience this kind of delay, the customer may actually think the call cannot been completed and so decide to hang up. And the situation gets worse when a call is from an LTE device to an LTE device. In such a case, both devices must perform the fallback procedure, representing an even greater delay before the call is connected.

Customer Experience: The Deciding Factor

Clearly, while CSFB may well be an alternative, it is most likely only useful in the short-medium term. Ultimately, customer experience will be the deciding factor that will eventually drive MSPs to implement true Voice over LTE.

For more information about understanding customer experience in LTE deployments, read this paper. Do you have any thoughts about Circuit Switched Fallback vs VoLTE? Let me know in the comments below.

Source: http://blog.empirix.com/2013/07/23/circuit-switched-fallback-falls-short/

FirstNet: we only have three LTE vendor choices that make sense…allow me to explain.

18 Jul

If you are FirstNet, a State, or a procurement official you are probably well aware that LTE has a limited amount of potential vendors. In the North American market we have Alcatel-Lucent, Ericsson, NSN (soon to be Nokia), Huawei and IP Wireless with GD. Let me break it down to the real players. First, Huawei is out, probably due to some type of overreaching threat of spy activity that would tap into all our phone lines and data calls to track what we are doing….or am I talking about the NSA? Doesn’t matter they are out.   If we look at the remaining players three of them have real carrier deployments of LTE and make up the bulk of the worlds LTE deployments. IP Wireless does not have that footprint. It doesn’t mean somebody won’t roll out IP Wireless and given the four stages of a relationship I wish that willing party the best in their exploratory phase of such a young relationship. Thats always the best part of the relationship — lots of touching, feelings, and kissing….off topic sorry. We do have other makers of LTE, such as Fujitsu, but they seem to have an issue with leaving their own mainland.

Out of the main providers on the table — ALU, Ericsson and NSN — we have to look at the design of the solutions and whats best for this particular case. At the base of that comparison is the terms FDD and TDD. I’m not going to get technical on you here but you need to understand the TDD stands for “Time Division Duplex” and FDD stands for “Frequency Division Duplex”. If you insist on having the technical details then just google it. The main thing you need to know is that the traditional telephone networks, since the Bell days, were built on “Time Division Multiplexing” and is better known as “voice” or “telco” networks”. The entire cloud of the Internet was based on “Frequency Division Multiplexing” or better referred to as data or packet networks.

The introduction of wireless started on the TDM side of the house in direct support of Voice. Around the same time certain ventures starting exploring the use of such things as Wifi which ultimately created something called OFDM (Orthogonal Frequency Division Multiplexing). Got to love the complex terms. Makes me feel smart. Anyway OFDM became the basis for WiMax and LTE, but in this case the carrier market chose LTE over WiMax due specifically to the reason that LTE is better suited to accommodate the vast amounts of TDM infrastructure the carriers own and have owned since their creation. As it stands today 99% of the entire worlds carrier market has chosen LTE. It doesn’t matter if you think WiMax may be better…..Betamax was better than VHS.

Then came along the terms FDD versus TDD in the current realm of available LTE vendors. In layman’s terms what is the easiest way to explain which of the platforms is best suited for FirstNet? Well FirstNet doesn’t have the burden of an installed base of old TDM architectures that were designed to support voice and voice only, so why install TDD. The better choice is FDD!

The FDD solution was designed and made for the next step in the wireless networking world, which was the leap beyond small 32-bit voice packet architectures and onto the much bigger 64–1600 bit data packet architectures. The bigger packet sizes accommodate for more efficiency in data packet transmissions. Being that there is so many packets its better to take the large bus to school as opposed to the short small bus. As I have always said size does matter. Being that the majority of all the traffic on the FirstNet architecture will be data, then why would we consider deploying an architecture to support voice when voice isn’t our main reason for the network? Unless of course your business plan calls for a full-out connection and relationship with the national carriers to provide you your services — I’m referring to the FirstNet model. What better than to tie the entire Public Safety data requirements to an already established voice architecture that isn’t optimized for our needs!  Now it may be me just stepping out of the box here, but wouldn’t it be inventive to deploy a data network for our data needs?

The best way to explain FD-LTE and TD-LTE is that FD-LTE is a router based network and the TD-LTE is a switch based network. Routers were made for larger data packets and switches were designed for smaller voice packets. The only time this really will really have an impact is if you are really pushing the bandwidth limits of your network; enough to where you have to start looking at efficiencies of use. Traditional TDM architectures carry a 30% overhead on every packet — that’s like taking a trip with a fully packed roll-aboard suitcase, plus an full packed computer bag, then adding another fully packed computer bag.  It just becomes another financially impacted and non-efficient way of carrying your crap. It’s easier just to take two roll-aboard suitcases.

Being that the first iteration of the LTE deployments will have bandwidth 300 times that of the current data requirements of Public Safety gives us a little breathing room. But in the end their is only one real LTE vendor that properly aligns with the LTE based data packet architecture — NSN….who would have thought! So if you aren’t considering NSN for your solution then you may have been duped down a path that best supports the commercial carrier market than your own private data needs. Hopefully this explains why Voice Over LTE doesn’t exist today (as you would expect) — it’s because the carriers don’t need it. They make all their main revenue from their traditional business of assets which are all based on TDM telco voice services and designed for that means…why change to this thing called data? Seems so archaic. (sarcasm)

Just some guy and a blog…..

Confusion about voice vlan

27 Apr

This set up is most definitely how it all looks like in your office environment, go ahead and first check and see how your PC connects with your desk phone then from the phone trace the cable which most likely connects to RJ45 floor port which most likely is located under your desk then it all goes through the walls of your company all the way back to your Company’s Comms Room (Data Centre) where it connects into a patch panel in one of the network cabinets and from there directly to L2 switch which then goes to your business’s L3 Core switches, routers,firewalls etc …

voice

 

I have spent really long hours on this one, especially the one that involves  802.1p tag

I have been looking into this like a madman and must admit that Voice combined with QOS is not the easiest to understand.

The reason why it takes so long top prepare for the LAB is because you never know what Cisco is going to ask you to configure or troubleshoot and this is because we need to know and understand it all !!

The upstream switch communicates with the Cisco IP phone using CDP to set up an interconnection link that allows the Cisco IP phone to send VoIP packets on its uplink port back to the switch, either in the VoIP VLAN or in the data VLAN

So there are 4 modes to set up a switch port you expect to plug a phone into (Interface Ethernet 4/0 connects to the phone)

===============================================================================
===============================================================================
1. First you can just use a regular access port. In this mode, both the phone traffic and pc data both land on the same access vlan and there is no way to distinguish between the two. Two things to note, because the traffic will use the same vlan then you have a security risk as well as having no ability to provide QOS priority to only the phone. Any QOS is applied to ALL traffic coming in that switch port.

Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport mode access
Rack5SW2(config-if)#switchport access vlan 79

or

Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport mode access
Rack5SW2(config-if)#switchport voice vlan none

 

===============================================================================
===============================================================================
2. Now we see the special 802.1Q trunk where CDP is required. The second mode is referred to as “untagged”. Now cisco doesn’t use the term untagged too often but when you create a dot1Q trunk, every packet entering the switch needs to have a vlan tag to specify what vlan number it belongs to. Any packets entering the trunk port without a vlan tag, is dumped into the untagged vlan, or as cisco calls it a native vlan.
By default this is vlan 1, so you probably need to specify a untagged vlan for this method.

Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport trunk encapsulation dot1q
Rack5SW2(config-if)#switchport mode trunk
Rack5SW2(config-if)#switchport trunk native vlan 146
Rack5SW2(config-if)#switchport trunk allowed vlan 79,146 (This is optional and Vlan 79 is for data)
Rack5SW2(config-if)#switchport voice vlan untagged

 

===============================================================================
===============================================================================
3. Third we have the dot1p mode. In this mode just like in the first method but this time you gain the qos abilities by adding 802.1p COS tag. The phone will actually tag it’s own voice traffic with vlan id equal to 0, and send it with a 802.1p priority of 5 by default. (call control gets a priority of 3). The benefit of this mode is that you get QOS abilities without needing a separate voice vlan created on your switches and routers. The PC traffic should be the default priority of 0 or best effort.

Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport mode access
Rack5SW2(config-if)#switchport access vlan 79
Rack5SW2(config-if)#switchport voice vlan dot1p

 

===============================================================================
===============================================================================
4. Fourth is the most common method the vlan-id option and it is most likely used in your office.
Create a vlan on your routers and switches that will be used just for phones. The phone will now send voice packets tagged with your voice vlan ID to the switch, with Layer 3 IP precedence and Layer 2 CoS values, which are both set to 5 by default, while the data packets are sent along untagged to the access vlan.

Rack5SW2(config)#int ethernet 4/0
Rack5SW2(config-if)#switchport mode access
Rack5SW2(config-if)#switchport access vlan 79
Rack5SW2(config-if)#switchport voice vlan 146

Note that spanning-tree portfast is automatically enabled as soon as “switchport voice vlan ID” is applied

 

Now log on to few access switches in your company and check switchports configuration and compare with all above examples also if and ONLY if you have an opportunity and you’re convinced you will not affect any of your business daily operations go ahead and lab it up , I guess for that you could use your own office desk phone just to minimise risk , well I’ll leave it for you to decide

Source: http://ccie4all.wordpress.com/2013/04/27/confusion-about-voice-vlan/

%d bloggers like this: