Subject: [rtcweb] Fwd: New Version Notification for draft-alvestrand-rtcweb-msid-01.txt

From: Harald Alvestrand <[email-masked]>
Date: Wed, 25 Jan 2012 15:17:39 +0100

I have updated this draft with a proposal to add an identifier for the 
index of the mediastreamtrack inside a mediastream, and an 
inclusion-by-reference that is my proposal to solve the muting problem.

Comments appreciated.

                     Harald

-------- Original Message --------
Subject: 	New Version Notification for draft-alvestrand-rtcweb-msid-01.txt
Date: 	Wed, 25 Jan 2012 05:25:44 -0800
From: 	[email-masked]
To: 	[email-masked]
CC: 	[email-masked]

A new version of I-D, draft-alvestrand-rtcweb-msid-01.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository.

Filename:	 draft-alvestrand-rtcweb-msid
Revision:	 01
Title:		 Signalling Media Stream ID in the Session Description Protocol
Creation date:	 2012-01-25
WG ID:		 Individual Submission
Number of pages: 9

Abstract:
    This document specifies how the association between the RTP concept
    of SSRC and the WebRTC concept of&quot;media stream&quot; /&quot;media stream
    track&quot; is carried using SDP signalling.

    This document is an input document for discussion.  It should be
    discussed in the RTCWEB WG list, [email-masked].

The IETF Secretariat

---

From: Ted Hardie <[email-masked]>
Date: Wed, 25 Jan 2012 10:16:14 -0800

Given that the aim is to have these be unique over an SDP session's
lifetime 1 character seems to small and 64 too big, so I think the range
needs some tweaking.  I would personal make these UUIDs or reserved values
(you "default"), just to get the code re-use, but your mileage may vary.

Ted

On Wed, Jan 25, 2012 at 6:17 AM, Harald Alvestrand <[email-masked]>wrote:

> **
> -------- Original Message --------  Subject: New Version Notification for
> draft-alvestrand-rtcweb-msid-01.txt  Date: Wed, 25 Jan 2012 05:25:44 -0800  From:
> [email-masked]  To: [email-masked]  CC:
> [email-masked]
>
>    of SSRC and the WebRTC concept of &quot;media stream&quot; / &quot;media stream
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 25 Jan 2012 14:26:05 -0500

Harald,

One major functionality gap that is present in this proposal is ability to
negotiate codecs or codec parameters per SSRC. Imagine a situation where
you are communicating with a remote party that is sending you 3 video
streams. How would you be able to indicate that you want larger resolution
for one video stream and smaller resolution for two of the others? Or that
you want to allocate more bandwidth to one stream vs the others?

Also, imagine a situation where you are trying to implement the SBC that
bridges a network with SSRC multiplexing with a traditional one by
implementing signaling conversion and stream demultiplexing. You get an
offer that lists multiple SSRC streams per m-line and convert it into an
offer with multiple m-lines each corresponding to a single stream. You send
this offer to the traditional network and you get back an SDP where for
whatever reason, different codecs (or codecs with different parameters)
where accepted for different m-lines. How do you convert this answer into
an answer where those multiple m-line correspond to a single m-line in SSRC
multiplexed offer?
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 25 Jan 2012 20:47:07 +0100

On 01/25/2012 08:26 PM, Roman Shpount wrote:
> Harald,
>
> One major functionality gap that is present in this proposal is 
> ability to negotiate codecs or codec parameters per SSRC. Imagine a 
> situation where you are communicating with a remote party that is 
> sending you 3 video streams. How would you be able to indicate that 
> you want larger resolution for one video stream and smaller resolution 
> for two of the others? Or that you want to allocate more bandwidth to 
> one stream vs the others?
If you want to do that using SDP, you may want to use more RTP sessions 
- even on separate ports, if you want the network to help you treat them 
differently.

If the connection setup negotiation and its SDP description is just a 
small part of the communication that occurs between the communication 
partners and the servers that support them, this can be handled by 
entirely different means, ones that don't need to be standardized.

This proposal only speaks to the issue of uniquely identifying the 
streams; once we have an identifier for them, we can speak about them 
using other protocols.
(And muting them, because it seemed simple.)
>
> Also, imagine a situation where you are trying to implement the SBC 
> that bridges a network with SSRC multiplexing with a traditional one 
> by implementing signaling conversion and stream demultiplexing. You 
> get an offer that lists multiple SSRC streams per m-line and convert 
> it into an offer with multiple m-lines each corresponding to a single 
> stream. You send this offer to the traditional network and you get 
> back an SDP where for whatever reason, different codecs (or codecs 
> with different parameters) where accepted for different m-lines. How 
> do you convert this answer into an answer where those multiple m-line 
> correspond to a single m-line in SSRC multiplexed offer?
What application have you downloaded into the browser that would cause 
this to happen?

If you want an application in the browser that will connect well to a 
traditional SBC, which has behind it a telephone network, you will 
likely avoid using multiple SSRCs at all.

Not all applications will be telephones. In fact, I think most of them 
won't be.

> _____________
> Roman Shpount
>
>
> On Wed, Jan 25, 2012 at 9:17 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I have updated this draft with a proposal to add an identifier for
>     the index of the mediastreamtrack inside a mediastream, and an
>     From: 	[email-masked] <mailto:[email-masked]>
>     To: 	[email-masked] <mailto:[email-masked]>
>     CC: 	[email-masked] <mailto:[email-masked]>
>
>
>
>         discussed in the RTCWEB WG list,[email-masked]  <mailto:[email-masked]>.
>
>
>
>
>
>     The IETF Secretariat
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Colin Perkins <[email-masked]>
Date: Sun, 29 Jan 2012 17:27:07 +0000

Harald,

A couple of minor points on this draft:

- Section 2 lists an open issue on when the recipient should signal that a track is closed, suggesting either when the maid disappears from the description, when a BYE packet is received, or when a timeout passes with no media as options. The RTP rules for the latter two cases are defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would be appropriate for this draft to follow, and reference, then, rather than trying to define something new.

- Section 3: is "a=ssrc:??? sending:off" is signalled, clarify whether RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out in the RTP code).

Colin

On 25 Jan 2012, at 14:17, Harald Alvestrand wrote:
> I have updated this draft with a proposal to add an identifier for the index of the mediastreamtrack inside a mediastream, and an inclusion-by-reference that is my proposal to solve the muting problem.
> 
> Comments appreciated.
> 
>                     Harald
> 

-- 
Colin Perkins
http://csperkins.org/

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 29 Jan 2012 18:50:50 +0100

> A couple of minor points on this draft:
Thanks for the review!
>
> - Section 2 lists an open issue on when the recipient should signal 
> that a track is closed, suggesting either when the maid disappears 
> from the description, when a BYE packet is received, or when a timeout 
> passes with no media as options. The RTP rules for the latter two 
> cases are defined by RFC 3550 sections 6.3.4 and 6.3.5, and it would 
> be appropriate for this draft to follow, and reference, then, rather 
> than trying to define something new.

Thanks for the pointers!

The phenomenon of MediaStreamTrack and the SSRC are not necessarily 100% 
aligned, but if I interpret you correctly, you think that a track should 
be signalled closed when its corresponding SSRC is removed from the 
senders list, and not in response to any changes in signalling?

Or do you think we should signal a MediaStreamTrack closed in all 3 cases?

Do you think we should add an SSRC to the sender table when it is seen 
in an SDP configuration? If not,  MediaStreamTracks that never get any 
RTP packets never time out, which seems a bit odd.

(I assume that the "sender table" in 6.3.4 and the "sender list" in 
6.3.5 are the same thing)

>
> - Section 3: is "a=ssrc:??? sending:off" is signalled, clarify whether 
> RTCP is sent for that SSRC (yes, presumably, otherwise it'll time out 
> in the RTP code).
Being lazy, and because this is an "elsewhere" definition, I'd prefer to 
have that clarification made in section 2 of 
draft-lennox-mmusic-sdp-source-selection. But I agree, and would also 
think RTCP should be sent for muted streams.

>>     discussed in the RTCWEB WG list,[email-masked].
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>

---

From: Colin Perkins <[email-masked]>
Date: Sun, 29 Jan 2012 18:22:22 +0000

On 29 Jan 2012, at 17:50, Harald Alvestrand wrote:
> The phenomenon of MediaStreamTrack and the SSRC are not necessarily 100% aligned, but if I interpret you correctly, you think that a track should be signalled closed when its corresponding SSRC is removed from the senders list, and not in response to any changes in signalling?
> 

I'm not sure I understand the definition of MediaStreamTrack well enough to answer that question, but if we do use RTCP BYE or RTP-level timeouts to signal that a track has been closed, it should be done following the RFC 3550 rules, rather than by inventing a different set of rules. 

> Do you think we should add an SSRC to the sender table when it is seen in an SDP configuration? If not,  MediaStreamTracks that never get any RTP packets never time out, which seems a bit odd.

Section 5 of RFC 5576 talks about this ("sources that are only known through SDP, for which neither RTP nor RTCP packets have been received, MUST NOT be counted for RTP group size estimation", etc.). I interpret that as saying that you mark an SSRC learnt about via SDP as reserved, so you don't pick it using random SSRC selection, but don't consider it as existing in the RTP session until you receive an RTP/RTCP packet with that SSRC. That is, sending an SDP with an "a=ssrc:" line says "I plan to use this SSRC", but the SSRC doesn't come into being until you send an RTP or RTCP packet using it. 

This may mean that MediaStreamTrack needs a "potential" state, as well as open and closed.

> (I assume that the "sender table" in 6.3.4 and the "sender list" in 6.3.5 are the same thing)

Yes.

> Being lazy, and because this is an "elsewhere" definition, I'd prefer to have that clarification made in section 2 of draft-lennox-mmusic-sdp-source-selection. But I agree, and would also think RTCP should be sent for muted streams.

Sure - I already sent a comment to Jonathan Lennox along those lines.

Colin

-- 
Colin Perkins
http://csperkins.org/