[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] 2833bis - RTP ping




Henning Schulzrinne wrote:

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

Actually, I wasn't planning on sending the "pong" back to the source address if
that's what you're implying. Rather, it should go where all other RTP packets
for the session goes.

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

1) Verify, in real-time, that RTP packets sent to the destination are actually
received (keeping in mind that NATs, firewalls, etc. may play different tricks
on RTP and RTCP).
2) Perform 1 on demand (at least once), including during call setup.

-- Flemming


>

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