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-18 14:29:
> 
> 
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]]
>> Sent: Monday, January 17, 2011 9:55 AM
>> To: Ali C. Begen (abegen)
>> Cc: IETF AVT WG; [e-mail]
>> Subject: Re: WGLC comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-11: Part 4 SDP attribute semantics
>>
>> 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.
> 
> Right, the messages that control the unicast session and that are sent in the unicast session (like BYE and CCM) need to be authenticated (as written in 4.3.1).

Yes,

>  
>> 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".
> 
> Ok. I guess your concern is that the "portmapping" attribute is defined media level and used in multicast block, yet it means messages triggering or controlling the unicast session might need token authentication. Is this your concern?

Yes, lets indicate in which RTP session where token verification request
truly are needed.

> 
> I don't think we should define it as session level as I mentioned earlier, it opens other corner cases. So, let's see how we can address this while keeping it media level. 

Media level only is fine.

> 
> I guess we have two options here. We either repeat the "portmapping" attribute in both blocks and keep the "portmapping-req:port" in the unicast block only, or repeat "portmapping-req:port" in both blocks and remove the "portmapping" altogether. The latter saves one line from the SDP.

I would do the later. Keep portmapping-req and put it in all media
blocks that defines RTP session that uses Token Verification.

>   
> BTW, the last part of the 3rd paragraph in section 7.1 needs to be changed to:
> 
>   ... (ii) the client MUST receive the
>    unicast session's RTP and RTCP packets from the server on the port
>    from which it sent the RTCP message triggering the unicast session.
> 
> (Removed "or controlling" since that would mean port c2).
> 

Yes, I think you might have to explicit call out where the verification
failed message is sent from the server to the client for any
verification message sent from client at C2->P4.

> ...
>>> 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.
> 
> Correct.
>  
>> 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.
> 
> Does putting the attribute only in the mcast block resolve your concerns? I don't think so as it will not cover the unicast session for which the rtcp messages are sent for.

Correct, I want it the semantics of the attribute to be. In this RTP
session, there is need to use Token Verification for some RTCP messages.
And here is the server port and address where you can get a 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]
----------------------------------------------------------------------