[OpenSIPS-Devel] [opensips] don't save ruri to Route in handle_sr if there is no next hop (#642)

Bogdan Andrei IANCU notifications at github.com
Thu Jan 21 13:53:35 CET 2016


Hi @doome , sorry for late handling on this patch.
I checked a bit the whole logic in handling the routing and IMHO, your change is not correct.

The handle_sr() function is called from after_loose() when the next hop (indicated by Route hdrs) is marked as strict router. Coming via the after_loose() route, it means in RURI we have something else than our own IP (most probably the IP of the end point).
Going back to handle_sr()....as next hop is strict , we need to place its IP in RURI; and not to loose what we have in RURI (the end point), this must be added as a last Route to the message.
You say this insertion (of current RURI as Route) should be do only if there is another Route to follow, but this has no impact actually.

Let's take this example:
>RURI: end_point
>Route: myself;lr
>Route: proxy_sr

after going through after_loose(), the local Route is dropped and the next route will point to "proxy_sr" which is strict route:
>RURI: end_point
>Route: proxy_sr

Now, the handle_sr() should re-arrange the message as the next hop is a strict router. If you do it as per your patch, the RURI will not be saved into Route any more, and only have the proxy_sr moved into RURI:
>RURI: proxy_sr

Which is wrong as you lost the last element in the routing set - the "end_point" ; the next proxy will have no idea where to send the message further.

Currently, without your patch, the result after handle_sr() is:
>RURI: proxy_sr
>Route: end_point

so proxy_sr will know that it has to fwd the request to end_point.

Am I missing anything on your patch ?

Regards,
Bogdan


---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/642#issuecomment-173560932
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20160121/ee3a0488/attachment.htm>


More information about the Devel mailing list