Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req

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

...
> > Following up on this, for the 2nd question: Tying the token to the rtcp-fb line does not seem much right, either. For
> example, rtcp-fb line in the multicast media block has nothing to do with RAMS-T.
> 
> I said that the design of the attribute on which RTCP messages requires
> token could be done along the lines of the rtcp-fb attribute. Not that
> it should be tied to the SDP Attribute. I would say that the portmapping
> attribute is related to the RTCP sent for a particular RTP session.
> Independent of how that RTCP destination is indicated.

Hi Magnus,

We thought of describing the message types needing a Token in the SDP but there is a no clear way of doing this. It seems to be an unnecessary optimization to us, and it will not necessarily simplify the implementation.

First of all, when a client sends a message without a Token (although it was needed), the server will send a " Token Verification Failure" message. If the client implements the Token specification, it will know what to do (will try to acquire a Token). This will cost merely an RTT of delay. And this delay is not necessarily a serial delay. We don't need any further optimization here. If the client does not implement Token stuff, and the server requires it for that particular service, it means the client will not get that service. There is nothing we can do about this.

Second, listing which RTCP packet types (e.g., 204, 205 or 206) require a Token in the SDP description is not straightforward. If simply listing 205 or 206 were enough, we could use this approach. However, it is not. For example, under 205 some FMT values will require a Token while others will not. Furthermore, RAMS defines a sub-FMT field to identify specific RAMS control messages. To indicate that RAMS-R message requires a Token, we would have to say in the SDP "205 (for RTPFB) -> 6 (for RAMS) -> 1 (for RAMS-R)". We don’t think this is a clean approach.

Overall, I think we could keep the current approach where the SDP only carries the 'portmapping-req' attribute to indicate the port/address for Token requests. No need to describe anything further. Section 4.3 seems sufficient.

-acbegen