[MLB-WIRELESS] Free P2P phones will pressure telcos

[Ryan Abbenhuys]

Mainly technical but a bit of marketing doesn't hurt.

Keep in mind that there's a mixture of people at meetings from geeks who
want to know about encoding, bitrates, the underlying technology, etc, to
average people who just want to know what it does and how much it costs.

Is this something that would operate independant of the internet?  Would it
be possible to setup a private server on the wireless network to use the
devices?

----- Original Message ----- 
From: "Damian Halloran" <damian at phit.com.au>
To: <sneeze at ALPHALINK.COM.AU>
Cc: <melbwireless at wireless.org.au>
Sent: Wednesday, November 12, 2003 10:38 PM
Subject: Re: [MLB-WIRELESS] Free P2P phones will pressure telcos


> Yes we would be interested.  Please let me know available dates and
> I'll organise to be there with the director of the company.  How
> technically focussed (as opposed to marketing hype) should the
> presentation be?
>
> Thanks
>
> Damian Halloran.
> On 12/11/2003, at 10:25 PM, Ryan Abbenhuys wrote:
>
> > Would yourself or a representative from your company be interested in
> > giving a presentation at a Melbourne Wireless meeting at some stage
> > perhaps?  Followed up with a TIB deal for those interested?
> >
> >
> >> So that I'm not howled down by all and sundry this is a FYI post not a
> >> "shameless" plug.
> >>
> >> I work for a company who distribute IP telephony units aimed at the
> >> home user.  These units work through the USB port of Windows (only -
> >> damn) computers and even though they come with their own software they
> >> work with Skype.
> >>
> >> With the supplied software all units generate their own ring and dial
> >> tones, have an international prefix for telephone numbers,  and are
> >> registered with a central server in Taiwan.  We've tested them with
> >> broadband as well as dial-up and in both cases I would give the
> >> quality
> >> of the call an 8 (if PSTN is the benchmark of 10).  Making calls is
> >> simply a case of picking up the handset and dialling.
> >>
> >> They come in three flavours: A PSTN/IP phone model that allows you to
> >> connect an analogue handset to it, as well as a PSTN line.  Nothing
> >> really fancy about this unit but you can attach a cordless analogue
> >> handset to it, and attach it to a PABX for incoming and outgoing IP
> >> telephone calls.
> >>
> >> The next model is a handset type for your travelling person.
> >>
> >> The third model has all the same features as the first, but it also
> >> allows call hop off so you can call from the IP network to PSTN and
> >> vice versa, and call forwarding features.  We've tested call
> >> forwarding
> >> to PSTN and mobile telephones and again the quality is about 8.
> >>
> >> The only costs associated is the hardware, they don't charge for the
> >> calls.
> >>
> >> The only downside is that it is a "closed" network, ie you can only
> >> ring another one of the units.
> >>
> >> So that it doesn't come across as a plug I'll leave out the name of
> >> the
> >> equipment, and supplier.  If people do want more info you can e-mail
> >> me
> >> off-list.
> >>
> >> Regards,
> >>
> >> Damian Halloran.
> >>
> >>
> >> On 12/11/2003, at 4:06 PM, Tony Langdon wrote:
> >>
> >>>> Well, it would partly work, but you wouldn't be able to dial
> >>>> (afaik) as the
> >>>> soundcard input doesn't detect DTMF (afaik). You'd still need
> >>>> to dial via
> >>>> the software phone.
> >>>
> >>> Hmm, perhaps the IRLP style approach (but with phone handsets and
> >>> hardware
> >>> based line simulators, instead of radios) is the way to setup a VoIP
> >>> IP
> >>> ohone network.  The idea is actually quite simple in concept.
> >>>
> >>> 1.  Define a numbering scheme.  This can be a simple "flat" scheme
> >>> like ICQ
> >>> (basically the ham VoIP apps work this way), or something more
> >>> complex
> >>> using
> >>> international prefixes and the like.  I prefer KISS, we're not
> >>> billing
> >>> here.
> >>> :-)
> >>>
> >>> 2.  Setup some form of address resolution.  This could use DNS
> >>> (12345.freeipphone.org, etc), or some specialised server based scheme
> >>> (the
> >>> ham systems have their own schemes for address resolution).
> >>>
> >>> 3.  Define some sort of hardware interface to connect the phone to
> >>> the
> >>> PC.
> >>> The interface would need to generate ring voltage (80V AC -
> >>> oscillator,
> >>> audio power amp and a transformer should do), and all the necessary
> >>> voltages
> >>> and signalling to make an ordinary POTS handset work.  The interface
> >>> could
> >>> also include a DTMF decoder chip so it can perform this function as
> >>> well.
> >>> Alternatively, you could write this function into the software (I
> >>> have
> >>> seen
> >>> both approaches used, but the hardware one works best).  Hardware
> >>> decoding
> >>> also makes it easy to script in special functionity that can be
> >>> accessed
> >>> whenever the phone is off hook, regardless of whether it's on a call
> >>> or not
> >>> (a la IRLP).
> >>>
> >>> 3.  Start with some existing piece of open source software.  Hack it
> >>> to work
> >>> with the above interface for call establishment and termination, so
> >>> all the
> >>> user has to do is treat it like a normal phone - just pick it up and
> >>> dial
> >>> (or answer).  For our application, probably one of the SIP based VoIP
> >>> packages would be most appropriate.
> >>>
> >>> 4.  Build on extra functionality outside the package.  Shell
> >>> scripting
> >>> can
> >>> work well here, and make the package very "hackable".  That's one of
> >>> the
> >>> strengths of IRLP in the radio world.  If the functionality is not
> >>> there,
> >>> chances are you can add it in. :)
> >>>
> >>> Of course, the hardest part will be getting the hardware out there.
> >>> Now, if
> >>> any of us is involved in electronic manufacturing, that would help.
> >>> Good
> >>> thing is it won't need Austel/ACA approval, as it's not interfacing
> >>> to
> >>> the
> >>> phone line, just your PC. :-)
> >>>
> >>> Might also be a good project for mags like Silicon Chip. :)
> >>>
> >>> This correspondence is for the named person's use only. It may
> >>> contain
> >>> confidential or legally privileged information or both. No
> >>> confidentiality
> >>> or privilege is waived or lost by any mistransmission. If you receive
> >>> this
> >>> correspondence in error, please immediately delete it from your
> >>> system
> >>> and
> >>> notify the sender. You must not disclose, copy or rely on any part of
> >>> this
> >>> correspondence if you are not the intended recipient.
> >>>
> >>> Any opinions expressed in this message are those of the individual
> >>> sender.
> >>>
> >>>
> >>> To unsubscribe: send mail to majordomo at wireless.org.au
> >>> with "unsubscribe melbwireless" in the body of the message
> >>>
> >>>
> >>
> >> --
> >> Damian Halloran B Comp
> >> P: 03 8430 8691
> >> M: 0419 308 036
> >> F: 03 9417 1848
> >> E: damian at phit.com.au
> >>
> >>
> >> To unsubscribe: send mail to majordomo at wireless.org.au
> >> with "unsubscribe melbwireless" in the body of the message
> >>
> >>
> >>
>
> --
> Damian Halloran B Comp
> P: 03 8430 8691
> M: 0419 308 036
> F: 03 9417 1848
> E: damian at phit.com.au
>
>
> To unsubscribe: send mail to majordomo at wireless.org.au
> with "unsubscribe melbwireless" in the body of the message
>


To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message