Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Magnus Westerlund
> Sent: Friday, January 14, 2011 5:22 PM
> To: IETF AVT WG; draft-ietf-avt-ports-for-ucast-mcast-rtp@tools.ietf.org
> Subject: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 1 SSRC spaces
> 
> Hi,
> 
> This is one of several issues I still see remaining in the document. It
> has clearly improved. I am sorry that I become sick before Christmas and
> couldn't continue the discussion then.
> 
> There is an issue with SSRC usage in this document related to the
> different RTP sessions. Please remember that the most fundamental part
> of the RTP session definition is that each RTP session has its own SSRC
> space.
> 
> So there is one SSRC number space for the multicast RTP session. An SSRC
> from this space is used in the Token Verification Request to identify
> the requesting client. In the Token Verification response message this
> SSRC identifier is included in the Token response message. The problem

Are you referring to the port mapping request/response messages? In that request, client chooses an SSRC randomly. This exchange does not belong to either session (not necessarily) since the same token can be used in different unicast sessions.

In the token verification request message, the client uses whatever SSRC it needs to use for that particular unicast session.

> is that this message is conveyed in the unicast RTP session that has its
> own SSRC space. Thus we have potentially create a coupling between the
> two RTP sessions.

Nope, this is not correct.

> As I see it this can be fixed in two ways. Either one explicitly notes
> that this RTCP Token Response message field carries a value that refers
> to the SSRC space in another RTP session then one currently are in. This
> is likely the simplest solution.

This is already mentioned in section 4.1 where we say the ssrc is chosen randomly. 

> The alternative is to accept the coupling. But then one has to make
> clear on how to handle SSRC collisions. This seems problematic as the
> coupled session is a multicast session. A multicast session has bigger
> difficulties with changes due to its number of receivers and also that
> if one forces an active sender to change it may causes widespread
> disruption.
> 
> I also observe that it is not clear what SSRC space the Port Mapping
> request and response messages uses. Does this need to be synchronized
> with any other space or can it be its own unique one. A unique one is
> probably easiest. I don't see any direct coupling to the other sessions.

That SSRC is not used anywhere for a purpose, so that's why we decided to say "choose it randomly and forget about it".

-acbegen

> 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: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt