1 / 4

Active RTP liveness discovery

Active RTP liveness discovery. Henning Schulzrinne Columbia University hgs@cs.columbia.edu 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

jael-benson
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Active RTP liveness discovery Henning Schulzrinne Columbia University hgs@cs.columbia.edu AVT working group IETF 55 (November 2002, Atlanta) AVT IETF55 November 2002

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

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

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

More Related