There are a couple of things to look out for here
(straying into tech issues):
1) buffering - TCP tends to get buffered in the kernel to a
much greater extent than udp - so you can easily find yourself
with seconds of latency.
2) codecs - The only low-latency codec supported by flash
is patented and expensive to license, so the gateway to PSTN
or 'normal' VoIP will always have to carry an aditional cost
of the nelly-moser codec license.
3) protocols - Flash is using a streaming protocol (RTSP),
which isn't a VoIP protocol, so has not got the VoIP features
we have come to expect.
All of which is why adobe is (supposed to be) adding SIP
to some future version of Flash.
- Ok, I admit it, I'm biased, I'm in the Java - IAX camp :-)
But in general I'm sure that this sort of web-telephony
integration is inevitable. See http://www.phonefromhere.com for our
latest experiment - an iGoogle 'phone home' gadget.
Tim.
----- Original Message -----
From: "Trixter aka Bret McDanel" <trixter@0xdecafbad.com>
To: "Commercial and Business-Oriented Asterisk Discussion" <asterisk-biz@lists.digium.com>
Sent: 29 February 2008 12:47:21 o'clock (GMT) Europe/London
Subject: Re: [asterisk-biz] Ribbit.com ? 1ezphone.com
> > ----- Original Message -----
> > From: "Mike Clark"
> > To: email@mattruby.com, "Commercial and Business-Oriented Asterisk
> > Discussion"
> > Subject: Re: [asterisk-biz] Ribbit.com ?
> > Date: Mon, 17 Dec 2007 17:21:50 -0500
> > Ribbit has a totally different model as they are a full blown ITSP and
> > have provided a Flex/Actionscript API to their Flash phone
> > component at
> > no charge to developers. I have an app ready to roll as soon as
> > they are
> > completely live.
> >
> > I would love to see a similar type API to a Flash SIP or IAX2
> > component
> > where I could access my own Asterisk or Freeswitch server.
> >
Flash does not afaik support UDP so the RTP part would be difficult at
best. I am unsure if the really new versions do or not. Granted you
could have a plugin (flash does have the ability to execute programs
that are in a special directory) which really only would need to be a
tcp->udp converter if you wanted, although it could be a full RTP stack
as well instead of doing that in flash.
Gizmophone has a web component that transmits the audio via HTTPS via
flash. I havent looked at ribbit so I dont know if that is how they are
doing it or not. They also use a plugin to try to limit how many calls
you can do at one time off one box (they did give away free minutes at
one point, they may still do that).
While the SIP RFC requires TCP support for signalling, the media would
still be udp and still be the problem. And if you want to connect to
asterisk you have to use UDP signalling since asterisk does not yet
officially support TCP, despite the RFCs requirement.
Personally what I think would be better is a very simple app that can
send events (on/off hook, dnd/presence, dtmf digits, number dialed, etc)
as well as media (just stream it from the mic direct, which is something
that flash has built in). This would connect to some server side
process that will then connect to whatever protocol you prefer for
termination elsewhere.
On lossy networks you would have a problem of a dropped packet causing a
retransmit, however this may not be that big of a problem in many
environments. If you have any sort of jitter buffer you should be able
to resync the call dynamically so that packet loss does not cause a
growing skew between leg A and leg B. This is probably the biggest
problem to solve, and I do not know how big of a problem it will be for
most users (for some it will be a killer).
Now if they have java installed as well, flash can do liveconnect calls
to the JRE, but if you are going to go that route, it might be better to
just do it all in java to begin with.
Now flash recently aquired a key person that was involved in SIP stuff.
The theory (and some statements officially) indicate that the intention
is to build a proper sip stack into flash, but that has yet to be
released.
There are other bridges that exist to basically do the tcp->udp
translation, which could be run on the users system. Examples include
http://www.transmote.com/flosc/
While this is designed to do the open sound protocol, it would not be
difficult to make it do something else, and if you really know action
script you can get around little things like you dont have to do xml
with the xmlsocket, you can bypass the null byte terminator that is
often sent, etc.
For what is needed to do the tcp->udp bridge it wouldnt be hard to write
that on your own, and then go nuts.
--
Trixter http://www.0xdecafbad.com
Bret McDanel
Belfast +44 28 9099 6461 US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-biz
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
Posts
No comments:
Post a Comment