Hi, I've been testing and analyzing the GRUU implementation and I think we need to fix the loose_route function to properly accommodate GRUU support. Lets take the following simple case (proxy does record routing):
- Alice calls Bob (both users of the same domain, same proxy) - Bob replies with 200 OK and his public GRUU in the Contact header: "sip:[email protected];gr=foobar" - Alice send a re-INVITE to put the call on hold At this point, Alice sent a SIP request with Bob's GRUU as the RURI and the Proxy IP in a Route header. Since it's a re-INVITE we'd call loose_route. However, loose_route will think that the previous hop was a strict router, because it will see it's own domain in the RURI and the route set is not preloaded because this is an in-dialog request. This can be fixed with the following configuration trick: - Check if the RURI of an in-dialog request contains the ;gr parameter. - If it does, lookup the location - Do loose_route Now lets take another case: Alice and Bob are still on the same domain different proxies (Alice is at P1 and Bob at P2), and both proxies do record routing. - Alice calls Bob - Bob replies with 200 OK and his public GRUU in the Contact header: "sip:[email protected];gr=foobar" - Alice send a re-INVITE to put the call on hold When alice sends the re-INVITE, it will contain Bob's GRUU as the RURI and 2 Route headers, one pointing to P1 and another one pointing to P2. If P1 calls loose_route it will act as the previous hop was a strict router, but it wasn't, what needs to happen is that the request arrives at P2 with the RURI untouched and then P2 can lookup the location and route the request to Bob. The simple case can be solved with configuration, but the advanced one can't, so I propose that the loose_route function adds an extra check: if is_myself return true, check if the URI has the gr parameter. In such case, don't assume the previous hop was a strict router, but a loose router. Thoughts? -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Devel mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
