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

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Magnus,

Thx for the comment, see below 
Tom
-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
Sent: vrijdag 14 januari 2011 17:22
To: IETF AVT WG; [e-mail]
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 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.

<Tom: well the text says for the "token verification failure message":

SSRC of Requesting Client (32 bits):  Field that contains the SSRC
      of the client who sent the verification request.

..but this does not mean it equals the SSRC in the token verification request message.  The port mapping "client" has its SSRC in the SSM session, its SSRC in the port mapping exchange messages with the server and its SSRC in the unicast sessioon. It needs to use the correct SSRC in the messages sent in all these sessions. Of course, a relaxing implementation may use the same client SSRC across
these sessions.. (but in conflict with RFC 3550)>

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. 

<Tom: this is what was implied by the text..but should be called out more explictly perhaps>

This is likely the simplest solution.


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.

<Tom: has its own SSRC space....  See also the figure that shows the three sessions decoupled by means of the dashed lines..>

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www.ietf.org/mailman/listinfo/avt