The part of my application is shown using the information which I retrieve from server's API: the problem is that everything runs well on virtual device, but when I test the app on my phone, the http request doesn't work, so I only see progress indicator, which I set in FutureBuilder.
P. S. INTERNET permission is set in "main" AndroidManifest.
If you working with HTTP files on Android 9+, you also need to add android:usesClearTextTraffic="true" flag in the AndroidManifest.xml
Sorry, it was just a problem with the responding server
I have a sample app that uses Parse Server. I've been testing my app on both emulator and physical devices and I noticed that the response time is much slower on the physical device.
This one is from the emulator.
and this is one is from the physical device:
I've been scratching my head regarding this one. I've also posted it on the parse community platform and followed the advice there to manually monitor the server for every change I've made until I reach my prior server configuration. I overhauled the server from scratch. Do some load testing -> Deployed the server on a replica set -> load testing. Now, I'm in the process of doing some basic queries. I used ADB logcat to see what's happening on both device and saw these errors on the physical device and not on the emulator:
E[N rtchannel]_rt_mqtt_publish_callback(356)=>Failed to publish the request over MQTT. token:be925eea-407c-417d-96c9-3af5a7e83e48, category:mcd-sync-data-task-category, requestId:54138, error:Error Domain=mqtt Code=3008
E[S sync]_createResponseError(166)=>Network Response be925eea-407c-417d-96c9-3af5a7e83e48 contains sync error Error Domain=mqtt Code=3008 - Underlying error (null): Error Domain=mqtt Code=3008
This one also shows before pulling the payload.
W[S sync-state-machine]MCDSyncStateMachineScheduleDelayedRetry(173)=>skipping the new retry with longer delay
W[S sync]_scheduleNextCursorRetry(326)=>skipping delayed retry due to state machine state decision
The number of times these errors pop up is related to the number of queries executed. I did not put any configurations on the server which use MQTT. Any help is much appreciated.
It started all of the sudden on one device and soon on all my devices and I can't seem to understand what this error even means or how to overcome this.
I am trying to capture the response code while activating the call forwarding using MMI Code via android application as on the phone it just shows activates or deactivates. Anyone if knows the format of the response code or any method other than phonestatelistner kindly suggest.
This service is not supported by google. checkout this issue has been raised https://code.google.com/p/android/issues/detail?id=1285
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.