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

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

On the 1st issue: I remember this coming up at some point (maybe it was you or somebody else). And you are right, the current text in section 7.1 and the example in 7.3 indicate that the 'portmapping-req' goes into the unicast media block (if used at media level).

The reasoning was:
- There could be multiple associated unicast sessions for each SSM session, and in that case specifying this separately made more sense
- The messages we bundle with the Token (such as RAMS-R, RAMS-T, BYE, CCM, etc.) are actually related to the unicast stream not the multicast stream. Well, you could argue that RAMS-R starts the burst for a multicast stream but I could argue that it starts *the* unicast stream. OTOH, RAMS-T directly controls the unicast stream has nothing to do with the multicast, so does the BYE for the unicast session.

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.

We tried to be as explicit as possible in section 4.3 and left the door open for future possible additions to the list of messages that require or might require a Token. If that does not look good, we are open to suggestions.

-acbegen

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Thursday, December 09, 2010 8:10 AM
> To: IETF AVT WG
> Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-06: SDP attribute usage of port-mapping-req
> 
> Hi,
> 
> I looking at the new text and even more on the example I think there is
> something about the SDP attribute a=portmapping-req we need to discuss.
> 
> Section 7.1 says:
> 
> "  This new SDP attribute is used declaratively to indicate the port and
>    optionally the address for obtaining a Token.  Its presence indicates
>    that a Token MUST be included in the feedback messages sent to the
>    server triggering or controlling a unicast session (See Section 4.3
>    for details)."
> 
> As the messages that the token goes into is the RTCP feedback related to
> the multicast stream. Thus I would assume that the portmapping attribute
> would actually go into the media block in the SDP that describes the
> multicast session and its unicast RTCP feedback. But, according to the
> example it goes into the unicast session. I find that strange.
> Especially as one of the purpose is to indicate in which RTCP flow the
> token needs to be included. To me following the example would indicate
> that tokens are to be included in the RTCP directly related to the
> unicast session, i.e. reporting on the RAMS burst for example, rather
> than in relation to the RTCP message requesting the RAMS burst.
> 
> I think there needs clarification on where one puts this attribute.
> 
> 
> 2. I wonder if one shouldn't explicitly include some indication of what
> RTCP messages one expect the token to be included in. We already have a
> similar indication in the rtcp-fb attribute. Shouldn't this mechanism be
> made part of the portmapping-req attribute to indicate which messages
> that needs token?
> 
> 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]
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt