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-17 14:23:
>> 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.
> 
> Right.
>  
>> 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
> 
> Yes, and the server simply gets this SSRC from the request message. 
> 
>> session, but is in reality a response to the message in the multicast
> 
> Yes, maybe it was a NACK sent for the multicast session.
> 
>> 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.
> 
> In the failure message:
> 
> SSRC of Packet Sender: This is server's SSRC, which equals the SSRC of the respective primary multicast stream.
> SSRC of Requesting Client: This SSRC is directly copied from the Token Verification Request message (this text already exists in 4.4).
>  
> Is the "packet sender SSRC" definition fine with you?

I think I would like to have extra warning: "Note, theis SSRC value are
from a different SSRC space than the one used in the Unicast RTP session."

>> 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?
> 
> We can move them to the bullets. We probably did not so because, they are pretty much part of the baseline format.

I think it has its point when we do have some irregularities here in
some cases.

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