1 / 6

Implicit Subscriptions

This article discusses the challenges faced in implementing implicit subscriptions in SIP, including issues related to NAT, SBCs, and unsolicited NOTIFY messages. It also proposes a solution that couples subscriptions with registrations to improve efficiency and reduce messaging volume.

ouidaj
Télécharger la présentation

Implicit Subscriptions

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. Implicit Subscriptions Jonathan Rosenberg Cisco Systems

  2. A Trend • IETF and SIP WG are (for the better) recognizing that industry usage doesn’t match specifications in several areas • NAT (behave) • SBCs (voipeer, sipping SBC work) • But, there are others • Unsolicited NOTIFY

  3. Why is it common? • Perceived high cost of subscription maintenance at client • Refreshes, dialog for entire registration interval • Perceived high cost of subscription maintenance at server • One for EVERY user that is logged in • Perceived high cost of messaging compared to frequency of events • Not like presence • Assumption of endpoint interest • “Self” cases – unlike presence • There is a real engineering issue here

  4. Other Problems • Avalanche restart: Metropolitan power outage and reboot • Endpoint messaging • SUBSCRIBE config-pkg • REGISTER • SUBSCRIBE for • MWI • Reg-event • Presence-list • Winfo • Dialog-event (BLA) • 13 SIP transactions! • Time to recover and potential scope of load directly proportional to this

  5. Requirements • Reduce messaging volume • Ideally: 1 transaction (REGISTER) • Allow event servers to have a finite number of dialogs • Preserve compatibility with RFC3265 mechanisms

  6. Proposed Solution • Couple a subscription with a registration • Subscription lifetime bound to registration lifetime • Create subscription as a side effect of registration • Tunnel dialog identifiers through REGISTER request and response

More Related