VoIP the low down

Discussion in 'Royal Signals' started by Disco, Apr 21, 2004.

Welcome to the Army Rumour Service, ARRSE

The UK's largest and busiest UNofficial military website.

The heart of the site is the forum area, including:

  1. following on from the Cormorant - Why thread

    Ok no doubt thieving FofS and YofS and IS Supv will print this out 100 times and use it for their final presentations. Hey you read it here first :D

    Ok I spoke with my guru mate and here is the lowdown on VoIP in regard to how we would deploy it (mobile or static HQ LAN ).

    Currently VoIP works fine with 100Meg systems. The 100meg LAN would require no upgrading as long as voice traffic was low. Now we know in our enviroment voice activity is very high so our LAN would benefit from the QoS (quality of service) protocol. QoS detects and prioitises voice and data packets keeps them seperate and sends in prioity. This reduces latency issues and increase network integrity. Most CISCO, 3M hubs and switches will allow the QoS protocols to be installed.

    So everything is fine so far, what impact does voice have on a LAN well according to my guru friend, voice on an average network will be 15% overhead of all transmissions. Now this could be a problem, especially with a 1 star HQ. Thats a lot of traffic. If network traffic increases to 100% capacity then LAN`s without the QoS protocol will see their speech clipped to the point where speech becomes unusable, so the network will not fall over.

    Lets look at the voice access itself. There are 2 options, hard and soft.

    A soft client require a mulimedia PC. It is a software install and the user requires either a USB headset or USB handset. Dialing and call control is done through the PC itself. (Could be a drama with users)

    Soft Client Advantages

    Numbers can be assigned to personal account/login, when the user logs that number is secure. Good for RED systems and multinational HQ`s.

    Cheap install, If PC has multimedia then only headset/handset required. Good for high density LAN`s

    Headsets/handsets cheap to replace and repair.

    Soft Disadvantages

    Training required to use.

    Department numbers would require a department login to keep the voice circuit open to use. Logged and switched off PC`s will disable voice circuit.

    A voice circuit requires a PC, standalones not supported.

    A hard client is an IP phone. Looks and works just like a normal phone but the insides are different. It does not require a dedicated cable. It connects inbetween the telecomms outlet (socket) and the PC.

    Hard Client Advantages.

    No training required.

    Standard telephony

    Remains independant of the PC, no login or log out issues.

    No cabling required. Network is reduced by 50%

    Hard Client Disadvantages

    Cost, your talking £100 per instrument.

    No Det repair possible (apart from handset and leads)


    The PABX switch requries a Gateway card (to connect to the CISCO) this will then support up to two DSP (digital signal processor) cards. A DSP card will support up to 32 clients but a gateway combined with 2 DSP cards will give 96 clients. There are some traffic issues which will affect the amout of gateways required.

    Cost of cards is comparable to existing subscriber line cards.

    Trunk connections would remain the same would not affect krypto/Satallite connectivity. But IP trunks are also available which would be useful for newer systems inservice.


    Currently in military service we use HICOMM REALTIS and ISDX PABX switches. PATRON typically runs over old ISDX switches but teh good news is that VoIP cards are available for all three switch types. Of course remote voice users such as sentrys or the 16line ULS can be fed from traditional subscriber cards over CW1308 or DON10 cabling.

    So VoIP upgrade on our LAN`s although increase costs it will reduce the amount of cabling required reducing the amount of time for setup and then number of installers required.

    Its not all roses, their will be transmission problems and some networks could be hit by bad bottlenecks through poor design etc.

    Right thats it my fingers are about to drop off.

    I hope you find this useful if you are considering a VoIP approach to your next deployment.

    Disco :wink:
  2. msr

    msr LE

    Funnily enough, I managed an acceptable video link to Sarajevo, myself on ADSL (256k upload) and the other end on 56k modem.

  3. Well performance with video conferencing is dependant many things such as frame rate, size of window and quality/compression etc.

    The compression would of been set by the lowest speed user in this case your 56k friend, although you may have had a smooth reception he/she may have been a bit more choppy from the lag.

    Main thing with the internet is you are at the mercy of network traffic. I would expect your routing to your friend was probably over 20-30 hops (hop being an router, building block of the net). If any of these "hops" experience a period of high demand they crawl to a halt regardless of your connection speed.

    In the forces we use various size Vid Conf systems running over everything from highband connections to Ptarmigan.

    I wouldnt be suprised to see agencies such as Paradigm start to offer video conf as part of the forces welfare package. They already use MSN Messenger, it is just a matter of bandwidth.

    It is a growth market and we would be fools not to take advantage of up and coming systems.
  4. Isn't BOWMAN using VoIP via the UCD's?
  5. DangerMouse

    DangerMouse Old-Salt Moderator

    Presumably you're not just referring to comms within HQs - what bearers are you considering? I've just come from the Data Comms cse run by Info Div at RMCS/Defence Academy, and I've read about VoIP as part of my Open University course, so I pestered the R SIGNALS tfc offr running the course for information. The following summarises the discussion:

    - VoIP relies heavily upon reliable, high bandwidth bearers. (Try using VoIP on your dial-up internet connection. Not fun.)

    - ATM is all but a prerequisite due to its implementation of Fast Packet Switching, and Quality of Service protocols used to prioritise voice packets.

    - ATM is designed to work on high bandwidth, low error circuits, with errors in the region of 10 to the minus 6 - it's designed for fibre optics, basically. Military trunks comms, for example, the TWACN/Coromorant SOR, requires comms to be established with as bad a quality link as 10 to the minus 2 (10,000 times more errors).

    - ATM is so fast because it uses small (53 byte) packets which contain very little error detection, and no error correction. These result in severe difficulties when using it to establish comms over military systems.

    - Apparently the Cormorant IPT have 'customised' the ATM protocol by 'hardening' the packets, by somehow enhancing the packet headers in order to allow bearers to be established over radio as opposed to purely fibre optic links.

    My understanding is that Cormorant uses traditional connection-orientated circuits for voice calls, and that at this stage no decision to implement VoIP has been made. The likely system for Falcon is apparently some form of TCP/IP protocol implementation (If so, hopefully version 6 not version 4), but again, this is speculation. If it is a TCP/IP solution though, then VoIP may then be an option, but problems over bandwidth and latency in deployed CIS systems remain.

    At this stage, as I understand it, there's no place for VoIP in anything other than static HQs and organisations. I can't even see that changing though, as all our bearers are contracted, through DCSA, to BT INCA, so it would be an immensely expensive task to change them, with little benefit to us. (i.e. We'd still be paying BT for a 'fluffy cloud' linking our voice and RLI networks together, it'd just be done in a slightly different way inside the cloud.)
  6. Because we could use the existing PABX switches (fitted with a gateway and DSP cards) the bearers would not change. The existing connectivity over RLI and SLI will remain the same. The PABX switch still controls the trunks. The VoIP bit is just an add on feature providing capability.

    The existing KELP cards with voice trunks running over 9.6k should suffice.

    My main point was that existing deployed HQ`s could be converted using off the shelf products which are compatable with ours.
  7. so it boils down to cost?
    if it is this easy then that must be the only reason?
  8. But VoIP is a cost saving measure. Thats the sweetness of its design, but cost effectivness is dependant on your user base etc. Smaller installs would not see the benefit apart from trunk dialling other agency locations and that could be done with a gateway card anyway leaving a standard PSTN install.

    DM says BowMan will use ATM (155megs) which is masses of bandwidth but ATM is incredibly expensive to run especially via satallite, but then these projects are run by people who never look at over all running costs such as cost effectivness ( KERCHING!!) too many company shares to look after :roll:

    But we would not require ATM for VoIP (although ATM is required for Bowman as a bearer) we can run a solid system over far far less bandwidth.

    As for who delivers VoIP well this is 3 fold. The Install Tech still designs and implements the LAN. The existing exchanges (PATRON) can still be maintained by Techs (VoIP is just extra cards and a small config) and continue normal extension and trunk managment(COS/TAC) and the IS Engr installs the hard or soft client and configures the QoS protocol through the active LAN equipment.

    Bobs your uncle fannies your aunt, Jobs a good un. Now that didnt hurt did it :)
  9. The problem lies with the protocol - IP (Internet Protocol). In the military we want to give certain users a voice/data circuilt on demand, you can't do this with IP.

    It is however more efficient, normally the 12 or so voice channels waste bandwidth when not used but with VoIP that bandwidth can be utilised.
    (Say if you have a 256 link .. maybe 12 of the channels are currently dedicated to voice circuits leaving for example 48k for data, using VoIP you can use the full 256)

    If IP could be assigned preceedence or addresses given different priorities then VoIP would be an excellent system
  10. Just a point I heard from somebody who works in the VoIP civvy market. A large portion of calls handled by BT are in fact now switched through VoIP technology. Is this a case of civilian market place being a number of steps of the military (again)?
  11. Don't sound so bl00dy surprised. Civvy St is always way ahead of the military, they won't hand over the cash unless a system is up to date. Bowman was state of the art when the initial project was set up, way back in the 80's, now it's just 'a state'.
  12. Call me crazy, but shouldn't the powers that be approach some of these civvy firms, who are obviously investing heavily in R and D and start up technology sharing etc. Or is that all too unsporting?
  13. the MoD like everything squadie proof which takes time and adds to the cost
    if we just used COTs equipment then everything would be fine and dandy.
    the other problem is the maintenance policy.
    they pay large amounts for this and that too takes time to set up
    that's why we are always so far behind
    the only good thing is that it is a tried and tested technology by the time we get it!
  14. "Tried and tested" just means that you can't get spares for it anymore. Ever seen how much it costs the MoD to make lifetime buys of obsolete kit on military projects ? Frightening numbers, and all because the retards at the DPA can't get their heads around that fact that it's cheaper to replace the kit every few years than buy something to traditional standards that lasts 25 years. Some of the gain is wiped out by the need to run a development team all the time but even so it's still cheaper.

    The US Navy did it with submarine combat systems and saved ridiculous amounts of money - as well as getting a more up to date product.