I am working with Cisco phones and i want to send them alert messages.
I do this by posting the following to the phone
"<CiscoIPPhoneExecute><ExecuteItem URL=\"Play:chime.raw\"/><ExecuteItem Priority=\"0\" URL=MY GET MESSAGE URL></CiscoIPPhoneExecute>";
My HTTP server then responds with a CiscoIPPhoneText xml object.
This is all working fine, however it is my desire not to have the messages stacking up on top of each other so that the user does not have to dismiss each message individually. I wish only for the most recent message to remain active on the phone so regardless of how many messages the phone has received the user can dismiss one and be returned home.
At first i included an init:services uri in the post but this caused a conflict with another service and my CiscoIPPhoneText was being dismissed immediately by the other service (i have no control over the other service).
Is there a way to return the phone to the home screen before an CiscoIPPhoneText is displayed or any other way to ensure that only one message is active?
Thanks
I found the answer
App:Close:0 is an internal URI which closes the current (or specified) application.
All my messages have the same AppId so when this URI is invoked all my messages close
Related
We're using ActiveMQ locally to transfer data between 5 processes that turn simultaneously.
I have some data I need to send to a process, both at runtime (which works perfectly fine), but also a default value on start. Thing is it is published when the process starts, it just doesn't read because it wasn't subscribed to the topic at the time the data was sent.
I have multiple solutions : I could delay the first publishing for a moment so that the process has time to launch (which doesn't seem very appealing) ; or is there a way to send all stored previously non-treated messages to some process that just subscribed ?
I'm coding in C#.
I don't have any experience with ActiveMQ, but other message system usually have an option which marks the subscription as persistent, which means that; after the first subscription; the message queue itself checks if a certain message is delivered to that system and retries with a timeout. In this scenario you need to start the receiver at least 1 time.
If this is not an option and you want to plug in receiver afterwards, you might want to consider a setup of your messages which allows you to retrieve the full state, i.e. if you send total-messages instead of differential- messages.
After a little google, I came upon this definition durable subscribers, I hope this helps:
See:
http://activemq.apache.org/how-do-durable-queues-and-topics-work.html
and
http://activemq.apache.org/manage-durable-subscribers.html
since you are using C# client i don't konw if this is supported
topic = new ActiveMQTopic("TEST.Topic?consumer.retroactive=true");
http://activemq.apache.org/retroactive-consumer.html
So, another solution is to configure this behavior on the broker side by adding that to the activemq.xml and restart :
The subscription recovery policy allows you to go back in time when
you subscribe to a topic.
<destinationPolicy>
<policyMap>
<policyEntries>
<policyEntry topic=">" >
<subscriptionRecoveryPolicy>
<timedSubscriptionRecoveryPolicy recoverDuration="10000" />
<fixedCountSubscriptionRecoveryPolicy maximumSize="10000" />
</subscriptionRecoveryPolicy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
http://activemq.apache.org/subscription-recovery-policy.html
I went around the issue by sending a message from each process when they're launched back to the main one, and then only sending the info I needed to send.
Im having some troubles with the Lync 2013 client SDK. I want to accept incoming conversations with my own program. For AV-calls this is working fine: When a new conversation starts, the ConversationAdded event fires, the AVModality state of the conversation is Notified and when calling Accept on the modality, the conversation window of Lync pops up as expected.
The trouble comes when trying to handling incoming IMcalls. On an incoming IMcall, the InstantMessageModality State is connected instead of notified. Also, calling Accept() on the modality does nothing. The first is acceptable, as i can register to window available events and interpret that. The second however, is not. To me it seems rather strange this doesn't work.
Is there any way to accept an incoming IM conversation like a AVconversation? (Ie, the Lync toast should dissappear and the lync conversation window should open)
Thnx
Did you already look at How to: Join a Lync conversation on MSDN? In that doc they explain how joining/accepting an incoming A/V conversation is different than doing the same for an incoming IM conversation.
E.g. one of the differences is that IM conversation does not need to be connected.
HTH
Edit 2:
Client Library: After reviewing it is not easily suggested that this is for the .NET client library.
DLL: Google.Apis.Admin.email_migration_v2.dll
What steps will reproduce the problem?
Generate a process which contains a
Google.Apis.Admin.email_migration_v2.AdminService instance for each
unique Google Apps Gmail mailbox that will have messages sent to it.
All of the AdminService objects generated use the same OAuth2.0
credentials and application name. Each AdminService object generated
will only send messages to one Google Apps user’s mailbox. For
example, if we were sending messages to five different Google Apps
Gmail mailboxes we would generate five AdminService objects to send
messages; one for each user’s mailbox.
Biggest thing to note is that each AdminService object created is created on a separate process.
AdminService objects were given a FileDataStore object to change the location of where the refresh token is stored; C:\ProgramData\SomeFile\SomeFile.
Supplied appropriate scopes to the credentials.
Begin sending mail messages on each process. Using one thread to send messages in each process, so only one message is sent at a time to each user’s mailbox.
Each message sent gets its own instance of MailItem and MailResource.InsetMedia
The MailResource.InsertMedia object is generated for each item by calling AdminService.Mail.Insert(MailItem, string, Stream, string) method.
When our code makes the call to MailResource.InsertMediaUpload.UploadAsync(CancellationTokenSource).Result is where we can receive the error.
The error is caught and handled (logged) from the return type of the aforementioned call; the type is Google.Apis.Upload.IUploadProgress. The exception is handled using the IUploadProgress.Exception property.
What is the expected output? What do you see instead?
The expected output would be a successful message response or the exception property of the IUploadProgress to be null after the return of the task. Instead we are receiving the following error message:
The service admin has thrown an exception:
Google.GoogleApiException:Google.Apis.Requests.RequestError
Limit reached. [412]
Errors [Message[Limit reached.] Location[If-Match - header] Reason[conditionNotMet] Domain[global]]
at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
at Google.Apis.Upload.ResumableUpload`1.d__e.MoveNext()
What version of the product are you using?
Google.Apis.Admin.Email_Migration_v2 (1.8.1.20)
What is your operating system?
Windows Server 2008 R2 Enterprise (SP1)
What is your IDE?
Visual Studio 2013 Premium
What is the .NET framework version?
4.0.30319
Please provide any additional information below.
Non-consecutive messages can fail (with the 412 http status code
provided above) during the process of sending the messages. Once we
receive this error other messages sent after the failed message(s)
can succeed. (Items can fail at any point during the process
beginning, middle or end.)
Each message sent has nearly identical content. The size of the
messages range from 1KB to 100KB including the size of all associated
attachments, not all messages have attachments.
Reprocessing the failed items at a later time results in successful
message responses and the appropriate items are sent to the user’s
Google Apps Gmail Inbox.
The maximum number of Google Apps user’s mailboxes sent to at one
time was ten.
After checking the quotas of our Google Developers Console project:
We were nowhere near the specified limit of 20 requests a second for
the Email Migration API; maxed out at sending 7 requests a second.
Only 2% of the maximum daily requests had been reached.
All messages sent had the same label; the label was well under the
225 character limit. Actually all of the labels/sub-labels applied
together only surmounted to 40 characters.
This error message can still be received when sending to only one
Google Apps user’s mailbox; only using one process and one thread.
Each process is normally sending anywhere from 1000-5000 messages.
I have not found a lot of specific documentation to explain this particular error in enough detail to remedy the problem at hand.
Questions:
So what exactly does this 412 http status code mean? What limit is being encountered that this message is referring to?
Shouldn’t we be receiving some form of 5XX error from the server if we are hitting a limit? In which case wouldn’t the built in exponential back off policy kick in?
a. Unless the server is checking the POST request for a pre-condition about a server side limit then telling the client to back off which is what a 412 error seems to typically indicate. In that case please give as much detail as possible for question 1.
Sorry for the extensive post! Thanks for your time! I will also be creating a defect/issue in Google's .NET issue tracker and providing a link.
Edit 1:
For anyone interested in following this issue here is a link to the submitted item in Google's issue tracker for .NET.
Submitted Issue
For reference it is issue 492.
I am not quite sure where you see the "the specified limit of 20 requests a second for the Email Migration API". Reminder: the QPS limit you see in the Google Developers Console project is not the actual default limit. You can change that limit to anything you want, and thus, that's not the actual limit for the API. It is really just for managing the consumption of the API quota (some APis will have a much higher QPS where you can adjust it to lower for different projects across your console).
According to the email migration APi documentation, the QPS is 1 request per second (the link is here: https://developers.google.com/admin-sdk/email-migration/v2/limits).
I have experienced 412 errors when the QPS limit is being hit, and I have also seen the 412 error returned when I am uploading too much data to a single domain. How much data are you loading all at once? I would suggest doing an exponential backoff to see if the issue would disappear.
I believe I have found an answer to this problem, though I will advise a disclaimer, I do not work for Google and cannot be 100% sure of the accuracy; you've been warned. This should at least hold true for the .NET version of Google's Email Migration v2 API. I cannot guarantee how other APIs work because I do not use them..
Through working with this API in spurts for well over eight months now, it appears that if an application or multiple applications are to send messages to a single Google Apps user/mailbox consistently, at a faster rate than which Google servers can process, then at some rate you should start to get a bunch of GoogleApiExceptions stating "412 - Limit Reached" when sending new messages. What we have gathered through using our application is that each Google Apps user/mailbox has its own pending items queue. When you send a message to Google Apps it is first put into this queue before being processed by a Google Server and put into the user's mailbox. If this queue becomes full and you attempt to send another message you will receive a 412 error.
Options are to wait before sending another message, you'll have to wait however long the Google server takes to process the next message in the user's queue before sending another; which is unpredictable. The better option in my opinion is to start sending messages to another Google Apps user; because each user appears to have its own message queue. Be sure to stop sending to the user who is consistently getting 412 errors. This will give the Google server some time to process that user's packed message queue. Note each pending messages queue appeared to hold about 100-150 items before throwing 412 errors.
503 errors appear to occur when sending messages into a user's mailbox queue at a higher rate than 1 request per second. As Emily has stated "the QPS limit you see in the Google Developers Console project is not the actual default limit" it is truly 1 QPS per Google Apps user.
As for the exponential back-off it is supposed to be implemented automatically see this. Note Peleyal appears to be the gentleman in charge of the API; can be noted from the download page for the API.
This took us a little while to figure out so cheers if you're having this issue! Please if you find any contradicting information correct any mistakes found in this answer or make your own!!
We are trying to use the NotificationHubClient in Microsoft.ServiceBus.Notifications. We are having a strange problem which the code below shows where we register the Device like so:
NotificationHubClient client = GetHubclient();
var task = client.CreateMpnsNativeRegistrationAsync(deviceToken, tags);
Task.WaitAll(task);
This registers the device fine and if we send a test toast message from the azure portal debug page it comes through to the windows phone without issue. However if we call the following:
var sentTask = client.SendMpnsNativeNotificationAsync(GetPayload());
Task.WaitAll(sentTask);
private static string GetPayload()
{
return "<wp:Notification xmlns:wp=\"WPNotification\"><wp:Toast><wp:Text1>Great News</wp:Text1><wp:Text2>Great News</wp:Text2></wp:Toast></wp:Notification>";
}
No toast notification arrives on the phone and if we then go and try to send a test toast notification again from the debug page of the azure portal it no longer works and the following error is displayed:
The Push Notification System handle for the registration is invalid
None of this is making sense, we have enabled testSend and there are no errors coming back from the client in the code, in fact it says everything was successful the first time even though this appears to break the PNS handle.
Has anyone come across this before?
It turns out that if the Xml declarations are missing:
<?xml version="1.0" encoding="utf-8"?>
Then you can no longer send push notifications to any phones you tried to send a push notification to as it is invalidated. This seems pretty awful, sure don't send the notification if the payload is invalid but why invalidate the PNS.
I'm working on a project which receive notification from GCM server.
I've got the registration ID from GCM server and i send it to my server application which save it in the database.
My device receive the message but when I try to send another one, the precedent is replaced.
I know that we've 2 types of message:
Collapsible "send to sync"
Non-Collapsible
So without changing the name of the message, how can I get two message send at different time?
UPDATE 1:
When my device is offline (for example airport mode activated), I try
to send for example 2 messages from my application server to Google
server (I read that Google stores all the messages). But when I
desactivate this mode, I receive only the last message sent.
I use different collapse_key for different message and I receive all
of them (of course when the device online).
Is anybody knows how can I fix this?
The collapse key is relevant only to messages that were sent to the GCM server but haven't reached the destination device yet (if more than one such message has the same collapse key, only one of them will be sent to the device when it becomes online).
In your question you describe a different situation - the first message is received by the device and then the second message is received by the device and replaces the original message. That has nothing to do with GCM. It has to do with the way your application handles the received messages. For example, if your application code that receives the message displays is as a notification, it's up to you to decide whether a new message will override the existing notification or create a new notification.
You need to make sure that the value of the 'collapse_key' field in each message is different