search

rtcweb-wg / jsep

33 stars 32 forks source link

Determine how a remote peer can be notified of a locally stopped stream #76

Closed juberti closed 8 years ago

juberti commented 10 years ago

The SDP will indicate a=recvonly, but it won't be clear if the stream is stopped or merely held. Harald proposed msid-control at IETF 89 to deal with this, but IIRC there wasn't consensus for this yet.

juberti commented 10 years ago

Justin to dig up IETF 89 decisions.

juberti commented 9 years ago

According to IETF 89 minutes, the decision was to add something new in MMUSIC for this, but it needs to be something other than msid-control. Harald removed msid-control from the MSID draft.

I think that we need a new mechanism here.

juberti commented 9 years ago

IETF 91 discussion - we need a new mechanism, but we don't really have anything yet.

juberti commented 9 years ago

IETF 92 discussion - this doesn't cause any real problems, so we'll just leave it as-is for v1 of this doc. Need to check whether any text needs to be updated for this.

gloinul commented 9 years ago

For an actual explicit indication of local pause, one could use PAUSED indication from https://datatracker.ietf.org/doc/draft-ietf-avtext-rtp-stream-pause/ which is in IETF last call and thus no issues to reference if desired to be used.

fluffy commented 9 years ago

I don't think pause will work here. The issue is if something is rcvonly, how is it indicated it will never go back to sending and thus the PT can be used for something else. The existing equipment assumes the answer to this is never, it can always attempt to renegotiate it back to sending after seting it to rcvonly

juberti commented 8 years ago

Regarding the original bug - I think that if you are sending and stop your stream, the other side learns this by the disappearance of a=msid for the stream, in addition to going a=recvonly.

If you are receiving and stop the incoming stream, then the other side doesn't learn this if you still have a sending stream; your side goes to a=sendonly, but it's unclear to the sending side whether the stream has been stopped or just held.

Nevertheless, as mentioned on Mar 26, not sure this information is critical to have.

hardie commented 8 years ago

@juberti Can this be closed as OBE?

juberti commented 8 years ago

I have been leaving this open to document the actual changes to track assignment and directionality status.

juberti commented 8 years ago

Likely addressed by #65

juberti commented 8 years ago

Closing since this is now handled via sender/receiver states.