From morgan at mcode.co.za  Wed Mar  2 16:21:40 2005
From: morgan at mcode.co.za (Morgan Collett)
Date: Wed, 02 Mar 2005 17:21:40 +0200
Subject: [Shtoom] shtoom through NAT
Message-ID: <4225DA04.20608@mcode.co.za>

I'm trying to get shtoom working on Ubuntu with Dafydd Harries's package.

shtoominfo tells me this:
 
Shtoom, version 0.3alpha0
Using python version 2.4.1a0
Using twisted version 1.3.0rc1
Running on Linux i686 2.6.10-4-686
Available audio interfaces: ossaudio, fileaudio, alsaaudio
Available user interfaces: text, wx, tk, gnome
Available codecs: speex, gsm, mulaw
Local IP address: 192.168.1.120
No UPnP-capable device discovered
STUN says NAT type: Symmetric
You will need to use an outbound proxy to make calls to the internet
And the mapper we'd use is: <shtoom.nat.NullMapper instance at 0xb7925b4c>

My ADSL gateway runs a one-line ipchains masquerading setup. What is 
this outbound proxy thing then? Or is there a better firewall setup to handle this traffic?

Thanks,
Morgan



From smadim2 at grads.ece.mcmaster.ca  Wed Mar  2 19:01:20 2005
From: smadim2 at grads.ece.mcmaster.ca (M.N.A.Smadi)
Date: Wed, 02 Mar 2005 13:01:20 -0500
Subject: [Shtoom] REFER method
Message-ID: <4225FF70.1020807@grads.ece.mcmaster.ca>

hi;
any body thought of implementing the REFER method?

smadi


From smadim2 at grads.ece.mcmaster.ca  Thu Mar  3 02:59:00 2005
From: smadim2 at grads.ece.mcmaster.ca (M.N.A.Smadi)
Date: Wed, 02 Mar 2005 20:59:00 -0500
Subject: [Shtoom] playout delay
Message-ID: <42266F64.9030207@grads.ece.mcmaster.ca>

hi;

i have several sip clients (HW and SW) on my network), there is a 
noticeable playout delay in shtoom, anybody know why?

thanks
m.smadi


From zooko at zooko.com  Thu Mar  3 12:27:38 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Thu, 3 Mar 2005 07:27:38 -0400
Subject: [Shtoom] playout delay
In-Reply-To: <42266F64.9030207@grads.ece.mcmaster.ca>
References: <42266F64.9030207@grads.ece.mcmaster.ca>
Message-ID: <4430c2af9c0dd5bd063adc7d3ad6c073@zooko.com>

> i have several sip clients (HW and SW) on my network), there is a 
> noticeable playout delay in shtoom, anybody know why?

Hello!

Are you sure it is audio playout delay and not microphone readin delay?

What platform is Shtoom running on?

--Z



From anthony at interlink.com.au  Thu Mar  3 14:20:08 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri, 4 Mar 2005 00:20:08 +1100
Subject: [Shtoom] shtoom through NAT
In-Reply-To: <4225DA04.20608@mcode.co.za>
References: <4225DA04.20608@mcode.co.za>
Message-ID: <200503040020.09402.anthony@interlink.com.au>

On Thursday 03 March 2005 02:21, you wrote:
> I'm trying to get shtoom working on Ubuntu with Dafydd Harries's package.

> STUN says NAT type: Symmetric
> You will need to use an outbound proxy to make calls to the internet
> And the mapper we'd use is: <shtoom.nat.NullMapper instance at 0xb7925b4c>

> My ADSL gateway runs a one-line ipchains masquerading setup. What is
> this outbound proxy thing then? Or is there a better firewall setup to
> handle this traffic?

Symmetric NATs are a pain. As the output says, you'll need to use an outbound
proxy. A number of providers run these - for instance, FWD, divmod and 
stanaphone all have them. To use it with, for instance, FWD, set the outbound
proxy setting to 	fwdnat.pulver.com:5082

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From anthony at interlink.com.au  Thu Mar  3 14:23:52 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri, 4 Mar 2005 00:23:52 +1100
Subject: [Shtoom] shtoom through NAT
In-Reply-To: <200503040020.09402.anthony@interlink.com.au>
References: <4225DA04.20608@mcode.co.za>
	<200503040020.09402.anthony@interlink.com.au>
Message-ID: <200503040023.53379.anthony@interlink.com.au>

On Friday 04 March 2005 00:20, Anthony Baxter wrote:
> Symmetric NATs are a pain. As the output says, you'll need to use an
> outbound proxy. A number of providers run these - for instance, FWD, divmod
> and stanaphone all have them. To use it with, for instance, FWD, set the
> outbound proxy setting to 	fwdnat.pulver.com:5082

I should also add that the other way to deal with symmetric NATs is to 
enable UPnP on them. I'm not sure about the state of UPnP on Linux - 
at some point, I plan to write a small UPnP server (in Python) which will
have hooks to call out to the relevant programs to actually do the port
forwarding...


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From daf at muse.19inch.net  Thu Mar  3 14:28:16 2005
From: daf at muse.19inch.net (Dafydd Harries)
Date: Thu, 3 Mar 2005 13:28:16 +0000
Subject: [Shtoom] shtoom through NAT
In-Reply-To: <200503040023.53379.anthony@interlink.com.au>
References: <4225DA04.20608@mcode.co.za>
	<200503040020.09402.anthony@interlink.com.au>
	<200503040023.53379.anthony@interlink.com.au>
Message-ID: <20050303132816.GE25737@muse.19inch.net>

Ar 04/03/2005 am 00:23, ysgrifennodd Anthony Baxter:
> On Friday 04 March 2005 00:20, Anthony Baxter wrote:
> > Symmetric NATs are a pain. As the output says, you'll need to use an
> > outbound proxy. A number of providers run these - for instance, FWD, divmod
> > and stanaphone all have them. To use it with, for instance, FWD, set the
> > outbound proxy setting to 	fwdnat.pulver.com:5082
> 
> I should also add that the other way to deal with symmetric NATs is to 
> enable UPnP on them. I'm not sure about the state of UPnP on Linux - 
> at some point, I plan to write a small UPnP server (in Python) which will
> have hooks to call out to the relevant programs to actually do the port
> forwarding...

So UPnP is the sanest of the available NAT-punching protocols?

In which cases does Shtoom need to be able to accept incoming
packets? Are these packets TCP or UDP or both?

-- 
Dafydd


From anthony at interlink.com.au  Thu Mar  3 14:38:54 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri, 4 Mar 2005 00:38:54 +1100
Subject: [Shtoom] shtoom through NAT
In-Reply-To: <20050303132816.GE25737@muse.19inch.net>
References: <4225DA04.20608@mcode.co.za>
	<200503040023.53379.anthony@interlink.com.au>
	<20050303132816.GE25737@muse.19inch.net>
Message-ID: <200503040038.55819.anthony@interlink.com.au>

On Friday 04 March 2005 00:28, Dafydd Harries wrote:
> So UPnP is the sanest of the available NAT-punching protocols?

I wouldn't call UPnP "sane" in any sense of the word. It's certainly the
easiest, tho.

> In which cases does Shtoom need to be able to accept incoming
> packets? Are these packets TCP or UDP or both?

UDP. Unfortunately, it's UDP on dynamically allocated ports. If you
have anything _but_ a symmetric NAT, shtoom does sufficient magic
to enable it to just work, without having to change anything(*). UPnP 
allows shtoom to tell the NAT what ports it needs punched down, on the
fly. 

There's a fair amount of text on this issue in an appendix to the paper I 
presented at OSDC2004 - see 
http://www.interlink.com.au/anthony/tech/talks/OSDC/shtoom-paper.txt

(*) There's an issue with communications between two people who are both 
behind RestrictedCone-style NATs - I have a workaround planned for these,
but it's awaiting some round-tuits to do the work. For now, UPnP or an 
outbound proxy work best for these.


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From anthony at interlink.com.au  Thu Mar  3 16:05:03 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri, 4 Mar 2005 02:05:03 +1100
Subject: [Shtoom] anyone interested in helping work on a UPnP server?
Message-ID: <200503040205.05770.anthony@interlink.com.au>

Hey there,

I want to look at extending shtoom's UPnP support to create a UPnP server for
Linux &c. I can do the work for the UPnP side, but I'm not particularly clear 
on the commands needed to insert the relevant ipchains or whatever rules.
If you're up on this stuff, and want to help out, drop me an email.

Thanks,
Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From anthony at interlink.com.au  Thu Mar  3 18:38:49 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Fri, 4 Mar 2005 04:38:49 +1100
Subject: [Shtoom] REFER method
In-Reply-To: <4225FF70.1020807@grads.ece.mcmaster.ca>
References: <4225FF70.1020807@grads.ece.mcmaster.ca>
Message-ID: <200503040438.51489.anthony@interlink.com.au>

On Thursday 03 March 2005 05:01, M.N.A.Smadi wrote:
> hi;
> any body thought of implementing the REFER method?

Thought about it - the problem is that the existing implementation of 
SIP in shtoom is very much a prototype, and needs to be massively
refactored before adding new things like REFER could be done in 
any sane way. This is planned for the 0.4 release.

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From smadim2 at grads.ece.mcmaster.ca  Fri Mar  4 21:37:05 2005
From: smadim2 at grads.ece.mcmaster.ca (M.N.A.Smadi)
Date: Fri, 04 Mar 2005 15:37:05 -0500
Subject: [Shtoom] cli
Message-ID: <4228C6F1.8080207@grads.ece.mcmaster.ca>

hi;

is there an easy way to pass an already registered shtoom client and 
argument containing a phone number from another program?

thanks
m.smadi


From zooko at zooko.com  Thu Mar 17 17:24:08 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Thu, 17 Mar 2005 12:24:08 -0400
Subject: [Shtoom] about patch dependencies
Message-ID: <716fdb6a6927bdffd5f6b59938a428b2@zooko.com>

I asked darcs which of the patches I've offered for inclusion in Shtoom 
are required for the clean application of the "rewrute of the 
microphone" patch.  It answered thusly:

I suggest we start at the oldest one.  If you, Anthony, will accept the 
"move some tests" patch, then do so first, else I will unroll that one 
and regenerate the other ones without that one.

etc.


Mon Feb 28 16:19:13 AST 2005  zooko at zooko.com
   * rewrite of the microphone -> encoder -> RTPstream channel
    * Microphone samples are asynchronously pushed up by the lower 
layers rather than being polled by the upper layers.  On Mac, the 
high-precision realtime thread is use
d to push microphone samples.  This fixes a bug with short reads and a 
bug with inaccurate polling.  On ALSA, there is a LoopingCall in the 
ALSA driver that polls at an
appropriate interval.
    * The encoder base class has a buffer to store up the appropriate 
bytes of microphone data to make up a media frame.  This buffer gets 
flushed when the audio device c
loses or reopens.
    * The audio device gets closed and reopened during important state 
transitions, namely call start and call end.  This fixes the "That 
jerk!" bug, in which you could s
ay "I have to call that jerk!" immediately before a call connected and 
then the jerk in question would hear you say it when he answered.
    * Remove some extremely detailed diags that measured the number of 
packets sent per second and the number of packets received per second.  
Those diags have served wel
l and are now retired.
    * The Mac audio loopback test is rewritten, and a bug involving 
closing the loopback test versus closing a phone call is fixed.
    * The discovery/selection of the appropriate audio device is done 
before the construction of the Phone object.  This makes the other 
platforms' initialization process
  parallel to the Mac initialization process, and also I prefer this 
approach.  (The other approach is that you construct the Phone object 
and then it discovers/selects t
he audio device itself.)


Mon Feb 28 12:37:54 AST 2005  zooko at zooko.com
   * fix bug: closing already closed ALSA device works now

Mon Feb 28 12:18:52 AST 2005  zooko at zooko.com
   * replace audiodevice.isClosed() with audiodevice.isOpen()
   It sometimes helps to reduce the number of logical nots.  Also I 
recently found a bug in which someone had reversed the sense of 
"alsa.isClosed()".


Fri Feb 25 17:03:25 AST 2005  zooko at zooko.com
   * new playout algorithm

Fri Feb 25 16:20:44 AST 2005  zooko at zooko.com
   * play ring.wav on incoming call and play ringback.wav on outgoing 
ring

Fri Feb 25 14:48:46 AST 2005  zooko at zooko.com
   * fix alsa audio to do the "isClosed()" method properly

Fri Feb 25 15:55:58 AST 2005  zooko at zooko.com
   * fix bug in which the value of Mac audio isClosed() was reversed

Fri Feb 25 12:03:26 AST 2005  zooko at zooko.com
   * move some tests from test/ to livetest/



From zooko at zooko.com  Mon Mar 21 20:05:17 2005
From: zooko at zooko.com (Zooko O'Whielacronx)
Date: Mon, 21 Mar 2005 15:05:17 -0400
Subject: [Shtoom] how to test doug and DTMF
Message-ID: <cbcae320c113312b1b60b076ebac62e5@zooko.com>

I've done some refactoring work, and I wonder how to tell whether the 
end result has broken doug and DTMF.  Obviously I know how to run the 
unit tests, but are there any other tests I should run in addition to 
those?  I don't use these features normally so I don't know how to 
exercise them other than running the unit tests.

Thanks,

Zooko



From Adrien.DiMascio at logilab.fr  Wed Mar 23 15:02:07 2005
From: Adrien.DiMascio at logilab.fr (Adrien Di Mascio)
Date: Wed, 23 Mar 2005 15:02:07 +0100
Subject: [Shtoom] Small fixes
Message-ID: <20050323140207.GA7058@logilab.fr>

Hi there,

I've been playing with Shtoom these last days, and I had to make some
minor fixes (typos and al.) to make it work with our app.

I've attached a diff file to this mail that enumerates my changes. I'm
pretty sure that I didn't always fix things in the right way,
but I guess it will at least point out some errors in the code.

Thanks for developing Shtoom !

Cheers,
Adrien.

-- 
Adrien Di Mascio
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr   http://www.logilab.org

-------------- next part --------------
Index: test/test_callcontrol.py
===================================================================
--- test/test_callcontrol.py	(revision 1272)
+++ test/test_callcontrol.py	(working copy)
@@ -90,7 +90,7 @@
         if TDEBUG: print "callFailed", self.cookie
 
     def cb_callConnected(self, cookie):
-        if TDEBUG: print "callConnected", self.cookie
+        if TDEBUG: print "callConnected", cookie
         self.actions.append(('connected',cookie))
 
     def callDisconnected(self, cookie, reason):
Index: app/phone.py
===================================================================
--- app/phone.py	(revision 1272)
+++ app/phone.py	(working copy)
@@ -88,7 +88,7 @@
             # Otherwise we chain callbacks
             ringingCommand = self.getPref('ringing_command')
             # Commented out until I test it
-            if 0 and ringingCommand:
+            if ringingCommand:
                 from twisted.internet import reactor
                 args = ringingCommand.split(' ')
                 cmdname = args[0]
Index: app/base.py
===================================================================
--- app/base.py	(revision 1272)
+++ app/base.py	(working copy)
@@ -35,7 +35,7 @@
     def getPref(self, pref):
         if self._options.hasValue(pref):
             return self._options.getValue(pref, None)
-
+    
     def updateOptions(self, dict, forceSave=False):
         m = self._options.updateOptions(dict)
         if m or forceSave:
Index: app/doug.py
===================================================================
--- app/doug.py	(revision 1272)
+++ app/doug.py	(working copy)
@@ -42,17 +42,18 @@
             pass
         elif not self.getPref('logfile'):
             print "logging to stdout"
-            log.startLogging(sys.stdout)
+            # FIXME: Do we really want to force stdout to be catched by log ?
+            log.startLogging(sys.stdout, setStdout=False)
         else:
             file = open(self.getPref('logfile'), 'aU')
             #print "logging to file", file
-            log.startLogging(file)
+            # FIXME: Do we really want to force stdout to be catched by log ?
+            log.startLogging(file, setStdout=False)
         BaseApplication.boot(self)
 
     def start(self):
         "Start the application."
         from twisted.internet import reactor
-        import sys
         vargs = self.getPref('dougargs')
         if vargs:
             kwargs = [x.split('=') for x in vargs.split(',') ]
@@ -76,7 +77,7 @@
             v.va_start()
         except:
             ee,ev,et = sys.exc_info()
-            log.err("voiceapp error", ee, ev, traceback.extract_tb(et))
+            log.err("voiceapp error %s, %s, %s" % (ee, ev, traceback.extract_tb(et)))
             v = None
         if v:
             log.msg("new voiceapp %r"%(v), system='doug')
Index: sip.py
===================================================================
--- sip.py	(revision 1272)
+++ sip.py	(working copy)
@@ -407,7 +407,7 @@
         ''' Accept currently pending call.
         '''
         log.msg("rejecting because %r"%(response,), system='sip')
-        if hasattr(response, sipCode):
+        if hasattr(response, 'sipCode'):
             code = response.sipCode
         else:
             code = 603
Index: doug/voiceapp.py
===================================================================
--- doug/voiceapp.py	(revision 1272)
+++ doug/voiceapp.py	(working copy)
@@ -76,7 +76,11 @@
     def va_callrejected(self, leg=None):
         if leg is None:
             leg = self._inbound
-        self.__legs.remove(leg)
+        # self.__legs.remove(leg)
+        try:
+            del self.__legs[leg]
+        except KeyError:
+            print "Key %r not in self.__legs, can't remove it" % leg
         self._triggerEvent(CallRejectedEvent(leg))
 
     def va_abort(self):
Index: ui/gnomeui/prefs.py
===================================================================
--- ui/gnomeui/prefs.py	(revision 1272)
+++ ui/gnomeui/prefs.py	(working copy)
@@ -56,7 +56,7 @@
 
         self.tooltips = gtk.Tooltips()
 
-        notebook = gtk.Notebook(spacing=8)
+        notebook = gtk.Notebook() # spacing=8
         notebook.set_border_width(4)
         self.dialog.vbox.set_border_width(4)
         self.dialog.vbox.pack_start(notebook)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050323/79538a49/attachment.pgp>

From fschiwek at eurodns.com  Thu Mar 24 17:11:40 2005
From: fschiwek at eurodns.com (Frederick SCHIWEK)
Date: Thu, 24 Mar 2005 17:11:40 +0100
Subject: [Shtoom] looking for a nicely working softphone
Message-ID: <CCCE2F3248C28044996B41CC35FA474FF85F7C@dclux1.dclux.lu>

Hi, is there someone that has shtoom stable?

I am looking for a softphone to serve it as a free download on the
website voipgate.com

Would pay for modifications.

 

Best regards,

 

Frederick Schiwek

fschiwek at voipgate.com <mailto:fschiwek at voipgate.com> 

www.voipgate.com <http://www.voipgate.com/> 

41 z.a. Am Bann

L-3372 Leudelange

Luxembourg

 

Luxembourg: +352 261916-38

Germany: 0180 5236275

Belgium: +32 (0)80 503005

USA: +1 360 2275688

UK: +44 (0)20 70438288

Fax: +352 26202996

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050324/81af344b/attachment.htm>

From anthony at interlink.com.au  Mon Mar 28 10:27:07 2005
From: anthony at interlink.com.au (Anthony Baxter)
Date: Mon, 28 Mar 2005 19:27:07 +1100
Subject: [Shtoom] Small fixes
In-Reply-To: <20050323140207.GA7058@logilab.fr>
References: <20050323140207.GA7058@logilab.fr>
Message-ID: <200503281827.08637.anthony@interlink.com.au>


Thanks! I've applied most of these fixes to the trunk. The ones I've not
committed are:

   I've left the if 0 in the ringingCommand code. I'm deeply unhappy with 
how this is currently implemented, and plan to fix this to use the normal 
audio playout in the future. It's there for a couple of people who really 
wanted it, but chances are it will behave incorrectly more often than not,
hence leaving it disabled. 

  I've also left the code in that keeps stdout going to the log. I don't like
having two sets of output (log and stdout) and so prefer to have this work
in the current way.


-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.


From Adrien.DiMascio at logilab.fr  Mon Mar 28 17:27:57 2005
From: Adrien.DiMascio at logilab.fr (Adrien Di Mascio)
Date: Mon, 28 Mar 2005 17:27:57 +0200
Subject: [Shtoom] Small fixes
In-Reply-To: <200503281827.08637.anthony@interlink.com.au>
References: <20050323140207.GA7058@logilab.fr>
	<200503281827.08637.anthony@interlink.com.au>
Message-ID: <20050328152757.GA26622@crater.logilab.fr>

Hi,

On Mon, Mar 28, 2005 at 07:27:07PM +1100, Anthony Baxter wrote:
> 
> Thanks! I've applied most of these fixes to the trunk. The ones I've not
> committed are:
[...]
 
>   I've also left the code in that keeps stdout going to the log. I don't like
> having two sets of output (log and stdout) and so prefer to have this work
> in the current way.

I understand. I had made this because we were directly using the
DougApplication in our application, and we didn't want to merge both
logs.

Another question : is there any plan to make a WAV Codec
implementation ?

Thanks again.

Cheers,
Adrien.

-- 
Adrien Di Mascio
LOGILAB, Paris (France).
http://www.logilab.com   http://www.logilab.fr   http://www.logilab.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/shtoom/attachments/20050328/d3b9657a/attachment.pgp>