unable to get remote stream in case when a “remote stream” is attached by calling “peer.addStream(remoteStream) #2
Comments
|
unable to generate ice candidates (on the answerer side) when attaching remote stream.. a=candidate:2437072876 1 udp 2113937151 192.168.1.2 54082 typ host generation 0 --------offer sdp provided by offerer v=0 --------answer sdp: v=0 Maybe RTP ports already opened....We may need to change them dynamically. |
|
Latest one-page demo on attaching remote media streams. Still fails. |
|
Any process on this issue so far? |
|
This issue is not fixed yet. Attachment of remote media streams still failing on both chrome and firefox. I tried audio-only remote streams too but no success. |
|
Do you know when Google/Mozilla are going to support this feature? I couldn't find clear informations on the roadmaps.. |
|
I'm not sure, however it seems that audio-only remote streams' attachment works fine. |
A general comment is that we only support one audio source today in Chrome given that we only have one ADM. To me it sounds like we need a new type of source here where the audio is driven by the remote peer. Perhaps it would be less complicated to build something initially if we only worked in relay mode (one source). Reference: https://code.google.com/p/webrtc/issues/detail?id=383 .....take a remote stream from one peer connection and adding it to another peer connection and having it Just Work™ for that second peer. Implementation awaited! |
|
Hi @muaz-khan, I think this is what I thought about on my other issue questioning. The use case is: 1.) Peer1 connects with audio only In this case I get a black video on the peer this stream is delivered to sending a "new" offer and there are removeStream + addStream events fired up but also the data of the newly added stream isn't send. I tried multiple settings and also tried to find an answer but it doesn't seem to work. Also the sample implementation presented in the webrtc issue tracker isn't working like expected: https://code.google.com/p/webrtc/issues/detail?id=1086 Do you have any idea how to bring this up and running or is there something missing in browsers webrtc implementation for now? |
|
Try this demo:
Don't need to add ice candidates when renegotiating. |
|
Dear @muaz-khan, thx for your sample. I also found something else since setting the localDescription failed while switching like explained here: https://groups.google.com/forum/#!msg/discuss-webrtc/ets-eex6H-0/bkN2UwZI-gEJ I changed the |
|
We need this idea. This communication is low cost for end user. |
|
Hi Muaz, In your example below firstPeer.onaddstream = function(remoteSteam) { Why we are recreating remoteStream again using new MediaStream ? And pls tell me what we have to do for screen share while creating new instance of MediaStream...? |
|
There are some bugs preventing video tracks to be forwarded. In screen sharing apps; we need to retransmit video RTP packets; which seems failing on both chrome and firefox. In the example; new media stream is created; because in old days, chrome were throwing not-supported exceptions for Nowadays, you can attach remote stream directly, on chrome; without initiating new object; because both local and remote streams have identical I think identical ports (RTP or UDP) are causing failures to attach remote media streams. Though, I don't know the exact issue. Maybe ICE Agent is unable to locate right ports to retransmit remote media stream. Maximum peer connections limit is 256; so it is preferred to use application specific bandwidth parameters to stream low-quality packets; also specify width/height constraints to handle freezing issues. |
|
Any updates on "attaching remote audio/video stream"? |
|
Hi Muaz, Is there any progress in this issue? I am able to attach remote streaming on the same page. But when I try to do the same over two different pages it is failing. |
|
It works. Try following demo on chrome stable (desktop): <script src="//www.webrtc-experiment.com/RTCMultiConnection-v1.6.js"> </script>
<button id="open-main-session">open main session</button>
<button id="forward-main-session">forward main session</button><br />
<button id="join-main-session">join main session</button>
<button id="join-forwarded-session">join forwarded session</button>
<script>
var h1 = document.createElement('h1');
h1.innerHTML = 'user-id: ' + prompt('What is Your Name');
document.body.insertBefore(h1, document.body.firstChild);
// http://www.rtcmulticonnection.org/docs/constructor/
var mainConnection = new RTCMultiConnection();
// http://www.rtcmulticonnection.org/docs/session/
mainConnection.session = {
video: true,
oneway: true
};
// http://www.rtcmulticonnection.org/docs/constructor/
var dummyConnection = new RTCMultiConnection('dummy-connection');
// http://www.rtcmulticonnection.org/docs/session/
dummyConnection.session = {
video: true,
oneway: true
};
// http://www.rtcmulticonnection.org/docs/dontAttachStream/
dummyConnection.dontAttachStream = true;
// http://www.rtcmulticonnection.org/docs/onstream/
mainConnection.onstream = function(e) {
// see this line--------------------------
dummyConnection.attachStreams.push(e.stream);
document.body.appendChild(e.mediaElement);
};
// http://www.rtcmulticonnection.org/docs/onstream/
dummyConnection.onstream = function(e) {
alert('Wow, got forwarded stream!');
document.body.appendChild(e.mediaElement);
};
document.querySelector('#join-main-session').onclick = function() {
this.disabled = true;
// http://www.rtcmulticonnection.org/docs/connect/
mainConnection.connect();
};
document.querySelector('#join-forwarded-session').onclick = function() {
this.disabled = true;
// http://www.rtcmulticonnection.org/docs/connect/
dummyConnection.connect();
};
document.querySelector('#open-main-session').onclick = function() {
this.disabled = true;
// http://www.rtcmulticonnection.org/docs/open/
mainConnection.open();
};
document.querySelector('#forward-main-session').onclick = function() {
this.disabled = true;
// http://www.rtcmulticonnection.org/docs/open/
dummyConnection.open();
};
</script>
mainConnection.onstream = function(e) {
dummyConnection.attachStreams.push(e.stream);
}; |
|
Hi Muaz, Thanks for your help, I tried this demo and its work fine for video, but Thank You |
|
Did you appended mainConnection.session = {
audio: true,
video: true,
oneway: true
}; |
|
Yeah I did that, on the second tab I am able to listen audio, but when on On 5 February 2014 22:52, Muaz Khan notifications@github.com wrote:
|
|
@muaz-khan
Seems interesting as I am unable to find the reason for failure of forwarded stream at the same time its relation with main stream. |
|
Hi Muaz, I tried to forward stream of screen, but it failed. Can you tell me why? Thank You |
|
Hi Muaz, Did you find any remedy for the problem I described you (no sound from the Thanks. On 5 February 2014 22:56, Abhishank Sahu abhishanksahu@gmail.com wrote:
|
|
See this comment:
That's why remote audio recording doesn't work. |
|
Hi Muaz, I tried this demo. and changed line 135 mainConnection.session = {
video: true,
audio: true,
screen: true,
oneway: true
};
When I joined forwarded session, I can get screen stream only. Please help me to find out the problem :) Thank you. |
|
After looking into logs; it is appeared that only single "remote" media stream is attached to peer connection object: In theory, it MUST attach both audio+video and screen streams. You can see that we are trying to attach both: After going a little bit deeper; it is appeared that both remote streams has identical ids and labels. It can be RTCMultiConnection implementation issue. |
|
Hi Muaz, Is this problem fixed by chrome guys ? |
|
@shtefcs, it's been quite a while since you asked, but yes, Chrome 49 (Canary, at the time of writing) should: |
|
Any peer output without a "closed" sign, causes the remaining peers seek to reconnect? |
|
what happens with the pear 60 when pear 59 was disconnected ? |
|
If peer-59 leaves, peer-60 is told to If peer-60 will rejoin, server will give him fresh relaying-peer-id. During this rejoin-process, RTCMultiConnection tries to play recorded stream until fresh stream-event is fired. If peer-5 leaves then all-kinds-of nested child are told to |
|
Hi Muaz, I read through this thread and run your demo it seems that adding remote stream to another peerconnection does work. Howerver, when I wrote my own code, I cached the remote stream and added it to another peerconnection, the far end does not get onaddstream event fired and cannot get the forwarded stream. There was no errors and iceconnectionstate is completed too. I have also checked the ice candidates information. There are all generated completely and correctly without duplication to the original peerconnection. Would you help to provide some hint? Thank you very much! |
|
@muaz-khan For solving the problem you describe with peer-5 leaving, could the server instead tell peer 6 or 7 (who should be in the same link in the chain as 5) to take over instead? Similarly, could this system be made redundant/safe by having each child peer be aware of all 3 parent peers in the chain and fallback automatically if one drops? |
|
@muaz-khan |
|
Dear Muaz, hope you are doing great. I need your help, I have install asterisk on Ubuntu and now with nodeserver am trying to connect sip with the websocket using webrtc. I have followed thhe link below to connect asterisk. The error which i am getting on the webrtc console is mention below. Senging message: {"id":"register","ext":"2000","password":"asteriskpass"} and the error i am getting in CLi is mention below. 2000 calling 2001 ... Can you lease help me out to resolve this issue? |
|
@naeemaziz the reconnect log you received means the node.js application is not able to connect your kurento server. |
|
Any progress on this module? |
|
Hey, how does it work for around +1.000 users? |
Issue: unable to get remote stream in case when a “remote stream” is attached by calling “peer.addStream ( remoteStream )”
Is it beneficial to attach remote stream?
Yeah, it allows us overcome burden from a single peer. Burden will be shared.
Also, we can support a wide range of peer’s connectivity.
How to attach remote stream?
What I want to do?
We will get following benefits (in case of success):
A known bug in chromium: peer.onicecandidate not fires for 11th peer. You don’t need to worry about that bug!!
Pitfall: If peer number 1, 2, 5, 8 … tries to leave the room without informing other peers to play a host role.
If peer number 2 leaves the room, without informing master peer or peer number 5 to handling upcoming peers.
A demo experiment to test it:
https://googledrive.com/host/0B6GWd_dUUTT8V1Fodm9WQldkb28/
Open 4 tabs....1st table should create room……..join room from other tabs.....see the behavior of the 4th tab.
The text was updated successfully, but these errors were encountered: