Date: Sun, 28 Nov 1999 01:20:59 +0000 (GMT) From: Andrew Gordon <arg@arg1.demon.co.uk> To: Roger Hardiman <roger@cs.strath.ac.uk> Cc: isdn@freebsd.org Subject: Re: Help - I need a login shell over my ISDN line Message-ID: <Pine.BSF.4.21.9911280048590.5545-100000@server.arg.sj.co.uk> In-Reply-To: <383FCB8A.41C6@cs.strath.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 27 Nov 1999, Roger Hardiman wrote: > > In my case I am making a 'digial' data call from my Mobile > Phone and I set the Mobile Phone from "dialing an anlogue > modem/fax" to "dialing an ISDN line" mode. > Next week I'll get hold of a new GSM Phone (HSCSD) which > supports 42kbits speeds. These _only_ talk to ISDN lines > as they do not support any audio modulation. Note however that none of this is ever "end-to-end" ISDN. You are always running a GSM protocol over the wireless link, which implements a bytestream (or bitstream if synchronous mode), and then connects to a modem or TA at the MSC. > Sorry for being ignorant to V.110 and V.120, but > are these the protocols for negotiating the connection > speeds for a digital connection. These are 'rate adaption' protocols, for transferring data between RS232 (V.24) ports on the terminal adaptors, in the case where the data rate is not the same as that of the B channel. V.110 simply involves stuffing extra bits into an async data stream to make it come out at the right rate; officially, it only permits low speeds (max 19200 IIRC), but I have seen implementations (not strictly conformant) that use the same scheme up to 38400 bps. V.120 packetizes the data, and transmits it over the B channel in HDLC frames, with packet-level flow control and optional error protection. > Ie would these be used for my Mobile Phone to tell my > ISDN hardware that the phone onlu supports 9600 and not > the fill 64kbits? In effect, yes. These are the protocols used inside the B channel to actually perform the rate adaption; the fact that you are using (say) V.120 rate adaption can be signalled in the call setup protocols on the D channel. From an I4B point of view, the hard part is not implementing the protocols themselves, but the infrastructure to support them: Rec. V.120 itself is only 36 pages, and the code to do HDLC over the B channel already exists for other other purposes in I4B. The major stuff to write is the tty handling, call set-up control etc. In BISDN, there was a skeleton of this, doing all the work in the kernel. However, it occurs to me that you might be able to save a lot of work by doing it as a daemon: you can get all the tty stuff by sitting on the back end of a pty, and you can probably get most of the ISDN interface out of the RBCH stuff that /usr/sbin/ppp has recently started using: it needs to do much the same work (exchanging HDLC frames over the B channel, dialling calls etc.). One thing I am not sure of is whether /usr/sbin/ppp is able to accept incoming ISDN calls (I haven't been following that work too closely). If it does, then all the interfaces you need are there to drop in a V.120 daemon. 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?Pine.BSF.4.21.9911280048590.5545-100000>