Project DiaStar and the DiaStar Server

Re: How can I test IVVR demo apps with Dialogic ?

dariusjack2006@yahoo.ie — Tue, 04 May 2010 08:59:31 GMT

Thanks. This place is ok.

I have to get used to keep track of 2+ threads at the same time.

Using iPod Touch I really can't enter plain text into Description box.

Changing to HTML I have entered to long string (multi-line plain text) to be handled by html parser,

so I do still hope to use iPod Touch in responding safely, using <p> tags

from time to time as a new line.

I am just testing demo apps from your Wiki.

http://wiki.projectdiastar.org/index.php/DiaStar%E2%84%A2_Multimedia_Demos

I can't record video and none error is generated, selecting menu options

Calling sip:300

Mayby I need to reconfigure Kapanga to start sending/ recording video.

Set up codes or alike.

Darius

btw

(the following error is generated when I select web links coming with e-mailed cmmunications frm DEN.)

http://www.dialogic.com/den/forums/p/7157/27151.aspx#27151

Re: How can I test IVVR demo apps with Dialogic ?

jhermanski — Thu, 29 Apr 2010 21:09:32 GMT

Hi Darius,

The best I can suggest would be that we move this discussion to the project diastar mailing list. That operates with just plain old email. To be honest, I'd rather have it there anyway. The users list is the best one for this subject. You can sign up here - http://www.projectdiastar.org/index.php/mailing-lists

Re: How can I test IVVR demo apps with Dialogic ?

dariusjack2006@yahoo.ie — Thu, 29 Apr 2010 20:53:11 GMT

Sorry spent an hour responding your last communication and on updating HTML it is lost. Please test your forum using iPod iPhone.

Re: How can I test IVVR demo apps with Dialogic ?

jhermanski — Thu, 29 Apr 2010 18:39:38 GMT

Hi Darius,

I'm afraid that DiaStar, like Asterisk, is a Linux-only sort of thing. But since the DiaStar ISO install pretty much sets up the system for you, leaving little to the imagination, it shouldn't be too hard to use. It is also relatively simple to add an asterisk installation to the Diastar server for testing.

As far as our public demo server goes - it is mainly something that I use for providing a quick, dial-in demo of some of the things Diastar can do. So that people who are interested don't have to go through the trouble of setting up their own system to see some of the features. I would admit that having this sort of a "sandbox" environment is not a bad idea, but we just don't have the time and equipment for it at the moment. And that's also not to say that if someone had a really cool app built using DiaStar, I wouldn't be tempted to put it on our public system if they wanted me to.

As far as 3G gateways go - I have to give you the same sort of answer as the public demo system. We are just now setting up Diastar with one of Dialogic's CX Vision SIP-3G gateways in our support office in Barcelona. But it is more for an internal trial than allowing people to use it for their own testing. But my same comment on a "really cool app" applies here also.

-John

Re: How can I test IVVR demo apps with Dialogic ?

dariusjack2006@yahoo.ie — Thu, 29 Apr 2010 07:58:12 GMT

Thanks John for your kind reply

I have already visited both wiki diastar and diastarproject websites.

The issue is I run ms vista laptop, iPod touch ( now) and nokia Internet tablet.

Please tell me what is a chance to emulate DiaStar under ms vista, if any.

Writing my reply I must use your HTML source editor as there is no way to enter any text in text mode, using iPod touch.

I am looking ivvr hosting with your DiaStar to let me develop dialplan + media files locally and have them uploaded to your server.

And finally I would like to access real 3g video gateway, to let me test ivvr demo apps using real gsm phone.

Darius

dariusjack2006@yahoo.ie

btw. I have spent a month on talks with orange to have demo 3g video gateway set up and run to test ivvr demos and failed.

Re: How can I test IVVR demo apps with Dialogic ?

jhermanski — Mon, 26 Apr 2010 18:18:57 GMT

Hi,

Although we have this DiaStar discussion forum, most of the "action" takes place on the projectdiastar.org website. There, we actively maintain a newsfeed, provide downloads, have mailing lists, and post documentation in a wiki.

But, to answer your question - You download a DiaStar ISO release, complete with operating system, find an empty system, and install it. You then request a 4 port trial license to activate the software. We have several demo apps that you can download and run on Asterisk and DiaStar. Once you are familiar with them, we would encourage you to build your own, based on our examples.

Also, we have a public demo system. All you need is a SIP video phone to try our demo apps.

Anyway, the place to start is www.projectdiastar.org. I hope to see your request for a trial license! (send your system's MAC address to license@projectdiastar.org)

Thanks for your interest,

John

How can I test IVVR demo apps with Dialogic ?

dariusjack2006@yahoo.ie — Mon, 26 Apr 2010 10:25:10 GMT

How can I test IVVR demo apps with Dialogic ? dariusjack2006@yahoo.ie

Project DiaStar

jeff.dworkin@dialogic.com — Mon, 31 Aug 2009 19:14:12 GMT

Hi All,

This Den group has been pretty quiet for a number of months, but we are now up and running again with today's press annoucement. http://www.dialogic.com/press/press_releases/pr_20090824_ITEXPO.htm

Not quite sure how the activity will split between the www.projectdiastar.org website and the DEN, but please check out the project site and send me any feedback. Thanks for your help with this.

Jeff

Design Point - Improving Dialogic Woomera 3 Commands and Events - Outbound

jhermanski — Thu, 05 Mar 2009 22:40:31 GMT

As there is a diagram here, see the Media section.

Thx,

John

Design Point - DHWS and Woomera Versions and Components

jhermanski — Mon, 02 Mar 2009 18:53:42 GMT

See the Media section, as there is a diagram involved.

For DHWS, a listing of:

Woomera server versions we need to use
Pieces we keep from DDWS
Pieces we discard from DDWS

Desing Point - Improving Dialogic Woomera 3 Events and Commands

jhermanski — Fri, 27 Feb 2009 16:41:15 GMT

Again, see the media section for this one, as there is a diagram involved.

Proposes how to remedy the current problem with woomera 3 design explained in the previous post. Ladder diagram and explanation solution.

Re: Design Point - DHWS and Woomera 3 Commands and Events

jhermanski — Fri, 27 Feb 2009 13:36:19 GMT

Hi Brough,

Yes, I'm the technical guy working for Jeff Dworkin. And I agree, a little constructive "sucking up" goes a long way. Jeff knows Craig and can arrange whatever. In fact, Marcello Federico (from your side of the house who was working wiih me up until today) , spoke with Craig a couple of weeks ago to confirm that our move to Woomera 3 from Woomera 2 was not premature.

I myself am not real familiar with the innards of Woomera yet, but I get better daily as we get a Woomera 3/HMP prototype going. So I need a little more familiarity with the code before pointing out what look to be its shortcomings. We've got two development guys in the UK who have just started and we talked yesterday about a session with Craig week after next when we are all in Parsippany.

It would be also a good idea to get more familiar with Sangoma - both getting some of their hardware and setting up a system and getting some dialog going between us and their open source advocates.

-John

Re: Design Point - DHWS and Woomera 3 Commands and Events

brough.turner@dialogic.com — Fri, 27 Feb 2009 13:04:28 GMT

John,

Just curious... Are you the technical lead for our interface with the open source community? In the end, we're interested in attracting people to our code and our products. That may be furthered by sucking up to Craig or the guys at Sangoma and/or others. Is there someone technical who's on friendly terms with all of the parties in and around the Woomera code base?

Thanks,
Brough

Re: Design Point - DHWS and Woomera 3 Commands and Events

jhermanski — Fri, 27 Feb 2009 02:19:47 GMT

The problem here is with the Woomera 3 ( and 2) server, which was designed and written by Craig Southernern long before we had anything to do with it. But, it would seem that any sort of realtime telephony-oriented server that interfaces with a network API like ours should take into account the possibility that anything/everything would be done asynchronously.

On the bright side, it is open source, not a very complicated piece of code and can be rewritten accordingly. And it's likely that we will have to diverge from the basic Woomera server anyway.

Re: Design Point - DHWS and Woomera 3 Commands and Events

dslopres — Fri, 27 Feb 2009 01:40:25 GMT

This seems like significant re-design, i.e. synch -> asynch.

(we should have probably done a managed design with DHWS)

Design Point - DHWS and Woomera 3 Commands and Events

jhermanski — Thu, 26 Feb 2009 23:01:52 GMT

See the media section for this one, as there is a diagram involved.

Explains the current problem with woomera 3 design - how it does not take into account the async model we need to use with DHWS. Ladder diagram and explanation of problem.

Design Point - Woomera Cleint/Server Code Bases

jhermanski — Thu, 26 Feb 2009 20:18:23 GMT

This is as of 2/26/09. Things constantly change....

This is a short explanation of what woomera code we are working with, where it has come from, and where we are hopefully going with it.

DDWS - Dialogic Dm3 Woomera Server. "ddws" trunk in SourceForge. Code from the outside contractor CUWorld. Uses DM3 hardware and Dialogic SR 6.1. Based on woomera 2. Chan_woomera is version 1.34. Uses PTLIB for threading portability, logging, (along with log4clpus) remote web acces, command line parsing. We are no longer doing active development here and it will not be released to customers.

DHWS - Dialogic HMP Woomera Server. "dhws" branch in SourceForge. Pretty much the same code as DDWS, but it will compile under HMP and run to a limited extent. It does NOT use IPM/RTP for audio streaming. This branch will morph into the full HMP-based version eventually.

NMS Prototype - Marcello Federico put together a prototype using woomera 3 and chan_woomera version 1.36 and NMS hardware for an RTP-based audio/video woomera server. Ask me for a copy.

DHWS Prototype. - based on NMS prototype. So, uses woomera 3 and chan_woomera (version 1.36) from Sangoma. Currently does not use PTLIB framework but will. Linux only now, will be bilingual when PTLIB added back in. There have been improvements in woomera 3 since it was pulled for the NMS prototype. These must be reconciled. Chan_woomera from CUWorld must also be check against this for anything done by CUWorld that we need to port over. This will be the active version. Currently I am keeping track of it. Ask me for a copy. This will go on a Dialogic SVN server when one is available and then merge into the DHWS branch on SourceForge.

Re: Design Point - Static vs. Dynamic Device Connections

jhermanski — Fri, 20 Feb 2009 16:54:46 GMT

Thanks for the reply, Pablo. Doing things in a forum like this is going to work out decently, I think.

Requiring devices be 1:1 would make the person who sets up the system responsible for getting sufficient licenses for the soft resources. We would have to nicely deliver an error if something was lacking, rather than charge ahead with a half-baked set of devices.

But the same principle applies with pooled resources - more annoyingly, you might run out at runtime when a call comes in, rather than when the app is starting up. So, decent error handling applies here also.

I would only consider doing things sync with 1:1, listen calls on app start. If we do it dynamically, it would have to be async for all xx_Listens().

3PCC model would be the only one that applies here. 1PCC is really only valid when you use GC/SIP. We are using Woomera for call control in place of SIP, so have to do IPM streaming programmatically. So that makes it 3PCC.

Re: Design Point - Static vs. Dynamic Device Connections

pgdepaul — Fri, 20 Feb 2009 14:46:39 GMT

I would think you are going to do the routing from/to TDM to/from ipm devices dynamically unless you have a way to guarantee that there's somehow a 1-to-1 relationship. Most applications cannot guarantee this thus do routing dynamically using a pool of resources that are dynamically routed to the gc devices.

I assume here that your gc devices are standard ISDN TDM channels, of course.

Now, gc has async listen functions so you should use them regardless; I know there are "ex" voice listen APIs in HMP in case you need to use voice at some point. ipm_listen has an async mode so I'd recommend you use that.

The main reason for using listen in async is not so much for the latency; Cheetah returns right away on a sync listen, however the underlying SW usually takes additiional time to complete. We've seen, at least in the board SW, many cases of race conditions due to this so try to avoid sync listen commands at all cost (though in HMP they are not as costly).

Incidentally are you going to do 1PCC or 3PCC HMP model? I think John K. recommended using 3PCC.

Not much but I wanted to give you my two cents.

Design Point - Static vs. Dynamic Device Connections

jhermanski — Thu, 19 Feb 2009 18:41:27 GMT

Device virtual CTBus listen/unlisten. This would include GC/ISDN, IPM and Voice devices so far.

Do we do GC/IPM synchronously at app startup, or dynamically when calls arrive? Our architecture is tending toward single threaded async, so we want as few synchronous delays in it as possible.

Now in there temporarily as sync as call arrives - not a good idea. Might check via RTF log to see how long sync really takes. Could be be inconsequential? If we do it async, some amount of state machine work involved, but it shouldn't be a big deal.

How about other devices in the future? We will be adding play/record, conferencing and who knows what else. Are we likely to be bringing different media devices in on a call-by-call basis? It doesn't seem that way, but I might be wrong.