-
-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic RTCPeerConnection constraint handling #119
Conversation
I've my concerns about this PR. "according to the spec" is no true as the new spec does no longer use Said that, it is also true that the current libwebrtc ObjC implementation still uses the old syntax, but I prefer to move on. |
Got it. My thinking was that you would be looking at the current Chrome WebRTC spec so we could use same code for iOS or Android (using crosswalk or not). |
I don't want to close the PR, but instead think about how to make both specs work together. For example, we could use the current libwebrtc ObjC API (mandatory&optional) within the plugin Swift code, and let the JavaScript layer to do the magic. In that way we can accept both the new and old syntax and convert the user given constraints to the old syntax in the JS layer before passing them to the Swift code. Do you agree? |
That sounds awesome! |
OK, then let me do this next week. I think that your PR is 100% valid with the suggested design. |
@ibc do you have the time to look at this PR this week? |
Unfortunately merging this PR would require some extra minor changes in the plugin JS layer and also in some of my apps at work, and I do not have time for it in the short term. This is not a "not", but a "later". |
@ibc it seems that this PR solves all of our issues as described in https://groups.google.com/forum/#!topic/cordova-plugin-iosrtc/LXAxyw0x2Wo. |
I am hunting a similar issue at the moment but have to admit that as stated in the test repository |
@inspiraluna I have been testing this on internet too, but then with the commercial version of Kurento which is in beta now. It did work when being a only a presenter or only a viewer. Change the var options = {
localVideo: videoPresenter,
onicecandidate : onIceCandidatePresenter
configuration: {
iceServers: [
{
'urls': 'turn:XX.XX.XX.XX',
'username': 'user',
'credential': 'pass'
},
{
'urls': 'turn:XX.XX.XX.XX?transport=tcp',
'username': 'user',
'credential': 'pass'
}
],
'iceTransportPolicy': 'relay'
}
}; And change the var options = {
localVideo: videoViewer,
onicecandidate : onIceCandidateViewer
configuration: {
iceServers: [
{
'urls': 'turn:XX.XX.XX.XX',
'username': 'user',
'credential': 'pass'
},
{
'urls': 'turn:XX.XX.XX.XX?transport=tcp',
'username': 'user',
'credential': 'pass'
}
],
'iceTransportPolicy': 'relay'
}
}; It seems to get a bit better, but still not quite there yet. |
I was working with the eface2face fork of iosrtc and was not aware you have another one. I tried yours - works definitely great. thanks a lot! I also had in my configuration before a stun:173.194.71.127:19302 server. (which should be working just normally) browser2ios and ios2browser worked without testing viewer and presenter on the same device.. (but that will probably come soon) Cheers.
Liebe Grüße Nico M +49 174 9891949 |
I believe this one can be closed down since |
mmm, I don't think so. However, that the libwebrtc ObjC wrapper still require |
You are right I misread the changes the optional and mandatory arrays are still needed. |
Closed in favor of #394 for v6.0.0 |
This commit makes rtc peer connection constraint handling generic. Also it makes it according to the spec, as previously the following dictionary would fail: