[Iaxclient-cvs] iaxclient/lib TODO,1.1,1.2

[<st...@us...>]

Update of /cvsroot/iaxclient/iaxclient/lib
In directory sc8-pr-cvs1:/tmp/cvs-serv26222

Modified Files:
	TODO 
Log Message:
some todo items are now done.



Index: TODO
===================================================================
RCS file: /cvsroot/iaxclient/iaxclient/lib/TODO,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- TODO	16 Jun 2003 16:10:14 -0000	1.1
+++ TODO	16 Jun 2003 23:39:41 -0000	1.2
@@ -34,7 +34,22 @@
 	really robust enough for our needs once we do this stuff.
 
 
-2) Call handling:
+
+2) Codecs:  (I think that someone is working on this)
+
+	Currently, the library assumes that all calls will be GSM only,
+	and further assumes that all frames will be 20ms.  It can
+	control the frame size (within reason) for frames it sends out,
+	but should deal gracefully with incoming frames that aren't
+	20ms.
+
+	Codecs should probably be implemented via a similar set of
+	structure abstractions as audio drivers, above.  They also need
+	to handle incoming packets which may switch formats abruptly(?).
+
+DONE (or, at least, mostly done):
+==============================================================
+Call handling 
 	currently, the library really only supports one call, and not
 	very well.  It should have a collection of calls (either an
 	array, or a linked list), and keep track of the current state of
@@ -62,19 +77,7 @@
 	testcall would just ask for a single call, so it wouldn't have
 	to worry about a lot of this.
 
-3) Codecs:  (I think that someone is working on this)
-
-	Currently, the library assumes that all calls will be GSM only,
-	and further assumes that all frames will be 20ms.  It can
-	control the frame size (within reason) for frames it sends out,
-	but should deal gracefully with incoming frames that aren't
-	20ms.
-
-	Codecs should probably be implemented via a similar set of
-	structure abstractions as audio drivers, above.  They also need
-	to handle incoming packets which may switch formats abruptly(?).
-
-4) Events:
+Events:
 	We might want to consolidate the (currently three) callbacks
 	that the library makes to clients, into a single callback, that
 	passes back a structure with event info.  I was thinking of a