How to talk to the Modem with AT commands[转]

asterisk的chan_celliax，使用了AT commands来和phone交互。

http://www.asteriskwin32.com/chan_celliax.php

 

http://forum.xda-developers.com/showthread.php?t=1471241

chan_celliax and chan_skypiax,

View and share presentations on PowerShow.com

什么是Caller ID[转]

Caller ID

                                       Caller ID
      Your phone rings. A name pops upon on your phone's screen. It's the name and number of the person calling you. Actually, it's the originating telephone number and the name the phone company thinks is the subscriber. The originating telephone number is stored in the originating central office equipment register, which is a database. That number supports a further database lookup, which associates the directory listing, assuming that the originating number is listed (i.e., not unlisted, or "nonpub" for nonpublished). The name and number information is passed through the local and long distance networks, and appears on your Caller ID box or your display telephone between the first and second rings.
      The delivery of Caller ID information assumes several things. First, the entire network of switches must be supported by SS7 (Signaling System System #7). Second, the calling party must originate the call from a single-channel line, rather than a multichannel trunk (e.g., T-1). Third, the originating line/caller must not block the transmission of the information. If all of these criteria are not met, your Caller ID box will display "ANONYMOUS" or "NOT AVAILABLE." Caller ID is one of several CLASS (Custom Local Area Signaling Services) provided by your LEC (Local Exchange Carrier). There generally is both a small installation charge and a monthly charge for Caller ID. Caller ID lets you amaze your parents and scare your technophobic friends, when you answer the phone with something like "Hi, Harry! Great Dictionary!" Caller ID also helps you avoid those dinnertime calls from telemarketers. They always block their numbers. By the way, Caller ID is not the same as ANI, although they often are confused. See also ANI, Caller ID Message Format (for a very detailed explanation), and CLASS.
来电显示
      你的电话振铃。你的电话机屏幕上跳出一个名称。正是呼叫你的人的名称和电话号码。事实上，这正是电话公司认为的该用户的初始电话号码和名称。这个初始电话 号码被存储在最初的市话局设备寄存器，也就是数据库中。这个电话号码支持与号码指南列表相关联的进一步的数据库查询，假设这个初始号码被列在指南里面（即 没有未被列入或者是未被出版“nonpub”）。名称和号码信息通过本地和长途网络传输，出现在你的来电显示器上或者是你的第一次和第二次振铃之间的显示 电话机上。
      来电显示信息的传输假定了几种情况。首先，整个交换机网络必须支持 SS7（系统 7 号信令）。第二，主叫方必须从一个单信道线路而不是多信道中继线（即 T-1）发起呼叫。第三，主叫线路/呼叫方不得阻碍该信息的传输。如果这些标准全部不能满足，那么你的来电显示器上将显示“匿名”或者是“无效”。来电号 码是你的LEC（本地电话公司）提供的几种CLASS（客户本地信令服务）中的一种。通常来电显示有一小笔安装费和月租费。当你接起电话时说 “嗨，Harry，字典编的不错！”时，你会让你的父母吃一惊，也会让你的工学院朋友吓一跳。来电显示功能也会让你避免在吃饭时间接到来自电信市场的电 话。他们总是隐藏自己的电话号码。顺便说一句，来电显示与ANI不一样，尽管这两者总是容易搞混。参见 ANI、Caller ID Message Format （解释的非常详细）和 CLASS。
Caller ID Message Format
      Calling Number Delivery (CND) came about as an extension of Automatic Number Identification (ANI). ANI is a method that is used by telephone companies to identify the billing account for a toll call. Although ANI is not the service that provides the information for CID, it was the first to offer caller information to authorized parties. The CID service became possible with the implementation of Signaling System 7 (SS7). The CID information is transmitted on the subscriber loop using frequency shift keyed (FSK) modem tones. These FSK modem tones are used to transmit the display message in American Standard Code for Information Interchange (ASCII) character code form. The transmission of the display message takes place between the first and second ring. The information sent includes the date, time, and calling number. The name associated with the calling number is sometimes included also. Since the time CID was first made available, it has been expanded to offer CID on Call Waiting (CIDCW) as well. With CIDCW, the call waiting tone is heard and the identification of the second call is seen. In earlier editions of my dictionary, I included the complete formatting, down to individual bits. It's too technical for this dictionary. However, if you want the entire story in all its detail, go to http://www.testmark.com/develop/tml_callerid_cnt.html and read the article on "Caller ID Basics", by Michael W. Slawson of Intertek Testing Services, TestMark Laboratories. Michael has assured me that he will leave his excellent paper on the Web forever.
来电显示信息（CID）格式
      主叫号码传送（CND）是自动号码识别（ANI）的一个扩展功能。ANI是电话公司用来识别长途电话呼叫账单的一种方法。尽管 ANI 并不为 CID 提供信息服务，但是也是第一个为获得授权的被叫方提供主叫方信息的。使用7号信号系统后就可以提供 CID 服务了。使用移频键控（FSK）调制解调器音频可以在用户环路上传输 CID 信息。这些 FSK 调制解调器音频可以以美国信息交换标准码（ASCII）字符代码形式传输显示信息。显示信息的传输发生在第一次和第二次振铃之间。信息传输包括日期、时间 和主叫号码。与主叫号码相关的主叫方名称有时也包括在内。由于是第一次使用，因此对 CID 功能进行了扩展，同时还提供呼叫等待来电显示信息（CIDCW）。使用了 CIDCW，可以听到呼叫等待音，并且第二次呼叫的识别号也可以看到。在我这本辞典的早期版本中，我收纳了完整的格式，直到单个的比特。对这本辞典来说， 太专业了。然而，如果你希望看到所有详细的解释，可以查阅 http://www.testmark.comdevelop/tml_callerid_cnt.html，阅读“来电显示基础”一文，作者是 TestMark实验室 Intertek 测试服务中心的 Michael W. Slawson。Michael 已经向我保证了，他将永远在网站上留下他精彩的论文。

关于协同编辑

协调编辑在某些情况下还是很有用的。

收集了一些资料, 有多种实现的方式，具体见Technical challenge, http://en.wikipedia.org/wiki/Collaborative_real-time_editor

CoEditor
----------

http://vhost1597.developer.ihost.com:8080/cowebx-apps/coedit/index.html
https://github.com/opencoweb

Client-side

Less than 2000 lines of Dojo-powered javascript

Server-side

A python web server capable of Operational Transformation, powered by the Open Cooperative Web Framework

 

https://github.com/opencoweb  

 

Gobby

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

 

Gobby is a free collaborative editor supporting multiple documents in one session and a multi-user chat. It runs on Microsoft Windows, Mac OS X, Linux and other Unix-like platforms. 

http://gobby.0x539.de/trac/

 

moonedit

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

http://moonedit.com/

Mozilla Skywriter 

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

 

https://github.com/mozilla/skywriter 

 

 

ACE

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

 

http://sourceforge.net/projects/ace/

 

EtherPad

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

有两个版本，算两个完全不同的实现吧。

http://en.wikipedia.org/wiki/EtherPad

http://etherpad.org/

http://code.google.com/p/etherpad/

https://github.com/ether/pad

https://github.com/pita/etherpad-lite

mobwrite
--------------

http://code.google.com/p/google-mobwrite/

 

 

协同编辑的理论基础

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

 

Operational transformation (OT) is a technology for supporting a range of collaboration functionalities in advanced groupware systems.  

 

http://en.wikipedia.org/wiki/Operational_transformation#OT_Control_.28Integration.29_Algorithms

 

 

最后，协同工作的理论

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

computer-supported cooperative work (CSCW)  

http://en.wikipedia.org/wiki/Computer_Supported_Cooperative_Work

SCTP介绍

SCTP在功能上介于TCP和UDP之前，比TCP轻量级，但比UDP功能强。另外还有multi-home功能支持，能合理利用本地的多个接入网络。

http://tdrwww.exp-math.uni-essen.de/inhalt/forschung/sctp_fb/sctp_intro.html

http://www.bluestop.org/SctpDrv/

关于ATM cell的一段描述[转]

Why cells?

Consider a speech signal reduced to packets, and forced to share a link with bursty data traffic (traffic with some large data packets). No matter how small the speech packets could be made, they would always encounter full-size data packets, and under normal queuing conditions, might experience maximum queuing delays. That is why all packets, or "cells," should have the same small size. In addition the fixed cell structure means that ATM can be readily switched by hardware without the inherent delays introduced by software switched and routed frames.
Thus, the designers of ATM utilized small data cells to reduce jitter (delay variance, in this case) in the multiplexing of data streams. Reduction of jitter (and also end-to-end round-trip delays) is particularly important when carrying voice traffic, because the conversion of digitized voice into an analogue audio signal is an inherently real-time process, and to do a good job, the decoder (codec) that does this needs an evenly spaced (in time) stream of data items. If the next data item is not available when it is needed, the codec has no choice but to produce silence or guess — and if the data is late, it is useless, because the time period when it should have been converted to a signal has already passed.
At the time of the design of ATM, 155 Mbit/s Synchronous Digital Hierarchy (SDH) with 135 Mbit/s payload was considered a fast optical network link, and many Plesiochronous Digital Hierarchy (PDH) links in the digital network were considerably slower, ranging from 1.544 to 45 Mbit/s in the USA, and 2 to 34 Mbit/s in Europe.
At this rate, a typical full-length 1500 byte (12000-bit) data packet would take 77.42 µs to transmit. In a lower-speed link, such as a 1.544 Mbit/s T1 line, a 1500 byte packet would take up to 7.8 milliseconds.
A queuing delay induced by several such data packets might exceed the figure of 7.8 ms several times over, in addition to any packet generation delay in the shorter speech packet. This was clearly unacceptable for speech traffic, which needs to have low jitter in the data stream being fed into the codec if it is to produce good-quality sound. A packet voice system can produce this low jitter in a number of ways:

• Have a playback buffer between the network and the codec, one large enough to tide the codec over almost all the jitter in the data. This allows smoothing out the jitter, but the delay introduced by passage through the buffer would require echo cancellers even in local networks; this was considered too expensive at the time. Also, it would have increased the delay across the channel, and conversation is difficult over high-delay channels.

• Build a system that can inherently provide low jitter (and minimal overall delay) to traffic that needs it.

• Operate on a 1:1 user basis (i.e., a dedicated pipe).

The design of ATM aimed for a low-jitter network interface. However, "cells" were introduced into the design to provide short queuing delays while continuing to support datagram traffic. ATM broke up all packets, data, and voice streams into 48-byte chunks, adding a 5-byte routing header to each one so that they could be reassembled later. The choice of 48 bytes was political rather than technical.^[4] When the CCITT (now ITU-T) was standardizing ATM, parties from the United States wanted a 64-byte payload because this was felt to be a good compromise in larger payloads optimized for data transmission and shorter payloads optimized for real-time applications like voice; parties from Europe wanted 32-byte payloads because the small size (and therefore short transmission times) simplify voice applications with respect to echo cancellation. Most of the European parties eventually came around to the arguments made by the Americans, but France and a few others held out for a shorter cell length. With 32 bytes, France would have been able to implement an ATM-based voice network with calls from one end of France to the other requiring no echo cancellation. 48 bytes (plus 5 header bytes = 53) was chosen as a compromise between the two sides. 5-byte headers were chosen because it was thought that 10% of the payload was the maximum price to pay for routing information.^[3] ATM multiplexed these 53-byte cells instead of packets which reduced worst-case cell contention jitter by a factor of almost 30, reducing the need for echo cancellers.

Read more: http://www.answers.com/topic/asynchronous-transfer-mode-1#ixzz1p9bKbgVj

关于windows wifi API的一段说明

If you are starting the development of some software that must manage WiFi connections and settings in Windows, you will be faced with the following problem. There are two versions of Windows that have API for WiFi networks management: Windows XP Service Pack 2 (or SP3) and Windows Vista, and both versions use absolutely different APIs for wireless network management.

• Windows XP SP2/SP3
  - uses the "Wireless Zero Configuration" (WZC) API. This API is almost undocumented and there aren't any examples how to use it, although this API can perform all necessary operations with WiFi connections and Windows XP SP2/SP3 is the most popular version of Windows at present.
• Windows Vista and Windows 7
  - uses the "Native WiFi" API. This is a new API that allows you to manage WiFi networks, this API is simpler and more documented, although there is only one example how to use it. You can find this example for the C++ language in the Vista SDK.

There is a patch from Microsoft that allows you to use part of the "Native WiFi" API in Windows XP SP2, though it means that your software must download and install this patch. Unfortunately, we have tried using the "Native WiFi" API for XP in our projects and we have found out that it does not work properly in some cases. It returns some data fields incorrectly and does not set some of them at all. After studying it in detail, we have discovered that the "Native WiFi" API for Windows XP is only a wrapper for the WZC API and it is much better to use the WZC API directly.

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


参考：

http://www.codeproject.com/Articles/19341/Wifi-scanner-custom-MFC-controls

http://openwps2.googlecode.com/svn-history/r73/trunk/WM_client_cpp/WifiPeek.cpp

http://www.codeproject.com/Articles/24756/How-to-query-miniport-driver-information-802-11-OI

Linux traffic control参考链接

http://blog.edseek.com/~jasonb/articles/traffic_shaping/introduction.html

http://tldp.org/HOWTO/Traffic-Control-HOWTO/index.html

http://www.docum.org/docum.org/

http://opalsoft.net/qos/

Policing

Policing就是超出限速后将包直接丢弃，它通常是和filter结合在一起用。filter可以对包采取多种措施：

 - ok or pass     - 通常用于暂时禁用掉某个filter

 - continue         - 找不到匹配的filter，继续找其他的匹配

 - drop or shot   - 丢弃

 - reclassify        - 重新标记为Best Effort，默认的action

 如果qdisc没有实现policing，那么drop和reclassify会被当做continue，即不被处理。

有两种方式来做police：

1. kernel estimator，内核的estimator来统计Exponential Weighted Moving Average平滑后的速率(40ms统计一次，每秒有25次统计，然后再平滑），用来避免burst流量的影响，如果超出，就采取特定的措施，默认是reclassify。这种方式只需要一个参数avrate。

2. 使用token bucket filter。这种和tc-tbf一样，只是数据不会缓存，所以没有"limit/latency"的参数，可用的参数如下：

  - burst/buffer/maxburst，桶的容量

  - mtu/minburst， 第二个burst桶的容量，如果设置的太小，包有可能会过不去。

  - mpu，minium packet usage,每个包不管大小多大，都需要消耗token，这个值指定了一个包需
    要消耗的最小token量（字节）。

  - rate, 第一个桶token注入的速率

例子：

1） 限制icmp的流量为2kbit：

tc filter add dev $DEV parent ffff: protocol ip prio 20 u32 match ip protocol 1 0xff police rate 2kbit buffer 10k drop flowid :1


2）限制包大小不超过84byte：

tc filter add dev $DEV parent ffff: protocol ip prio 20 u32 match ip tos 0 0xff police mtu 84 drop flowid :1

3）丢弃所有的icmp包：

tc filter add dev $DEV parent ffff: protocol ip prio 20 u32 match ip protocol 1 0xff police mtu 1 drop flowid :1

模拟国内某些小区adsl的带宽限制

这类网络在速率超出带宽限制后就直接丢包，不会缓存数据，即采用的是police而不是shape。

要用linux的流量控制模拟这种情况，需要在ingress上采用流量控制，这里使用linux的eth0做包转发

tc qdisc add dev eth0 ingress

可以用tc qdisc show dev eth0来查看，可以看到id为"ffff:"的qdisc就是ingress对应的qdisc的id:

qdisc ingress ffff: parent ffff:ffff1 ------------

接下来添加一条过滤规则，并设置限速策略，将目标地址为64.104.177.71的包过滤出来，如果要匹配任意地址，可以使用0.0.0.0/0

tc filter add dev eth0 parent ffff: protocol ip prio 20 u32 match ip dst 64.104.177.71 police rate 800kbit burst 10k drop flowid :1


这里flowid :1是比较费解的，很少有提及，看到一个比较合理的解释是：

“ As fas as I know,this qdisc is a dummy one, and flowid is just used with :1 because the traffic have to be redirected to something.”

也就是说过滤出来被drop掉的数据会被重定向到一个dummy的qdisc?

要查看filter是否生效可以用，但这里只能看到egress接口上面的

tc filter show dev eth0


对于ingress的filter，需要使用

tc filter show parent ffff: dev eth0