I am having trouble sending a message to a device through the company proxy.
I have done the GCM tutorial on the google site and have successfully registered a device on the google servers with the android emulator,
and also on the server at my end.
For this I had to go through the company proxy, setting it in the access point of the emulator.
Now the problem I have is sending a message from my server to the device through the same proxy.
I am using the servlet code from the demo which uses the
com.google.android.gcm.server.Sender
helper class to send the message.
I am running the servlets on tomcat 7.
I have tried setting the proxy up in the catalina.properties file like so.
http.proxyHost=proxy.company.com
http.proxyPort=8080
And I have tried setting properties inside the servlet itself like below.
System.setProperty("http.proxyHost", "proxy.company.com");
System.setProperty("http.proxyPort", "8080");
But still I get the timeout.
I know its the company proxy because I got the messaging working at home where I have no proxy.
I have seen a proxy object created in the java code and then a connection created with it, but I dont think that is usable here since I am using Sender helper class to send the message.
This is the line that fails in a timeout.
Result result = sender.send(message, registrationId, 5);
Any help would be appreciated.
Regards
Bill
Alright, I finally have it working. In my comment I mentioned that I had succeeded in sending out the message, but the emulator was not recieving it. I had forgotten to follow my own earlier advice and run the emulator from the command line with the proxy parameters set like so:
emulator.exe -avd avd22google -http-proxy proxy.company.com:8080 -debug-proxy
So to summarise, my initial problem was that I had registered the emulator on the with GCM and with my local server, but the when I clicked send message I was getting a timeout.
I initially thought it was the firewall so I did some research and set up the proxy in tomcats catalina.properties file.
This made no difference.
I used the "Charles" web proxy debugger software to see where the message was attempting to be sent to and it came up with https://android.googleapis.com:443
So I initially I added the following to my catalina.properties file:
https.proxyHost=proxy.company.com
https.proxyPort=443
It still did not work. A colleague of mine told me that our company proxy handles all types of requests through port 8080, so I changed the the poort line to:
https.proxyPort=8080
This allowed the message to be sent out.
But then the message was not getting through to the emulator and I was receiving the following error in LogCat.
[GTalkConnection.12] doConnect: caught XMPPError connecting to mtalk.google.com:5228.: -- caused by: java.net.SocketException: The operation timed out
Then I remembered that you need to start the emulator with the command line to get it to use the proxy. Once I did this a flood of messages appeared on my emulator!
So I finally have it working end to end. It's taken me about a week to get GCM fully working within my company firewall, so hopefully this post can help some other poor sod doing this in the future.
cheers
Bill
Related
I am getting the error "It is impossible to create a new session because 'createSession' which takes HttpClient, InputStream and long was not found or it is not accessible"
also my Appium server gets killed autometically after this error in console.
Please help to resolve.
The error may occurs from various reason. You need to check your appium server log to know the exact cause. Beside that you can verify following.
Start your appium server in session-override option.
Make sure your appium server is running.
Make sure your are using correct url of appium server.
Confirm your device is properly connecting to the laptop. You can verify it by using adb devices command (for android). Make sure it is showing only one device.
Make sure your DesiredCapabilities are correct or all required desired capabilities are included.
Try re-starting the appium server.
I am using below code to connect to MQTT server
MqttConnectOptions options = new MqttConnectOptions();
options.setCleanSession(true);
options.setKeepAliveInterval(Constants.CLOUD_KEEP_CONN_ALIVE);
byte[] payload = String.valueOf(0).getBytes((Charset.defaultCharset());
options.setWill("willTopic", payload, 0, true);
mAndroidAsyncClient.connect(options, this);
Once connected I get a callback . Now my question is how to debug in server , that setWill is working using mosquitto_sub .
I am using setWill to know client presence.
To confirm setWil is working I wanted to debug from server by subscribing to willtopic and get logs .
I tried connecting and disconnecting many times but there is message sent over will topic.
Command I used on server is
mosquitto_sub -t appTopic --will-topic willTopic
It will be helpful if anyone share the command or way to debug Mqtt setWill.
I tried referring to How to Find Connected MQTT Client Details . But it did not workout for me.
The only real way to test that the LWT (Last Will & Testement) message gets sent is to make the broker send it.
To do this you will have to cause a none clean shutdown of the client, given this is on android the easiest way would be to run the app in the emulator, let it connect then kill the emulator (You have to do this because last time I tried to get the emulator to disable all network activity I discovered it just sent the Network Down broadcasts but left the network up). Once the keep alive period expires and the broker notices the client has gone it should publish the LWT message and you should be able to see this with mosquitto_sub.
There may be ways to query the broker for a given LWT message but this would be totally dependant on the broker you are using. I'm not aware of any brokers that make this easy, but there may be something under the '$SYS/#' topic tree on brokers that support that interface.
EDIT:
Also when using mosquitto_sub you should just be using the -t not --will-topic. --will-topic is the topic that mosquitto_sub would publish it's own LWT on if it was disconnected. You can have as many -t options as you need, and -v will print the topic name before the message body so you can tell them apart
mosquitto_sub -v -t appTopic -t willTopic
I'm implementing GCM for Android based on the Android sample code:
https://code.google.com/p/gcm/source/browse/#git%2Fgcm-client%2FGcmClient%2Fsrc%2Fmain%2Fjava%2Fcom%2Fgoogle%2Fandroid%2Fgcm%2Fdemo%2Fapp
and the server sample code:
https://developer.android.com/google/gcm/ccs.html
at the bottom of the page under Python sample.
After substituting my API key and sender ID, it worked for sometime at my office, and then stopped working (there's no exchange of messages, the server only sends out a "Bad registration" message and keeps waiting), then back to normal the next day. Now it stops working again.
I then tried the server code again at home, it's even worse:
Invalid debugflag given: socket
DEBUG:
DEBUG: Debug created for build/bdist.macosx-10.10-intel/egg/xmpp/client.py
DEBUG: flags defined: socket
DEBUG:
with not even a "Bad registration" message.
I suspect mostly the problem would be with the server, but I don't know if it's blocked by the network administrator (it shouldn't be). I've examined the possible registration problems, and it seems the registration id only gets messed up when there's an update. Any ideas what's happening here? TIA.
Having a problem with the android sipdemo timing out when making calls. The native sip client on the phone has no issues calling, works perfect. Its When i initiate the call within the sipdemo i get a timeout in the logcat. timeout is set to standard of 30 seconds.. a local asterisk box is what its connecting to. Registers fine.
I'm having the same problem.
I traced packages in wireshark and here's what I found:
I register to SIP server in SipDemo
I register to SIP server on Desktop (using Ekiga)
I place a call in SipDemo to Ekiga.
INVITE message gets sent to Ekiga
Trying is sent from Ekiga to the server
Ringing is sent from Ekiga to SipDemo
I answer the call on Ekiga client
OK (with session description) is sent from Ekiga to SipDemo. This happens 11 times before Ekiga just gives up
BYE is sent from Ekiga client to SipDemo
Please note that OK is being sent 11 times before Ekiga just gives up and ends the call. This is why the call lasts just 30 seconds.
If you take a look at the RFC here:
http://www.ietf.org/rfc/rfc3261.txt section 13.3.1.4
you can see that the reason Ekiga is giving up on SipDemo client is because it never gets ACK back from SipDemo.
I believe this is android bug, but I can't imagine they could have missed something this basic in their SIP implementation.
In the next few days, I'll try to dig up some answers in android source code...
I'll try see what happens when establishing calls between 2 SipDemo applications. If it works, that means android just ignores ACK all together.
EDIT:
I just tried a call between 2 SipDemo clients. It sends OK 5 times and gives up on the OK, but does not end the call. Interesting behavior :)
EDIT2:
I dug up androids SIP implementation, and I found that ACK should get sent... Even logcat logs this, but I still see nothing in Wireshark. I thought maybe it gets blocked or something, so I ran Shark (like Wireshark for android) on the device, pulled the dump to my laptop, opened it up in Wireshark, and I don't see ACK anywhere. I even looked trough all packets... No filters, just in case I might be filtering it out. Anyways... Here's what I found in android code:
http://hi-android.info/src/com/android/server/sip/SipSessionGroup.java.html
class: SipSessionImpl
method: private boolean outgoingCall(EventObject evt)
in case Response.OK:
you can see this call:
mSipHelper.sendInviteAck(event, mDialog);
In SipHelper, method sendInviteAck, you can see:
if (DEBUG) Log.d(TAG, "send ACK: " + ack);
dialog.sendAck(ack);
Dialog is nist javax.sip, so I don't think there's a need to go further...
I see this message "send ACK" in my logcat when running the application
EDIT3:
I noticed that this issue occurs only with some SIP servers. I now tried opensips, and it works fine. I guess the problem I was having had to do with the server responding to androids keep-alive OPTIONS messages with 404 Not Found. Then, android tried to not use the server as soon as possible. Because of that, as soon as android got the address of its peer client, it tried to send a direct message, and failed
Hard to tell just like that. Try capturing the packages with wireshark, filter for the SIP protocol and have a look at what is sent over the network. Also try it with the native client and compare it to the sipdemo.
Another starting point is the log of your asterisk instance (systemlog)
If you can't figure it out yourself, post the results here.
I am developing an application that will make SIP calls using the SIP APIs. I want to use the SipDemo code as my starting point, but when I run SipDemo on my devices (Nexus or Galaxy Tab) I always get "Registration failed. Please check settings." I am using the same username/password/server information that works successfully in Sipdroid.
I inserted log messages in setRegistrationListener to follow what's happening, and I will see onRegistrationDone fire, but then it seems to register again, because it will then see Registration failed with the error message "registration timed out" followed by registration failed with the error message "cannot initiate a new transaction to execute".
I've been beating my head about this for a few days, and I've got a deadline rapidly approaching. Any help on this issue would be greatly appreciated, or if you could point me to some other examples/tutorials of how to use the SIP APIs.
I fixed it! The demo wants to use UDP by default, but I was able to make it connect by hardcoding the protocol to TCP. I have a netgear modem from charter cable, and I have seen several reports of it blocking access. I assume the two are related, but for now I'm just happy to have it work so I can continue my development.
Thanks for the help!
Check the logcat, it should have more information about what failed. Also if you have control over the server, check the server logs as well.
Seems like you are not alone http://code.google.com/p/sipdroid/issues/detail?id=60.
I would suggest that you try what people tried there: i.e.
Try another router.
Change port in code. Read the link for more details.