Subject: [MMUSIC] Thoughts on m= lines and media streams

From: Adam Roach <[email-masked]>
Date: Thu, 31 Jan 2013 18:17:36 -0600

Based on the conversations we've had so far, I've put together the 
following summary of my thoughts on the topic of whether we want to put 
multiple media streams in a single m= line.

http://www.ietf.org/id/draft-roach-mmusic-mlines-00.txt

Sorry for the relatively short lead time before next week's meeting -- I 
had meant to put this kind of summary together a week or two ago, but 
have been far busier than I anticipated.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Jan 2013 19:57:33 -0500

Adam,

Thanks for writing this. A few thoughts about it:

1) Putting session-level attributes in the first m-line has problems if 
that m-line is rejected and others are accepted. Maybe this can be 
solved with some more text in a new draft. But it will likely have 
backward compatibility problems.

2) For option 2, when you talk about a single stream per m= section, 
exactly what do you mean? Do you mean a single SSRC? If so, is a=ssrc 
used to specify which one? Or do you mean that the m= section applies to 
one RTP stream at a time, but might (serially) apply to different SSRCs 
without new O/A exchanges?

I can possibly buy in to having as many m-lines as concurrently active 
RTP-streams. But having to exchange SDP when SSRCs change is hard to accept.

	Thanks,
	Paul

On 1/31/13 7:17 PM, Adam Roach wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 1 Feb 2013 07:48:17 +0000

Adam,

thanks for analysing the various proposals and putting the draft together.
>From a quick read I have some issues with backward compatibility of your proposal to include 
"common" attributes only in the first m-section.
Assuming that the examples in the draft are offers, an answerer that
didn't implement any of the mechanisms would probably show the
following behavior.  

Alternativ 1a and 2 have ICE candidates only for the first m-section.
An answerer that doesn't understand the grouping semantics could -
dependent on the network topology - end up having audio, but no video
connectivity.  
With having other attributes only in the first m-section we could get other issues.

Alternative 1b doesn't have this problem, but the offer would most likely
be rejected resulting in no media at all. 
I preferred the original mmt proposal as it had additional m-sections,
that could be accepted by a legacy answerer without the need for a GW that performs complex SDP operations.

Regards
Thomas