> > ----- Original Message ----- > > From: "Mike Clark" > > To: [EMAIL PROTECTED], "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
