[OpenSIPS-Users] Routing requests when using GRUU

[Saúl Ibarra Corretgé]

Hi,

Today I came across this problem again, and while I thought I could fix it by using match_dialog and fix_route_dialog that didn't work out, so I think we need to get something fixed so that GRUU routing works. Lets assume this scenario:

- Bob has bob at biloxi.com URI and is registered on P1
- Alice has alice at atlanta.com URI and is registered on P2
- They both call through their own domain's proxies
- They are both using GRUU
- Both proxies do record routing

When alice calls Bob, the following happens:

Alice ----> P2 ----> P1 ---> Bob

Both the INVITE an the 200 OK will contain GRUUs in the form of sip:alice at atlanta.com;gr=jhdjihiduh9 or sip:bob at biloxi.com;gr=jihfiuohoufh4f

The problem manifests when Alice tries to send the ACK. The RURI in the ACK will look like sip:bob at biloxi.com;gr=jihfiuohoufh4f and it will have 2 Route haders, pointing to P2 and P1.

When the ACK arrives at P2, the proxy will remove the Route header pointing to himself and send the request to the destination identified by the next Route header, that is, P1. Now, when the request arrives at P1, if will identify himself in the Route header and it will remove it, but because there are no more Route headers the request needs to be routed to the RURI, which is sip:bob at biloxi.com;gr=jihfiuohoufh4f.

If we just t_relay, the request will loop back to P1 forever.

So, I thought I could fix this by not doing loose_route for in-dialog requests when GRUU is in use:

---------
        $var(uri_is_gruu) = 0;
        if ($(ru{uri.params}) != "" && $(ru{uri.params}{param.exist,gr}) == 1) {
            $var(uri_is_gruu) = 1;
        }

        if (has_totag()) {
            if ($var(uri_is_gruu)) {
                 if (!match_dialog()) {
                      # Oh, it doesn't match, so lets drop it
                      ...
                 }
                 fix_route_dialog();
            } else {
                  # Do loose_route...
            }
        }
---------

In theory this should fix it, because force_route_dialog would set the destination URI pointing at Bob. In practice, this didn't seem to change anything, I added log lines to see if $du had changed after fix_route_dialog, but it was still NULL.

Is this a known limitation of fix_route_dialog? A bug? Am I using it wrong?

Thanks in advance for any pointers.


Kind regards,

PS: If you are thinking about doing a lookup() for the location, that won't work in case the user re-registers while in the middle of the dialog, if Path is used and a different path was chosen. I can elaborate on that but I didn't want to complicate the example even more :-)

--
Saúl Ibarra Corretgé
AG Projects