Where could we get the patch?<div><br clear="all">--<br>Nick<br>
<br><br><div class="gmail_quote">2012/3/22 SourceForge.net <span dir="ltr"><<a href="mailto:noreply@sourceforge.net">noreply@sourceforge.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Patches item #3510049, was opened at 2012-03-22 04:46<br>
Message generated for change (Tracker Item Submitted) made by saghul<br>
You can respond by visiting:<br>
<a href="https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3510049&group_id=232389" target="_blank">https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3510049&group_id=232389</a><br>
<br>
Please note that this message will contain a full copy of the comment thread,<br>
including the initial issue submission, for this request,<br>
not just the latest update.<br>
Category: core<br>
Group: trunk<br>
Status: Open<br>
Resolution: None<br>
Priority: 5<br>
Private: No<br>
Submitted By: saghul (saghul)<br>
Assigned to: Nobody/Anonymous (nobody)<br>
Summary: Allow $ru and $du to be changed in local_route<br>
<br>
Initial Comment:<br>
Hi,<br>
<br>
Currently local_route doesn't allow the Request-URI not the destination URI to be changed, which is probably OK for many cases but I came across a case in which I can't solve a routing problem without setting the $du in the local_route.<br>
<br>
Scenario is as follows:<br>
<br>
Alice <--> P1 <--> P2 <--> Bob<br>
<br>
Alice and Bob belong to the same domain and are both registered on P2. P2 alo has dialog ping feature enabled.<br>
<br>
Alice happens to use GRUU, so her Contact header's URI looks like this: <a href="mailto:sip%3Aalice@atlanta.com">sip:alice@atlanta.com</a>;gr=1234567890<br>
<br>
When P2 generates the in-dialog OPTIONS request for Alice, it will contain Alice's GRUU as the RURI and P1 in a Route header. Because P2 is Alice's registrar, P1 will not know how to route that request.<br>
<br>
A workaround for this situation which doesn't require (presumably) complex changes is to self-forward the OPTIONS request in P2, then in the main routing block to a lookup() to get the real location of Alice, and loose_route(). This way, P1 will get the packet with Alice's received contact in the RURI and will know how to route it.<br>
<br>
Self forwarding could be avoided if lookup() was allowed in the local_route, but I didn't want to go that far.<br>
<br>
The attached patch allows $ru and $du to be changed in the local_route to be able to deal with the scenario described above.<br>
<br>
<br>
Regards,<br>
<br>
--<br>
Saúl Ibarra Corretgé<br>
AG Projects<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
You can respond by visiting:<br>
<a href="https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3510049&group_id=232389" target="_blank">https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3510049&group_id=232389</a><br>
<br>
_______________________________________________<br>
Devel mailing list<br>
<a href="mailto:Devel@lists.opensips.org">Devel@lists.opensips.org</a><br>
<a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/devel" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/devel</a><br>
</blockquote></div><br></div>