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

["Ali C. Begen (abegen)" <[e-mail]>]

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

We can move them to the bullets. We probably did not so because, they are pretty much part of the baseline format.

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