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

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2010-12-02 22:36:
> 
> 
>> -----Original Message-----
>> From: Colin Perkins [mailto:[e-mail]]
>> Sent: Thursday, December 02, 2010 4:23 PM
>> To: Ali C. Begen (abegen)
>> Cc: Magnus Westerlund; IETF AVT WG
>> Subject: Re: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments [csp]
>>
>> Most of my comments have been covered in the discussion. Just some minor points inline.
>>
>> Colin
>>
>>
>> On 2 Dec 2010, at 17:47, Ali C. Begen (abegen) wrote:
>>>>>> - Reusing a unicast session for different multimedia session, which I think implies having them share the FTap.
>>>>>
>>>>> This is not a problematic case, either.
>>>>
>>>> I am not agreeing fully. There need to be some consideration here for it. Because you need to know which session the
>> incomming UDP data relates to. For example if one has an ongoing RAMS burst for one channel and then sends a NACK
>> request or another RAMS request and request to use the same unicast session it is not obvious that the data is distinguishable
>> from one channel to the other. Thus clearly consideration should be done here. like alternating between two different unicast
>> sessions with RAMS requests to avoid overlap.
>>>
>>> Such considerations are discussed in the RAMS draft. If the (feedback) port on the server is shared among multiple RTP
>> sessions, then the client has to know the SSRC of the media stream(s) it wants to acquire. If SSRCs are not available in the
>> SDP, that port cannot be shared.
>>>
>>> I don't think that discussion belongs in here.
>>
>> I suspect this can happen with services other than RAMS, so the general issue should be highlighted.
> 
> Probably yes. Correct if I am wrong but this does not relate to the Token AFAICT. Here we are discussing the PT port which is used to acquire a Token from, whereas the concern Magnus has raised is related to sharing the feedback target port among multiple RTP sessions (which is the a=rtcp line in the multicast session).
> 
> Maybe, this belongs to 5760?

I think it belongs in the port mapping draft. Because without it what we
are discussing here is not really possible. The port mapping allows one
to do late binding between a receiver local port and a specific feedback
target address that relates to a specific SSM session. If there is some
overloading ongoing for the FT Adress plus port then re-using the
receivers local port creates an issue of separation. This would not
likely happen if one had to pre-establish the unicast sessions. It
becomes the receivers choice to re-use a specific local port, and that
is really what the discussion here is about.

>From my point of view a receiver really should use different local ports
when submitting RTCP requests related to different SSM sessions. That
way you avoid the whole mess, even if there is some overloading happening.

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