I'm developing an application using the Cisco JTAPI API. But one issue I'm facing is when the user enables mobility on his VoIP telephone. Then I'm unable to control the mobility call (the call forwarded to fx. the users mobile phone) through the JTAPI API as it's not tracked.
Does anyone have an idea on how I can control the call? Basically I just wanna hangup the mobility call in order to make the call return to the terminal so I can control it.
Thanks a ton.
Once the call goes to mobile phone or any pstn gateway Cisco JTAPI cannot control it. JTAPI has fine grained control only for registered devices. I would suggest looking at Cayuga API from the Cisco Voice gateways to get similar controls on calls flowing mobile phones. These are part of the Integrated Service Routers (ISR) itself.
Related
Is it possible to receive a PSTN telephone call with Azure Communication Services?
All the docs and the demos talk about initiating a call to a known number.
My use case is that somebody rings a phone number from their mobile phone (PSTN) and I want to be able to handle the call.
I cant find any documentation that discusses this or how to do routing! For example, which route the call to a particular agent.
Have I missed something? Any thoughts?
For anybody looking.... you cant as of 18/03/2022
This came directly from a conversation with Microsoft.
You can initiate a call via the API, but you cannot receive a call made from a telephone on a PSTN or manage routing etc.
I can connect to a VOIP phone, on my web app I have a list of telephone numbers. When I click on a telephone number, how can I send a number to this VoIP phone and initiate a call from that handset?
Webapp is on an intranet and is privately used only.
Phone model: Avaya 1210 and Avaya 1220
Is this possible?
For click to call, call process monitoring on Avaya phone system, you should use Avaya CTI. It helps you to make a Windows application or web application to connect your CS1000 phone system and dial a phone number.
When you click on the phone number on your web app, your web app should connect to Avaya CTI API and send dial command with parameters like phone number and extension number.
For more information read the following documents:
https://www.devconnectprogram.com/site/global/products_resources/communication_server_1000/interfaces/sip_cti/overview/index.gsp
https://www.devconnectprogram.com/site/global/products_resources/communication_server_1000/releases/7_6/index.gsp
I need to implement a renewable subscriptions in my mobile application, with different plans, duration and prices (like Netflix is doing), that is valid on mobile but also in my desktop app.
I read many threads and I understood that the only way to know if the subscription is correctly renewed is to check it from the mobile app: this is a problem for me because if I bought a subscription in my mobile app and I stop using it, but I'm still using the desktop application, at the end of the subscription I will not know if the subscription was renewed (because the user never opened the mobile app) and so I'll block the user for log-in in the desktop app.
I also read that it's not possibile to use Stripe or Paypal to manage the payment in mobile app, because the store will block the application that is not using a proprietary purchase system to sell not-physical goods or services.
So, the question is: is there a way to make a recurring subscription and know if it's currently active or not and the total payed without open the mobile app? If not, how can I manage a recurring subscription both in mobile and desktop apps? May be I'll need to create an external web page using a webview and then use Stripe or Paypal?
Thanks.
Matteo
Font:
Renewalbe subscription on mobile
Implement Stripe in Xamarin
EDIT
Our purpose is to manage subscriptions on desktop application but give the mobile user the possibility to buy a plan also on mobile.
Is possible to use a web view or default mobile browser to redirect the user to desktop web page and buy from here, without have any problem when publish app on apple and play store.
Some time ago, it was commonplace for smartphone apps to open a browser to a registration page with a CAPTCHA, or to require separate signup via web, because API signup was seen as vulnerable.
Now most apps seem to offer registration via native form, though endpoints for this are usually not documented in their public API. I haven't seen many reports of this being abused to create spam accounts.
How is this done? Is there a standard crypto/handshake process to verify real signups, or does signup typically rely on undocumented endpoints and simple API key passing?
Embedding yields a better experience but has the issue you mention. Yes, the service owners on the other end are still worried about this and combating the problem. And undocumented APIs don't help and the service owners know this.
One of the tools in the toolbox these days is keys assigned to devices which can be used for throttling. This would essentially let you limit the amt of service that can be consumed on a per device basis and it would require you have a device (or can steal the key from one) in order to provide service. So long as the process to issue keys to new devices is strong (a solvable problem) then you can offer a CAPTCHA-free signup experience within the confines of what you are willing to give to a device.
I'd also note that there are other well known approaches you can use, like IP throttling and handshakes with other service providers (like a phone carrier). Depending upon the problem domain these are on the table too...
I am creating a j2me application for mcommerce, which uses mobile internet(gprs). I wanted make it more secured by binding the application to the SIM card and the device. That is a user should be able to login to the system, only using his/her SIM card or from the registered mobile number.
To achieve this I need to fetch the mobile number.
So, on login i thought of Triggering an SMS from the server with a key, which the application reads and uses the key for the entire session. Here the challenge is, that sms should not go to the inbox.
Any suggestions pls?
Yes it can be achieved using the Wireless Messaging API. Have the MIDlet set up a server connection on a chosen port number, then send the SMS to that port number. It will go straight to your app, bypassing the inbox. If you use the Push Registry, you can even make the SMS start your app if it is not running.
It doesn't matter if the user sees the number in his/her inbox.
As long as the key is only used that session, it is her/his responsibility to not share the key with others.
The one thing you make sure is that ONLY the person who owns the SMS phonenumber gets the key and is able to log on.
This doesn't take care of the phone being stolen though.