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

[Magnus Westerlund <[e-mail]>]

Van Caenegem, Tom (Tom) skrev 2011-01-14 17:44:
> 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>

Yes, just being a bit more explict about that this SSRC value are in
another RTP session SSRC space resolve this.

> 
> 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..>

Ok, it is not obvious. And I have to say that this session is far from a
common RTP session. It is only RTCP messages, and also in fact not sent
using normal timer rules. Only when needed, which might actually need to
be pointed out also.

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]
----------------------------------------------------------------------