Subject: [AVTCORE] Comments on draft-lennox-rtcweb-rtp-media-type-mux-00

From: Magnus Westerlund <[email-masked]>
Date: Mon, 7 Nov 2011 11:17:56 +0100

Hi,

(as individual)

I have reviewed draft-lennox-rtcweb-rtp-media-type-mux-00 and have some
comments.

I think this document is most appropriately discussed in AVTCORE as it
concerns RTP details. Therefore both lists are cc:ed and reply-to set to
AVTCORE WG mailing list. So if you are on RTCWEB and would like to
follow this discussion, please follow the AVTCORE mailing list also
([email-masked]).

1. I think the biggest issue with multiple media type in a single RTP
session isn't discussed. I think it is very important that this issue is
brought up as it has to do with the applicability of this solution.

To start the discussion on this issue I think a quote from section 4.3
of draft-westerlund-avtcore-transport-multiplexing-01 is appropriate:

   Many transition scenarios use an RTP translator as a gateway between
   a single RTP session containing multiple media types multiplexed
   together, and several separate RTP sessions each using a single media
   type.  In this scenario, it is possible that a legacy device that
   uses one RTP session for each media type will use the same SSRC in
   each session.  When translating these into a single RTP session, it
   will be necessary to rewrite one of the SSRCs, so that each stream
   has a unique SSRC.  This SSRC translation process is straight-forward
   for RTP packets, but is very complex for RTCP packets.  It also
   hinders innovation, since such a gateway will not be able to
   translate new RTCP extensions that it is unaware of, even if they are
   supported by devices on both sides of the gateway.

The issue is that in any case where you have a desire to mix end-points
supporting this and where some don't you create a situation where you
will either get malfunctioning translators or translators that likely
are a barrier for deploying new RTP/RTCP extensions.

Even in WebRTC contexts the case combing the single session and multiple
sessions are likely to occur. One case is media plane gateways to legacy
that will negotiate the multiplexing between the WebRTC end-point and
the gateway and then attempt to perform basic splitting to two RTP
sessions on the legacy side based on the payload formats. Another
scenario is the centralized conferences where the RTP mixer or
translator can negotiate individual behavior to each end-point. Thus one
might start out fine with all being single session compliant. Then
someone joins who is not and the result is that one is in a situation
that either requires renegotiation (including NAT traversal) for the
already connected end-points or to do a translator. I am certain that
translator is going to be the approach rather than interrupting the
ongoing media streams.

So yes this would not be an issue if everyone supported it. But it is
clear that the world will be one of incremental deployment. So I am
quite worried on the future impact using a single RTP session creates. I
think RTCWEB needs to seriously consider if this really is the right way
to go or if another solution would be better.

2. Section 7.2.9 of draft-westerlund-avtcore-multiplex-architecture-00
discusses a number of aspects of this type of multiplexing. I think the
document covers most in a reasonable fashion. The ones that seems to be
missing are;

A) the number space limitation of the PT field. The 128 values should
after all cover all the RTP payload configurations one like to use/offer
+ the RTCP payload type overlap due to RTP/RTCP multiplexing. So the
fact that the real limitations in RTP payload types are in fact that all
media types need to share in 96+ available payload type values rather
than 128 per each media type.

B) I think the bit-rate issues could be improved but it is present.

C) Decomposited end-points are missing. This is not a big issue, only a
down side with this that increases the bit-rate to the actual functional
end-points and require them to have handling of the multiple media
types. So this is a limitation if one attempt to use this in a
Telepresence scenario with dedicated hardware, not an issue in a browser
context.

3. Section 3:
   For sessions using the RTP/AVPF [RFC4585] and RTP/SAVPF [RFC5124]
   profiles, however, endpoints SHOULD set the minimum RTCP regular
   reporting interval trr-int to 5000 (5 seconds), unless they
   explicitly need it to be lower.  This minimizes the excessive RTCP
   bandwidth consumption, as well as aiding compatibility with AVP
   endpoints.  Since this value only affects regular RTCP reports, not
   RTCP feedback, this does not prevent AVPF feedback messages from
   being sent as needed.

When AVP compatibility is the goal, I think 5 seconds is mostly ok. The
regular RTCP suppression algorithm has a bit of strange behavior in
cases where the Td value becomes similar to the T_rr_interval. That as
the scheduled transmission time of an regular RTCP packet might close to
the randomized value of the T_rr_interval but still smaller, that can in
worst case result in that the AVPF RTCP sender sends RTCP some cases
with close 2*T_rr_interval but no more often than 0.5*T_rr_interval.
Thus the median of the distribution gets skewed towards higher value
than T_rr_interval. I will send a separate email about this as it
requires a bit of graphs and more in detail discussion.

4. Section 3.1:

"An endpoint MAY choose to send multiple sources' RTCP messages in a
   single compound RTCP packet (though such compound packets SHOULD NOT
   exceed the path MTU, if avoidable and if it is known)."

I think this recommendation is appropriate but I think should likely
become a general recommendation for RTCP. However, that clearly requires
some feedback if it will fail with some implementations. And if it does,
I think that signalling support may be necessary. If that is the case,
this optimization can't be used when working in the separate RTP session
mode in WEBRTC, thus causing a situation where WebRTC end-points needs
to have a run-time switch to control if this is used or not.

5. Section 3.1:
   Regular (non-
   feedback) RTCP compound packets MUST still begin with an SR or RR
   packet, but otherwise may contain RTCP packets in any order.
   Receivers MUST be prepared to receive such compound packets.

I think this needs to make clear that for each SSRC include, both SR/RR
and the corresponding SDES CNAME items MUST be included.

6. Section 3.1:
  "An endpoint SHOULD NOT send reception reports from one of its own
   sources about another one ("cross-reports")."

This topic should also likely be discussed if it should be a general
clarifications to RFC3550. That includes how one determines what is the
considered the same end-point and what implications it provides. Is it
based on all SSRCs with the same CNAME in an end-point SHOULD NOT send
report blocks from more than one?

I do note that all SSRC still needs to send an SR or an RR(possibly
empty) just to announce there presence in the RTP session.

7. Section 3.1:
Similarly, an endpoint sending multiple sources SHOULD NOT send
   reception reports about a remote source from more than one of its
   local sources.

The same comments as for 6) applies to this.

8. Section 4:
   The more difficult case is if an offerer cannot reply on its
   potential peers supporting any features beyond baseline RTP (i.e.,
   neither ICE nor multiplexing).

I don't think this becomes a real issue if one assumes the offer
following the signalling as defined by
https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/

9. Section 5:

So we do now have two proposals on the table for how to signal this. One
in
https://datatracker.ietf.org/doc/draft-holmberg-mmusic-sdp-bundle-negotiation/
(BUNDLE) and one in this document (Lennox).

A comparison is quite interesting.

BUNDLE will have very straightforward back-wards compatibility as that
can happen in the single offer/answer exchange. However, there exist no
way of forcing the usage of BUNDLE.

Lennox requires a new Offer if the peer doesn't support this. In
addition it creates a SDP media type that isn't supposed to be used with
MIME. That is likely going to be an interesting to execute. It does
allow for mandating support and refusing to establish a session not
compliant. In addition it reduces the risk of confusion around payload
types as they are only listed on a single media description.

I personally prefer the BUNDLE approach.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 07 Nov 2011 11:37:12 +0100

(RTCWEB deleted from CC list, as per request)

> are a barrier for deploying new RTP/RTCP extensions.
Magnus,

why would such a gateway want to offer the BUNDLE extension in its SDP 
negotiation?
(I'm assuming support for draft-holmberg-mmusic-sdp-bundle-negotiation 
as the way to negotiate multiple media types in a single session here.)

An assumption in the deployment of extensions is that one is able to 
negotiate their non-use where some participant does not support the 
feature. I find your arguments compelling if (and only if) I accept the 
premises that:

1) Gateways between RTCWEB deployments and non-RTCWEB deployments will 
want to relay RTP sessions rather than terminate them (something which I 
do not believe, but that's another debate)

2) Gateways between RTCWEB deployments and non-RTCWEB deployments can't 
negotiatiate non-support for the BUNDLE extension with the RTCWEB deployment

Given that I believe 2) is false, I don't agree with your conclusion.

Some details below.
> translator is going to be the approach rather than interrupting the
The 3 viable approaches I see for gateways are:

- The gateway refuses to negotiate BUNDLE with anyone
- The gateway terminates RTP sessions
- The gateway refuses to establish non-BUNDLE sessions at all

In neither of these 3 scenarios do I see the issue you posit.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Nov 2011 11:56:21 +0100

Harald,

Inline

> Given that I believe 2) is false, I don't agree with your conclusion.

I will follow up one below. But regarding 2) that is not the reason. 
Even if one can negotiate that the one bundles multiple media types in a 
single RTP session, there is going to be gateways/conference nodes that 
are going to turn on this feature anyway.

The reason for that behavior is that they will think this issue is a 
non-issue. Short term thinking rather than long term implications. They 
will like to avoid the small but existing risk of establishing more NAT 
pinholes. Also, to be certain that this not occurs, you either have zero 
possibility to use the non bundled session to a central node, or you 
configure your central node to never use bundling to avoid this. I think 
more than one developer will look at this and ignore the issue. Because 
if you don't think it through it do look simple on the surface. You 
simply translate the SSRCs if you end up in a collision.

When it comes to using a common session. I agree that for media mixing 
central nodes (RTP mixer), the RTP session is anyway almost individual 
between each end-point and end-point. The only information you forward 
between the legs are the CSRC CNAMEs to ensure the possibility to bind 
the information to the right sources.

But, when looking at the cheapest central node solution, the transport 
relay (transport translator) the common RTP session becomes interesting 
as it limits the central nodes processing to bascially a packet 
forwarder. This gives you on the order of 1000 times higher capacity in 
the number of streams the central node can handle compared to one that 
performs media operations given the same general purpose hardware. Thus 
having a common RTP session and not having to change anything within the 
packets, not even having to perform decryption and encryption cycles in 
the relay is a big bonus.

> In neither of these 3 scenarios do I see the issue you posit.
Agreed, these do avoid the issue of having to translate. From my 
perspective, they should be documented and considered if they will be 
followed.

Raising this issue had two goals.

1) Ensure that the issue and the implications on what one need to do is 
clearly documented in the draft.

2) Raise discussion if those are acceptable

So I hope the authors at least will agree to perform 1). Regarding the 
outcome of 2) that is very much open.

When it comes to 2) I think we need to take into account the 
alternative. Is any of the evaluated alternatives in 
https://datatracker.ietf.org/doc/draft-westerlund-avtcore-transport-multiplexing/ 
actually less problematic?

And I think it is important we do consider what happens when WebRTC is 
successful. I fear the desire to interoperate will kill of the RTP 
session completely as a useful tool. Instead all RTP users will end up 
with a single RTP session and we have to re-invent mechanisms for 
separation when the short-coming of not having an layer of multiplexing 
for media stream purposes.

I know that the window for this is closing, but I think we should at 
least have some reconsideration if the direction proposed in Quebec 
really was the most appropriate.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 10 Nov 2011 13:33:05 +0100

This response has two parts:

- One discussion about the scenarios Magnus is positing in his note 
(first half)
- One discussion about evaluating the approaches proposed (second half)

People who want to comment on just one of them may want to fork the 
discussion.

On 11/10/2011 11:56 AM, Magnus Westerlund wrote:
> Even if one can negotiate that the one bundles multiple media types in 
> a single RTP session, there is going to be gateways/conference nodes 
> that are going to turn on this feature anyway.
>
> non-issue. Short term thinking rather than long term implications. 
> They will like to avoid the small but existing risk of establishing 
> more NAT pinholes. Also, to be certain that this not occurs, you 
> either have zero possibility to use the non bundled session to a 
> central node, or you configure your central node to never use bundling 
> to avoid this. I think more than one developer will look at this and 
> ignore the issue. Because if you don't think it through it do look 
> simple on the surface. You simply translate the SSRCs if you end up in 
> a collision.

I still don't get this argument. Can you describe in more detail a 
situation where you think trouble will occur, which does not involve a 
transport translator?

> the information to the right sources.
Not even that, for the case of central nodes that don't do source mixing.
> relay (transport translator) the common RTP session becomes 
> interesting as it limits the central nodes processing to bascially a 
> packet forwarder. This gives you on the order of 1000 times higher 
> capacity in the number of streams the central node can handle compared 
> to one that performs media operations given the same general purpose 
> hardware. Thus having a common RTP session and not having to change 
> anything within the packets, not even having to perform decryption and 
> encryption cycles in the relay is a big bonus.
Can you give some reference for the claim of "1000 times higher capacity"?
In particular, there are 3 cases:

- Pure packet forwarder ("transport translator")
- RTP session terminator, non-media-mixing
- RTP session terminator, media-mixing

I think it's reasonable to assume that the RTP session terminator will 
always do decrypt/encrypt, since not doing so requires using key 
handling schemes that are no more secure than the transport translator case.

Still, I think we may be talking about CPU time per packet well below a 
millisecond for the middle case.
> 1) Ensure that the issue and the implications on what one need to do 
> is clearly documented in the draft.
>

I have serious problems with evaluating 
draft-westerlund-avtcore-transport-multiplexing, because I still 
disagree with its problem description.

That problem description is described in section 3.1 as "allow 
separation of streams that have different purposes, for example 
different media types".

I agree fully with the part before the comma; I disagree fully with the 
part after the comma. The idea that the *infrastructure needs to 
dictate* that different media types have different purposes is very far 
from self-evident, and I believe it to be false.

I believe that the user of RTP functionality is the only one who's in a 
position to decide when "different purposes" are appropriate.

This means that I think the solutions described in section 4.2 
(multiplexing shim) and section 4.3 (single session) are *both* 
appropriate to pursue, because I believe that there are situations where 
differing RTP sessions that need differential treatment in some way is 
important. Thus, the dichtonomy is false.

> separation when the short-coming of not having an layer of 
> multiplexing for media stream purposes.
>

In summary: I believe that pursuing multiplexing of RTP sessions across 
a single transport connection is a worthwhile pursuit, and the 
multiplexing shim seems a reasonable approach to make this work.

I believe that the RTP users are capable of evaluting for themselves 
when using multiple RTP sessions is appropriate, and that the current 
shortcoming of SDP that forces them to use multiple RTP sessions when 
the media they are sending is classified under different top level MIME 
types should be addressed - and that 
draft-homberg-mmusic-sdp-bundle-negotiation addresses this in a fashion 
that does not do damage to the rest of the SDP/RTP ecosystem.

                         Harald

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 10 Nov 2011 15:39:52 +0100

Hi,

Inline with comments on both topics.

> situation where you think trouble will occur, which does not involve a

The most likely case I think is the legacy gateway. Yes, the purpose 
with the fallback is to avoid it. However, if you have a SIP SBG and you 
anyway need to do ICE termination, then the media separation into two 
RTP sessions might actually be that you decide that it looks simpler to 
have bundled media on the WebRTC side and only one instance of the ICE 
termination, than to have two ICE terminations and not do the session 
separation.

But, I do agree, there is nothing forcing an implementation to do this. 
I only fear that implementors in their search for features to 
differentiate themselves will put something on the spec sheet for an SBG 
to an SIP or IMS system that says:

- Support WebRTC Bundle of media types, improved NAT traversal performance!

> Can you give some reference for the claim of "1000 times higher capacity"?

I can give you the motivation why I believe 1000 be the right ball park 
figure.

If you do a pure packet forwarder what you have to do is.
- Receive the packet from a given UDP flow, look up the corresponding 
outgoing UDP flows, forward it out one all of these flows.

- If you have a media mixing functionality then you will have to:
   - Receive the RTP packet
   - Decrypt the RTP packet
   - Decode the RTP packet
   - Perform up to one mix per destination with this media and others
   - Encode the mix
   - Encrypt the mix

That are at least 5 different steps, Decryption, Decoding, Mixing, 
Encoding, Encryption where the required CPU operations per byte of data 
is a number of CPU operations. G.719 for example has a complexity figure 
of roughly 18 MIPS, how many RTP packets can you forward using 18 MIPS. 
Quite a lot.

- If it is non mixing entity like an RTP mixer that switches media 
streams, i.e. sends them out using the Mixer's SSRCs. Then you still 
have the decryption and encryption cycle even if the media mixing, 
encoding and decoding goes away. So this is clearly less complex, but 
still more heavy than just forward the packet.

> millisecond for the middle case.

Yes, but if your goal for how many streams a single media range server 
should handle is in the region of 100000 or more, then it does matter.

> from self-evident, and I believe it to be false.

I agree that the application should have the freedom to choose. And the 
goal of the RTP Multiplexing architecture document is to provide 
guidance in those choice to the application.

And I think my guidance so far is that separate media type do have a 
advantage of using separate RTP session. However, it is clear in the 
trade-off between additional UDP flows and having to build more 
elaborate demultiplexing of the incomming RTP packets based on the 
payload type I would also have chosen a single RTP session.

But if we remove that consideration from the equation, isn't it still a 
reasonably good choice to separate media types from each other from the 
sole reason that the processing handling of the different media types 
simply are different.

> that does not do damage to the rest of the SDP/RTP ecosystem.

Then my argument towards WebRTC is that it should chose the RTP shim 
based multiplexing as also a realization of the case when you have 
multiple media types in one RTP session. The shim based solution clearly 
can support that also, both in the media plane on the signaling.

The reason is that if WebRTC choices the single RTP session over a lower 
layer transport as the only implemented choice then the application 
developers in any case that could have use for multiple RTP sessions 
will still be locked into two choices if they want to have inter 
operation with WebRTC end-points

A) Using multiple media types in one RTP session over a single UDP flow

B) Using multiple RTP sessions over independent UDP flows.

While using SHIM would enable independent RTP sessions over a single UDP 
flow. Thus being capable of handling all the use cases, including 
towards gateways and transport translators where one leg doesn't have 
the same capabilities as the other when it comes to using multiple RTP 
sessions over a single transport. Thus preventing a lock in effect to a 
potentially problematic solution, even if one do want to run multiple 
media types in a single RTP session.

Cheers

Magnus Westerlund

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 10 Nov 2011 11:02:01 -0500

(I'm cutting down this conversation heavily, to respond to just one point...)

Magnus Westerlund wrote:

> - If it is non mixing entity like an RTP mixer that switches media streams, i.e. sends them out using the Mixer's SSRCs. Then you still have the decryption and encryption cycle even if the media mixing, encoding and decoding goes away. So this is clearly less complex, but still more heavy than just forward the packet.]

I think, in practice, that an RTP mixer *inevitably* has to have at least this capability, and a pure transport translator is impossible for multipoint conferences, assuming that the endpoints' sessions with the central point are negotiated by SDP offer/answer.

The primary reason is that offer/answer allows each receiver to pick its own RTP payload type values.  This means the mixer has to re-write RTP headers, and also means it can't blindly forward unknown RTCP packets (since some RTCP extensions refer to the session's payload types). 

Additionally, both SDES and DTLS keying negotiate keys point-to-point, and offer/answer allows endpoints to pick their own b= receive bandwidth, which means different RTCP timings.  Both of these can be worked around to some extent (SRTP EKT is almost done, and having minorly-inconsistent RTCP timings is usually harmless), but it's not clear how much point there is to working around these issues, given the first one.

In practice, though, decryption and re-encryption isn't that expensive, particularly on modern CPUs with built-in crypto accelerators.  It's certainly tiny compared to the cost of media transcoding.

Thus, I think trying to design an architecture that makes pure-transport translation possible is a lost cause, if your primary use cases are offer/answer based, and so there's no point in creating new mechanisms in an attempt to support it.

Unless I'm missing something, SHIM falls in this category -- the benefits of SHIM over single-session muxing are largely for transport translation.

-- 
Jonathan Lennox
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 11 Nov 2011 10:20:04 +0100

On 2011-11-10 17:02, Jonathan Lennox wrote:
>> streams, i.e. sends them out using the Mixer's SSRCs. Then you
>> still have the decryption and encryption cycle even if the media
>> mixing, encoding and decoding goes away. So this is clearly less
>> complex, but still more heavy than just forward the packet.]
>
> I think, in practice, that an RTP mixer *inevitably* has to have at
> least this capability, and a pure transport translator is impossible
> for multipoint conferences, assuming that the endpoints' sessions
> with the central point are negotiated by SDP offer/answer.

I would disagree with you here. I think it is very much possible. Yes 
the PT picking is an issue, but if the translator is the inviting party 
and the responder doesn't renumber it will work. Having the translator 
or application server start the media invite is actually easier in the 
WebRTC context, than it is in normal SIP, as there you likely need to 
accept an initial invite from the client and then re-offer from the 
server to get things correct.

The renumbering of payload is introduced because of something in the H. 
suite, is it really commonly happening?

> Additionally, both SDES and DTLS keying negotiate keys
> point-to-point, and offer/answer allows endpoints to pick their own
> b= receive bandwidth, which means different RTCP timings.  Both of
> these can be worked around to some extent (SRTP EKT is almost done,
> and having minorly-inconsistent RTCP timings is usually harmless),
> but it's not clear how much point there is to working around these
> issues, given the first one.

This I agree is the other hazzle, but with EKT we do resolve it. And the 
transport translators only task beyond forwarding media in such a 
session will be to inject keys from the other legs towards each end-point.

>
> In practice, though, decryption and re-encryption isn't that
> expensive, particularly on modern CPUs with built-in crypto
> accelerators.  It's certainly tiny compared to the cost of media
> transcoding.

I agree it is tiny to transcoding. But is not tiny in comparision to 
packet forwarding.

>
>
> Thus, I think trying to design an architecture that makes
> pure-transport translation possible is a lost cause, if your primary
> use cases are offer/answer based, and so there's no point in creating
> new mechanisms in an attempt to support it.

We are definitely disagreeing on this point.

>
> Unless I'm missing something, SHIM falls in this category -- the
> benefits of SHIM over single-session muxing are largely for transport
> translation.
>

Not at all. It benefits any usage where you want to have an additional 
demultiplexing point based on purpose. The alternative is to classify 
each and every SSRC into a role, then process them differently in any 
node. That is under the assumption you want to avoid multiple transport 
flows.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Nov 2011 10:32:37 +0100

> should handle is in the region of 100000 or more, then it does matter.

Hm. 100.000 streams of audio at 50 pps is 5 Mpps.
At average packet size 128 bytes, this is 640 Mbytes/sec, or 5 Gbits/sec.

You need 6 cores equivalent to Eric Rescorla's Macbook Air (which 
encrypts on the order of 100 MB/s, no hardware encryption support) to 
handle encryption of those streams.

Or two Altera AES cores 
(http://www.altera.com/products/ip/dsp/encryption_decryption/m-dcr-aes_enc.html).

Yes, it does matter. Somewhat.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Nov 2011 11:32:58 +0800

I think this discussion shows pretty clearly that a pure RTP mixer (one 
that just forwards packets, and does not process any of them) is 
functionally equivalent to a multicast group.

I used to think that offer/answer was completely useless for negotiating 
media for multicast groups, but I think now that Magnus' comments seem 
to show how one can use offer/answer for that as long as a central node 
does all the offering.

On 11/11/2011 05:20 PM, Magnus Westerlund wrote:
> the PT picking is an issue, but if the translator is the inviting 
> party and the responder doesn't renumber it will work. Having the 
> translator or application server start the media invite is actually 
> easier in the WebRTC context, than it is in normal SIP, as there you 
> likely need to accept an initial invite from the client and then 
> re-offer from the server to get things correct.
>
> The renumbering of payload is introduced because of something in the 
> H. suite, is it really commonly happening?
>
> This I agree is the other hazzle, but with EKT we do resolve it. And 
> the transport translators only task beyond forwarding media in such a 
> node. That is under the assumption you want to avoid multiple 
> transport flows.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Nov 2011 18:26:05 +0800

> functionally equivalent to a multicast group.

No, a pure RTP Transport Translator is equivalent to a multicast group.

An RTP mixer uses its own SSRC for delivering media to any session
participant why using the media streams from the other. And thus mostly
disconnecting the legs only selected information are passed.

> to show how one can use offer/answer for that as long as a central node 

Well, there is special rules for multicast also to avoid this issue if
you look at SDP O/A.

Cheers

Magnus Westerlund

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 14 Nov 2011 18:55:05 +0800

> disconnecting the legs only selected information are passed.
Thanks. I keep swapping those terms.
> Well, there is special rules for multicast also to avoid this issue if
Yes, I noticed that 3264 rules for multicast were incompatible with 
those for unicast.

Is anyone using the 3264 rules for multicast setup?