I need to implement a Notification Application in Mitel IP Phones (mainly 5330 and 5360). Where can I start? I tried to have a look at the applications samples provided by the Mitel HTML Toolkit but there is no sample for the Notification App since the web server is needed.
Any guidance (tutorial, advice, sample, etc.) you could give me will be greatly appreciated.
Depends on if you're trying to do a popup on the phone, or on a computer client. The HTML Toolkit is used typically to load apps on the phones, but there's some issues depending on what phone system the 5330 and the 5360 are connected to, the 3300 for instances has better support for apps on the phones, whereas the 5000 cp does not. The phones can be used in SIP mode which allows you the ability to do html redirect and apps easier, but then you have to pay for the sip licenses, and loose the minet functionality. An alternative is to use the UCA client SDK, it notifies a computer of events, e.g. ringing, hang up, dialed etc. and you can then use those in dot net to integrate to other sw. Hope this helps.
Related
I would like to setup a Voip Server and Client for Windows but when I searched on Google, there was too many results and too many softwares.
I want to setup a Voip sytem for my Intranet, that's why I can't use Skype. Because all the user of my computer are in different rooms I would like to be able to call the users easily by a voice chat application.
What are the best free softwares ?
Thank your for your help.
EDIT 1: I think I didn't give enough details: Thank you mrescape for your help but I don't want to create a program, I just want to download one.
EDIT 2 : I finally discovered WebRTC and decided to use this technology, it will be much easier to setup in my environment...
About VoIP server you can use http://www.asteriskwin32.com. And about client you can use X-lite or Portgo, Linephone ...
We are currently planning to develop a suite of Windows Store Apps. They are independent and fully work alone, but they are related and act in concert. If a user has several of them, they should share some of their settings (and data), so that the user does not have to manually change these settings in every single one of them.
Is such a scenario even intented?
And how to implement it?
Registry: Does not work. Apps cannot access the registry.
ApplicationData (LocalFolder, LocalSettings etc.): Does not work. Apps cannot access the data of other apps.
Cloud services: Kind of works, but only when the machine is online. Our apps should work offline, too. And we would need to create/rent such a cloud service, which would cause additional costs.
KnownFolder.DocumentsLibrary: This –currently– looks like the only solution to me. The apps are already saving and sharing data there, so let's just save our settings there, too. But the name of the shared folder is one of the settings! And Windows Store Apps cannot create hidden files, so the user can see the settings file. This makes this solution a bit... "rough".
Any other ideas or additional information I have missed?
If you want them to sync with each other instantly, even when the device is offline, then that's your only option. Windows 8 Apps are not intended to share settings.
So much want of sharing.
Roaming API will only share with the SAME app, the SAME user, ANY W8 device.
SkyDrive will only share across ANY app, the SAME user, ANY device.
Using Azure (or any web service) will share across ANY app, ANY user, ANY device.
Don't do this
Don't use the register, the API is not supported
Don't use the file system, the boundaries cause your app to be brittle
Don't use ApplicationData.AnyFolder, this is restricted to a single app GUID
You had might as well get "instant" out of your language, man. That just doesn't happen. But you can have fast (let's call it near instant); you can use Sockets or SignalR to connect your client to some service out there with nearly instant responses. A less sophisticated approach would be to poll from your client, too. It has served developers for decades.
As far as I understand, Microsoft wants to allow "having both desktop and modern ui GUIs" only available for web browsers (am I mistaken here ?).
Does that mean common apps will be developped twice ? With e.g Skype being available both as pure desktop app and pure modern ui app ? And if a user installs both, these both instances will share no data ?
I can't imagine them doing a shift towards gesture friendly uis/hybrid ui, and leaving full blown desktop apps (not toy/phone-like/game apps, that can live in one space only) with no integration/entry points inside modern ui. Or maybe they want to participate in that "kill full-blown desktop apps" movement ?
So is there a model for a desktop app developped in whatever GUI toolkit, that wants to have some minimal integration with a small HTML/CSS/JS frontend in modern ui, like for e.g providing a dashboard of favorite or recently accessed files, contacts, etc ?
Your first statement of "only in a browser" is not correct. Desktop applications don't change their current design paradigms. You can have browser-based apps on the desktop, of course. But full clients are still supported and still viable as a real solution to problems.
Your takeaway from that comment should be that desktop applications are not deprecated as people assert. The reality is, desktop applications are still the only solutions to many problems.
Your second question of shared data is not correct. Skype shares lots of data with its app companion. Not because of shared local storage, however; it is because of the services that it shares. My account and contacts are on the server. So, they share a lot.
Your takeaway from that comment should be that Windows 8 apps should not highly leverage local storage but should be built as service-oriented clients. To that end, your desktop applications should have already started to leverage this architecture, too.
Your third question (which is very cryptic) seems to be asking if a desktop application and a companion Windows 8 app can share or integrate with each other. The answer is yes. Not only can they share the same service, but file associates, custom protocols, and some of the non-Store manifest capabilities allow for this explicitly. Line of business applications should have a companion app, if you ask me. The integration points are many - though not every. But there is no other way to leverage the new capabilities of Windows 8 without introducing a companion app - even if that app does very little.
Your takeaway from that comment should be that Windows desktop applications and companion Windows apps are the preferred and anticipated development approach.
Best of luck, thanks for the question.
I have a local installation of Voxeo's Prophecy platform, and a voice xml application that runs on the voicexml browser of the platform. How can i call the application to listen to the message, without having a sip phone, and without using the voxeo's hosting capability? I just want to call the application at the local installation without using a phone. When i try this from the browser, i just get the xml file containing the dialog.
Why are you trying to start the application without a SIP phone? The developer version of Prophecy comes with a SIP phone that works great for testing and debugging. Are you trying to access the application from a regular telephone or POTS. If that is the case you will need additional hardware, such as a Cisco VoIP Gateway to translate the land-line signal to SIP. There are a number of VoIP Gateways available. Another option is to put Dialogic cards in your server and use a software that translates between SIP and the Dialogic API. If you purchase Prophecy from Voxeo as an appliance there are options they can sell you to achieve this. The advantage of getting this from Voxeo is that they will help configure it, which is not trivial depending upon the type type of telephone lines you are using and whether they are behind a PBX or not.
The telephony/communications interface to Prophecy is SIP so that is the only way to communicate with it. You could use any open source SIP stacks to develop something yourself, but the easiest thing to do is to use a software based SIP phone. It is not like you could just start talking and the VXML app would know what you intended, or if the if the voice input was really intended for the VXML app. You still need to maintain things like sessions and routing to the correct application which is easily handled by a SIP phone. Prophecy is designed for a telephony environment. If you are trying to use it for something like a home automation system, which some people have, I would think you would have to provide some type of SIP front end that is voice activated.
Does anyone know of an open source web service/wcf service that can stream media content to clients? In particular I am looking for something that could access my music collection and stream it to a client (could be a client browser, win mobile app or even iphone application).
I guess it would have to be WCF based as I'm not sure that webservices do streaming really well. Also Windows Media Streaming Services is not the best way to go as the service should operate from a vista/xp machine (preferably).
If not, does anyone know the best way to start going about creating something like this - I'm not sure I know where to start with this one, although I can see many many uses for such a service!
Even though it's not open source, Windows Server 2008 has a Streaming Media role that will do what you ask. Of course, you'll need to have a server to put it on.
I tried Orb and it is quite good, apart from the fact that it hijacked my tuner card so media center would no longer work. However I'm going to try and create a home grown version.
Orb (www.orb.com) will stream your media to just about anything with a web browser. I've been running it on an XP virtual machine for about a year. I love being able to stream my entire media collection to my phone while I'm working at a client's site.
While it isn't open source, it is free and relatively well supported. One of the best features is that the architecture is set up so that there are no special requirements for your firewall -- it just works.