1 / 10

GRUU Open Issues

GRUU Open Issues. May 2004 Interim Jonathan Rosenberg dynamicsoft. Pending Changes Agreed at IETF 59. Registrar will reject registrations for a Contact with an existing instance ID with a new response code Client can decide to delete the existing one if it wants

mboltz
Download Presentation

GRUU Open Issues

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. GRUU Open Issues May 2004 Interim Jonathan Rosenberg dynamicsoft

  2. Pending Changes Agreed at IETF 59 • Registrar will reject registrations for a Contact with an existing instance ID with a new response code • Client can decide to delete the existing one if it wants • Instance ID will remain a callee cap, add text about why using Caller Prefs to try to route to the instance ID won’t work

  3. Format of Instance ID • Current text merely says it’s a string • This isn’t good enough • Want something with structure to avoid conflicts across namespaces • List Proposal • Instance ID is a URN • URN value must be selected so that UA knows that no other instance with the same AOR would pick the same value • Give an example of UUID URN as a good choice, Bibliographic Reference as bad choice

  4. GRUU Properties • The spec defines three • Routes to a single UA instance • Temporally scoped – disappears when registration ends • Global – works anywhere • Temporal scope no longer makes sense • Same URI will be assigned when UA instance re-registers • URI doesn’t exist (404 returned) when there is no registration against an instance • Existence has a “swiss cheese” property – not the same as temporally scoped • Is that OK?

  5. Administrative GRUU Creation • GRUU being used by specs where UA instance is a server • KPML – application server instance • Conferencing – focus • In these cases, GRUU is not created by registration • But its still a GRUU! • GRUU is created administratively and configured into UA • Some confusion on what it means to be a GRUU in those cases • Proposal • document administrative assignment as a means for GRUU construction • Scrub text so its not biased towards registrations

  6. What if UA is physically separated UI (with keypad) on one host Signaling on another host Currently, GRUU is carried in Contact URI Thus, signaling and app interaction (KPML, REFER) go to same place List conclusion: don’t worry about this Separate UI/Signaling Component App SUB/ NOT SIP dialog UI Signaling

  7. Meaning of Contact: * Expires: 0 • Two possibilities • Delete all registrations (current meaning) • Delete all registrations with this instance ID • Would require providing the instance ID in the Contact • Change in semantics • Necessitates Require • On crash and reboot, you still need two REGISTER requests • Current: One to try to REGISTER your GRUU, which fails, another to remove old and add new • With change: One to delete all registrations for your instance, another to add new • No clear benefit to change • Proposal: clarify Contact:* Expires: 0 treatment as deleting all registrations

  8. Issue 1: No instance ID • Got a proposal to allow GRUU without instance ID • GRUU would then be bound to contact URI • This is the way GRUU previously worked • Do not want two algorithms • One idea is that different “URN” selections can achieve this effect • Contact IP as seen by registrar • TCP Connection ID • These are unique within an AOR but not temporally persistent • Describe this?

  9. Issue 2: Provide GRUU to Server • Got a proposal to allow client to propose GRUU to server • Moves persistent storage of GRUU to client • Problems with this • GRUU exists within the namespace of the domain, client doesn’t own that namespace • What if GRUU exists on server already? • What if its chosen in a way that the server doesn’t like or doesn’t support? • Adds complexity • Proposal: don’t do this

  10. Issue 3: Big GRUU • Suggested algorithm for stateless GRUU requires AES encrypting a concatenation of AOR, instance ID, salt • This can result in really long GRUUs • One experiment yielded ones 129 bytes long • These would be carried in each and every request sent by UA! • They are sigcomp compressible • Do we care? Alternate suggestions?

More Related