[sr-dev] Registrar - check for local path

[Charles Chance]

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" <miconda at gmail.com> wrote:

>
> On 08/12/14 16:40, Charles Chance wrote:
>
>
>
> On 8 December 2014 at 15:09, Olle E. Johansson <oej at edvina.net> wrote:
>
>>
>>  On 08 Dec 2014, at 16:00, Charles Chance <charles.chance at sipcentric.com>
>> 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20141208/e133009c/attachment.html>