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

> Ok, can you then write down the exact semantics of the portmapping-req
> and portmapping attribute? Because to me their semantics aren't clear.
> And without clear semantics this is going to cause confusion when used
> the next time.

I am not sure what you are looking for in addition to what section 7 says.  they are used in pairs. portmapping is used in the multicast block and portmapping-req is used in the unicast block. Together they mean, certain rtcp messages will require the token. The portmapping-req will tell you where to get the token from. Any confusion or question here?
 
> >> 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.
> 
> Fine, I can live with that.
> 
> >
> > Overall, I think the current SDP stuff works just fine.
> 
> I disagree, because in cases where you need token verification requests
> also in the unicast client to server RTCP leg C2->P4, then I don't

The only thing that travels from c2->p4 is the receiver reports for the unicast session. How would you send a token verification request message on that path? The verification request message goes from c1 to p3.

-acbegen

> understand how that is separated from when it is only needed in C1->P3.
> This as I don't understand the semantics of the SDP attributes.
> 
> 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]
> ----------------------------------------------------------------------