Re: [AVT] 2833bis - RTP ping

[Flemming Andreasen <fandreas@cisco.com>]

Henning Schulzrinne wrote:

> Continuing on Flemming's comments:
>
> >
> > Other:
> > =====
> > RTP continuity:     Continuity tests are being performed in the PSTN
> > to verify
> > the operation of the trunk over which your call is setup. It turns
> > out, that
> > it's very useful to have a similar capability to verify continuity of
> > an RTP
> > session. While RTCP does offer some help in this area, it's not a complete
> > solution for a couple of reasons; 1) the RTP and RTCP destination
> > ports differ,
> > 2) you can't force the other party to actually send you an RTCP packet
> > when you
> > would like to (e.g. immediately to verify RTP continuity on call
> > setup). If we
> > had something like a "ping" and a "pong" event, it would be very
> > helpful (if
> > you get a "ping", you send a "pong"). Comments ?
>
> Clearly, this would only make work if you knew ahead of time whether the
> other side supports this feature. I can see the usefulness of this
> feature, but there are some details that may make this more than just
> another special event. A few questions:
>
> (1) Who should send this? Clearly, end systems, but what about RTP
> mixers and translators?
>

I was only considering end-systems.

>
> (2) If mixers just replicate the packet without knowledge of the
> content, they'll get a response from each participant. Is that ok?
>

Only if we can guarantee that they won't be flooded with packets, but per (3),
that seems to be rather difficult.

>
> (3) What happens if you send this to a multicast address with 10,000
> participants? The sender and receiver may not actually know that this is
> multicast, since there may be a translator that bridges between unicast
> and multicast. The translator may also be ignorant of the special 2833
> event type (and 2833 in general), but will quickly figure out that it
> did something special, after getting flooded with 10,000 "pong" packets...
>

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