Re: [AVT] 2833bis - RTP ping

[Henning Schulzrinne <hgs@cs.columbia.edu>]

As your note points out, you'd have to be a lawyer to deal with all the 
corner cases where things could go wrong, particularly since translators 
and mixers may not always be visible to the parties initiating the session.

There's also another, non-multicast problem: You have to be really 
careful that you don't inadvertently create a DOS mechanism. You won't 
get amplification, but the system now has to check for various no-no 
addresses (local broadcast, multicast) to make sure the return address 
is safe.

It might help to determine what types of diagnostics problems this is 
supposed to solve; maybe there's another way. (One possibility would be 
a triggered RTCP message that "uses up" the RTCP bandwidth allocation 
and is subject to the usual reconsideration rules.) This still doesn't 
address the same-port-as-RTP requirement you posed, but it should 
diagnose most likely problems.

My general concern is that the mechanism better be simple, or nobody 
will implement it, defeating its usefulness as a diagnostic tool.

Thus, can you summarize the problems that this mechanism is supposed to 
solve?

> Hmm, that's a good question. I suppose an answer along the lines of 
> ""we would
> only do it if we knew that" won't be satisfactory...
> We wan't to send as soon as possible, i.e. don't want to wait for any RTCP
> reports, so we have no way of knowing or even guestimating the actual 
> number of
> RTP session participants based on RTCP. As you indicate, the presence of
> translators means we have no reliable way of distinguishing a 
> point-to-point
> case (which is what I am interested in) from a point-to-multipoint or
> multipoint-to-multipoint case based on IP-address information.
>
> This all seem to suggest that the only solution is
> 1) End systems must not use it if you believe you are not doing 
> point-to-point
> (use of multicast would probably imply that it is not point-to-point)
> 2) Mixers and translators must not support these packets if they 
> believe they
> are engaged in a multipoint session.
>
> In general, we can't expect mixers and translators to apply special 
> processing
> to some RTP packets, so we would have to require, that any session 
> description
> containing the destination address of a mixer or translator cannot 
> violate 2)
> above. That in turn would seem to imply that any such session 
> description would
> have to be generated by the mixer or translator itself (and hence it 
> would have
> to actively announce use of these events for them to be used) as 
> opposed to e.g.
> some middle-man just changing the destination address in a session 
> description
> without looking further into what is actually going. That's probably not a
> viable path forward.
>
> Any good suggestions ?
>
> -- Flemming
>
>
> >With RTCP, we have rate-limiting options in place which deal with these
> >issues, particularly (3).

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt