Re: [sr-dev] Registrar - check for local path

wrote:

Hi Daniel, You are right, it is not trivial to perform via config. The patch was made quickly to illustrate a point, but I have reworked it now to include a parameter for enabling the check, as well as accounting for more than one Path header. If you think it is worthwhile, I will post the full patch for review tomorrow. Best regards, Charles On 8 Dec 2014 16:28, "Daniel-Constantin Mierla" &lt;miconda(a)gmail.com&gt; wrote: > > On 08/12/14 16:40, Charles Chance wrote: > > > > On 8 December 2014 at 15:09, Olle E. Johansson &lt;oej(a)edvina.net&gt; wrote: > >> >> On 08 Dec 2014, at 16:00, Charles Chance < >> charles.chance(a)sipcentric.com&gt; wrote: >> >> Hi Olle, >> >> msg_apply_changes() is for getting the Path saved the first place if >> adding/saving on the same instance. >> >> My patch is for later on, to avoid looping if lookup is performed on >> the same instance that received the register. >> >> Scenario is 2 x registrar/location servers, both sharing common DB - >> no separate edge proxies, but each adds itself as Path before saving (which >> is where msg_apply_changes() comes in). >> >> Can't you sort that out in the routing script? I don't see why we need >> to add this in the code... >> >> If the topmost, leftmost routing header in the outbound INVITE points >> to me, remove it and move on. >> You have the branch route for that kind of manipulation. >> >> What am I missing? >> > > If I got it right upon quick read, this case is not trivial to handle > via config file -- i.e., it is about saving registration with local address > as a Path, the registration can be read by same proxy or another one (the > other will have to send the register to this instance, this one will need > to ignore the path). > > After lookup("location"), the first Path appears as outbound proxy > address ($du / dst_uri), but it is also added in the lumps to be a Route > header for outgoing INVITE. If there are more than on Path header, things > can get quite complex to handle from config and might be easier to simplify > by adding a module parameter to enable/disable the proposed patch. > > Cheers, > Daniel > > -- > Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda > > > _______________________________________________ > sr-dev mailing list > sr-dev(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >