This is a recommendation from the EBU, aiming at interoperating audio codecs over IP networks. The EBU recommends the SIP and SDP protocols, as well as a mimimum set of coding algorithms to be supported. Our Audio over IP codecs all comply with this recommendation, and they interoperate with many other brands.
Using a server is not mandatory with the SIP protocol, and you can definitely set up a point-to-point link without such server. Just use the IP address of the destination codec to set up the link. There is no need to disable the SIP protocol! Even not using a SIP server, you still benefit from the automatic negotiation of the coding parameters, and do not need to handle details such as UDP port numbers, etc.
Symptom: The codec receives undesired and very frequent fake calls from weird entities, sometimes the codec even seems to be called by itself. The device may become unavailable for legitimate calls.
In fact, these are solicitations and attacks by robots, using for example the SIPVicious tool. Most often, these attacks are favored by direct exposure of the codec to the Internet without NAT: codec on a public IP address or in DMZ, or public port SIP 5060 statically redirected to the SIP port of the codec. In these cases, the codec will be quickly “spotted” by scanners and easily attacked. This exposure should be avoided unless it is impossible to do otherwise. Here are some ways to counter these attacks:
Like for any device connected on a network, accessing the Internet with an AoIP codec raises security issues. The network managers are afraid of possibly opening breaches with codecs, or these happen to be themselves targets for attacks. We propose a white paper on this security topic.
AMR-WB (=Advanced Multi-Rate Wide Band) is a wideband (50-7000 Hz) speech coding algorithm, to be compared with the common narrow band speech codecs (300-3400 Hz). AMR-WB is also standardised as G722.2 by the ITU-T.
AMR-WB is used by the service called “HD Voice” by mobile operators.
HD Voice is not a VoIP service, although this is suggested by some features. This is a circuit switched mode, as is the basis for the mobile telephony service often called “GSM”. For deployment reasons, most operators implement this new service on their 3G/3G+ base stations, and less often on the 2G (GSM) ones. As the sales communication emphasises the Internet and data features for the 3G/3G+ networks, users may forget that these networks also support the circuit mode telephony service, just like the 2G networks.
Transmission of HD Voice uses same channels and benefits same conditions and quality or service as “standard” mobile voice. The priority granted to voice conversations (over packet mode data) in high traffic situations is still valid, and the network resources allocated to a link stay committed until it is released, even if other users are stressing the network.
The bits rates used are roughly similar to those used with GSM, the bandwidth extension is due more to the codec performance and efficiency than a higher bit rate.
As the primary goal is telephony, the system and coding are designed for a moderate latency, close to that of normal mobile telephone communications, if not better.
All AETA codecs currently on the market, as far as they are fitted with the “Wireless” capability for accessing mobile networks, all support the HD Voice service:
Mobile operators usually sell “HD” calls at same rates and conditions as standard telephony, and the service is automatically included in voice subscriptions.
As this is still circuit switched telephony, calls are charged based on duration (or fixed price, etc.) just like normal voice service.
Provided that the network and the involved terminals support AMR-WB, the terminals will encode/decode using this algorithm.
The switch to “HD Voice” is automatic; no special handling to do, no special subscription needed. On the contrary, it is not normally possible to prevent this from taking place, and this is not signalled neither! Only the user’s ears will tell…
“Folding back” to narrow band takes place when one of the terminals is not compatible, and/or there is an interconnection with a non-compatible network (a noticeable example is the “wired” telephone network). So far there is no connectivity between competing operators or different countries. This will eventually be implemented, however.
To make sure your link is in “HD Voice” mode, there are three conditions to fulfill:
The two first conditions may not be convenient, but they are predictable and thus can be dealt with. In contrast, the last one is uncertain for field operation, because the “nomad” device may meet variable network access conditions.
First, if the network coverage is poor, the link may set up in 2G/GSM for the lack of a suitable 3G signal, and then stay in narrow band mode.
What can also happen is that during the link, because of a decrease of the 3G signal, the codec folds back on the 2G network, and so doing loses the HD Voice. That is however a good side of the HD Voice service: even if the 3G network is lost, at least the link stays active. And this handover is so efficient that the switch is hardly noticeable.
Conversely, once the link runs over the 2G access, regardless that was from the start of after folding back, there is no return to 3G, even if the conditions become favorable again. The only way to get 3G back is then to hang up and relaunch the call. Of course, that is hardly acceptable in the middle of a live transmission.
To deal at best with this rather sensitive 2G fold back issue, there are two possible policies; the best one depends on your specific requirements.
APN is for “Access Point Name”. It is the name of a gateway through which the mobile terminal gets access to the data network (usually Internet). The device must have an APN set in order to use the mobile data service. However, the user often does not care for that, because mobile operators usually provide pre-configured phones.
The suitable APN usually depends both on the mobile operator and the subscription characteristics. For these reasons it is not possible to tell beforehand which APN is adequate for you. Please ask your provider which APN suits your application.
Hint: if you have a cell phone already configured for the SIM card, look in the phone’s settings for the APN parameter, this is probably a working option.
Note: the APN is irrelevant for using the regular voice service, including the possible HD voice mode. For such use you just don’t need to set an APN in the unit
Plugging a USB device is one way you can add mobile access to a Scoopy+ S or a Scoop5 S. This can be useful in several ways:
* Add mobile IP to a unit without mobile capability
(option “Mobile via USB” required; consult us to get the software upgrade)
* Add an alternative network when the unit has got the integrated mobile feature
* Get 4G/LTE connectivity on an older product not having this capability
The device must be supported by the codec. Currently supported USB devices:
3G/3G+:
LTE/4G:
If the 5G peripheral is well connected to the device, you may want to check:
• If it is powered properly
• If the used SIM card is valid
• If the network provider has not blocked AoIP or VoIP communication. If it is the case, DHCP is probably not possible and requesting a fix IP address to your network provider would solve the problem
The antennas provided with our wireless products are suitable for typical uses, but not in all situations. For instance, it is sometimes necessary, for a correct performance, to move the antenna farther away from the codec than allowed by the cable of the provided antenna.
In such case, it is not recommended to use the antenna and simply add an “extension cable”. This usually leads to excessive signal losses and a poor performance.
The preferred solution is to go for another antenna, and a cable to link it to the codec. We recommend you to look for a specialised distributor or reseller who can provide accurate advice and propose equipment best adapted to your needs.
The criteria for selecting the antenna are as follows:
* Mounting: indoors/outdoors, on roof/wall/mast/windscreen…
* Directivity: in bad reception conditions, a high-directivity antenna pointed towards a base station can be a good solution.
* Supported bands: a multiband antenna is more flexible, but for a fixed installation a single band device can be satisfactory. In any case, check first the local coverage in the area (and the mobile operator). Our product user manual describes the bands that are supported; you should cross-check this with the specific conditions in your country and with your operator.
Regarding the cable, the elements to be considered are:
* Length of cable needed depending on the installation.
* Characteristic impedance: 50 Ohm.
* Cable quality: determines cable losses. With a longer cable, you should look for lower losses per unit of length. Preferrably not more than a few dB should be lost in the cable, in the frequency band that is used (e.g. 2100 MHz for UMTS in Europe). Generally, low loss cables are also more expensive and thicker.
* Note that you cannot use an amplifier like for a TV or satellite downlink, because a mobile link is bidirectional, both downlink and uplink via the same cable.
* Connectors: on the codec side, this is an SMA plug (except for Scoopy+ which features a Hirose MS-151NB antenna socket). On the antenna side, this depends on the antenna model (another good reason to select first the antenna). Avoid connector adaptors as much as possible: every connection brings some amount of signal loss.
Warning : solutions such as “femtocells” proposed by the mobile operators are often efficient for improving the reception, but do not support the “HD Voice” service. As a consequence they are useless if you want to use this service. In fact, if the antenna of the codec is in the coverage area of a femtocell, you must make sure not to include the SIM card in the list of users entitled to access the femtocell.
You must be using Internet Explorer as browser? A recent version, IE9 or newer, must be used to get the level displayed on bargraphs. Otherwise, Firefox or Chrome do not need a specific version
In the previous firmware versions, Scoopy+ used to record the programme transmitted to the network, and the return signal could not be recorded.
Since the firmware version 3.01, that is possible: is the recording is started while a mono connection is active, Scoopy+ records both the transmitted program and the return signal. The two signals are recorded in two separate tracks of a wav file. In this way it is possible to remix them later and adjust the send/receive balance at will.
We recommend you to update the Scoopy+ to the latest firmware revision in order to benefit this feature.