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

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2011-01-17 14:58:
>> 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?

I think the confusion is that I believe it will be cases where Token
Verification Requests are going to be need to be sent on C2->P4. If that
is the case one needs semantics to say that token may also be included
in RTCP message related to this session.

In addition the semantics for the portmapping-req that now is mandated
to be on the declaration of the unicast RTP session. If we take your
argument there is no need for token verification in that session. Thus,
can you please explain why it is part of that session declaration?

In my world there could be token verification messages in the RTCP for
the unicast session. However, the declaration of where the Token server
should then either be in all RTP sessions that uses Token Verification
Messages, or at session level and applies to all "portmapping".



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

Here we seem to disagree. If one looks at the list in section 4.3.1, i
think that this does contain messages where you would like to attach
token, such as BYE or CCM messages.

It might be me taking the generalized look on this specification. Then I
do see a need to make sure that it can be used in any RTP session where
indicated.

If the intention to not have any session level attribute, then I don't
understand why we have two SDP attributes, then only portmapping-req is
needed. And I think it should be defined as having the meaning. Shall be
included in the SDP media blocks that define an RTP session that needs
Token Verification messages. Which means that portmapping-req are needed
in the multicast m= block, not the unicast.



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