[asterisk-dev] [Code Review] PineTree:: Matching SIP peers beyond SIP proxy

[Olle E Johansson]

> On 2009-09-01 12:48:44, David Vossel wrote:
> > Other than the comments below, I'd clean up some of the excess debug information as well.

Totally agree :-) But that's before commit.


> On 2009-09-01 12:48:44, David Vossel wrote:
> > /trunk/channels/chan_sip.c, line 8952
> > <https://reviewboard.asterisk.org/r/348/diff/1/?file=6317#file6317line8952>
> >
> >     This is really minor. It might be nice to have a comment with a VIA header example so it's easier to follow how its being parsed.

You have that if you scoll down a few lines.


> On 2009-09-01 12:48:44, David Vossel wrote:
> > /trunk/channels/chan_sip.c, line 8956
> > <https://reviewboard.asterisk.org/r/348/diff/1/?file=6317#file6317line8956>
> >
> >     This function looks pretty solid to me, as long as the ' ' is guaranteed to always be present between the transport and the beginning of the host.

I haven't seen otherwise, but we need to check the ABNF.


> On 2009-09-01 12:48:44, David Vossel wrote:
> > /trunk/channels/chan_sip.c, line 9001
> > <https://reviewboard.asterisk.org/r/348/diff/1/?file=6317#file6317line9001>
> >
> >     This is a very complicated for loop.  Here are a few ideas I have to make it at least appear safer and possibly avoid any weirdness that could occur.   Really, I'd just try and rethink this a little.
> >     
> >     1. The "if (ast_strlen_zero(viaheader))" block should explicitly return either TRUE or FALSE... I'd do this by making the internal if statments, (line <=) and (!findsecond), if, else if, and else statements, with the final else returning FALSE by default.
> >     
> >     2.  I'd make the "if (line == 2 && findsecond)" block an else if block right under the "if (ast_strlen_zero(viaheader))" block.  This keeps all the return statements together.

Added a few comments to explain my thinking, as I don't really agree with your thoughts here. I did however find a potential bug in this very complicated loop while doing that, so it was good reviewing it again. Please check now and see what you think.


> On 2009-09-01 12:48:44, David Vossel wrote:
> > /trunk/channels/chan_sip.c, line 9019
> > <https://reviewboard.asterisk.org/r/348/diff/1/?file=6317#file6317line9019>
> >
> >     Are we guaranteed previous is not NULL here?  What if the Via header is not present for some reason.

You mean if there's a comma and nothing there? Well, I guess there are a lot of broken SIP devices out there :-) Let's prevent that from happening.

The function get_address_from_via includes a lot of checks so I don't think soemthing bad will happen anyway.


- Olle E


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/348/#review1032
-----------------------------------------------------------


On 2009-09-01 09:08:00, Olle E Johansson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/348/
> -----------------------------------------------------------
> 
> (Updated 2009-09-01 09:08:00)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Many of us implement asterisk behind SIP proxys for load balancing or  
> failover or both. That means that all messages to Asterisk is sent by  
> the proxy and all peer matching on IP/port fails. Asterisk simply  
> doesn't know how to separate the devices behind the proxy.
> 
> With my new code, you can add a rule to the SIP proxy [peer] section,  
> saying "don't match me, match who sent to me". The way Asterisk does  
> that, is by reading the second VIA header. This is the device that  
> sent the message to Asterisk - another proxy or an endpoint. You can  
> also be very strict and say "match last via" - which always will be  
> the other endpoint.
> 
> The benefit of all this is that all Asterisk features now work -  
> accountcode, codec settings, authentication. You can provision  
> different SIP trunks with different features, even though Asterisk is  
> hidden by a proxy.
> 
> For outbound calls, you use the outbound proxy setting as before.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 215108 
>   /trunk/configs/sip.conf.sample 215108 
> 
> Diff: https://reviewboard.asterisk.org/r/348/diff
> 
> 
> Testing
> -------
> 
> Testing in private networks. Have had this code in production with customer for a couple of months, albeit on 1.4.
> 
> 
> Thanks,
> 
> Olle E
> 
>