Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2010-12-02 17:38:
> Hi Magnus,
> 
> We are almost there. A few points are left below. I also removed a few issues (such as O/A stuff) and I will discuss them separately.

Ok, see below

>  
>>>
>>>> T4. Section 4. IP address for token request.
>>>>
>>>> It is not clear on how the IP address for the Token Request is
>>>> determined. Is this the C=? I think there is a good point in allowing
>>>> optional specification of the address information in this SDP attribute,
>>>> similar to the a=rtcp attribute.
>>>
>>> The address is the feedback target address in the primary session, which equals to the address given in the C line for the
>> unicast session (as you indicated).
>>>
>>> Does it make any sense to have the token request message to be sent to a different address than the unicast source (which
>> also means the token response could be sent by another entity)? This may break the Token actually since client's IP address
>> might be different for different destinations, right?
>>
>> I think we should enable it as I find it likely that someone will use
>> such a setup. If the setup is a anything like homes with NATs and no
>> large scale NAT then I don't think there is likely that you will get
>> another IP address in the NAT. Even large scale NATs will do their best
>> to use the same IP address for the same underlying host.
> 
> True, it really increases the number of failure modes. Do we really need this?

Yes, it does increase the number of failure modes if wrongly used. Used
in deployment where it makes sense to have the token generator in one
host and then use that for a number of servers it will not. But that
assumes you know have some knowledge about your deployment infrastructure.

As I see the benefit of allowing optionally to specify a token request
address and not only port is to allow re-use of tokens across several
servers. I don't have a strong view on the need for this, however if we
don't add it now, it will be difficult to introduce.

> 
>>> I don't think the server can determine which component was the reason for verification failure. I.e., the server generates a
>> new token based on the new input and it can only decide whether it is a match or not. If it is not, it cannot determine
>> whether the nonce or the IP was to blame.
>>>
>>> As for the expiration time, the client should not send such tokens anyway. If it does and it receives a failure message, the
>> reason would be obvious.
>>>
>>> Overall, I don't think we can (or need anyway to) specify the reason for failure.
>>
>> So you are basically saying, if you get Token error, simply go request a
>> new one?
> 
> Right. 
>  
>> And you don't think there will be any difference in the client behavior
>> based on the reason.
> 
> The client always needs to make sure that the token has not expired. Beyond that its behavior does not matter.
> 
>>
>> Ok, I think I can live with that in the token verification step.
>> However, then I think we need something in the token request response
>> message that says, sorry, I can't give you a valid token. Otherwise the
>> server has no way of cleanly say no to a receiver that are not being
> 
> We already have this. The server sends the Port Mapping Response with relative expiration time set to 0. 

Ok, forgot about that. Then I guess it works.

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