Warning(openssladapter.cc:407): OpenSSLAdapter::Error(SSL_write, -1)

[seankovacs]

I get this error after about 35+ minutes of idle. Here is some more bits of the log:

Thu May 16 14:58:00 2013 | Processing PingTask
Thu May 16 14:58:00 2013 | Processing PingTask
Thu May 16 14:58:10 2013 | Processing PingTask
Thu May 16 15:04:00 2013 | Processing PingTask
Thu May 16 15:04:00 2013 | Processing PingTask
Thu May 16 15:04:10 2013 | Processing PingTask
Thu May 16 15:10:00 2013 | Processing PingTask
Thu May 16 15:10:00 2013 | Processing PingTask
Thu May 16 15:10:10 2013 | Processing PingTask
Thu May 16 15:16:00 2013 | Processing PingTask
Thu May 16 15:16:00 2013 | Processing PingTask
Thu May 16 15:16:10 2013 | Processing PingTask
Thu May 16 15:22:00 2013 | Processing PingTask
Thu May 16 15:22:00 2013 | Processing PingTask
Thu May 16 15:22:10 2013 | Processing PingTask
Thu May 16 15:31:40 2013 | Processing PingTask
Thu May 16 15:31:40 2013 | OpenSSLAdapter::OnCloseEvent(54)
Thu May 16 15:31:50 2013 | Processing PingTask
Thu May 16 15:37:40 2013 | Warning(openssladapter.cc:407): OpenSSLAdapter::Error(SSL_write, -1)

I noticed you posted some new code regarding ping task. Could that resolve?

[lukeweber]

Ping fails to get a response so it calls disconnect.

Which phone are you on? My personal guess is what seemed like it worked
before actually wasn't. If you wait for a offline event and reconnect
that's one solution because I'm disconnecting now when ping fails. As well
I see three ping tasks which makes me wonder if you called login three
times? In addition nexus has a sleep mode where all traffic is blocked, in
which case reconnect wouldn't work.
On May 16, 2013 9:43 PM, "Sean Kovacs" [email protected] wrote:

I get this error after about 35+ minutes of idle. Here is some more bits
of the log:

Thu May 16 14:58:00 2013 | Processing PingTask
Thu May 16 14:58:00 2013 | Processing PingTask
Thu May 16 14:58:10 2013 | Processing PingTask
Thu May 16 15:04:00 2013 | Processing PingTask
Thu May 16 15:04:00 2013 | Processing PingTask
Thu May 16 15:04:10 2013 | Processing PingTask
Thu May 16 15:10:00 2013 | Processing PingTask
Thu May 16 15:10:00 2013 | Processing PingTask
Thu May 16 15:10:10 2013 | Processing PingTask
Thu May 16 15:16:00 2013 | Processing PingTask
Thu May 16 15:16:00 2013 | Processing PingTask
Thu May 16 15:16:10 2013 | Processing PingTask
Thu May 16 15:22:00 2013 | Processing PingTask
Thu May 16 15:22:00 2013 | Processing PingTask
Thu May 16 15:22:10 2013 | Processing PingTask
Thu May 16 15:31:40 2013 | Processing PingTask
Thu May 16 15:31:40 2013 | OpenSSLAdapter::OnCloseEvent(54)
Thu May 16 15:31:50 2013 | Processing PingTask
Thu May 16 15:37:40 2013 | Warning(openssladapter.cc:407):
OpenSSLAdapter::Error(SSL_write, -1)

I noticed you posted some new code regarding ping task. Could that resolve?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/98
.

[seankovacs]

iOS - Single login has always produced 3 pings. Not sure why. Single login that is left unattended for a longer duration results in that error mentioned. The same was happening when the app would go to the background, so I "fixed" that by disconnection prior to going in the background and logging back in once the app resumes. Though if an app never goes to the background and just chills for a bit, this error occurs.Though I think when the phone goes inactive, the connect is probably dropped by Apple. If anything I want it to fail gracefully. So I'm moving over some of your ping task commit code and see if that resolves.

[seankovacs]

I'll run the code from the webrtc repo directly and see what it yields.

[lukeweber]

Ah on apple you need to implement the always open socket for VoIP apps.
Ping type task would then have to be managed through a callback on that
socket as part of the iOS sdk. They do a callback on a timer for you to
execute a ping as part of said system whereby you'll have 10 seconds.

Example of socket linked below. I think some of the changes from @hailg
might have this but haven't looked. Either way with xmppframework and the
new iOS example app you wouldn't have pingtask enabled and would use the
equivalent from xmppframework. In addition setting this special socket up
should be much easier as libjingle now uses the native iOS socket of
xmppframework.

http://stackoverflow.com/questions/6601536/ios-voip-socket-will-not-run-in-background
On May 16, 2013 10:11 PM, "Sean Kovacs" [email protected] wrote:

I'll run the code from the webrtc repo directly and see what it yields.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/98#issuecomment-18025889
.

[lukeweber]

See tips for developing a voip app:
http://developer.apple.com/library/ios/#documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/AdvancedAppTricks/AdvancedAppTricks.html#//apple_ref/doc/uid/TP40007072-CH7-SW14

[lukeweber]

Keepalive logic example:
third_party/xmppframework/Xcode/iPhoneXMPP/Classes/iPhoneXMPPAppDelegate.m

• (void)applicationDidEnterBackground:(UIApplication *)application

Which you could use and put into:
ios/VoiceClientExample/AppDelegate.mm

Socket that is used under the hood, and method to tag the socket with voip capability:
third_party/xmppframework/Vendor/CocoaAsyncSocket/GCDAsyncSocket.m
enableBackgroundingOnSocketWithCaveat

[lukeweber]

Okay, well you said you have the backgrounding working on the socket.

If you want to try out code from Hailg just follow the instructions in README now as it's all merged. You're on an old version of everything at this point, so it's hard to speculate or help too much. I think we might have solved the multiple ping issue in our code.

Main concern then would be the keepalive handler and maybe a server timeout, but could be anything really. If you want it to run in the background, you'll have to do your ping inside the special iOS handler.

Based on the documentation, on iOS "The minimum allowable interval for running your handler is 600 seconds" so this would be in violation at 6 minutes or 360 seconds of the PingTask interval, as well as the fact that it runs in it's own socketserver.

Anyways best of luck and if you have any specific changes or fixes, feel free to improve and send a pull request.

[seankovacs]

What I did to maintain voip calling when the app closes (if you're on a call still) is add the following to the *socketserver.cc:

  CFReadStreamRef readStream;
  CFWriteStreamRef writeStream;
  CFStreamCreatePairWithSocket(kCFAllocatorDefault, s_, &readStream, &writeStream);
  CFReadStreamSetProperty(readStream,kCFStreamNetworkServiceType,kCFStreamNetworkServiceTypeVoIP);
  CFWriteStreamSetProperty(writeStream,kCFStreamNetworkServiceType,kCFStreamNetworkServiceTypeVoIP);
  CFReadStreamOpen(readStream);
  CFWriteStreamOpen(writeStream);

While I'm not interested in receiving calls while in the background, that will raise a interesting problem since you can only have those flags on 1 socket at a time, otherwise iOS will kill them all. So it's almost like we need to remove those properties from the data socket and apply it to the xmpp socket if we're not on a call. Because xmpp is the driver for incoming calls while in the background. I have yet to get to that point. I tried hailg's xmpp version he posted on Mega but I couldn't get it to make a call - haven't really dug into it yet though.

I think related to this current issue - you're right, I think I just need to add the keepalive callback and do the pings. I'm disconnecting the connection when it goes into the bg, so it doesn't matter too much.

Regarding xmpp-ios vs libjingle-xmpp ... I would most likely stick with the libjingle version since its already baked in. I just don't have the time to redo my code to work with the xmpp-ios version (delegates and whatnot). I'm sure if we dug into what makes it work in the bg, it would end up being similar properties mentioned above.

[lukeweber]

If you follow the instructions in the README of this project that does work
and build and it is hailigs code, that was in that link. His link predates
a working merge.

You probably would want a fresh checkout though so you don't mess up your
fork. Current master would no longer work as well with the old way that
you're using it, but could if you remove XMPP_FRAMEWORK var from
libjingle.gyp