[asterisk-dev] [Code Review] 2554: Pimp my SIP: alwaysauthreject

Olle E. Johansson oej at edvina.net
Fri Jun 7 08:28:34 CDT 2013


7 jun 2013 kl. 15:03 skrev Joshua Colp <jcolp at digium.com>:

> Olle E. Johansson wrote:
>> 
>> 401/403 ==>  401/407 - right? Asterisk is an end point and should
>> never send a proxy authenticate, so please don't copy that part of
>> the code.
> 
> 407 is Proxy Authentication Required, it never sends that.
Great - one step forward.

> 
>> I asked if there are any use cases for getting a 404 above.  I don't
>> think so.
>> 
>> The new channel driver should not have an option to turn it on in my
>> opinion - which is why I think the code in the code review should not
>> be committed.
> 
> The code within the normal tree right now does *NOT* do 401/403. Kevin's code changes it so it does, but per the discussion he has made it so the functionality can not be disabled. The behavior (SIP flow) of failed authentication and not found are exactly the same in it.

> 
>> Now, I would like to see a document that is readable that describes
>> the object matching in chan_pjsip. Start with a request coming in and
>> how that is matched with the object model and configuration file.
> 
> How the matching is done is pluggable and extensible, right down to the order itself. What we've written so far are two modules: one that uses the From header to match and one that can do source IP address (or even ranges). If someone was doing authentication at the edge using a proxy but wanted to pass the authenticated user along in a custom header in a trusted environment, they could do that.
Ok, but then we need to start shaping the default set, not just all the time say "our users can do anything" because that will just confuse everyone.

> 
>> Let's make a solid foundation this time and not the mish-mash we've
>> built during more than 10 years of chan_sip hacking ;-)
> 
> I think by making it pluggable, extensible, and configurable this is possible. If we need to change the behavior of the existing stuff we easily can, and it can be tested alongside the old.

That sounds to be just like another type of mish-mash. We need to have a clear path forward to make people understand what you're coding.
Asterisk is a pbx and not an object-oriented-framework. That project was closed down.

/O


More information about the asterisk-dev mailing list