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

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2011-01-14 19:32:
> 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
>> Sent: Friday, January 14, 2011 5:22 PM
>> 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
> 
> 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.

Lets try again to describe the above paragraph, as we clearly
missunderstanding each other.

The client has an SSRC that is uses for regular RTCP feedback to the
Retransmission server. If is want to send a NACK, then it include a
Token Verification Request. In that message it include the SSRC of the
client. This SSRC comes from the Multicast RTP sessions SSRC space.

Then the Retransmission server may send an RTCP message back to the
client in a form of the Token Verification Failure message. This message
include the SSRC of the requesting client. As this Token Verification
Failure message is sent in the RS -> Client leg of the created unicast
session, but is in reality a response to the message in the multicast
RTP session. This creates a case where it is uncertain which SSRC space
the SSRCs in the failure message belong to. Based on network selectors,
e.g. UDP ports this message is in the unicast space. But semantically it
belongs to the Multicast channel.

Please make it clear in the description in 4.4 what space the SSRC
values belongs to.



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

Yes, for mapping message that is fine. The thing I can complain about is
why the SSRC fields aren't there own bullets and instead hidden in the
pre-facing text to the figures?

-- 

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