Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Sep 2016 09:45:18 -0700

# Major Issue 

## Interoperable PT reuse 

Reuse of PT inside a bundle group in an offer needs to only be allow the m= line is bundle only. Without this, when this if the offer drives at a device that does not support bundle, it will be invalid SDP. 

## RTP Demux 

Need more explicit text how how to demux RTP based on MID and how SSRC latching works. The definition of MID in RTP does not really make sense without this. 

## RTCP mux. 

Section 10.3 reads like RTCP has to be multiplexed. This seems wrong. What it should say is that if RTCP is multiplexed or not needs to be negotiated. 

## MID transmission

Saying that the MID might might not ever be in the RTP will result in failures. I think we should say that MID MUST be sent in the RTP (does not need to be in every RTP packet, but some  more on which ones later). 

Figuring out when to send MID and when not to is not easy and we need the sender and receiver to have common assumptions. I think we will have much better interoperability if we specify something for this even at the SHOULD level. I’m proposing something along the lines of

1. at start of session or change of SSRC, MUST send at least 5 times 
2. if it has not been sent in last second, MUST send in next RTP packet 

(this is phrased this way so that if device is not sending any RPT for 5 seconds there is no need to send a RTP packet just for this)

# Medium Issue

Given the other conversation around “update”, does this needs to update 3264?

## Mux only confusions. 

I think we agreed that if and endpoint was sending mux-only, it still had to put in the rtcp-mux attributes, it is just saying that it is never going to negotiate a non mixed option. A bunch of text reads that you have mux-only or rtcp-mux but I think it needs to be if you have mix-only, then you must also have rtcp-mux. The reasons for this is that we want stuff that does not implement mix-only but does do rtcp-mux to work in theses cases. 

# Small Stuff

In the para in section 1 where we are taking about MID, I think we should introduce the name MID here. 

Think we should delete first two paragraphs of section 9. Don’t add anything and just confusing.

14.1 specifies uses of UTF strings that implementation need to compare. Should specify normalization for this. 

I did not review the SDP examples.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 16 Sep 2016 21:25:45 +0000

Hi Cullen,

I will address your other issues later, but regarding your comment on RTCP mux: there was consensus at IETF#94 to mandate RTP/RTCP mux within a BUNDLE group.

You had another preference, but when people were asked to hum if they can not live with mandating RTP/RTCP mux there was silence. 

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: 16 September 2016 19:45
To: mmusic WG <[email-masked]>
Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-bundle-negotiation-32

# Major Issue 

## RTP Demux 

## RTCP mux. 

## MID transmission

1. at start of session or change of SSRC, MUST send at least 5 times 2. if it has not been sent in last second, MUST send in next RTP packet 

# Medium Issue

## Mux only confusions. 

# Small Stuff

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 16 Sep 2016 16:29:25 -0700

> On Sep 16, 2016, at 2:25 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi Cullen,
> 

sure - totally agree with that in WebRTC (not in SDP in general obviously). 

What we are talking about here is when you are doing a  mux-only, do you also add the rtcp-mux attribute. Chrome and FF people both seemed to want to do that for interop between things that *only* do rtcp-mux but need to indicate this. This does not mean you can negotiation not muxing. It mean that even when using mux-only, you also add rtcp-mux attribute to to indicate that RTCP is being muxed. T

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 17 Sep 2016 06:33:07 +0000

Hi,

> sure - totally agree with that in WebRTC (not in SDP in general obviously). 

It was BUNDLE in general.

> What we are talking about here is when you are doing a  mux-only, do you also add the rtcp-mux attribute.

The text says that one may also add rtcp-mux with mux-only.

> Chrome and FF people both seemed to want to do that for interop between things that *only* do rtcp-mux but need to indicate this. This does not mean you can 
> negotiation not muxing. 

The consensus was to *only* do rtcp-mux for BUNDLE. 

>It mean that even when using mux-only, you also add rtcp-mux attribute to to indicate that RTCP is being muxed. T

As defined in the O/A subsections, the endpoints DO add the mux attributes. Or, do you think there is some place where it is missing?

Regards,

Christer