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 b...@biloxi.com URI and is registered on P1
- Alice has al...@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:al...@atlanta.com;gr=jhdjihiduh9 or sip:b...@biloxi.com;gr=jihfiuohoufh4f

The problem manifests when Alice tries to send the ACK. The RURI in the ACK 
will look like sip:b...@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:b...@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




_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Reply via email to