This is a post on how to make and receive phone calls for free to and from numbers within the United States.
These instruction require you to have a SIP phone. You can run SIP phone software on your computer (SIP Communicator is nice, free, and open source -- http://sip-communicator.org/), on your smartphone/PDA (Fring is available for free -- http://www.fring.com/), or buy a SIP phone device which are a tad expensive (investigate this option after you get it working with the software if you wish).
In brief, you'll need to set up the following:
Step 1: SIP service
A SIP service provider is somewhat like Skype except that it uses the standard SIP Voice-Over-IP (VoIP) protocol. Here is a relatively recent list of free SIP service providers
http://snapvoip.blogspot.com/2009/01/free-sip-accounts-revisited.html
Register an account with any one of them.
After you get a SIP account, configure your SIP software on your computer or smartphone with your account details. Your SIP service provider should have a number to call to test your configuration. Make sure you are set up correctly by calling the test number.
Step 2: IPKall service
IPKall (www.ipkall.com) provides a land line number with a Washington State area code to receive land line calls and route them to your SIP phone service. To register an account with IPKall you'll need some details from your SIP service provider such as your SIP number and your service provider's SIP proxy server name.
After you register an account with IPKall, they'll email you your new Washington state phone number. Call that number from a phone and it should ring your SIP phone.
At this point (if you are set up correctly) you can receive but not place calls.
Step 3: Google Voice
Google Voice (www.google.com/voice) is a really neat free service provided by Google. With a Google Voice account you will receive a phone number with an area code in your area. You will be able to use that number to ring any of your phones (your home phone, cell phone, office phone, etc.). It also provides services to screen and block calls and gives you visual voice mail and a transcription of your voicemail via email and/or SMS. It's pretty neat. Using Google Voice you can also initiate calls.
Add your new IPKall number to your Google Voice account then use the Google Voice web site to place calls to any number within the United States. If you are using an iPod Touch you should use https://www.google.com/voice/m/contacts to place calls.
One caveat: Many people have set up IPKall numbers with Google Voice and IPKall terminates accounts inactive for 30 days. So, you might get a recycled number that is already registered with Google Voice. Google won't allow you to add it to your Google Voice account if someone else already has it added to their account. In that case, cancel your IPKall account and try again.
There you go. Free phone calls.
iPod Touch users will need the earphones with remote and mic (which can be found elsewhere for as low as a tenth the Apple price).
The easiest and best SIP service to use for this is Gizmo5 which Google bought a year ago. But since then new registrations have been closed. With a Gizmo5 account you don't need to use IPKall as Google Voice will allow you to set up your Gizmo5 SIP number as one of your phones.
I recommend that you enter your email address in the Gizmo5 web site to receive information about the re-launch if you don't already have a Gizmo5 account.
Sunday, October 31, 2010
Free Phone Service
Labels:
free,
gizmo5,
google voice,
ipkall,
ipod,
phone,
pstn,
sip,
telephone,
united states
Sunday, November 8, 2009
document.lastModified in Google Chrome
It's fairly common to put something like document.write(document.lastModified); on a web page to display the date and time the document was last updated. This works fine in IE and in FireFox and seems like straight forward cross browser compatible and is kosher according to "JavaScript: The Definitive Guide, 5th ed."
Chrome doesn't like it. Now, for cross browser compatibility, you've gotta use
document.write(Date().toLocaleString(document.lastModified));
I'm not sure what's going on here. The Chrome JavaScript console shows document.lastModified as undefined. Maybe it's a WebKit thing. I'll have to see what Safari does.
Alright everyone... update your scripts!
Chrome doesn't like it. Now, for cross browser compatibility, you've gotta use
document.write(Date().toLocaleString(document.lastModified));
I'm not sure what's going on here. The Chrome JavaScript console shows document.lastModified as undefined. Maybe it's a WebKit thing. I'll have to see what Safari does.
Alright everyone... update your scripts!
Wednesday, September 16, 2009
Fixing ColdFusion's issues with method="get" and multiple select boxes
ColdFusion doesn't seem to like forms with method="get".
I've been developing a simple search tool with a multiple select box to specify some of the search criteria. Because I wanted to make the results linkable I used method="get" in the form.
The browser with return the multiple select values like so:
?select1=val1&select1=val2
But ColdFusion will see it as url.select1 = "val2". Only the last select will be present in the url scope.
To solve this problem we've got to bypass the url scope and grab the values directly from the CGI.QUERY_STRING like so:
Now the get structure will contain everything in the url scope plus a comma separated list of values from the multiple select boxes.
From our example above: get.select1 = "val1,val2".
I've been developing a simple search tool with a multiple select box to specify some of the search criteria. Because I wanted to make the results linkable I used method="get" in the form.
The browser with return the multiple select values like so:
?select1=val1&select1=val2
But ColdFusion will see it as url.select1 = "val2". Only the last select will be present in the url scope.
To solve this problem we've got to bypass the url scope and grab the values directly from the CGI.QUERY_STRING like so:
<cfset get=StructNew()>
<cfloop index="keyvalpair" list="#CGI.QUERY_STRING#" delimiters="&">
<cfset key=ListFirst(keyvalpair, "=")>
<cfset keyval=URLDecode(ListLast(keyvalpair, "="))>
<cfif not StructKeyExists(get, key)>
<cfset get[key]="">
</cfif>
<cfset get[key]=ListAppend(get[key], keyval)>
</cfloop>
Now the get structure will contain everything in the url scope plus a comma separated list of values from the multiple select boxes.
From our example above: get.select1 = "val1,val2".
Wednesday, March 11, 2009
Large strings in ColdFusion
ColdFusion is great. Generating complex html with CF is very easy but sometimes I'm not interested in creating a complex html document but, rather, I need to create a large and complex string and maybe I want to write it to a file.
To work with strings in CF as easily as I work with html I wrote a very simple custom tag, <cf_BlockToString>.
The tag works like this:
To work with strings in CF as easily as I work with html I wrote a very simple custom tag, <cf_BlockToString>.
The tag works like this:
<cf_BlockToString var="myVar">The quick and dirty version (no error checking) of BlockToString.cfm is:
This is a bunch of text where I'm able to "quote" things and #pound# out the special characters without escaping.
<cfset newVar="I can still do normal CF stuff too."> <cfoutput>#newVar#</cfoutput> </cf_BlockToString>
<cfoutput>#myVar#</cfoutput>
<cfif thisTag.ExecutionMode is 'end'>Have fun.
<cfset Caller."#Attributes.var#" = thisTag.GeneratedContent>
<cfset thisTag.GeneratedContent = "">
</cfif>
Tuesday, February 3, 2009
SSL Woes with WebSite Pro
I run a web site that uses a site certificate that we buy from VeriSign. That certificate came up for renewal last month so I went through the usual process to buy a new certificate: Put in a purchase request, wait for approval, generate a certificate request, upload the certificate request to VeriSign, enter the credit card info, and wait for the new certificate to arrive in my inbox.
Every year previously it was as simple as that. But this year VeriSign rejected my certificate request on the grounds that it was a 512 bit request and that the minimum it would accept was a 1024 bit request. So, I went to my server and opened up the WebSite Pro server management tool to find the option for generating a 1024 bit request. It didn't exist. Apparently, with WebSite Pro, you can have as many bits as you want as long as it's 512.
Without any way to get WebSite Pro to make a 1024 bit certificate request I went back to VeriSign to find the option to upload a 512 bit request. It didn't exist. So, I clicked the button to request a chat with tech support and got someone to chat with me after a few minutes. I explained my situation and his first suggestion was to RTFM and find out how to generate a 1024 bit certificate request. Okay, I humored him and perused the help file for a few minutes after which I reported back that such instructions were absent from TFM.
Next, I asked him how to get VeriSign to accept a 512 bit request. He reported back that VeriSign has adopted "best practices" requiring a minimum of 1024 bits. I asked if this was a new best practice since one year ago 512 bits was not a problem. Indeed, yes, sometime during 2008 it became a requirement. Looks like their best practices did not include informing the WebSite Pro administrators that their servers would no longer be supported by VeriSign.
I told my tech support chat buddy that I was, therefore, not able to plunk down $2500 for a three year certificate. "What's your telephone number? When is a good time to have someone contact you?" Best practice does include keeping a $2500 sale alive.
A short while later I received a call from the saleswoman who had been calling me every week for the past 2 months to remind me that my certificate was expiring and offering help to get it renewed. I explained my situation again and she was eager to transfer me to tech support where I was on hold for way too long. Lunch hour came around while the hold music was playing and the cafeteria seemed more promising than the hollow hope of VeriSign tech support so I hung up with a little over one week to go until my site certificate expired.
In 2001, ownership of WebSite Pro changed from O'Reilly to Deerfield and in early 2004, Deerfield dropped sales and support for WebSite Pro all together. It's now five years later and we're still running this dinosaur. This little VeriSign issue is a good reason (amongst others) to move from WebSite Pro to web server that is still supported.
The decision was made to replace WebSite Pro with IIS. When I say that I am the administer of this server what I mean is that I am an administer with some (not all) rights. I did not set it up and I have no control over the security lock-down policies imposed on the machine. I spent four days trying to get IIS installed and working. The day before the VeriSign certificate was to expire I was able to achieve marginal success. IIS would serve static pages but asp was broken and I could not get ColdFusion (an essential part of the server) installed and working. I could, however, generate 1024 bit certificate requests and so I did.
Closing time was fast approaching so I emailed the certificate request to the credit card holder and visited her office to finally buy the new site certificate. I logged into VeriSign and uploaded the new certificate request but this time Verisign didn't like the fact that my certificate request abbreviated the state rather than spelling it out in full. So... I went back to the server, canceled the original certificate request, and generated another one with the state spelled out in full. I logged back into VeriSign and uploaded the certificate request and this time it was successful. We entered the credit card info and paid.
Now that I had completed that, I had to get back to the task of getting the server working with IIS. I tried various iterations of uninstalling and reinstalling IIS and uninstalling and reinstalling ColdFusion to no avail. Each uninstall or reinstall required a reboot which took a full 10 minutes just to reboot. It was getting late, now after hours, and my server was broken. My goal was now to forget IIS and put it back working with WebSite Pro which took another round of uninstalling and reinstalling ColdFusion. The server was finally working again so I called it a day but the clock was still ticking on the site certificate installed in WebSite Pro.
The morning of expiration day arrived and my boss called me while I was on my way to the office. It turned out that there were some ColdFusion configuration issues that I didn't catch the previous night and some of the users now couldn't get their job done. When I arrived I found the new site certificate from VeriSign in my inbox and I quickly fixed the configuration problem and had to wait until 2pm when most of the daily work would be done and the server wouldn't been needed again for a while. During that time I was able to install the new certificate in IIS and it occured to me that I could export the certificate from IIS and possibly import it into WebSite Pro.
Exporting the certificate as a .pfx file was no problem. But WebSite wants the certificate in .pem format. Using OpenSSL for Win32 I was able to convert the certificate with
>openssl pkcs12 -in cert.pfx -out cert.pem -nodes
and successfully imported it into WebSite Pro.
Now the server is running as before with a certificate that expires in three years and we still need to get rid of the old unsupported WebSite Pro.
Every year previously it was as simple as that. But this year VeriSign rejected my certificate request on the grounds that it was a 512 bit request and that the minimum it would accept was a 1024 bit request. So, I went to my server and opened up the WebSite Pro server management tool to find the option for generating a 1024 bit request. It didn't exist. Apparently, with WebSite Pro, you can have as many bits as you want as long as it's 512.
Without any way to get WebSite Pro to make a 1024 bit certificate request I went back to VeriSign to find the option to upload a 512 bit request. It didn't exist. So, I clicked the button to request a chat with tech support and got someone to chat with me after a few minutes. I explained my situation and his first suggestion was to RTFM and find out how to generate a 1024 bit certificate request. Okay, I humored him and perused the help file for a few minutes after which I reported back that such instructions were absent from TFM.
Next, I asked him how to get VeriSign to accept a 512 bit request. He reported back that VeriSign has adopted "best practices" requiring a minimum of 1024 bits. I asked if this was a new best practice since one year ago 512 bits was not a problem. Indeed, yes, sometime during 2008 it became a requirement. Looks like their best practices did not include informing the WebSite Pro administrators that their servers would no longer be supported by VeriSign.
I told my tech support chat buddy that I was, therefore, not able to plunk down $2500 for a three year certificate. "What's your telephone number? When is a good time to have someone contact you?" Best practice does include keeping a $2500 sale alive.
A short while later I received a call from the saleswoman who had been calling me every week for the past 2 months to remind me that my certificate was expiring and offering help to get it renewed. I explained my situation again and she was eager to transfer me to tech support where I was on hold for way too long. Lunch hour came around while the hold music was playing and the cafeteria seemed more promising than the hollow hope of VeriSign tech support so I hung up with a little over one week to go until my site certificate expired.
In 2001, ownership of WebSite Pro changed from O'Reilly to Deerfield and in early 2004, Deerfield dropped sales and support for WebSite Pro all together. It's now five years later and we're still running this dinosaur. This little VeriSign issue is a good reason (amongst others) to move from WebSite Pro to web server that is still supported.
The decision was made to replace WebSite Pro with IIS. When I say that I am the administer of this server what I mean is that I am an administer with some (not all) rights. I did not set it up and I have no control over the security lock-down policies imposed on the machine. I spent four days trying to get IIS installed and working. The day before the VeriSign certificate was to expire I was able to achieve marginal success. IIS would serve static pages but asp was broken and I could not get ColdFusion (an essential part of the server) installed and working. I could, however, generate 1024 bit certificate requests and so I did.
Closing time was fast approaching so I emailed the certificate request to the credit card holder and visited her office to finally buy the new site certificate. I logged into VeriSign and uploaded the new certificate request but this time Verisign didn't like the fact that my certificate request abbreviated the state rather than spelling it out in full. So... I went back to the server, canceled the original certificate request, and generated another one with the state spelled out in full. I logged back into VeriSign and uploaded the certificate request and this time it was successful. We entered the credit card info and paid.
Now that I had completed that, I had to get back to the task of getting the server working with IIS. I tried various iterations of uninstalling and reinstalling IIS and uninstalling and reinstalling ColdFusion to no avail. Each uninstall or reinstall required a reboot which took a full 10 minutes just to reboot. It was getting late, now after hours, and my server was broken. My goal was now to forget IIS and put it back working with WebSite Pro which took another round of uninstalling and reinstalling ColdFusion. The server was finally working again so I called it a day but the clock was still ticking on the site certificate installed in WebSite Pro.
The morning of expiration day arrived and my boss called me while I was on my way to the office. It turned out that there were some ColdFusion configuration issues that I didn't catch the previous night and some of the users now couldn't get their job done. When I arrived I found the new site certificate from VeriSign in my inbox and I quickly fixed the configuration problem and had to wait until 2pm when most of the daily work would be done and the server wouldn't been needed again for a while. During that time I was able to install the new certificate in IIS and it occured to me that I could export the certificate from IIS and possibly import it into WebSite Pro.
Exporting the certificate as a .pfx file was no problem. But WebSite wants the certificate in .pem format. Using OpenSSL for Win32 I was able to convert the certificate with
>openssl pkcs12 -in cert.pfx -out cert.pem -nodes
and successfully imported it into WebSite Pro.
Now the server is running as before with a certificate that expires in three years and we still need to get rid of the old unsupported WebSite Pro.
Labels:
site certificate,
ssl,
verisign,
website pro
Sunday, October 5, 2008
Welcome
I've been thinking about doing a blog like this for a while now. The idea is to write up how I come about solving a technical problem I'm having so that someone else with the same problem might have an easier time with it.
The first posting happens to be in the rather prosaic world of home appliances. I expect that future posts will be more computer related as I am a web application developer and general tech support for my family and friends.
I hope I can be of assistance.
Enjoy.
The first posting happens to be in the rather prosaic world of home appliances. I expect that future posts will be more computer related as I am a web application developer and general tech support for my family and friends.
I hope I can be of assistance.
Enjoy.
My Washing Machine
My washing machine is on the fritz. The motor runs and the pump pumps but the tub doesn't turn or agitate. After declaring to my wife the the thing was broken and needed fixing she proceeded to attempt another load. Guess how that turned out. I blame myself. I brought down the laundry at her request and didn't protest her clear intentions to start a load. I guess I was just happy to see her in action.
After the Skins beat the Eagles this afternoon I proceeded to attempt to diagnose the problem with my Whirlpool Heavy Duty Super Capacity Plus top loading washing machine which came with the house I bought eight years ago. I quickly discovered that I had no idea how to disassemble the thing. After a brief search online I found this diagram and a great site call Fixitnow.com. I quickly discovered that the drive motor to transmission coupling needed to be replaced. Fixitnow.com gave clear instructions on how to replace the thing and a link to the item on a vendor's web site.
The coupling is now on order and should arrive on Wednesday for a total for $23 (including expedited shipping).
Fixitnow.com is going in my delicious bookmarks.
I boasted to my wife how lucky she was to have a husband who saved us from a large repair bill. She was upset that she won't be getting a new washing machine.
Oh, well.
After the Skins beat the Eagles this afternoon I proceeded to attempt to diagnose the problem with my Whirlpool Heavy Duty Super Capacity Plus top loading washing machine which came with the house I bought eight years ago. I quickly discovered that I had no idea how to disassemble the thing. After a brief search online I found this diagram and a great site call Fixitnow.com. I quickly discovered that the drive motor to transmission coupling needed to be replaced. Fixitnow.com gave clear instructions on how to replace the thing and a link to the item on a vendor's web site.
The coupling is now on order and should arrive on Wednesday for a total for $23 (including expedited shipping).
Fixitnow.com is going in my delicious bookmarks.
I boasted to my wife how lucky she was to have a husband who saved us from a large repair bill. She was upset that she won't be getting a new washing machine.
Oh, well.
Subscribe to:
Posts (Atom)