Active rtp liveness discovery
This presentation is the property of its rightful owner.
Sponsored Links
1 / 4

Active RTP liveness discovery PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

Active RTP liveness discovery. Henning Schulzrinne Columbia University [email protected] AVT working group IETF 55 (November 2002, Atlanta). Requirements. Active, i.e., even if other side is not sending Deal with NAT and firewall disruptions use same port and protocol as “real” traffic

Download Presentation

Active RTP liveness discovery

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Active rtp liveness discovery

Active RTP liveness discovery

Henning Schulzrinne

Columbia University

[email protected]

AVT working group

IETF 55 (November 2002, Atlanta)

AVT IETF55

November 2002


Requirements

Requirements

  • Active, i.e., even if other side is not sending

  • Deal with NAT and firewall disruptions

    • use same port and protocol as “real” traffic

  • Don’t provide DOS tool

  • No implosion for multicast

  • RTP mixers & translators may not be aware of mechanism

AVT IETF 55

November 2002


Solution 1 rtcp

Solution 1: RTCP

  • send dummy RTP packet, use RTCP response to confirm receipt

  • RTCP already subject to multicast scaling, including reconsideration

  • RTCP response may be delayed

    • not substantially longer than max. reasonable RTT

    • can probably decrease min. interval

  • Can’t know if receiver implements RTCP

    • everybody should 

    • can tell whether any RTCP messages

AVT IETF 55

November 2002


Solution 2 rtp ping

Solution 2: RTP “ping”

  • send special RTP packet if other side advertises capability via SDP

    • receiver returns another special RTP packet, to either:

      • to SDP address

      • to IP source address & port  no guarantee that anybody’s listening there

  • potential feedback implosion  reimplement RTCP one feature at a time

    • ping sender can’t know for sure that there’s no multicast

      • conference mixers

      • RTP translators

AVT IETF 55

November 2002


  • Login