recommended way to pause sending of LocalMediaStream

[Bryan Donnovan]

What is the best way to to toggle sending of the localMediaStream after a call is set up and media is flowing in both directions?  The call is setup with a=sendrecv

I first tried setting the enabled flag to false on each track of localMediaStream, and that didn't work.

I tried doing a pc.removeStream(localStream) but that did not stop the RTP from being sent either. This method is not preferred since I will want to add the stream back later and do not want a new SSRC to be assigned.

I do not want to set up a new call as sendonly/recvonly since it is really sendrecv call (with pauses) that I am looking for.  

It would be sweet if LocalMediaStream had a pause method on it.

running 21.0.1150.0 canary and using webkitPeerConnection00

Any hints?  

[Justin Uberti]

Are you trying to pause, or mute? i.e. does the remote side need to be notified?

[Bryan Donnovan]

the sending of RTP is paused and unpaused at will, RTP may or may not be received, the ICE binding refreshes should continue.

There is no intention to notify the remote side with an updated offer, only to pause the sending data from the local stream.  However, if updating the offer/answer would accomplish this, then that is ok, but I suspect it would cause the SSRC to change when unpausing, which I want to avoid if possible. 

On Thursday, May 24, 2012 10:44:48 AM UTC-7, Justin Uberti wrote:

Are you trying to pause, or mute? i.e. does the remote side need to be notified?

[Justin Uberti]

Can you comment a bit more on what you are trying to do at the application level? Still not sure whether muting or a=recvonly is the right choice.

[Bryan Donnovan]

I have a star topology with a Push to Talk paradigm.  Many participants connected to the central server, few of them speaking at any given time.  In this example, assume that only one of those participants speaking at any given time, and that they all take turns at the mic.  (it might be several speakers depending on the room configuration)

The server receives packets from the current speaker, fixes up the SSRC, then forwards packets to all of the participants.  (all streams were given a common a=crypto during call setup).  I'm assuming that the receiving decoders will not have a problem with discontinuous transmission, since this could happen naturally with packet loss or silence.

Each user establishes a sendrecv stream with the server, but does not send packets during silent periods.  Keeping the LocalMediaStream running means no startup lag following a PTT.

On Thursday, May 24, 2012 12:12:58 PM UTC-7, Justin Uberti wrote:

Can you comment a bit more on what you are trying to do at the application level? Still not sure whether muting or a=recvonly is the right choice.

[Bryan Donnovan]

I found a solution that works well for my PTT needs.  After adding/removing the local media stream from the peer connection, do the following to have it take effect:

function updateSession(){

    var sdp = pc.createAnswer( pc.localDescription.toSdp() , {has_audio:true,has_video:true} ).toSdp();

    var sd = new SessionDescription( fixupSDP(sdp) );  

    pc.setLocalDescription( pc.SDP_OFFER , sd ); 

    pc.setRemoteDescription( pc.SDP_ANSWER , pc.remoteDescription ); 

[Justin Uberti]

I thought you wanted to preserve the SSRC? The code below is not guaranteed to do that, and it certainly won't preserve seqnum.

a=recvonly will preserve SSRC, but not seqnum. Muting will preserve both SSRC and seqnum.

[Bryan Donnovan]

I do preserve SSRC.  By modifying the SDP in fixupSDP before setLocalDescription I can assign any SSRC that I want. 

On Thursday, May 24, 2012 5:38:33 PM UTC-7, Justin Uberti wrote:

I thought you wanted to preserve the SSRC? The code below is not guaranteed to do that, and it certainly won't preserve seqnum.

a=recvonly will preserve SSRC, but not seqnum. Muting will preserve both SSRC and seqnum.

[Justin Uberti]

Makes sense (wasn't sure what fixupSDP did internally). Still think that a=recvonly or muting would be a simpler approach.

[Bryan Donnovan]

Yes, I think you are correct.  

Can you tell me how to accomplish muting?  I had assumed that the receiver muted a sender by not playing the received data, rather than causing the sender to not send data.

On Thursday, May 24, 2012 7:03:24 PM UTC-7, Justin Uberti wrote:

Makes sense (wasn't sure what fixupSDP did internally). Still think that a=recvonly or muting would be a simpler approach.

[Justin Uberti]

Enable should handle this. I will find out why this isn't working

[Prakash]

You may want to track this.

https://code.google.com/p/chromium/issues/detail?id=114163&q=feature%3DWebRTC&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Feature%20Status%20Owner%20Summary

[bryand...@gmail.com]

I expect that you could pc.removeStream(localStream) then update the offer/answer.  

You can look at the apprtc demo to see how offers/answers are updated now since it has changed since this thread began.

It might also work to update the offer/answer making the local description a=recvonly but I recall seeing some issues related to recvonly in the tracker.

On Sat, Mar 16, 2013 at 8:09 PM, Tom <tom....@gmail.com> wrote:

Hey Bryan,

I'm currently having the same issue and can't get this way to work, SDP_OFFER and SDP_ANSWER no longer exist, neither does this toSdp method. It would be great if you have an update on how this can be achieved?

Thanks!

--
 
---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/kt14TkSdLpo/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tom]

Hey Bryan,

I'm just coming back to this issue as its still a problem for us. Ive checked out the apprtc demo and it doesnt look to have changed - there is no example of updating offer/answers in there that I can see - I would be very grateful if you can you point me in the right direction?

I essentially need to produce exactly what this thread is about - simply pausing the stream between two peers. I feel like this shouldn't be too difficult but it has been the biggest hurdle so far.