I'm using libjingle_peerconnection installed with cocoapods. When I receive SDP offer through signaling server from my caller, I'm trying to set this as a remote description, which triggers RTCSessionDescriptionDelegate peerConnection:didSetSessionDescriptionWithError:
with error:
Error Domain=RTCSDPError Code=-1 "(null)" UserInfo={error=Failed to set remote answer sdp: Called in wrong state: STATE_INIT}.
My code is:
- (void)transportChanell:(TransportChannel *)channel didReceivedSignalWithSessionDescription:(NSString *)sessionDescription withType:(NSString *)type {
RTCSessionDescription *remoteDesc = [[RTCSessionDescription alloc] initWithType:#"answer" sdp:sessionDescription];
[_peerConnection setRemoteDescriptionWithDelegate:self sessionDescription:remoteDesc];
}
I've investigated the problem quite a lot and found in webRTC source code the place, as I suppose, this error comes from BadRemoteSdp(type, BadStateErrMsg(state()), err_desc); and all possible states of WebRtcSession are:
STATE_INIT = 0,
STATE_SENTOFFER, // Sent offer, waiting for answer.
STATE_RECEIVEDOFFER, // Received an offer. Need to send answer.
STATE_SENTPRANSWER, // Sent provisional answer. Need to send answer.
STATE_RECEIVEDPRANSWER, // Received provisional answer, waiting for answer.
STATE_INPROGRESS, // Offer/answer exchange completed.
STATE_CLOSED, // Close() was called.
Any suggestions, please, what could I missed in caller or callee side?
The offer seems to be marked as an "answer" according to the error message. It fails because it then expects you to be in the STATE_SENTOFFER state.
If you have created an offer and sent it to the other party, you may have forgotten to call setLocalDescription first. If you did not send an offer from the failing client, the other party should be changed to send an offer instead of an answer.
In the event this helps anyone coming here from Google:
I ran into this problem myself, and it turned out I'd hastily copy-pasted some code from the offerer I'd written. So I was init'ing RTCSessionDescription with type RTCSdpTypeAnswer instead of RTCSdpTypeOffer.
Make sure when allocating your RTCSessionDescription that you're using the right type!
Related
I'm trying to send packets over CoAP between two TI 2650 sensortags. I used the logic from the "er-rest-example" provided by contiki 3.0, that is:
coap_init_message(request, COAP_TYPE_CON, COAP_POST, 0);
coap_set_header_uri_path(request, url);
coap_set_payload(request, (uint8_t*)msg, sizeof(msg) - 1);
COAP_BLOCKING_REQUEST(&server_ip, REMOTE_PORT, request, client_chunk_handler);
When I started the program, it works as expected until the first time COAP_BLOCKING_REQUEST is called, at which point the program seems to freeze (doesn't react to button presses anymore).
So I assume COAP_BLOCKING_REQUEST blocks until it receives a response, which is not suitable for my project. Can anyone confirm that?
UPDATE:
Going forward from that assumption, my question now is, what steps to I have to take to send out a packet?
Do I use the coap_send_message function from er-coap.c or the coap_send_transaction function from er-coap-transaction.c?
I want to figure out what functions I have to call in which order to configure the packet correctly and then send it out with the correct function (which I guess would be one of the above).
Maybe there is some documentation out there that I haven't found yet and someone could point me to it?
Cheers
I get this error message
The connection to service named com.apple.gamed was interrupted, but
the message was sent over an additional proxy and therefore this proxy
has become invalid.
sometimes when calling
loadMatchesWithCompletionHandler:^(NSArray *matches, NSError *error)
What does it mean?
I'm on iOS 9.3.2
This is the worst possible answer, but it's my own experience with loading matches, I'm sorry to say: sometimes it works, sometimes it doesn't. I've received this error message before, and then had it go away after no code changes at all. Just try again.
Ok now I have more findings. Forget my comment to the other answer.
In my case I got the message when I did not use the #escaping keyword on a closure parameter of a function (using Swift 3 where closures are by default non-escaping). This function was called with a closure that did not refer to self (because it was not needed). However, that function called another function, forwarding the closure.
So in the end my closure ended up without a reference.
I recommend you keep a copy of your block that you use as an argument to loadMatchesWithCompletionHandler. This way the block is not released prematurely.
This also explains why the error occurs just sometimes and not always. It's typical for memory release issues.
I want know failed attempt.How many times user tried to log in.I am using this plugin compile ":spring-security-core:2.0-RC4".
Is it possible to find out failed attempts.
Thanks
To do this you will need to record/track them using the events provided by the plugin. Check the documentation for further information.
Specifically you will be interested in the AuthenticationFailureBadCredentialsEvent event or even more generically the AbstractAuthenticationFailureEvent (as Gaurav has pointed out in the comments).
#Joshua's answer is close but not complete as it wouldn't catch authentication failures for reasons other than "bad credentials". AbstractAuthenticationFailureEvent seems to be the best choice. Refer to the section Registering Callback Closures of the documentation...
grails.plugin.springsecurity.useSecurityEventListener = true
grails.plugin.springsecurity. onAbstractAuthenticationFailureEvent = {
e, appCtx -> // handle AbstractAuthenticationFailureEvent
}
…or you could implement ApplicationListener<AbstractAuthenticationFailureEvent> as described in the section Registering an Event Listener
I've been trying to use Corona SDK's Facebook API to post the score on the game I'm developing on facebook. However, I'm having a problem with it. During the first time I try to post to facebook, I get this error after login and user authentication:
NSURLErrorDomain error code -999
Then, it won't post on facebook. What are possible causes of this error and how can I address it?
By the way, I am not using webview on my app. Just the widget api and a show_dialog listener in my Facebook class.
The error has been documented on the Mac Developer Library(iOS docs)
The concerned segment from the documentation will be:
URL Loading System Error Codes
These values are returned as the error code property of an NSError
object with the domain “NSURLErrorDomain”.
enum
{
NSURLErrorUnknown = -1,
NSURLErrorCancelled = -999,
NSURLErrorBadURL = -1000,
NSURLErrorTimedOut = -1001,
As you can see; -999 is caused by ErrorCancelled. This means: another request is made before the previous request is completed.
Just wanted to add here, when receiving a -999 "cancelled" the problem usually is one of two things:
You're executing the exact same request again.
You're maintaining a weak reference to your manager object that gets deallocated prematurely. (Create strong reference)
hjpotter92 is absolutely right, I just want to provide solution for my case. Hopefully it is useful for you as well. Here is my situation:
On log in page > press log in > pop up loading dialog > call log in service > dismiss dialog > push another screen > call another service --> cause error -999
To fix it, I put a delay between dismissing dialog and pushing new screen:
[indicatorAlert dismissWithClickedButtonIndex:0 animated:YES];
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 0.01 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{
[self performSegueWithIdentifier:#"HomeSegue" sender:nil];
});
It is strange that this issue happens on iOS 7 only.
I have faced the same error with Alamofire and it was because the certificate pinning.
The certificate wasn't valid anymore, so I had to remove it and add the new one.
Hope it helps.
In addition to what Ramon wrote, there is a third possible reason when receiving a NSURLErrorDomain -999 cancelled:
You cancelled the task while it was executing either by calling .cancel() on the datatask object or because you used .invalidateAndCancel() on the session object. If you are creating a custom session with a delegate, you should call .invalidateAndCancel() or .finishTasksAndInvalidate() to resolve the strong reference between the session and its delegate, as mentioned in the Apple Developer Documentation:
The session object keeps a strong reference to the delegate until your app exits or explicitly invalidates the session. If you don’t invalidate the session, your app leaks memory until it exits.
If you are wondering about this logging behaviour, I found the following explanation in the Apple Developer forums:
By way of explanation, back in iOS 10 we introduced a new logging system-wide logging architecture (watch WWDC 2016 Session 721 Unified Logging and Activity Tracing for the details) and lots of subsystem, including CFNetwork, are in the process of moving over to that. Until that move is fully finished you’re going to encounter some weird edge cases like this one.
I didn't use Corona SDK's Facebook API but I encountered this problem when using Alamofire, the secondRequest always cancel in execution with the error -999, according to the posts I found on internet, the reason is that session property is deinit before completion of async work since it is out of the scope, I finally solved this problem by deinit the session property manually so the compiler won't deinit it at wrong position:
class SessionManager {
var session:SessionManager?
init() {
self.session = SessionManager(configuration:URLSessionConfiguration.ephemeral)
}
private func firstRequest() {
guard let session = self.session else {return}
session.request(request_url).responseData {response in
if let data=response.data {
self.secondRequest()
}
}
private func secondRequest() {
guard let session = self.session else {return}
session.request(request_url).responseData {response in
if let data=response.data {
self.secondRequest()
}
//session will no longer be needed, deinit it
self.session = nil
}
}
Our company's app has many -999 error in iOS. I have searched around, find the reason has two, like the network task has been dealloc or the certificate isn't valid. But I have checked our code, these two aren't possible. I am using Alamofire
which is using URLSession. Luckily, our company's android app's network is normal. So we check the difference. We found the http request from iOS is Http2.0, while android is Http1.1. So we force the backend http support version down to http1.1, then -999 error count descends!!!
I think there maybe some bug in Apple's URLSession. Check the link New NSURLSession for every DataTask overkill? for some detail thoughts
Please check If you call cancel() on URLSessionDataTask to fix
NSURLErrorDomain Code=-999 "cancelled"
I was getting this error in iOS specific version of Xamarin app. Not sure the underlying cause, but in my case was able to work around it by using post method instead of get for anything passing the server context in the request body -- which makes more sense anyway. Android / Windows / the service all handle the GET with content, but in iOS app will become partially unresponsive then spit out the 999 NSUrlErrorDomain stuff in the log. Hopefully, that helps someone else running into this. I assume the net code is getting stuck in a loop, but could not see the code in question.
For my Cordova project (or similar), turns out it was a plugin issue. Make sure you're not missing any plugins and make sure they're installed properly without issue.
Easiest way to verify this is simply to start fresh by recreating the Cordova project (cordova create <path>) along with the required platforms (cordova platform add <platform name>) and add each plugin with the verbose flag (--verbose) so that you can see if anything went wrong in the console log while the plugin is being downloaded, added to project and installed for each platform (cordova plugin add cordova-plugin-device --verbose)
Recap:
cordova create <path>
cordova platform add <platform name>
cordova plugin add cordova-plugin-device --verbose
For my case, I used an upload task post that did not need body contents:
// The `from: nil` induces error "cancelled" code -999
let task = session.uploadTask(with: urlRequest, from: nil, completionHandler: handler)
The fix is to use zero byte data instead of nil,
let task = session.uploadTask(with: urlRequest, from: Data(), completionHandler: handler)
The framework documentation doesn't specify why the from bodyData is an optional type, or what happens when it is nil.
We solved this problem by reloading the web view when it failed loading.
extension WebViewController: WKNavigationDelegate {
func webView(_ webView: WKWebView, didFail navigation: WKNavigation!, withError error: Error) {
webView.reload()
}
}
I'm trying to implement support for Apple's enhanced Push Notification message format in my Rails app, and am having some frustrating problems. I clearly don't understand sockets as much as I thought I did.
My main problem is that if I send all messages correctly, my code hangs, because socket.read will block until I receive a message. Apple doesn't return anything if your messages looked OK, so my program locks up.
Here is some pseudocode for how I have this working:
cert = File.read(options[:cert])
ctx = OpenSSL::SSL::SSLContext.new
ctx.key = OpenSSL::PKey::RSA.new(cert, options[:passphrase])
ctx.cert = OpenSSL::X509::Certificate.new(cert)
sock = TCPSocket.new(options[:host], options[:port])
ssl = OpenSSL::SSL::SSLSocket.new(sock, ctx)
ssl.sync = true
ssl.connect
messages.each do |message|
ssl.write(message.to_apn)
end
if read_buffer = ssl.read(6)
process_error_response(read_buffer)
end
Obviously, there are a number of problems with this:
If I'm sending messages to a large number of devices, and the failure message is sent half way through processing, then I'm not going to actually see the error until I've already tried to send to all devices.
As mentioned earlier, if all messages were acceptable to Apple, my app will hang on the socket read call.
One way I've tried to solve this is by to reading from the socket in a separate thread:
Thread.new() {
while data = ssl.read(6)
process_error_response(data)
end
}
messages.each do |message|
ssl.write(message.to_apn)
end
ssl.close
sock.close
This doesn't seem to work. Data never seems to be read from the socket. This is probably a misunderstanding I have about how sockets are supposed to work.
The other solution I have thought of is having a non-blocking read call... but it doesn't seem like Ruby has a non blocking read call on SSLSocket until 1.9... which I unfortunately cannot use right now.
Could someone with a better understanding of socket programming please point me in the right direction?
cam is correct: the traditional way to handle this situation is with IO.select
if IO.select([ssl], nil, nil, 5)
read_buffer = ssl.read(6)
process_error_response(read_buffer)
end
This will check ssl for "readability" for 5 seconds and return ssl if it's readable or nil otherwise.
Can you use IO.select? It lets you specify a timeout, so you could at limit the amount of time you block. See the spec for details: http://github.com/rubyspec/rubyspec/blob/master/core/io/select_spec.rb
I'm interested in this too, this is another approach, unfortunately with it's own flaws.
messages.each do |message|
begin
// Write message to APNS
ssl.write(message.to_apn)
rescue
// Write failed (disconnected), read response
response = ssl.read(6)
// Unpack the binary response and print it out
command, errorCode, identifier = response.unpack('CCN');
puts "Command: #{command} Code: #{errorCode} Identifier: #{identifier}"
// Before reconnecting, the problem (assuming incorrect token) must be solved
break
end
end
This seems to work, and since I'm keeping a persistent connection, I can without problems reconnect in the rescue code and start over again.
There are some issues though. The main problem I'm looking to solve is disconnects caused by sending in incorrect device tokens (for example from development builds). If I have 100 device tokens that I send a message to, and somewhere in the middle there is an incorrect token, my code lets me know which one it was (assuming I supplied good identifiers). I can then remove the faulty token, and send the message to all devices that appeared after the faulty one (since the message didn't get sent to them). But if the incorrect token is somewhere in the end of the 100, the rescue doesn't happen until the next time I send messages.
The problem seams to be that the code isn't really in real time. If I were to send in, say, 10 messages to 10 incorrect tokens with this code, everything would be just fine, the loop will go through and no problems will be reported. It seems that write() doesn't wait for everything to clear up, and the loops runs through before the connection is terminated. The next time the loop will be run, the write() command fails (since we've actually been disconnected since the last time) and we would get the error.
If there is an alternative way to respond to the failed connection, this could solve the problem.
There is a simple way. After you write your messages, try reading in nonblocking mode:
ssl.connect
ssl.sync = true # then ssl.write() flushes immediately
ssl.write(your_packed_frame)
sleep(0.5) # so APN have time to answer
begin
error_packet = ssl.read_nonblock(6) # Read one packet: 6 bytes
# If we are here, there IS an error_packet which we need to process
rescue IO::WaitReadable
# There is no (yet) 6 bytes from APN, probably everything is fine
end
I use it with MRI 2.1 but it should work with earlier versions too.