Subject: [Perc] MID and RID

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Mon, 30 Nov 2015 18:12:43 +0000

It's unfortunate we never reached some important header extensions like MID and RID in today's design meeting. The proposed MDD behavior (can't modify) in the slides does not seem right. Like PT, these values are dictated by signaling negotiation, and it may be impossible for MDDs to force symmetry and uniformity in the signaling negotiation across all participants in order to avoid modifying these values. So I think the MDD should be allowed to modify these, and we may want to preserve original values for the same reason as PT (in case highly secure implementations go as far as ensuring MDD signaling is reasonable given some E2E signaling).

Mo

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 30 Nov 2015 10:33:15 -0800

Right. Both MID and RID are chosen by the Offerer, so it is possible that a
packet might need different MID and RID values for each receiver, and the
MDD will need to modify the MID and RID header extensions to accommodate
this.

On Mon, Nov 30, 2015 at 10:12 AM, Mo Zanaty (mzanaty) <[email-masked]>
wrote:

> It's unfortunate we never reached some important header extensions like
> MID and RID in today's design meeting. The proposed MDD behavior (can't
> modify) in the slides does not seem right. Like PT, these values are
> dictated by signaling negotiation, and it may be impossible for MDDs to
> force symmetry and uniformity in the signaling negotiation across all
> participants in order to avoid modifying these values. So I think the MDD
> should be allowed to modify these, and we may want to preserve original
> values for the same reason as PT (in case highly secure implementations go
> as far as ensuring MDD signaling is reasonable given some E2E signaling).
>
> Mo
>
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>
>

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 30 Nov 2015 19:49:39 +0000

On Nov 30, 2015, at 1:33 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
On Mon, Nov 30, 2015 at 10:12 AM, Mo Zanaty (mzanaty) <[email-masked]<mailto:[email-masked]>> wrote:
It's unfortunate we never reached some important header extensions like MID and RID in today's design meeting. The proposed MDD behavior (can't modify) in the slides does not seem right. Like PT, these values are dictated by signaling negotiation, and it may be impossible for MDDs to force symmetry and uniformity in the signaling negotiation across all participants in order to avoid modifying these values. So I think the MDD should be allowed to modify these, and we may want to preserve original values for the same reason as PT (in case highly secure implementations go as far as ensuring MDD signaling is reasonable given some E2E signaling).
Right. Both MID and RID are chosen by the Offerer, so it is possible that a packet might need different MID and RID values for each receiver, and the MDD will need to modify the MID and RID header extensions to accommodate this.

Beyond this, in a fairly standard one-up-many-down conferencing scenario, if you’re bundled I’d expect that the MID of routed sources would change — each endpoint has one MID (per media type) upstream, and multiple MIDs downstream.  If the downstream MID corresponds to a role (e.g. current, previous loudest speaker) then routed streams’ MIDs will change dynamically based on the MDD’s routing decisions.

This is also the issue I raised in today’s call about SSRC rewriting.  Currently, we have no way to give a stream more than one MID at a time, so if you have role-based MIDs there’s no way for a given SSRC to have more than one role at a time.  In non-PERC scenarios, the solution to this is stream duplication, but if we don’t allow SSRC rewriting that won’t be possible.

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 30 Nov 2015 16:42:37 -0700

> On Nov 30, 2015, at 12:49 PM, Jonathan Lennox <[email-masked]> wrote:
> 

But sending two more or less identical copies of the same video to the same endpoint is just such a bandwidth wasted that it seems we really need a better solution than that. Like being able to assign multiple labels designed  to identify the role(s) to the stream. It's rather see us solve that problem that way.

---

From: Christian Groves <[email-masked]>
Date: Tue, 1 Dec 2015 12:46:46 +1100

Another related extension is the CLUE CaptureID 
(draft-ietf-clue-rtp-mapping). If the MDD also uses CLUE then it must 
have read/write access to this SDES item in order to correctly correlate 
the CLUE captures to the media.

Regards, Christian

On 1/12/2015 5:12 AM, Mo Zanaty (mzanaty) wrote:
> It's unfortunate we never reached some important header extensions 
> like MID and RID in today's design meeting. The proposed MDD behavior 
> (can't modify) in the slides does not seem right. Like PT, these 
> values are dictated by signaling negotiation, and it may be impossible 
> for MDDs to force symmetry and uniformity in the signaling negotiation 
> across all participants in order to avoid modifying these values. So I 
> think the MDD should be allowed to modify these, and we may want to 
> preserve original values for the same reason as PT (in case highly 
> secure implementations go as far as ensuring MDD signaling is 
> reasonable given some E2E signaling).
>
> Mo
>
>
>