I am using TokBox for an app. When doing P2P, one client shows both the local video and the other clients video. The other client only shows the local video and calls -subscriber:didFailWithError: with the error Error Domain=OTSubscriberErrorDomain Code=1 "The subscriber timed out." First, is there a way to change the TokBox timeout time. Second, why might this be happening?
There is no way to change the Timeout time. Second, I think you might have firewall settings that could be preventing streams from being subscribed. Heres a diagnostic tool to help you check your network: http://tokbox.com/tools/connectivity/
Related
I have to add live video streaming in one of my app; I am using Wowza Streaming Cloud for the same. I am using REST Api to make it as my requirement.
The flow I had used is:
Create a stream
Start stream
Check status unless it is "started"
if the status is started, I start broadcasting video.
It goes well sometimes, but sometimes when I try to broadcast even after starting the stream, it says:
Status is idle, An error occurred when trying to connect to host: (code = 15)
Also I see a green screen on player side, and the video on player side is not continuous, it keeps on fluttering.
For Player I used the code provided in sample app.
For Broadcasting I had used GoCoder SDK wherein I set all of the properties like host address, port, app name, stream name, etc.
Do I have to set bitrate or anything?
Where am I wrong?
That error occurs when the entrypoint itself is open for more than 20 minutes without a connection. Once you get an IP returned from the API for the stream, you can connect to it right away. The errors you're getting are showing idle due to lack of connection and it sounds like the timing between starting the event, checking the event, and then finally connecting are hitting this restriction.
I am using the Twilio Network Traversal Service as part of a native application I am working on to perform peer-to-peer remote desktop connections. We implement a subset of the WebRTC protocol stack that is equivalent to the WebRTC data channels (not the WebRTC video and audio protocols). When using a TURN relay, the TURN allocation seems to be invalidated randomly somewhere between a few minutes and a maximum of 12 minutes from the session start. This issue looks very similar to this one, but the proposed workaround (sending silent audio) is not acceptable in my case, since I do not implement the WebRTC audio/video protocols.
I have been pulling my hair on this problem for the last two weeks, and isolated the issue as being the Twilio service itself. To compare, I have used a web based WebRTC data channel demo using firefox and the Xirsys TURN server cloud. I have wireshark captures showing firefox getting disconnected with Twilio just like my native application, while the exact same firefox demo doesn't get disconnected when using the Xirsys servers.
I was using Xirsys originally, but I experienced some instability with their service that made me switch to Twilio, which is why I would rather have Twilio fix this issue instead of going back with Xirsys. At the bare minimum, I would rather have two WebRTC hosting providers I can choose from that I know should work fine. This is why I am taking the time to explain the issue in detail so it can get fixed.
Here are two wireshark captures (with the peer-to-peer data messages filtered out) showing firefox using WebRTC data channels and the Twilio TURN relay servers:
The traffic stops being relayed after 4 minutes in the first capture, and after about 11 minutes in the second capture. In both captures, firefox detects that traffic stops being relayed (at the data channel level) and attempts a graceful disconnection by sending a Refresh request packet with a lifetime of zero. Both graceful disconnections result in a 437 Allocation Mismatch error, indicating that the server doesn't even know about the allocation firefox is trying to close gracefully.
With my native application, this would often take the form of a CreatePermission Request message that fails with a 438 "Wrong nonce" error, which is basically what should happen if a client tries to update the permission on an allocation that no longer exists. The error code 438 usually means "Stale nonce", which is not really an error, but an indication that the nonce has expired and the client should try again using the new nonce contained in the "error" message. It took me a while to figure out, but even if the error code is 438, the error string is not the same. I have observed a true stale nonce error with Xirsys and successfully updated my permission with the new nonce from the error response, so I know I can properly handle this case in my implementation.
Here is the source code for the WebRTC data channel demo I have used:
https://github.com/devolutions/webrtc-demo
For comparison, here is the same firefox data channel demo using the Xirsys TURN server cloud:
In this capture, I have let the demo run for about 16 minutes (it works for much longer than that, the longest I have tried is two hours). We can see that the traffic keeps getting relayed for the entire duration of the session, and CreatePermission requests keep getting sent by firefox with success. At the end, the graceful disconnection is triggered by firefox closing the WebRTC data channel (instead of being closed due to traffic no longer being relayed). As opposed to the Twilio captures, the Refresh request with a lifetime of zero is successful: the Xirsys TURN server still knows about the allocation and sends back a success response, as expected.
It should be noted that the ICMP unreachable errors are normal because I think in this case firefox is no longer listening on the given port when the response comes back. In other words, it sends the Refresh request with a lifetime of zero and doesn't wait for the answer to come back.
For the time being, I have no other choice but to go back with Xirsys, but I would really like if the Twilio Network Traversal Service could be fixed. Let me know if you have more questions regarding the issue.
I have uploaded the wireshark captures here for reference.
EDIT: I have modified the webrtc demo page such that it doesn't close the connection when the ice connection state is set to 'disconnected'. Now I get the real disconnection when the ice connection state goes to 'failed'. However, it effectively didn't change anything, since in this case it takes just a few seconds more for the state to go from 'disconnected' to 'failed'.
Since I have new relevant screenshots and captures, I am updating the original question to clarify certain problems pointed out by Philipp Hancke:
First, here is a new capture with the ice connection state fix (the browser closes the connection only when the state goes to 'failed'):
It's interesting to see that this time, the session stayed up for a whole 18 minutes. This was taken on a saturday morning, so I'm guessing that the issue could be related to the current workload on the twilio servers. However, it failed in the exact same way as it always does so far for me. As a bonus, we even have a valid stale nonce response that is correctly handled by firefox.
However, if we take a different view of the same capture, we can see that the traffic stops being relayed for a solid 30 seconds before firefox considers the connection as being dropped and sends the Refresh request with a lifetime of zero. As in previous captures, the server responds with an Allocation Mismatch error, indicating it doesn't know which allocation firefox is talking about.
The last eight packets being sent are of the same size, so my guess is that they are retransmissions. After 30 seconds of retransmissions, it is likely that SCTP considers the transport as being dropped.
With regards to the refresh request with a lifetime of zero, I did a test where I close the connection early on, from the browser. In this case, the server recognizes the allocation and returns a success response:
The allocation mismatch is the easiest symptom to observe, but in my testing with my native application, I have seen similar errors with Refresh requests for non-zero lifetimes, and with CreatePermission requests (438 "Wrong nonce" error). However, since the browser closes the connection after 30 seconds of data not being relayed, it is hard to observe these errors with the current webrtc demo. If we could change that timeout to 10 minutes, we would see those errors as well.
Excellent problem description!
Without the server log this is hard to determine what goes wrong. I tried with the appear.in TURN servers which run an up-to-date version of coturn and show the same behaviour as the Twilio servers. Xirsys seems to be running a custom version of coturn (Coturn-0.5 'Xirsys Turn Services' from the software field but coturn never had such a version).
In both captures, firefox detects that traffic stops being relayed (at the data channel level) and attempts a graceful disconnection by sending a Refresh request packet with a lifetime of zero.
Not quite. A refresh request with a lifetime of 0 is used to discard an allocation. At that point it does not matter what the server returns as the connection is beyond repair anyway.
This is caused by peerjs closing the peerconnection if the iceconnectionstate changes to disconnected, here in your bundled library version.
This is overly aggressive (and does not even fix things) and we've had a discussion about what the specification should do wrt to trying to fix things with an ice restart here which also links to a great explanation of the disconnected state.
The disconnected state probably happens because a few packets get lost. But this is something that can happen when there is minor congestion. I'd recommend removing the pc.close() in the disconnected case.
If you are looking for other TURN providers, Tokbox provides the same service. For datachannels the latency of a properly run distributed TURN network does not matter as much as for VoIP so you might run your own servers in a single location instead.
I have a problem with Stream Management. I have added the following settings in my ejabberd.yml
stream_management: true
resume_timeout: 5
resend_on_timeout: true
The function of stream management working fine. i got the all message after resumption of connection. The main issues is before getting connection resumption, if client send me message in between then i got all in between message two times. How to manage queue on ejabberd server to work fine i.e. (how getting message in sequence as send) and avoid getting repeated message.
You cannot get reliable delivery without having duplicated message in some situation. When that happens you need to use message id to undupe the messages on the client side.
When I set up NSURLSession/Alamofire.Manager with a background session configuration, if there is no internet connection, I'm expecting to receive the usual NSError "Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline.".
This happened regularly if I'm not using a background configuration, but if I do such configuration my callback/delegate method will never be called. It will eventually be called when I activate the wifi again.
I'd prefer to receive an error straight away. Am I missing something?
The reason that why the network failure in background session task does not return any error is:
In general an NSURLSession background session does not fail a task if
something goes wrong on the wire. Rather, it continues looking for a
good time to run the request and retries at that time. This continues
until the resource timeout expires (that is, the value in the
timeoutIntervalForResource property in the NSURLSessionConfiguration
object you use to create the session). The current default for that
value is one week!
I found the above answer at developer forum.
More details which might help in the background session:
Another benefit is that in a background session, we monitor the
network and power environment for you. This means that we cover things
like network reachability and connectivity for you, so you don't have
to use the reachability APIs at all. We won't attempt to establish a
connection until we know that the server is reachable. And similarly,
if the user is performing a download and steps out of Wi-Fi, normally
that task would then fail with a transmission error. But, in a
background session, we'll actually recover from that automatically and
retry it and resume where we left off if the download is resumable.
And you won't hear about that error.
Source: WWDC 2014
The API doesn't tell you that the network is not present, because that would be an error, indicating that the connection will never finish. In reality, it will, assuming the network eventually comes back.
If you need to receive the error for some reason, don't use a background session.
Alternatively, if you just want to know whether the network is up or not for some sort of UI hint, use the reachability API. With that said, don't refuse to start the request based on failed reachability, because reachability lies.
I have some code that has been in production for a while now and all of a sudden doesn't work at all. I am getting an error that looks like:
[S3Response connection:didFailWithError:]|234|UserInfo.NSUnderlyingError = Error Domain=kCFErrorDomainCFNetwork Code=-1005 "The network connection was lost." UserInfo=0x15514d30 {NSErrorFailingURLKey=https://our-bucket-name.s3.amazonaws.com/t46945%2Fx0f04n77vo3724ky_3000.mp4}
There is also an issue where the SDK calls both the request:didFailWithError: and request:didCompleteWithResponse: are both called for a single request. I was doing some digging and saw there is a similar issue for GetObject.
We are getting a crash because when we start a request we enter a dispatch group and leave it on the completion or failure of the request but when both all called it throws an exception and crashes the app.
Any help as to why this is happening would be great.
After running the network connections through my computer and using Charles to inspect the traffic it turns out that Amazon was returning an error for RequestTimeTooSkewed but it doesn't make it to the error. The devices had their times manually adjusted. I now have a server side api endpoint to get the current server time and calculate the device difference. You can then set the runtimeClockSkew by calling [AmazonSDKUtil setRuntimeClockSkew:difference];