From anthony at interlink.com.au Fri Oct 1 11:33:14 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Fri, 01 Oct 2004 19:33:14 +1000 Subject: [Shtoom] Re: [Divmod-dev] An application with your framework. In-Reply-To: <415B2106.8090204@eicat.ca> References: <415B2106.8090204@eicat.ca> Message-ID: <415D245A.1000102@interlink.com.au> David Gilbert wrote: > Well... I must start by saying that I'm impressed with your sip > framework. I've got a few $'s to work on a project to product a SIP > thingie that calls a number, punches some DTMF and then records the > result (dialing into remote callcenter PBX's and monitoring a call for > later grading). Anyways, I thought I'd let you know that I'm poking > along with your code. It's a tough slog, but it's going. So far I've > centered on using a bit of the annoucing message server as a model (A > 'doug' application) ... but it still seems to listen on 5060 by default > --- not exactly what I want. Need to find that widget. You might want to look at scripts/testcisco.py, as this does exactly this - it connects to a host and interacts with an IVR. For applications like this, passing -p0 (or --listenport=0) will "do the right thing" and allocate a random port number. > I've checked out the source with subversion and to the extent that I > modify things in your base classes, I'd like to contribute. I also > don't know what your time/day is like for responding to email --- so if > it's tight, I'll just get back to you when I'm finished. If not, I'd be > happy to sync up and keep an open dialogue. My available time to spend on shtoom is highly variable, and depends on a pile of other things. Either email, or the channel #shtoom on irc.freenode.net, are the best way to contact me. > One thing I've noticed off the top is that the shtoomphone.py > application seems to receive a stream of RTP, but not send. I can hear > the "echo" of my input in my own speakers, but not in the phone I call > --- whereas taking in the called phone is audible in the speakers. > Using ethereal I determined that RTP packets were coming from the > provider but none were going to the provider (although the SIP > conversation appeared to be normal). Dunno what's going on there - you might want to try using the test harness (look in DEBUGGING.txt for details on how to run it) to check that your audio devices are sane. In particular, if you're on ALSA (a recent linux innovation), getting the settings right is a completely black art. Hearing yourself talk, but not actually generating any audio, often can mean a misconfiguration - if you can hear yourself talk, that's often the problem. When running the harness, you should only hear yourself talking when there's a call up - if you can hear yourself otherwise, your sound system is misconfigured :-( Anthony -- Anthony Baxter It's never too late to have a happy childhood. From zooko at zooko.com Fri Oct 1 21:26:37 2004 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: 1 Oct 2004 16:26:37 -0300 Subject: [Shtoom] bug report: OSX / audio / Python 2.3.4 Message-ID: I get this problem running shreadder with Python 2.3.4 (just built from source). I get different problems (fatal mismatch -- wrong interpreter?) when using the standard /usr/bin/python... --Z HACK draco:~/playground/shtoom-private-darcs-world/Shtoom/shtoom$ python Python 2.3.4 (#3, Oct 1 2004, 14:02:00) [GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin HACK draco:~/playground/shtoom-private-darcs-world/Shtoom/shtoom$ python ./scripts/shreadder.py Traceback (most recent call last): File "./scripts/shreadder.py", line 82, in ? main() File "./scripts/shreadder.py", line 61, in main dev = getAudioDevice() File "/Users/zooko/shtoominstdir/lib/python2.3/site-packages/shtoom/audio/ __init__.py", line 49, in getAudioDevice dev = audioint.Device() AttributeError: 'NoneType' object has no attribute 'Device' From cwi at unispeed.dk Mon Oct 4 10:32:19 2004 From: cwi at unispeed.dk (Casper Wilstrup) Date: Mon, 04 Oct 2004 10:32:19 +0200 Subject: [Shtoom] Thanks for merging my code In-Reply-To: <415E2D21.6030507@interlink.com.au> References: <1096669613.20400.21.camel@cwi.unispeed.dk> <415E2D21.6030507@interlink.com.au> Message-ID: <1096878739.6384.5.camel@cwi.unispeed.dk> Hi Anthony. Thanks a lot for merging my ALSA and playtback code so swiftly. Did you actually try it out yet? I've got several more minor fixes that I'd like to include at this time - mostly for enabling the actual use of alsa from the options. Do you think it would be possible for me to get an svn account at some point? Also, I'll switch to using the mailing list for future communication. BR, Casper Wilstrup From anthony at interlink.com.au Mon Oct 4 10:52:33 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Mon, 04 Oct 2004 18:52:33 +1000 Subject: [Shtoom] Re: Thanks for merging my code In-Reply-To: <1096878739.6384.5.camel@cwi.unispeed.dk> References: <1096669613.20400.21.camel@cwi.unispeed.dk> <415E2D21.6030507@interlink.com.au> <1096878739.6384.5.camel@cwi.unispeed.dk> Message-ID: <41610F51.8040905@interlink.com.au> Casper Wilstrup wrote: > Thanks a lot for merging my ALSA and playtback code so swiftly. Did you > actually try it out yet? The ALSA code, yes - the playout code, not yet. I need to write some test code for it first. I made a few changes to the code - firstly to give them correct names/modules, but a few others: - print -> log.msg - wrapped a lot of the log.msg() in the playout in a module level DEBUG. At some point in the future I'll roll out a better debugging infrastructure, so that this sorta stuff can be turned on and off - made playout underrun return '' rather than an all-zero sound. I also want to look at possibly playing white-noise (with the energy level set to the same as the previous packet). Apparently this gives a higher user feedback score. > I've got several more minor fixes that I'd like to include at this time > - mostly for enabling the actual use of alsa from the options. Do you > think it would be possible for me to get an svn account at some point? Yep, that's certainly do-able. > Also, I'll switch to using the mailing list for future communication. If you have an IRC client, there's also #shtoom on irc.freenode.net. Anthony From cwi at unispeed.dk Mon Oct 4 11:22:41 2004 From: cwi at unispeed.dk (Casper Wilstrup) Date: Mon, 04 Oct 2004 11:22:41 +0200 Subject: [Shtoom] Re: Thanks for merging my code In-Reply-To: <41610F51.8040905@interlink.com.au> References: <1096669613.20400.21.camel@cwi.unispeed.dk> <415E2D21.6030507@interlink.com.au> <1096878739.6384.5.camel@cwi.unispeed.dk> <41610F51.8040905@interlink.com.au> Message-ID: <1096881761.6624.8.camel@cwi.unispeed.dk> Yup, I looked through the changes to the logging, etc, and thats fine. One issue though. The reason I return zero sound in the BacklogPlayout rather than '' is that this will cause the PCM to underrun, causing ugly clicking sounds when the ALSA layer resets the PCM. The zero sound packets are in turn balanced by discarding real packets when the backlog is restored to it's maximum length. This is far better than having ALSA buffer the extra sound bits, since this can cause unacceptable playback latency to build up. Replacing the 0 sound with a low white static sounds like a good idea though. I'm looking forward to the day Shtoom phone supports conferencing and text messages - until then I'll start using th IRC channel :-) BTW, aren't you located in Australia? Just to get a sense of the time zone you're operating in... /Casper On Mon, 2004-10-04 at 10:52, Anthony Baxter wrote: > Casper Wilstrup wrote: > > Thanks a lot for merging my ALSA and playtback code so swiftly. Did you > > actually try it out yet? > > The ALSA code, yes - the playout code, not yet. I need to write some > test code for it first. I made a few changes to the code - firstly to > give them correct names/modules, but a few others: > > - print -> log.msg > - wrapped a lot of the log.msg() in the playout in a module level DEBUG. > At some point in the future I'll roll out a better debugging > infrastructure, so that this sorta stuff can be turned on and off > - made playout underrun return '' rather than an all-zero sound. I > also want to look at possibly playing white-noise (with the energy level > set to the same as the previous packet). Apparently this gives a higher > user feedback score. > > > I've got several more minor fixes that I'd like to include at this time > > - mostly for enabling the actual use of alsa from the options. Do you > > think it would be possible for me to get an svn account at some point? > > Yep, that's certainly do-able. > > > Also, I'll switch to using the mailing list for future communication. > > If you have an IRC client, there's also #shtoom on irc.freenode.net. > > Anthony From zooko at zooko.com Mon Oct 4 12:05:46 2004 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: 4 Oct 2004 07:05:46 -0300 Subject: [Shtoom] bug report: OSX / audio / Python 2.3.4 In-Reply-To: References: Message-ID: This was user error on my part. Or if it was a bug in Shtoom, then the bug was that shtoom/setup.py build_ext doesn't automatically invoke CocoaAudio/python_callbacks/setup.py build_ext. --Z On 2004, Oct 01, at 16:26, Zooko Wilcox-O'Hearn wrote: > I get this problem running shreadder with Python 2.3.4 (just built > from source). > > I get different problems (fatal mismatch -- wrong interpreter?) when > using the standard /usr/bin/python... > > --Z > > HACK draco:~/playground/shtoom-private-darcs-world/Shtoom/shtoom$ > python > Python 2.3.4 (#3, Oct 1 2004, 14:02:00) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin > > > HACK draco:~/playground/shtoom-private-darcs-world/Shtoom/shtoom$ > python ./scripts/shreadder.py > Traceback (most recent call last): > File "./scripts/shreadder.py", line 82, in ? > main() > File "./scripts/shreadder.py", line 61, in main > dev = getAudioDevice() > File > "/Users/zooko/shtoominstdir/lib/python2.3/site-packages/shtoom/audio/ > __init__.py", line 49, in getAudioDevice > dev = audioint.Device() > AttributeError: 'NoneType' object has no attribute 'Device' From anthony at interlink.com.au Mon Oct 4 13:06:47 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Mon, 04 Oct 2004 21:06:47 +1000 Subject: [Shtoom] Re: Thanks for merging my code In-Reply-To: <1096881761.6624.8.camel@cwi.unispeed.dk> References: <1096669613.20400.21.camel@cwi.unispeed.dk> <415E2D21.6030507@interlink.com.au> <1096878739.6384.5.camel@cwi.unispeed.dk> <41610F51.8040905@interlink.com.au> <1096881761.6624.8.camel@cwi.unispeed.dk> Message-ID: <41612EC7.3030804@interlink.com.au> Casper Wilstrup wrote: > One issue though. The reason I return zero sound in the BacklogPlayout > rather than '' is that this will cause the PCM to underrun, causing ugly > clicking sounds when the ALSA layer resets the PCM. The zero sound > packets are in turn balanced by discarding real packets when the backlog > is restored to it's maximum length. This is far better than having ALSA > buffer the extra sound bits, since this can cause unacceptable playback > latency to build up. Replacing the 0 sound with a low white static > sounds like a good idea though. Hm. My idea was that we put something in place to catch underruns and do sound substitution - for that, it's necessary to be able to distinguish between underrun and silence. > I'm looking forward to the day Shtoom phone supports conferencing and > text messages - until then I'll start using th IRC channel :-) > BTW, aren't you located in Australia? Just to get a sense of the time > zone you're operating in... Yep. I'm at UTC+10 for a few more weeks, then UTC+11. In general, I'm an evening/night person, not a morning person. -- Anthony Baxter It's never too late to have a happy childhood. From anthony at interlink.com.au Mon Oct 4 13:07:34 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Mon, 04 Oct 2004 21:07:34 +1000 Subject: [Shtoom] bug report: OSX / audio / Python 2.3.4 In-Reply-To: References:

Message-ID: <41612EF6.8010909@interlink.com.au> Zooko Wilcox-O'Hearn wrote: > This was user error on my part. Or if it was a bug in Shtoom, then the > bug was that shtoom/setup.py build_ext doesn't automatically invoke > CocoaAudio/python_callbacks/setup.py build_ext. The code now also raises a specific NoAudioDevice exception in this case. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From cwi at unispeed.dk Mon Oct 4 13:34:07 2004 From: cwi at unispeed.dk (Casper Wilstrup) Date: Mon, 04 Oct 2004 13:34:07 +0200 Subject: [Shtoom] Re: Thanks for merging my code In-Reply-To: <41612EC7.3030804@interlink.com.au> References: <1096669613.20400.21.camel@cwi.unispeed.dk> <415E2D21.6030507@interlink.com.au> <1096878739.6384.5.camel@cwi.unispeed.dk> <41610F51.8040905@interlink.com.au> <1096881761.6624.8.camel@cwi.unispeed.dk> <41612EC7.3030804@interlink.com.au> Message-ID: <1096889646.8204.8.camel@cwi.unispeed.dk> On Mon, 2004-10-04 at 13:06, Anthony Baxter wrote: > Casper Wilstrup wrote: > > One issue though. The reason I return zero sound in the BacklogPlayout > > rather than '' is that this will cause the PCM to underrun, causing ugly > > clicking sounds when the ALSA layer resets the PCM. The zero sound > > packets are in turn balanced by discarding real packets when the backlog > > is restored to it's maximum length. This is far better than having ALSA > > buffer the extra sound bits, since this can cause unacceptable playback > > latency to build up. Replacing the 0 sound with a low white static > > sounds like a good idea though. > > Hm. My idea was that we put something in place to catch underruns > and do sound substitution - for that, it's necessary to be able to > distinguish between underrun and silence. Yes, but wouldn't the right place to do the sound substitution be in the Playout code - the choice of which should probably also be made configurable? Another thing: I'd like to make a class which implements converting entered urls in the dial entry to a real sip URL. This would be the place future address book lookups should be performed, as well as normalizing, eg. entering '600' becomes 'sip:600 at voip.unispeed.dk', the domain being taken from the registrar URL. Would that be OK with you? /Casper From zooko at zooko.com Mon Oct 4 14:25:05 2004 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: 4 Oct 2004 09:25:05 -0300 Subject: [Shtoom] what happens to stdout in text-mode UI? Message-ID: <6C35EC41-1600-11D9-A082-000A95E2A184@zooko.com> I've added some code like this to protocol.py: LOG=open("protocol.py.log", "w") ... def sendFirstData(self): LOG.write("about to raise \"HELLO WORLD! PLEASE SEE ME! I am in sendFirstData()!\"\n") raise "HELLO WORLD! PLEASE SEE ME! I am in sendFirstData()!" When I run this code on Linux, I get the following result: 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] baseaudio: reopen 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] ossaudiodev opening 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] initialising playout 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] call Start 'CallCookie1' ('192.168.1.100', 47944) 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] Traceback (most recent call last): File "/home/zooko/instdirs/twisted/lib/python2.3/site-packages/twisted/ python/context.py", line 31, in callWithContext return func(*args,**kw) File "/home/zooko/instdirs/twisted/lib/python2.3/site-packages/twisted/ internet/d >> >> >> HACM pion:~/tmp$ l drwxrwsr-x 2 zooko zooko 112 Oct 4 09:15 ./. drwxr-sr-x 138 zooko zooko 14200 Oct 4 09:16 ./.. -rw-rw-r-- 1 zooko zooko 0 Oct 4 09:17 ./sip.py.log -rw-rw-r-- 1 zooko zooko 72 Oct 4 09:17 ./protocol.py.log HACM pion:~/tmp$ cat protocol.py.log about to raise "HELLO WORLD! PLEASE SEE ME! I am in sendFirstData()!" When I run this code on OSX, I get the following result: 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] Allow-Events: telephone-event 2004/10/04 09:17 ADT [shtoom.sip.SipProtocol (UDP)] User-Agent: Shtoom/0.3alpha0 2004/10/04 09:17 ADT [shtoINCOMING CALL: "None" ;tag=01ee022d Type 'accept' to accept, 'reject' to reject accept >> >> >> >> ^C^C HACK draco:~/tmp$ HACK draco:~/tmp$ HACK draco:~/tmp$ HACK draco:~/tmp$ l drwxr-xr-x 243 zooko staff 8262 4 Oct 08:09 ./.. -rw-rw-r-- 1 zooko staff 0 4 Oct 08:55 ./sip.py.log drwxrwxr-x 4 zooko staff 136 4 Oct 09:15 ./. -rw-rw-r-- 1 zooko staff 72 4 Oct 09:17 ./protocol.py.log HACK draco:~/tmp$ cat protocol.py.log about to raise "HELLO WORLD! PLEASE SEE ME! I am in sendFirstData()!" It appears to me that uncaught exceptions fall into a race condition or other inconsistency in the Shtoom/Twisted logging system. This is with the text ui. I guess the process's stdout is doing double duty here. Python's sys.stdout is redirected to the logger, which prepends a timestamp and then sends to the process's real stdout. Also the text ui has connected to the process's stdin/stdout as a Python transport and is using it for UI. What do you think? Should we just eliminate the concept of logging to stdout when you are also using the text-mode UI, and make a logfile for text-mode UI? Note that this problem isn't only for uncaught exceptions. In fact, I added a "print" statement before the "raise" statement and re-ran this experiment. This time nothing about the LOG/print/raise appeared at all in stdout, although the expected line still appeared in the log file. Regards, Zooko From zooko at zooko.com Mon Oct 4 14:43:08 2004 From: zooko at zooko.com (Zooko Wilcox-O'Hearn) Date: 4 Oct 2004 09:43:08 -0300 Subject: [Shtoom] what happens to stdout in text-mode UI? In-Reply-To: <6C35EC41-1600-11D9-A082-000A95E2A184@zooko.com> References: <6C35EC41-1600-11D9-A082-000A95E2A184@zooko.com> Message-ID: Here is a patch which sends log messages to a text file in the text ui. Index: shtoom/ui/textui/main.py =================================================================== --- shtoom/ui/textui/main.py (revision 818) +++ shtoom/ui/textui/main.py (working copy) @@ -11,6 +11,9 @@ from os import linesep as delimiter sipURL = None + def getLogger(self): + return open("shtoom.log", "w") + def debugMessage(self, msg): if self._debug: print msg Index: shtoom/ui/textshtoom.py =================================================================== --- shtoom/ui/textshtoom.py (revision 818) +++ shtoom/ui/textshtoom.py (working copy) @@ -18,7 +18,7 @@ UI = ShtoomMain() UI.connectApplication(application) stdio.StandardIO(UI) - #log.startLogging(UI.getLogger()) - log.startLogging(sys.stdout) + log.startLogging(UI.getLogger()) + # log.startLogging(sys.stdout) # This causes mucho problemas, as described in this post: http://mail.python.org/pipermail/shtoom/2004-October/000049.html return UI From anthony at interlink.com.au Mon Oct 4 15:38:48 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Mon, 04 Oct 2004 23:38:48 +1000 Subject: [Shtoom] Re: Thanks for merging my code In-Reply-To: <1096889646.8204.8.camel@cwi.unispeed.dk> References: <1096669613.20400.21.camel@cwi.unispeed.dk> <415E2D21.6030507@interlink.com.au> <1096878739.6384.5.camel@cwi.unispeed.dk> <41610F51.8040905@interlink.com.au> <1096881761.6624.8.camel@cwi.unispeed.dk> <41612EC7.3030804@interlink.com.au> <1096889646.8204.8.camel@cwi.unispeed.dk> Message-ID: <41615268.6090603@interlink.com.au> Casper Wilstrup wrote: > Yes, but wouldn't the right place to do the sound substitution be > in the Playout code - the choice of which should probably also be > made configurable? Thinking about it more, it'd probably make sense to maybe make this a mixin. I'll put the '\0'*320 back for now, until I can find a nicer approach. > Another thing: I'd like to make a class which implements converting > entered urls in the dial entry to a real sip URL. This would be the > place future address book lookups should be performed, as well as > normalizing, eg. entering '600' becomes 'sip:600 at voip.unispeed.dk', the > domain being taken from the registrar URL. Would that be OK with you? Sounds like a fine idea. One future direction is figuring out a top-level API for address-book lookup - a first cut at this would be something like lookup(somestr) -> sip:whatever launch() -> launches an address book editor That way we don't have to try and right the world's greatest address book, but can instead offer platform-specific modules to handle the given AB. The nice thing here is that we can then hopefully get others to contribute the small amount of code to work with a particular address book. Anthony From anthony at interlink.com.au Mon Oct 4 16:27:05 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Tue, 05 Oct 2004 00:27:05 +1000 Subject: [Shtoom] what happens to stdout in text-mode UI? In-Reply-To: References: <6C35EC41-1600-11D9-A082-000A95E2A184@zooko.com> Message-ID: <41615DB9.2090308@interlink.com.au> A better solution is to make an option logfile, that captures the logging as well as (non-text UI) or instead of (text UI) the standard logging approach. I need to read twisted's logging to figure out how to do this. Anthony From anthony at interlink.com.au Mon Oct 4 16:47:59 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Tue, 05 Oct 2004 00:47:59 +1000 Subject: [Shtoom] what happens to stdout in text-mode UI? In-Reply-To: <41615DB9.2090308@interlink.com.au> References: <6C35EC41-1600-11D9-A082-000A95E2A184@zooko.com> <41615DB9.2090308@interlink.com.au> Message-ID: <4161629F.5020300@interlink.com.au> Anthony Baxter wrote: > A better solution is to make an option logfile, that captures > the logging as well as (non-text UI) or instead of (text UI) > the standard logging approach. I need to read twisted's logging > to figure out how to do this. shtoomphone now has a logfile option, as mentioned above. It seems to work. In addition, textshtoom no longer screws with stdout. Anthony From zooko at zooko.com Mon Oct 4 21:29:30 2004 From: zooko at zooko.com (zooko at zooko.com) Date: 4 Oct 2004 16:29:30 -0300 Subject: [Shtoom] patch: one way to fix logging on Mac Message-ID: For reasons entirely obscure to me, this fixes logging on Mac. Perhaps this shows that there is a bug in Twisted logging? HACK pion:~/playground/shtoom/darcsworld$ darcs diff -u --patch="setStdout" Mon Oct 4 16:26:44 ADT 2004 zooko at zooko.com * remove setStdout=False diff -rN -u darcsworld-old/Shtoom/shtoom/shtoom/app/phone.py darcsworld-new/Shtoom/shtoom/shtoom/app/phone.py --- darcsworld-old/Shtoom/shtoom/shtoom/app/phone.py 2004-10-04 16:28:40.000000000 -0300 +++ darcsworld-new/Shtoom/shtoom/shtoom/app/phone.py 2004-10-04 16:26:21.000000000 -0300 @@ -51,7 +51,7 @@ l = self.getPref('logfile') if l: open("shtoom.meta.log", "aU").write("about to log.startLogging(open(%s, 'aU'), setStdout=False)\n" % l) - log.startLogging(open(l, 'aU'), setStdout=False) + log.startLogging(open(l, 'aU')) BaseApplication.boot(self) def register(self): diff -rN -u darcsworld-old/Shtoom/shtoom/shtoom/ui/textshtoom.py darcsworld-new/Shtoom/shtoom/shtoom/ui/textshtoom.py --- darcsworld-old/Shtoom/shtoom/shtoom/ui/textshtoom.py 2004-10-04 16:28:40.000000000 -0300 +++ darcsworld-new/Shtoom/shtoom/shtoom/ui/textshtoom.py 2004-10-04 16:24:57.000000000 -0300 @@ -21,6 +21,6 @@ stdio.StandardIO(UI) if not app.getPref('logfile'): open("shtoom.meta.log", "aU").write("about to log.startLogging(sys.stdout, setStdout=False)\n") - log.startLogging(sys.stdout, setStdout=False) + log.startLogging(sys.stdout) return UI From cwi at unispeed.dk Tue Oct 5 21:52:21 2004 From: cwi at unispeed.dk (Casper Wilstrup) Date: Tue, 05 Oct 2004 21:52:21 +0200 Subject: [Shtoom] New PyAlsaAudio in svn Message-ID: <1097005941.23400.11.camel@cwi.unispeed.dk> Hi all. For those of you who are testing out alsa support in shtoom, I've just updated the code with Mixer support. Happy hacking. - Casper Wilstrup From zooko at zooko.com Thu Oct 7 00:15:35 2004 From: zooko at zooko.com (zooko at zooko.com) Date: 6 Oct 2004 19:15:35 -0300 Subject: [Shtoom] PT/CT refactoring Message-ID: Anthony: Good news! The PT/CT refactoring was straightforward, the result passes all three tests [*], and the result feels good to me and is easily compatible with my private patches. I'll submit patches soon. Regards, Zooko [*] 1. trial shtoom.test, 2. scripts/shreadder.py, 3. a call from my Linux PC to my Mac laptop From zooko at zooko.com Thu Oct 7 14:00:18 2004 From: zooko at zooko.com (zooko at zooko.com) Date: 7 Oct 2004 09:00:18 -0300 Subject: [Shtoom] patches: new RTPPacket style and RTP Extension hooks Message-ID: Here are three patches: "new RTPPacket style" http://zooko.com/cgi-bin/darcs.cgi/shtoom/zookobranch/?c=diff&p=20041007104344-92b7f-e2a932b9647aad89d62b38ff82fd85af888603ff.gz "cleanup -- build packets with RTPPacket() instead of struct.pack()" http://zooko.com/cgi-bin/darcs.cgi/shtoom/zookobranch/?c=diff&p=20041007104704-92b7f-27b3d00c7bbbb715aae6b24908868670add326c3.gz "hook for RTP extensions" http://zooko.com/cgi-bin/darcs.cgi/shtoom/zookobranch/?c=diff&p=20041007105006-92b7f-bf02966aa075d1cf5d1428d1dbd603dc8d9482e3.gz You can browse patches here: http://zooko.com/repos/ If you (Anthony) prefer I will e-mail these unified diffs to this list, or just push them into SVN and let you revert them if you don't want them. I use the darcs revision control tool [1]. It is fun to use darcs because it only takes a minute to get started, and you can mix-and-match patches freely from different repositories. For example, install darcs [2], then do: darcs get http://zooko.com/repos/shtoom/upstream/head/ Now you have a full darcs repository sitting in the "head" subdirectory of your current working directory. Now do: cd head ; darcs pull http://zooko.com/repos/shtoom/zookobranch and it will interactively prompt you asking if you want to pull the individual patches that are in zookobranch that aren't already in your local repository. You can likewise erase individual patches from your local repository. It's fun! Regards, Zooko [1] http://abridgegame.org/darcs/ [2] http://www.scannedinavian.org/DarcsWiki/CategoryBinaries From cwi at unispeed.dk Mon Oct 11 15:09:27 2004 From: cwi at unispeed.dk (Casper Wilstrup) Date: Mon, 11 Oct 2004 15:09:27 +0200 Subject: [Shtoom] Address book patch Message-ID: <1097500167.15808.5.camel@cwi.unispeed.dk> Hi all This patch contains my preliminary work on an address book for shtoomphone. #cd shtoom #patch -p1 < shtoomaddr.patch The patch contains the interfaces for address books, as well as a simple 'default' address book, which stores contact locally. Only the gnome gui allows editing the address book, while the qt and tk gui's will do lookups. If you (Anthony) accepts this patch, you can either commit it to svn, or let me do it - you decide. My next steps will be to implement the address book editor in some of the other GUI's, and maybe start work on an Evolution address book (I use Evolution for mail and contacts) Happy hacking /Casper -------------- next part -------------- A non-text attachment was scrubbed... Name: shtoomaddr.patch Type: text/x-patch Size: 55070 bytes Desc: not available URL: From anthony at interlink.com.au Mon Oct 11 18:46:26 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Tue, 12 Oct 2004 02:46:26 +1000 Subject: [Shtoom] Address book patch In-Reply-To: <1097500167.15808.5.camel@cwi.unispeed.dk> References: <1097500167.15808.5.camel@cwi.unispeed.dk> Message-ID: <416AB8E2.9010507@interlink.com.au> Casper Wilstrup wrote: > Hi all > > This patch contains my preliminary work on an address book for > shtoomphone. Wow! That's very cool. Go ahead and check it in. Once 2.4b1 is out (hopefully this week) I'll have a look at it closer, but it seems pretty good to me. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From cwi at unispeed.dk Mon Oct 11 20:53:51 2004 From: cwi at unispeed.dk (Casper Wilstrup) Date: Mon, 11 Oct 2004 20:53:51 +0200 Subject: [Shtoom] Address book support added Message-ID: <1097520831.17501.10.camel@cwi.unispeed.dk> Hi shtoom'ers I've just checked address book support into svn. Check it out from the gnome GUI. Support in the other Linux GUI's is on the way. The design is interface based, so it should be easy to develop extra address books. Just add a file implementing the AddressBook interface. To edit your address book, click on the '...' button next to the address entry in the gnome GUI. Click the '+' button, and add entries. To dial an entry in your address book, just type 'addr:friend' and click 'Call', the nickname 'friend' is automatically looked up in the address book, and the address is substituted by the sip address of 'friend'. The prefix 'addr:' can be ommitted. It just indicates that the address is from the default address books. Future address book implementations should select their own prefix, like 'ldap:', 'evo:' and the like. I will do the following, before leaving the address book project: 1. Implement the address book GUI in 'wxwindows', 'qt', and 'tkinter' 2. Write an evolution address book. Volunteers who would like to add support in the windows and mac GUI's are more than welcome. Also developing address books for your favorite application would be cool. And obviously, bug reports are more than welcome too. /Casper From zooko at zooko.com Fri Oct 22 15:58:26 2004 From: zooko at zooko.com (zooko at zooko.com) Date: 22 Oct 2004 10:58:26 -0300 Subject: [Shtoom] bug report: wxShtoom call setup confused Message-ID: See BUGS.txt: http://zooko.com/cgi-bin/darcs.cgi/shtoom/upstream/head/Shtoom/shtoom/doc/BUGS.txt?c=annotate&p=20041022135528-92b7f-99840b89db5706b37ced85289bf61d61def3414d.gz Here is text of new bug report: name: wxShtoom call setup confused to reproduce: run shtoom with wx GUI, call it from another shtoom details: wx Shtoom opens audio channel before user decides whether to accept or decline call; exceptions in log more details: I've spent way too many hours trying to fix this without success. You are more than welcome to see my patches, but they don't fix it properly -- after my patches audio channel doesn't get opened prematurely, but there is an exception with cookie=None passed to the acceptedCall() callback, so the call never starts at all. Regards, Zooko From zooko at zooko.com Fri Oct 22 17:22:56 2004 From: zooko at zooko.com (zooko at zooko.com) Date: 22 Oct 2004 12:22:56 -0300 Subject: [Shtoom] investigation of call acceptance confusion Message-ID: I think I understand the first part of what is wrong in call accept state machine. Maybe if I post my hypothesis here then Anthony or someone can fill in the blanks and fix it. If you look in phone.acceptCall() it says 'd = self._createRTP()'. That d is a deferred which is going to be triggered when the sockets are connected and any STUN has been completed. A few lines later in acceptCall(), if calltype == 'inbound', it says 'self.ui.incomingCall(..., ..., d)'. Now this is Just Wrong! The last argument to self.ui.incomingCall is a deferred which the UI object can use to signal to the app object whether to accept the call or not. By passing d here, then when the user clicks "accept call", the same thing will happen as when the STUN discovery completes! That's not right. And if the user clicks "reject", then same thing will happen as if there were an unhandled exception in our STUN and RTP code. :-) This problem is not specific to the wx UI, although it is definitely related to the other problems with the wx UI. It would have been easier for me to figure this stuff out if we weren't using errbacks to mean "user clicked reject". We could pass a boolean as the argument to the deferred: True means the user said accept, False means the user said reject. Regards, Zooko From zooko at zooko.com Mon Oct 25 14:44:09 2004 From: zooko at zooko.com (zooko at zooko.com) Date: 25 Oct 2004 09:44:09 -0300 Subject: [Shtoom] bug report: media port off by 2 error Message-ID: http://zooko.com/cgi-bin/darcs.cgi/shtoom/zookobranch/Shtoom/shtoom/doc/BUGS.txt?c=annotate&p=20041025121431-92b7f-7d10512cb7ac9756fccad4b4f0c81c71e0b63235.gz name: media port off by 2 error to reproduce: run Shtoom behind NAT, let it use STUN to discover externally-visible port numbers details: the port numbers returned by STUN are the port numbers Shtoom listens on, but the port numbers it puts in the "media" line in SDP are +2 more details: I discovered this while trying to demo a Shtoom-derived product. I worked-around it by telling the other UA to subtract 2 from the RTP port in the SDP. This worked, enabling the other UA to send media packets to the behind-NAT-Shtoom.