Subject: [AVTCORE] review of draft-westerlund-avtcore-transport-multiplexing-02

From: "Roni Even" <[email-masked]>
Date: Fri, 23 Mar 2012 13:22:01 +0200

Hi,

I think that if we are going to have a multiplex multi session solution I
will support using the shim based solution.  On open issue 3 I think that
the fallback when bundled is supported and the application fails to support
the shim it should fall back to multi session (multiple ports) since if the
offerer wanted a single session he could have offered one and probably had
application reason for asking for multi session.

I have some comments and questions on the document

1.       In section 4.3 "Lacking different RTP sessions to demultiplex
incoming packets, a receiver will have to dig deeper into the packet before
determining what to do with it. " I am not sure what you mean here, the
receiver will need only to look at the SSRC which is simpler than looking at
the Shim based session ID.

2.       In section 4.3 when discussion the multi party case my view is that
most implementations use the RTP mixer model and have separate SSRC space to
each party so there is no problem from going from multi session to
multiplexed single session in this case in terms of extra overhead.

3.       In section 5.8 when you fail the single session for vanilla RTP
sessions, I am not sure what you mean by Vanilla RTP session but if it means
that multiplexing/translation is done without knowing the signaling than the
shim solution will also fail. I believe that you are talking about the case
where all parties use the same SSRC space in unicast based multi party with
centralized server in which case you are right that the server will need to
re-negotiate the SSRCs but for the Shim case it may also need to do it if
the session-id received from one of the parties is not the common one.

Roni Even

As individual