1 / 10

GRUU again for the last time really

GRUU again for the last time really. Jonathan Rosenberg Cisco. Changes from -11. Minor Changes Removed references to provisional responses for non-INVITES Added note from Dales draft about not mucking with Contacts with ;gruu

nyx
Télécharger la présentation

GRUU again for the last time really

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. GRUUagainfor the last timereally Jonathan Rosenberg Cisco

  2. Changes from -11 • Minor Changes • Removed references to provisional responses for non-INVITES • Added note from Dales draft about not mucking with Contacts with ;gruu • Added note from Dale’s draft about treating GRUU opaquely and not modifying URI parameters • Updated appendix to use EKRs stateless tokens draft

  3. Main Change: The Register Race REG Registrar Changes Expiration to 5s 200 OK NOTIFY reg-info 200 OK expiration REG new reg 200 OK NOTIFY reg-info Registrar sends a singleconsolidated state updatefor the result of the previoustwo events since they cameclose together So did My registerbeat the clock?? 200 OK

  4. General Problem • IF the registrar is going to muck with registrations, we need a reliable way for client to synchronize its temp-gruu with server at any time • Determine whether its set of valid temp-gruu match the servers

  5. Solution in GRUU-12 • If server modifies expiration times, MUST implement reg-event and gruu extension • Client that implements reg-event and GRUU MUST support gruu-reg-event • Reg-event notifications contain CSeq of first contact registered to that gruu with a given call-id • Client keeps all temp-gruu learned in REGISTER responses whose • Call-ID matches that of reg-event • CSeq is higher than that of reg-event

  6. Side Effect • Changing Call-ID in REGISTER refresh will • Expire all previous temp-gruu • Not cause any outage in registration – just a refresh – low overhead • Provides a crude bulk invalidation technique

  7. Consequences • If an instance fails and recovers and registers with a new Call-ID and same instance-ID • All temp-gruu are invalidated • Stateless token generation needs to use Call-ID and original CSeq instead of wallclock time

  8. Other ML Issues • Jeroen: temp GRUUs can be long • Will note this • Ekr-1: Is Supported or +sip.instance the trigger for GRUU generation? • As it is currently - +sip.instance. • Ekr-2: inclusion of pub-gruu and temp-gruu in REGISTER MUST NOT or SHOULD NOT? • Current SHOULD NOT is fine

  9. Other ML Issues • Ekr-3: Should a rebooting UA remove a stale contact? • No, as it is now • Ekr-4: Separators needed in string for cookie? • Yes – will add • Jeroen-1: only do GRUU processing for non-expiring contacts • Yes – will add • Jeroen-4: What if there are multiple contacts with same instance and no reg-id (GRUU but not sip-outbound) • Need to update – use outbound-like behavior to take most recent contact

  10. Next Steps • I have incorporated all comments into a working -13 • Once blackout period ends, -13 can be submitted and go to IESG

More Related