Archive for January, 2007

Ignoring SIP redirect messages from the Cisco 7912

Saturday, January 27th, 2007

A few months ago, I started using a Cisco 7912 with my home Asterisk system. It’s a much nicer phone than most analog sets you can buy. Furthermore, it is a pure IP phone and therefore doesn’t have the same echo problems as my analog phones hanging off ATAs.

However, there is one frustration. The phone attempts to be smart, and will redirect calls to voice mail after four rings if the voice mail number has been configured. Generally, it’s a nice feature, but it can be quite annoying when I have the Asterisk-powered doorbell ring the 7912. The procedure goes something like this:

  1. Somebody presses the Doorbell Fon, which creates a call into an FXO port on my Asterisk server.
  2. Asterisk handles the call, either by ringing a group of extensions directly, as in Dial(SIP/cisco7912&SIP/others), or by ringing all extensions in a queue.
  3. All the phones that are targets in the queue or Dial application ring. On the fourth ring, the 7912 gets smart and decides to send the call to voice mail.
  4. Upon receipt of the SIP redirect message, Asterisk sends the call to the voice mail extension. However, without knowing what mailbox to send to, Asterisk prompts the user. On a Doorbell Fon, there is only one button and no way to interact with the phone.

While redirection to voicemail may generally be a useful feature, four rings doesn’t make sense for a doorbell, especially if the 7912 causes the call to be sent to voice mail and prevents other extensions from answering it. What I would really like Asterisk to do is to ignore SIP redirect messages. (I can think of many applications where you’d want Asterisk to do the call processing without regard to what client devices tell you to do, especially if you might be liable for the resulting toll charges.)

It turns out that there’s an experimental flag to do this in the Dial application. In Asterisk trunk, there’s a small bit of code that allows you to pass the “i” option to Dial to instruct Asterisk to ignore SIP redirects. I’m still running the 1.2 release, so I don’t have this option just yet. I suppose it is just another reason why I am looking forward to my upgrade from Asterisk 1.2.

A look at 802.11a, b, and g throughput with short preambles

Saturday, January 27th, 2007

Three and a half years ago, I used a simple model to calculate the maximum throughput of 802.11 networks. Recently, a reader wrote to me and asked me how the use of the short preamble would affect the throughput numbers. The answer is that using the short preamble increases throughput by more than 20%.

The re-calculations aren’t particularly complicated. The short preamble is only 96 microseconds instead of 192. The initial slow component of the preamble is shorter, and the second and final component is transmitted at a faster data rate. This affects the model by making any frame transmitted with 802.11b data rates take 96 fewer microseconds in the air.

In the 802.11b model, that savings exists on four frames (the initial data frame with the TCP payload, the 802.11 ACK, the second data frame with the TCP ACK, and the final 802.11 ACK). Therefore, the simple TCP+ACK transaction the model is based on is 384 microseconds shorter.

In the 802.11g with CTS-to-self protection, the short preamble saves on just two frames. In CTS-to-self protection, the frames transmitted at 802.11b data rates are the two CTS frames used to lock up access to the medium. Therefore, the TCP+ACK transaction unit in the model is 192 microseconds shorter.

Finally, in the 802.11g with RTS-CTS protection, there are once again four frames with a preamble saving. Both of the two 802.11 data frames carrying a TCP payload are protected by an RTS and a CTS frame, so the TCP+ACK transaction unit is once again 384 microseconds shorter.

Throw it into a spreadsheet, and you get the following table, where the short preamble rows are new.

Technology Transaction time (μs) Transactions/ second TCP payload throughput, Mbps Improvement over long preamble
802.11b, long preamble 2084 479 5.6 -
802.11b, short preamble 1700 588 6.9 +23%
802.11g, CTS-to-self, long preamble 898 1113 13.0 -
802.11g, CTS-to-self, short preamble 706 1416 16.5 +27%
802.11g, RTS-CTS, long preamble 1285 778 9.1 -
802.11g, RTS-CTS, short preamble 948 1054 12.3 +35%

It’s also important to note that the equipment on the market rarely uses the full RTS-CTS protection. It is an option on most equipment, but it is rarely used.

802.11 Task Group N goes back to letter ballot

Friday, January 19th, 2007

I am sitting in the 802.11 working group meeting in London right now, and we have just voted overwhelmingly to send the draft out for another letter ballot vote. The vote was important enough that the chair required a rising vote, though a look around the room made it obvious that it passed; final count was 100-0 with five abstentions. This is a big milestone for the process because the nine-month slog to resolve the 12,000 initial comments is complete. It’ll be interesting to see how many comments the new draft gets.

BART’s EZ Rider card

Monday, January 8th, 2007

I’ve been a fairly regular BART rider for over three years now, and one of my big complaints about the system is the lack of discounts for regular riders. To get the 6.25% discount, you have to buy paper tickets from neighborhood vendors. The “high value” tickets are not available in stations, for inexplicable reasons.

To add insult to injury, the ticket inevitably has a small amount of money left on it, so you are left with a pile of sub-$1.00 tickets that must be laboriously exchanged into a single consolidated ticket. (The rules are much more complicated; when I tried to exchange a pile of tiny tickets, there was a problem exchanging the tiny residual tickets that had been purchased from a BART ticket machine with a credit card, but not the tiny tickets that were purchased with cash. Don’t even ask!)

The whole situation is maddening for somebody who has an Octopus card (Hong Kong), an EZ-Link card (Singapore), and will probably get an Oyster card at the IEEE meeting in London next week. The technology is quite well-developed, but BART is still stuck in the 1970s with pieces of paper and magnetic stripes.

Well, somebody at BART must be paying attention to what’s going on in the rest of the world, because the EZ Rider card is now entering its second trial phase. I’ve been wondering how to get one ever since I read about it in the Capricious Commuter in November. Never having to go buy a paper ticket at a “convenient neighborhood vendor” again and automatically having my tiny useless amounts of money carry over on the smart card would address two of my biggest complaints with the fare system.

So far, though, the card has been somewhat annoying. There is an “on line” sign up system, where you fill out a few questions and it says, teasingly, that you’re almost done. In this case, “almost done” means that you need to print out a sign-up form, mail it to BART in Oakland, and wait. After two weeks (though, to be fair, that included the Christmas and New Year’s holidays), a card finally arrived in the mail.

In an amusing contrast, my EZ Rider card arrived the same day as a credit card. To activate the credit card, I called the number on the card, entered the last four digits, and my card was activated. If I had wanted to buy something with it, it was ready right then. To activate the EZ Rider card, I had to call BART and leave a message on what sounded like an answering machine with my name, the card number, and the last four digits of the credit card number that it’s linked to. Several hours later, I received an e-mail informing me that my card would be activated in the next three days.

All in all, this process could be made a lot easier. (Automating the activation process would be an easy Asterisk project!)

Fortunately, when I used the card for the first time this morning, it functioned in the fare gate as expected. I’m on the train to work now. We’ll see if it also works when I get off the train in another half hour…