Subject: [rtcweb] Terminate or Reject streams by setting port to zero in SDP

From: José Luis Millán <[email-masked]>
Date: Tue, 17 Jul 2012 07:35:06 +0200

Hi,

Offer/Answer Model with Session Description Protocol states that a
stream can be terminated or rejected by setting the port to zero in
the Offer/Answer SDP respectively.

How can this be achieved with PeerConnection?

Thanks in advance.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Jul 2012 07:39:20 +0200

> How can this be achieved with PeerConnection?
Terminating a stream: Remove all references to the stream in the SDP 
"msid" attributes.

draft-alvestrand-rtcweb-msid-02 section 4.

Rejecting a stream: draft-westerlund-avtext-rtp-stream-pause-02 suggests 
one way to do this (I have not reviewed it).

Note: An m-line (the entity in SDP that carries the port number) does 
NOT correspond to a WebRTC MediaStream.

>
> Thanks in advance.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sat, 21 Jul 2012 14:25:43 +0200

> draft-alvestrand-rtcweb-msid-02 section 4.
Agree to that part.
> one way to do this (I have not reviewed it).
I don't think that draft covers rejecting a stream. It is more related 
to pause/resume (which correlates to enable/disable and mute/unmute in 
API terminology).

Which leads to the question: If we use a solution like described in 
draft-alvestrand-rtcweb-msid-02 to signal the mapping between 
MediaStream's and MediaStreamTracks and ssrcs (RTP) (which makes sense 
to me), how should rejection be signaled? And should the receiver be 
able to accept certain added ssrc's in a new offer while rejecting 
others, or should the entire offer be rejected (and the presumable the 
current state of the session be maintained)?

In 3264 it is said "The means for rejecting an offer are dependent on 
the higher layer protocol.", but that does not seem appropriate in this 
case.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jul 2012 11:57:20 -0700

On 21 July 2012 05:25, Stefan Hakansson LK
<[email-masked]> wrote:
> In 3264 it is said "The means for rejecting an offer are dependent on the
> higher layer protocol.", but that does not seem appropriate in this case.

Doesn't that mean that you need a way to reject an offer?  Imagine
that you call createOffer and that is incompatible with the state on
the other peer in some way.  Given that you have already
setLocalDescription, what do you do to back out an offer that has been
rejected?  It seems that the only action available is to create
another offer.

--Martin