1 / 8

Reg Event Package Extensions

This draft proposes extensions to the SIP GRUU registration event package to address issues with the returned contact information and enable global addressability. It includes use cases for welcome notices, coordination among registered endpoints, and learning GRUUs for implicit registrations. The proposed extension provides a simple and straightforward solution.

baileyjoyce
Download Presentation

Reg Event Package Extensions

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. Reg Event PackageExtensions draft-kyzivat-sipping-gruu-reg-event-03 IETF63 Aug-2005 draft-kyzivat-sipping-gruu-reg-event-03

  2. Reason for This Draft • The reg event package is broken by the GRUU extension • The returned contact info is not useful to subscribers • Applications depending on that info break when the GRUU is needed for global addressability • The fix is simple and straightforward draft-kyzivat-sipping-gruu-reg-event-03

  3. Use Case – Welcome Notices • Example 3 of RFC 3680 • Server subscribes to reg event • When a new contact is registered, the server sends a “welcome notice” to that contact. • Problem when registration requested (and needed) a GRUU • Without the GRUU, the welcome notice won’t reach the newly registered device • Solved by returning the GRUU in notification draft-kyzivat-sipping-gruu-reg-event-03

  4. Use Case – coordination among registered endpoints • Endpoints and/or State Agent subscribe to reg event of own AoR, • use returned contacts to subscribe to dialog events of all registered endpoints. • same failure mode as previous example • This usage now showing up in drafts • e.g. draft-anil-sipping-bla-02.txt draft-kyzivat-sipping-gruu-reg-event-03

  5. Use Case – Learning GRUUs for Implicit Registrations • In IMS, registrations to AORs may be implicitly created • Based on registration to another AOR • If IMS is to support GRUU, it needs a way to discover the gruu assigned to an implicit registration • while contact is same, GRUU must differ • IMS is being considered in environments where GRUU will be needed • The proposed extension provides a natural solution to this problem • The reg event subscription is already being used draft-kyzivat-sipping-gruu-reg-event-03

  6. Changes Since IETF-61 • Aligned with draft-ietf-sip-gruu-03 • Included IMS as an added rationale • With corresponding example draft-kyzivat-sipping-gruu-reg-event-03

  7. What is Proposed • This draft defines extension element for application/reginfo+xml • Provides watcher with GRUU for each Contact. <contact id="76" state="active" event="registered“ <uri>sip:user@192.0.2.1</uri> <unknown-param name="+sip.instance"> "<urn:uuid:f81d4…>" </unknown-param> <gr:gruu> sip:user@example.com;opaque=hha9s8d </gruu> </contact> draft-kyzivat-sipping-gruu-reg-event-03

  8. Next Steps • Hum: returning gruu in reg event is a good thing. • WG adopt this draft as base draft-kyzivat-sipping-gruu-reg-event-03

More Related