I didn't get the chance to look at it yet -- it is on my radar. Cheers, Daniel
On 11/12/14 11:24, Charles Chance wrote: > > Any further thoughts on this, please? > > Cheers, > > Charles > > Hi Daniel, > > Please see attached (I have tested already). > > Should it be added, or left up to the user to perform via config? > Either way, at least the patch is available here as an option, in case > the question is asked again. > > It would be good to hear others' opinions, too. > > Best regards, > > Charles > > > On 8 December 2014 at 20:10, Charles Chance > <[email protected] <mailto:[email protected]>> > 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" <[email protected] > <mailto:[email protected]>> wrote: > > > On 08/12/14 16:40, Charles Chance wrote: >> >> >> On 8 December 2014 at 15:09, Olle E. Johansson >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> On 08 Dec 2014, at 16:00, Charles Chance >> <[email protected] >> <mailto:[email protected]>> 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 Mierla > http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - > http://www.linkedin.com/in/miconda > > > _______________________________________________ > sr-dev mailing list > [email protected] <mailto:[email protected]> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > www.sipcentric.com <http://www.sipcentric.com/> > > Follow us on twitter @sipcentric <http://twitter.com/sipcentric> > > Sipcentric Ltd. Company registered in England & Wales no. > 7365592. Registered office: Faraday Wharf, Innovation Birmingham > Campus, Holt Street, Birmingham Science Park, Birmingham B7 4BB. > > > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
