在两篇RFC文档中对iLBC有比较全面的介绍：
1、RFC3591 Internet Low Bit Rate Codec (iLBC) 这篇主要是讲解iLBC的基本原理，非语音处理领域的专业人士很难看得明白。
2、RFC3952 Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech 进行RTP传输是必须遵守的规范，VOIP领域人士基本能看明白。
简单点说：iLBC采用8KHZ，16bit采样，但是分成两种模式：30ms（毫秒）模式以及20ms（毫秒）模式。最初只定义了30ms模式，后来考虑到窄带网络丢包的情况，增加了20ms模式。目前大部分设备多采用的是30ms模式。
30ms模式是指每30ms发送一帧，则每帧数据是400bits （50bytes），如果是20ms一帧，则每帧数据是304bits（38bytes）。
在SDP描述中，必须明确指明codec名字是iLBC。
如果是20ms模式，必须在SDP中明确指明，否则会认为是30ms模式。在RFC文档中有如下描述：
If 20 ms frame size mode is used, remote iLBC encoder SHALL receive “mode” parameter in the SDP “a=fmtp” attribute by copying them directly from the MIME media type string as a semicolon separated with parameter=value, where parameter is “mode”, and values can be 0 and 20 (where 0 is reserved and 20 stands for preferred 20 ms frame size). An example of the media representation in SDP for describing iLBC when 20 ms frame size mode is used might be:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=20 <– 30ms模式中，多数厂家的设备不会携带这个attribute。
需要注意的是SDP协商与一般的codec协商有不同，其中比较关键的就是ptime不能应用到iLBC的协商中。iLBC总是采用最低速率模式，例如，只要一方要求30ms模式，双方都必须使用30ms模式：
That is, an offer of “mode=20” receiving an answer of “mode=30” will result in “mode=30” being used by both participants. Similarly, an offer of “mode=30” and an answer of “mode=20” will result in “mode=30” being used by both participants.
注解：我想可能就是这个原因（当然，也有历史遗留的可能），大家都不约而同地采用30ms模式，避免对媒体资源的重新调配。
不能使用ptime的原因在于一个RTP包中，可能会封装若干个iLBC包，这种情况下ptime无法表述究竟是哪种模式：
Parameter ptime can not be used for the purpose of specifying iLBC operating mode, due to fact that for the certain values it will be impossible to distinguish which mode is about to be used (e.g., when ptime=60, it would be impossible to distinguish if packet is carrying 2 frames of 30 ms or 3 frames of 20 ms, etc.).
注解：在一个RTP包中封装多个iLBC包的方法，实在让人感觉多此一举。即没有减少流量，也不能降低丢包对语音质量的影响，反而增加了网络设备的复杂性。从实际应用来看，也没有什么人会采用这种方式。