Date: Sun, 25 Nov 2001 17:06:39 +0000 (GMT) From: Andrew Gordon <arg-bsd@arg1.demon.co.uk> To: Leif Neland <leifn@neland.dk> Cc: <freebsd-isdn@freebsd.org> Subject: Re: bidirectional /dev/i4btel0 ? Message-ID: <20011125163647.E42138-100000@server.arg.sj.co.uk> In-Reply-To: <200111231519.fANFJep38061@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 23 Nov 2001, Gary Jennejohn wrote:
> On Friday 23 November 2001 13:04, Leif Neland wrote:
> > Is it somehow possible to both be sending and recieving from
> > /dev/i4btel0?
> >
> > I would like to send voice to the caller, while also recieving
> > data, eventually decoding with dtmfdecode to make a
> > voice-response system.
> >
> > dd of=${DEVICE} if=${LIBDIR}/leifans.al bs=2k >/tmp/out.log
> > 2>&1 & sleep 2
> > dd if=${DEVICE} of=/tmp/answers.al bs=2k count=100
> > >/tmp/in.log 2>&1
Doing this with two independent processes is never going to work usefully,
due to the need to synchronize the transmit with the receive (eg. you want
the outgoing message to stop and switch to the next action immediately on
decoding a DTMF key, not some seconds later).
However, even with a single process (or coordination between send/receive)
there are not currently sufficient mechanisms in the i4btel driver to
control the buffering.
I am doing some work in this area - I'm mainly working on V.110, but it
also uses raw (non-HDLC) mode on the B channel and so suffers from the
same latency issues. After some discussion at BSDCon, I was planning to
sort out the telephony issues first, but it turned out slightly more
tricky than I first thought, so it isn't done yet.
> > Would it be possible for a single program to open the device
> > for reading and writing simultaneously?
>
> Right now the tel device is exclusive open, so only one process
> at a time can have it open. However, I don't see anything which
> would indicate that opening it RW would fail.
>
> However, the way that i4btelread and i4btelwrite are implemented
> it doesn't look like simultaneous reads and writes are possible.
> The kernel puts the process to sleep while waiting either to
> receive or send the data, so the process can only be doing one
> of the two at any given time.
It ought to be possible using select() [or poll(), according to taste]
such that you never block in read() or write().
In my first V.110 experimental code, I used select() on the read side
only, and then transmitted exactly the number of bytes that I had just
received: given that the transmit and receive run from the same clock,
this guarantees that the transmit buffer will never fill.
isdnphone(8) similarly uses select() on the receive sides, but in this
case there is the problem that the two sources (ISDN vs. sound card) have
different clocks: the network clock for ISDN is probably quite accurate,
but the oscillators on cheap sound cards will not be. Hence you would
expect over time for one of the transmit buffers (ISDN or soundcard) to
overflow and the other one to run dry. I haven't used isdnphone to see if
this is a problem in pracice: from a theoretical analysis, the clocks
might be expected to be somewhere between 30ppm-100ppm in error, so at
64Kbit/sec you would expect the buffers to fill up at a rate of 0.24 to
6.4 bits/sec, or 0.24 to 0.8 bytes/sec, which would add up to a whole mbuf
full after 42 seconds in the worst case.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011125163647.E42138-100000>