Re: [AVT] WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics

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

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: Friday, January 14, 2011 5:57 PM
> To: IETF AVT WG; [e-mail]
> Subject: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics
> 
> Hi,
> 
> I think the change for the SDP attributes "portmapping" and
> "portmapping-req" was an improvement. However, I think the semantics and
> usage of these SDP Attributes needs clarification.
> 
> Lets start with "portmapping", currently it seems vague and not match
> the generalize requirements needed. The current semantics appears to be:
> Include in the multicast m= block which in relation there might be need
> for token verification request. For example if one looks at Section
> 4.3.1 where BYE messages related to RAMS bursts may need tokens. That is
> within the unicast session created if I understand correctly. Thus there
> is no indication in this media block. Only in the Multicast session

There is indication in the unicast block.

a=portmapping-req:30000

> block. This appears to be rather fuzzy and unclear.
> 
> I would like to resuggest the semantics I was considering before:
> 
> The "portmapping" attribute SHALL be included in any SDP media block
> (m=) that define an RTP session that require the usage of token
> verification requests for one or more RTCP message.

We discussed this at length in the call and the group decided to propose what we have in the draft now. Your proposal, repeating the same attribute in two blocks, is actually worse, and even more confusing.
 
> Then I frankly have to say that I don't grasp what the semantics are
> related to the placement of the "portmapping-req" attribute. Yes, it
> conveys the port and possibly address for where to send the Mapping
> request. But what is the meaning of its placement on a particular media
> block? Why is it placed in unicast blocks? Even if no Token is required
> in this RTP session?

I don’t know what else to add on top of what I have written before. 
 
> To me it appears that this attribute would be better served by becoming
> an Session + possibly override in media blocks. At session level it
> would server as the port mapping port and possibly address, unless c= at
> session level is unicast to the mapping server, that is used for all
> tokens used in the RTP sessions indicated by the "portmapping"
> attribute. Then it may be included at media level in an media block
> containing a=portmapping to override this port and address within that
> particular media block.

We decided to have both attributes media-level only. Session-level attributes created a lot of corner cases and confusion, some of which was raised by Roni. 

Overall, I think the current SDP stuff works just fine.

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