Subject: Re: [AVTCORE] RTP Topology addition (was: Design choice comments..._

From: "David Benham (dbenham)" <[email-masked]>
Date: Sun, 22 Mar 2015 21:45:51 +0000

> From: Roni Even [mailto:[email-masked]]
> To me when looking at what is called switching conference server it seems that
> this is not a conference server but maybe just an some sort of RTP translator or
> maybe what we called a media server (RFC5576 section 6) 

First and foremost, we've been wanting to work on the security-centric requirements and not prematurely limit the RTP topologies.   To that end, and at the risk of pre-empting the discussion during agenda, we'll propose a design team meet to discuss ways to convey elements of cryptographic context that is as friendly to as many RTP topologies as possible.    Not unlike the design team focused on 'congestion management' issues and which meet back in Dec after IETF91.

That said, and to your RTP translator observation, wish to explore adding another RTP topology called "RTP Translator Forwarding Switch (RTFS).   Channeling Steve Wenger's post shortly before IETF 91,  ' ..topologies document is never really done' or something like that.   Can I get this started and in to the topologies doc update?

> So to summarize I would think that you describe an
> decomposed conference bridge and we can look at the work done in mediactrl
> WG for the architecture. 
> 
> Roni Even as individual
>

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 22 Mar 2015 22:36:28 -0500

On 2015-03-22 16:45, David Benham (dbenham) wrote:
>> From: Roni Even [mailto:[email-masked]] To me when looking
>> at what is called switching conference server it seems that this is
>> not a conference server but maybe just an some sort of RTP
>> translator or maybe what we called a media server (RFC5576 section
>> 6)
> 
> First and foremost, we've been wanting to work on the
> security-centric requirements and not prematurely limit the RTP
> topologies.   To that end, and at the risk of pre-empting the
> discussion during agenda, we'll propose a design team meet to discuss
> ways to convey elements of cryptographic context that is as friendly
> to as many RTP topologies as possible.    Not unlike the design team
> focused on 'congestion management' issues and which meet back in Dec
> after IETF91.

Good.

> 
> That said, and to your RTP translator observation, wish to explore
> adding another RTP topology called "RTP Translator Forwarding Switch
> (RTFS).   Channeling Steve Wenger's post shortly before IETF 91,  '
> ..topologies document is never really done' or something like that.
> Can I get this started and in to the topologies doc update?

As one of the authors of the document. Currently passed working group
last call and updated and ready for publication request, I say maybe.
But, please understand that we thought we was currently done.

I think you need to start by actually describing in which way this RTFS
is different from the RTP mixer or the SFM. Is this really different
from what is already described, or simply a variant?

Thus, please provide text to describe this thing you want to add.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Roni Even" <[email-masked]>
Date: Mon, 23 Mar 2015 13:40:50 +0200

Hi,
My concerns were not about the term translator but like Magnus is saying lack of  a description of this entity you defining.
I also think that the name "switched conferencing environment" is not correct you are only talking about switched media and not conference. Conference has more aspects than just media switching (e.g. conference control,..) which are as you say out of scope. 

Roni

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: 23 March, 2015 5:36 AM
> To: David Benham (dbenham); Roni Even; 'IETF AVTCore WG'
> Subject: Re: RTP Topology addition (was: Design choice comments..._
> 
> >> From: Roni Even [mailto:[email-masked]] To me when looking at
> >> what is called switching conference server it seems that this is not
> >> a conference server but maybe just an some sort of RTP translator or
> > First and foremost, we've been wanting to work on the security-centric
> > requirements and not prematurely limit the RTP
> As one of the authors of the document. Currently passed working group last call
> and updated and ready for publication request, I say maybe.
> I think you need to start by actually describing in which way this RTFS is
> different from the RTP mixer or the SFM. Is this really different from what is
> already described, or simply a variant?
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Mar 2015 07:32:16 -0500

In any case the issues go beyond switching - any MANE that modifies the sequence number or SSRC field will have a problem, regardless of whether supports switching or not.

> On Mar 23, 2015, at 6:41 AM, Roni Even <[email-masked]> wrote:
> 
> Hi,
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Mon, 23 Mar 2015 17:55:00 +0000

> > (RTFS)."   Channeling Steve Wenger's post shortly before IETF 91,  '

Understood.   

> from what is already described, or simply a variant?

From the doc, the SFM appears to require, like the media switching mixer referenced, a collection of its own SSRCs (ie, terminating SSRCs on all legs), sending only a finite set of SSRC values downstream to any given recipient or a 'cascade link' to another box.   

Is an SFM allowed per the definition to reuse the senders/upstream SSRCs, sending a potentially unlimited set of SSRCs downstream/to any given recipient?  Is allowing that a variant or?

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Mar 2015 13:15:25 -0500

On 2015-03-23 12:55, David Benham (dbenham) wrote:
> 
>> I think you need to start by actually describing in which way this
>> RTFS is different from the RTP mixer or the SFM. Is this really
>> different from what is already described, or simply a variant?
> 
> From the doc, the SFM appears to require, like the media switching
> mixer referenced, a collection of its own SSRCs (ie, terminating
> SSRCs on all legs), sending only a finite set of SSRC values
> downstream to any given recipient or a 'cascade link' to another box.
> 

The point of the SFM is that all SSRCs that exist upstream is projected
into the downstream. The point is that a selected set of the incoming
streams that are forwarded and rewritten according to need. SSRC
possibly, sequence number almost always needed, and often PT.

> 
> Is an SFM allowed per the definition to reuse the senders/upstream
> SSRCs, sending a potentially unlimited set of SSRCs downstream/to any
> given recipient?  Is allowing that a variant or?

Yes, that is possible. A point is that the SFM has a responsibility for
downstream congestion control.

Cheers

Magnus Westerlund

---

From: "David Benham (dbenham)" <[email-masked]>
Date: Mon, 23 Mar 2015 18:59:49 +0000

> downstream congestion control.

Great.    Others have asserted the SSRC termination and SN rewrite in the RTP header (sans header extension options) were absolutes.   And from my read, the text mostly to supported that assertion.   

Would it be friendly to the process to do some tweaking to SFM/sect 3.7 wording to make that bottom-line point of yours?   Hence SSRC and SN rewrite in the RTP header are but one way (alebit historically most common), but that not rewriting those values in the RTP header is allowed per the SFM definition.

I don't think I can work on that until late in the week, definitely not before tomorrow's agenda.   Can Stephan or another buddy up with me on such a text tweaking exercise?