> -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > [JRE] I am trying to figure out how things will work if a middlebox > rewrites a GRUU. Consider this scenario. A sends GRUU1 to B in a > dialog-forming request. Middlebox M rewrites the GRUU1 to GRUU2, so B > receives GRUU2. B sends GRUU2 to C. B closes the dialog with A. C sends > a new request to GRUU2, which I presume would be constructed so that the > request reaches M. Is it certain that M will have retained the necessary > state to map GRUU2 to GRUU1? In other words, how does M ensure that the > lifetime of GRUU2 matches the lifetime of GRUU1?
That is a hard question to answer, because I think it depends on where the middle-box is and what its purpose is for rewriting the contact. In other words, its "role". For example, for an SBC-type middle-box on the access side (as an outbound proxy between UA's and the core registrar/app-server), I think it should leave the gruu alone. The gruu should already be hiding device-specific IP addressing info, and thus hiding topology. We tested that at sipit and it seemed to work fine, but we haven't encountered gruu use in the wild much yet. If it isn't hiding such, the contact has to be changed unfortunately. For an SBC-type box on the peering side (between providers or enterprises), there are definitely cases where even a gruu will have to be changed based on policy. Some SBC's already have a proprietary way to provide a "global contact", which encrypts the original - they had to do this because the need for a contact to be reusable in the style of gruu has already happened, long before anyone was doing gruu. The lifetime is left up to operator policy. -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
