We're unable to connect you to Netflix. Please try again or visit www.netflix.com/tvhelp for guidance.

The fix to this problem is:

Option 1 – Clear Netflix Cache

1. Go to Google TV settings > Applications > Manage Applications > Netflix > Clear Cache. There are two listing and you have to do it to both of them.
2. Now reboot the Revue by pressing [Ctrl]+[Alt]+[Del] to reboot.
3. Launch Netflix and reenter your account information.

Option 2 – Deactivate and Reactivate Netflix

1. Open the Netflix application
2. Press Up, Up, Down, Down, Left, Right, Left, Right, Up, Up, Up, and Up
3. You should see the account information page click “Deactivate”.
4. Now reboot the Revue by pressing [Ctrl]+[Alt]+[Del].
5. Launch Netflix and reenter your account information.

First we need to get the dump and if you have your ATA directly connected to a firewall, you may need to put a hub in and capture the old fashion way or span a port. If you are using a Linux based firewall you can always use the tcpdump command. I run all of my ATAs to a central Linux Asterisk box. So no matter how you get the dump, you need to capture the packets.

Assuming you are on a Linux box either spanned off a port or sniffing in promiscuous mode on a hub, you need the proper command to capture the traffic. Using the tcpdump command is the easiest, use the command below to capture a dump that you can view in Wireshark.

tcpdump -i eth0 -s 1500 -w ~/dump.cap

The preceding command will listen on interface eth0. To find your interface you will initiate an “ifconfig –a”, to list your interfaces. It will capture 1500 bytes of data rather than the 68 bytes by default. It will dump it to your home directory as the file named dump.cap. To get it over to a windows box I recommend using winscp.

Voice Quality

If you’re lucky enough to be working with an Adtran Total Access AOS ATA router then the command below will work for you. If not other manufacturers like Cisco have similar commands. After the call has been placed you need to analyze the quality, you can do so with the following command:

Adtran #sh voice quality-stats
      Start                   Lost Discard Delay
ID Time From To Duration Codec Pkts Pkts Avg Max

--------------------------------------------------------------------------------

130 10:38 AM 4125551234 4125551212 5:43 G711u 0 0 50 50
131 10:45 AM 4125551234 4125551212 2:43 G711u 0 0 50 50
132 10:48 AM 4125551234 4125551212 8:16 G711u 5291 0 50 50
133 10:56 AM 4125551234 4125551212 4:49 G711u 27097 0 80 50
134 11:02 AM 4125551234 4125551212 1:03 G711u 0 0 50 50

The output will not show all calls just the most recent in the buffer. There is plenty of information in the dump above on our calls. The first being the codec used for the placement of the call. If the particular call is data and is going over g729 it will fail. If this is the case then it is recommended to configure the “modem-passthrough” command from part 1 of this series. Because it will force data calls to switch to the g711u or ulaw codec.

Another great piece of information is the lost packets, which are not really lost. They just show up to the destination out of order and inject latency to the RTP protocol. Again the “modem-passthrough” will help with this, as well as putting on a newer version of AOS. Some of these problems have been solved in later releases that have tuned the DSP or Digital Signal Processor.

You can also see the delay of the packets which are directly attributed to the jitter buffer. Again the “modem-passthrough” will help with this, as well as putting on a newer version of AOS.

Wireshark can also give you an over view of problems. To get the important information out, use the tcpdump and load it into Wireshark. Once loaded in, click on “Telephony”, then “RTP”, then “Show All Steams”

This will show you direction of flow from source IP and port to destination IP and port. It will also display the codec used for the call of either g729 or g711 ulaw. Most importantly it will show you the quality of lost packets, that never showed up on the other side. Your max delta should always be about 20ms. Lastly and not least is the max jitter and mean or average jitter. The lower this is to 0ms the better the call quality. If these are off by too much the Internet connection might be too poor for VOIP let alone data over VOIP.

TX and RX Gain

Although we can use Wireshark and look down to the packet level, I cannot stress the importance of a line man’s butt set to listen to the call. Saying that… We can analyze the packet for improper or low volume. Looking at the VOIP call with Wireshark and playing the audio back will give us a comparison to what we heard. In conjunction with the “tx-gain” and “rx-gain” commands we can see an actual difference in amplitude. My recommendation is to save your dumps with dates and times for comparison. To decode the RTP streams click on “Telephony”, then on “VoIP Calls”, find the call you want to view and select it, then click “Player”, then “Decode”. This will show both sides of the call, so to listen to the converged call you will need to select both, then click “Play”.

As you can see in the pictures above the pink capture has lower amplitude than the yellow capture. This is because these are two different units that I captured on, one having a higher RX and TX gain.

DTMF Relay

In the part two of this series I explain DTMF relay in detail. Since most alarm panels transmit data via DTMF tones, we can see the DTMF out of band in action here as well as the bleed over. The yellow Ws are wrong timestamps, which proves that the DTMF relay strips the DTMFs out leaving a jump in timestamps.

The pink capture shows the wrong timestamps and the bleed over of the DTMF tones. The yellow capture is after we initiate the “rtp dtmf-relay inband” command. We can now see the DTMF tones being sent in band of the RTP stream.

Wireshark is like any other tool, it will not fix the problem it will identify the problem. Ultimately you will need to fix the problem being the technician. However understanding what is going on at the packet level, helps us to ultimately fix the problem that can be seen.

As always if you found this article to be useful either donate or visit some of my sponsors so I can continue to create these articles.

In this second part I will cover in depth transmit volume or gain, receive volume of gain and out of band handling of DTMFs for Contact ID. These are all common problems with VOIP and fire alarm systems. The system ATA or Analog Telephone Adapter I will focus on is an Adtran with AOS, but these principles can be applied to all ATA devices. I still recommend a backup line of a POTS circuit since nothing replaces a simple POTS line, when you are dealing with life safety equipment.

TX Gain and RX Gain

TX gain or transmit volume and RX gain or receive volume can be an issue with fire, alarm, call boxes and any other type of analog panel. These are simple the volumes at which the information is transmitted or received from your panel. The defaults for an Adtran are a TX gain of -6.0 and an RX gain of -3.0 and this should be fine for most voice applications. However when it comes to data, panels can be picky as to what they expect.

One way to identify a problem is to listen to the panel as it is dialing out and the conversation between the transmitter (you) and the receiver (monitoring station). You can achieve this with a simple line’s man butt set, across the terminals of the phone line on the panel. A better way to identify problems with TX and RX gain is to packet capture the conversation and decode it. This will be covered in depth in part 3 of this series.

To raise or lower the TX and RX gain on an Adtran Total Access 924 you can use these commands:

Adtran #conf t
Adtran (config)#interface fxs 0/1
Adtran (config-fxs 0/1)#rx-gain 0
Adtran (config-fxs 0/1)#tx-gain -3.0

Be careful not to turn the gain up too high, since you will over gain the transmitter or receiver. This will work opposite of what you are trying to accomplish, so do it in small increments. The defaults are an rx-gain of -3.0 and a tx-gain of -6.0, so it’s safe to increase it in +3.0 increments.

DTMF and VOIP

DTMF tones are Dual Tone Multi Frequency tones that dial numbers. To understand what the function of an ATA is we must understand the process of a phone. When you go off hook you receive a dial tone, where you use the 12 digit key pad of 0 thru 9 and special dial plan characters like star and pound. This series of tones are picked up by the ATA and turned into a phone number to dial.

With SIP calls there are two distinct communication channels. The SIP channel is a symmetrical port 5060 UDP conversation with your SIP trunk. The RTP channel is what transmits your voice and that is usually carried over port 10000-20000 UDP with a typical Asterisk server. The SIP control channel sets up the RTP channel, and the RTP channel uses this to its advantage to transmit data like DTMF digits.

Many fire alarm panels communicate with DTMF tones. So once the call is setup any digits that are sent to the ATA will be intercepted. The DTMF digits sent are then removed from the RTP stream and are pushed to the SIP channel. This operation is called out of band DTMF relay and is the default of many ATAs. Take notice that at time of dial the RTP channel has not yet been established, this is only after the RTP in established. Sometimes the interception and omission of DTMFs is not clean and tones bleed over on the RTP stream, which is the root of our problem.

The default behavior of an Adtran Total Access 924 is to send DTMFs out of band in the SIP channel. This means that the SIP provider recreate the DTMFs on their end to the upstream provider, from the digits provided over the SIP channel. This is process is often known as DTMF Relay and an Adtran by default is configured with the command “rtp dtmf-relay nte 101”. You can change this behavior with the following command:

Adtran #conf t
Adtran (config)#voice user 4125551212
Adtran (config-4125551212)# rtp dtmf-relay inband

This command will tell the TA-924 not to intercept the DTMFs and to send them over the RTP channel. However the DTMFs sent for initial call setup will still travel over the SIP channel, since an RTP is not yet established at this point.

If this article has helped you please either donate or visit some of my sponsors.

The next article in this series can be found here http://www.bohack.com/2012/04/how-to-solve-common-problems-with-voip-and-fire-alarm-systems-dialing-out-part-3/

First let me state that nothing replaces a POTS or Plain Old Telephone System line when it comes to life safety devices. So although you may save a ton of money on VOIP the life you save might be your own, if there is a fire or life safety event. You are responsible for keeping the equipment up and running for at least 4 hours in the case of a power outage.

Cheap POTS Lines

That being said it will work, but you will have problems along the way. One alternative is to purchase a low usage POTS line. These are landlines you can purchase from the phone company of your choice that are low usage lines. Low usage lines are used for the explicit purpose of emergency usage like elevators, fire alarm systems, emergency call boxes and burglar alarms. When ordering such a line explain to the sales representative what it will be used for. However VOIP is cheaper and if you are still stuck on converting them then you need to learn how they work and their requirements.

Line Voltage

Since most alarm panels are legacy devices, they could require a higher voltage than what the ATA supplies. The symptoms of low voltage are usually the panel not recognizing the phone line is there and causing a trouble code or false alarm. The simple precaution is to measure the voltage of the normal working panel before you disconnect it. On hook phone line voltage from the phone company is usually between 35 to 48 volts DC. A simple multimeter across the ring and tip can get you this reading, while the phone is on hook.

Since the 1990s most phones are digital and no longer require a battery voltage of 48 volts. So VOIP Analog Telephone Adapters usually only supply 24 to 33 volts of power, this includes PBX equipment with analog cards. If you have an Adtran device with AOS, you can step the voltage up by configuring the command below:

Adtran#conf t

Adtran (config)#interface fxs 0/22

Adtran (config-fxs 0/22)#battery-mode high

VOIP Quality Settings

VOIP stand for Voice Over IP which means that you are sending voice over the Internet. When the RTP or Real Time Protocol packets travel over the Internet three problems get injected. The first being latency; every hop creates latency which is the time it takes to route the packet. Other factor to latency could be caused by congestion of the lines or transmission media like cable vs. fiber. The mechanisms that help voice quality, but work against us with modem and faxing is the jitter buffer. The jitter buffer stores UDP datagrams and puts them back in order, it also introduces latency.

The second is echo cancellation, another mechanism that works against us with data on phone lines. Echo cancellation queues the RTP conversation up or down by up to 100ms if an echo is detected. When modems send data it sometimes triggers this and throws the conversation off between transmitter and receiver.

The third is codec related, which applies to compression and decompression of the voice. If you use g729 it will compress audio using a compression algorithm that tends to lose quality of the audio channel, but use less bandwidth. So g711 ulaw should be used for modem lines. You can shut these three mechanisms off automatically by using the command bellow:

Adtran#conf t

Adtran (config)# voice user 4125551212

Adtran (config)# modem-passthrough

Once configured, if the DSP or Digital Sound Processor hears a modem signal it will: set the jitter buffer to a fixed value of 50ms, it will turn off echo cancellation and most importantly it will force g711 ulaw (which takes more bandwidth, but does not loose quality of the voice channel).

So if your alarm panel dials up with a modem protocol, then this could be your problem. My recommendation is to listen with a phone or lineman’s butt set while it’s dialing out. If you hear the tell tale modem mating call, these adjustments could solve your problem.

As always if this article helped you please donate or visit some of my sponsors.

For part two follow this link http://www.bohack.com/2012/04/how-to-solve-common-problems-with-voip-and-fire-alarm-systems-dialing-out-part-2/

You can also use the command below to identify all of Google’s mail servers from the SPF record it displays:

nslookup -q=TXT _netblocks.google.com 8.8.8.8
"v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all"

Google’s IPv4 CIDR netblock and IP Ranges

64.18.0.0/20 – Range (64.18.0.1 to 64.18.15.254)

64.233.160.0/19 – Range (64.233.160.1 to 64.233.191.254)

66.102.0.0/20 – Range (66.102.0.1 to 66.102.15.254)

66.249.80.0/20 – Range (66.249.80.1 to 66.249.95.254)

72.14.192.0/18 – Range (72.14.192.1 to 72.14.255.254)

74.125.0.0/16 – Range (74.125.0.1 to 74.125.255.254)

173.194.0.0/16 – Range (173.194.0.1 to 173.194.255.254)

207.126.144.0/20 – Range (207.126.144.1 to 207.126.159.254)

209.85.128.0/17 – Range (209.85.128.1 to 209.85.255.254)

216.239.32.0/19 – Range (216.239.32.1 to 216.239.63.254)

If you want to find the current netblocks that Google uses for firewall purposes, just run the nslookup command again. The list above is current as of March 2012.

The following worked flawlessly on Ubuntu 10.04 LTS x86:

The first step is to login as root or su as root, whichever you choose. You will need to install a few things before you install.

apt-get install cvs build-essential automake autoconf bison flex libtool libncurses5-dev libssl-dev libgsm1 libgsm1-dev libxml2-dev build-essential linux-headers-`uname -r`

Then you will need to download the Asterisk 1.8 tar.gz

cd /usr/src
wget http://downloads.asterisk.org/pub/telephony/asterisk/releases/asterisk-1.8.10.0.tar.gz

Unzip and untar it:

tar -zxvf asterisk-1.8.10.0.tar.gz

Let’s make something:

cd asterisk-1.8.10.0
./configure

Wait then:

make all

Wait more and then:

make install
make config

Start it up:

/etc/init.d/asterisk start

If you did it correctly everything should just work! You can confirm this by doing:

root@asterisk:/usr/src/asterisk-1.8.10.0# asterisk -r
asterisk*CLI> sip show peers
Name/username              Host                                    Dyn Forcerport ACL Port     Status
0 sip peers [Monitored: 0 online, 0 offline Unmonitored: 0 online, 0 offline]
asterisk*CLI>

Since most authentication systems require only your username and a password, a strong password that is complex is best. Coming up with good strong passwords that are complex is easy, remembering them is the tough part.
Phonetic passwords contain characters like 2, b, r, i, m, a, 4, and 8 to sound words like to, be, are, I, am, a, for, ate. Using these characters to create a ‘leet speak’ password is good, but weak because iterations of these are in ever dictionary attack out there.

An alternative is using salt to key cryptography. A salt is a random numeric number that alters the password to create a key; it is also known as a nonce. The key is irreversible, only the original salt and password can equal the key.

salt + password = key

Since we need to make this easy we will not be using md5 algorithms, instead we will use substitution; just like the Romans only with a twist. We need to first pick our salt, this salt will become yours and you will never disclose your salt ever. It’s like picking your totem from the movie Inception; it is only for you to know.

To pick your salt you will need non-pattered words at least 10 or more characters long, preferably with vowels. The first twelve letters “e t a o i n s r h l d c”, are found in around 80% of the words in the English language. You will need to find an isogram or non-pattered word, which means the word does not repeat any letters. I have a few below, none are mine (or maybe they are).

aftershock – artichokes – authorizes – bankruptcy

Note: To find more words like these Google the term Isogram.

We choose our salt let’s use aftershock. You will take the letters and place numbers above the word from left to right.

A F T E R S H O C K
1 2 3 4 5 6 7  8 9 A

or A=1, F=2, T=3, E=4, R=5, S=6, H=7, O=8, C=9, and K=A

If we have a name like ‘Jonathan’ we want to encrypt we will substitute a letter for number so ‘Jonathan’ would look like this ‘J8n13h1n’ this is our encrypted password that we can encrypt over and over again. Knowing our salt is always ‘aftershock’.

Basically the Integer 8 data type is the large value that is seen on a typical Powershell get-aduser command or csvde from Active Directory. Windows NT and Active Directory store dates as nano ticks or 100-nano second intervals from the Windows NT time epoch; which is January 1st 1601. Please make a note that PowerShell’s epoch is January 1st 0001 which could screw you up if you assume all integers are like NT’s epoch.

So let’s use an integer of “128271382742968750”. There are several methods of converting this I will cover most of them:

Command Line:

Converting logontimestamp from command line:

C:\>w32tm.exe /ntte 128271382742968750

148462 05:57:54.2968750 - 6/24/2007 8:57:54 AM (local time)

Note: that the results are in GMT and the offset of the computer’s local time is added UTC +3:00 in this example above.

PowerShell:

Converting logontimestamp from PowerShell:

PS C:\>$lastlogontimestamp = “128271382742968750”
PS C:\>[DateTime]::FromFileTimeutc($lastlogontimestamp)

Sunday, June 24, 2007 5:57:54 AM

To convert using the current computers offset use the code below (current computer offset UTC +3:00):

PS C:\>[DateTime]::FromFileTime($lastlogontimestamp)

Sunday, June 24, 2007 8:57:54 AM

Note: If you experiment please be sure to open a new PowerShell after changes to the offset of the computer since it is read into the environment only once during powershell launch.

Excel:

Lastly converting in excel the integer to human read able time:

=A1/(8.64*10^11) – 109205

• (8.64*10^11) is the number of nanoseconds in a day divided by 100.
• 109205 is the number of days, including leap days, between 1601 and 1900.

This formula would assume that A1 contains the integer of “128271382742968750” and the cell was formatted for date and time. If so it would return:

6/24/07 5:57:54 AM

To calculate offset:

=A1/(8.64*10^11) - 109205 + time(3,0,0)

Use the above to add UTC +3 to the time to display the below format:

6/24/07 8:57:54 AM

Since there is nothing that can really go wrong with this module, it’s actually the off lamp that has gone bad. A quick check can verify this, first the code flashing on your dash. The second is using your key to deactivate the passenger air bag should light the off lamp.
If it doesn’t light then follow my instructions and for about $2 dollar you can save yourself the expense of changing the entire module. The module F81B-14B268-AD lists for about $80 dollars so it worth the effort.

The air bag system goes thru a check of everything and if one little thing light a lamp is out, it deactivates the entire system and set a code. Since the lamp is actually a bulb with a filament it is really common to go bad. You cannot replace it with an LED, because there needs to be continuity across the leads. I’m sure you can put a diode in to show forward voltage, but let’s just fix the bulb with a bulb.

I used a Radio Shack 272-1154 Bi-Pin Lamp bulb as the replacement which is a 12v 50mA bulb. At 12 volts and 50 milliamps it generates 12x.05=.6 watts of energy. You can use a little bigger bulb like 60mA or 70mA; you just don’t want a really bright light on your dashboard. I choose the bulb because it had solid leads; the 272-1099 has wire leads. It’s a little smaller than the original, but it will work just fine.

Tools you’ll need:

• 5.5mm socket or 7/32” socket and ratchet
• Large flat tip screw driver
• Small flat tip jewelry screw driver
• Radio Shack 272-1154
• Soldering Iron and solder
• De-soldering sucker or soldering wick with flux
• Pair of small needle nose pliers
• About 1 hour of time

Step 1 – Removal of the dash board fascia – Use your flat tip screw driver to gently pry the dash board plastic from the dashboard. They use snap clips on mine, but you’re on your own as to how yours is held in place.

Step 2 – Removal of the module from the fascia – Unplug the module’s connector and put it to the side. Use your 7/32” socket or 5.5mm socket and remove the three bolts that hold it onto the dashboard fascia.

Step 3 – Disassembly of the module – Use your jewelry screw driver and pry the tabs on the front of the module; one by one. Then pry the tabs in the back of the module one by one. You will now have three pieces: the switch and body, the circuit board and the top of the module.

Step 4 – Desolder the bulb – You can either use your solder sucker or soldering wick with flux. I personally use desoldering wick, but there is a little talent to it. Remove the rubber yellow cover from the bulb, you will need to reinstall it on the new one.

Step 5 – Solder the new bulb in – Use your needle nose pliers and bend the leads (without breaking them) so they fit into the circuit board. The bulb should have a right angle to the leads. Since the bulb cover is bigger than the bulb, just bend the bulb over to clinch the rubber cover. It’s not perfect but it works.

Step 6 – Test it – before you reassemble the module take it to the vehicle and plug it in. Turn the key to the ignition position and observe the light; both on the dash and the module.

Step 7 – Reassembly – If it is all back to normal put the module back together and reinstall the module into the dash.

You’re done, and if you found this article to be of help… Donate or visit some of my sponsers.

To register the RTSP protocol with Internet Explorer you need to register it with the operating system. This is easily achieved thru a registry edit, however this article explains it all http://msdn.microsoft.com/en-us/library/Aa767914.aspx. So once you register the RTSP with the .reg file below just close Internet Explorer and open it back up. VLC will prompt you with a warning, if at this point it doesn’t show video; open TCP port 554 in your firewall outbound. If you do not have outbound restrictions, like in the case of 99% of home users; it either a bad feed or upgrade your VLC to the latest version.

Firefox will also see the registry change and when a user clicks the link; Firefox will prompt them with an application dialog box then open it in VLC Player. Just check the box to always open without prompting and it’ll work every time!

This fix will be valid for all users of the computer. I’m pretty sure you can register it under HKEY_CURRENT_USER on XP and above; to make the change for only that users.

RTSP registry edit file:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\RTSP]
@="URL:Real Time Streaming Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\RTSP\shell]

[HKEY_CLASSES_ROOT\RTSP\shell\open]

[HKEY_CLASSES_ROOT\RTSP\shell\open\command]
@="C:\\Program Files (x86)\\VideoLAN\\VLC\\vlc.exe -vvv %1"

Copy the text above into a file of RTSP.reg and double click it to merge it into the registry.

Note: You may have to change the path where your VLC lives.