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

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

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Friday, December 10, 2010 4:57 AM
> To: Ali C. Begen (abegen)
> Cc: IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req
> 
> Ali C. Begen (abegen) skrev 2010-12-10 05:36:
> > ...
> >>> 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.
> >
> 
> Ok, that is actually a point that is pretty strong. However, I would
> point out that the RTT you are talking about is the time of sending one
> RTCP message in each way. Which is likely substantially longer than the
> network layer RTT between the two nodes.

Still not necessarily a delay factor since it is not serial if used properly.
 
> I would like to see clearer text on what future extensions requiring
> this functionality needs to define. It appears that they would need to
> define what RTCP messages that needs tokens. And taking RAMS as a case,
> the need to possibly do it in two sessions.
> 
> Which leads me into a question if it is not clearer to signal this
> explicitly. For in RAMS we do have the RAMS-R that goes to the RTCP
> feedback port in relation to the multicast group. Then we have RTCP BYE
> and RAMS-T that goes in the created unicast session. If one combines
> this with also retransmission then that goes into the multicast RTCP
> feedback flow. Having explicit indication on where all of these goes I
> think has its points. Especially when people do extensions and stuff and
> may require more than what the basic extension requires.
> 
> I also wonder if this can become a point of interoperability. Not that
> it in practice is difficult to include the token verification request
> together with any other messages, but you need to write your code in a
> certain way so that you can do it always, and especially if one gets a
> token verification failure on a message you where not expecting it on.
> Especially if it is a compound packet with several message types so that
> you don't really know.
> 
> > 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.
> 
> Yes, I agree not straight forward, but clearly possible to do and you
> probably can write up a good one in a few hours. As I see it you need to
> cover general RTCP packet types of single purpose, some that has
> multiple subfields or functionaltity, the APP one and private extensions
> (maybe using a reverse domain name system).
> 
> >
> > 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.
> 
> Still disagreeing and would like to hear more input into this question.

Does anybody else think about this strongly one way or another?

-acbegen

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