2010/3/21 Iñaki Baz Castillo <i...@aliax.net>: > Hi, after reading the RFC 5627 I don't understand why the registrar > can create a new temp-gruu URI for each registration refresh. > If it does so, the registrar would end with a database full of temp-gruu > URI's. > > From the point of view of a registrar implementing GRUU, is it posible > to mantain an unique temp-gruu for each registration instance (as it > occurs for the public-gruu? > It would make the implementation easier (by adding two columns > "temp_gruu" and "public_gruu" in the location database table). > > Do I miss something? Also, the example in section 9 of RFC 5627 shows > the same temp-gruu for two different registration from same UA > instance (as it crashed and generates a new registration with > different Call-ID after rebooting).
This is the exact point I cannot understand in RFC 5627: ----------------------------------------------------------------- 3.2. Obtaining a GRUU When a user agent refreshes this registration prior to its expiration, the registrar will return back the same public GRUU, but will create a new temporary GRUU. Despite the fact that each refresh provides the UA with a new temporary GRUU, all of the temporary GRUUs learned from previous REGISTER responses during the lifetime of a contact remain valid as long as (1) a contact with that instance ID remains registered, and (2) the UA doesn't change the Call-ID in its REGISTER request compared to previous ones for the same reg-id ----------------------------------------------------------------- By following this specification, if a phone is registered for one day by refreshing its registration hourly (same Call-ID), then the registrar would have to store 24 temp-gruu values for same registration. How could it make sense? So my question is: is it legal if the registrar mantains an *unique* temp-gruu per registration (according to AoR and sip.instance)? -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
