Hi George,
Kamailio is very flexible application and don't be afraid to change default
config file. ;)
So if default config file do not fit you, just update accordingly.
With kind regards,
Jurijs
On Wed, Aug 2, 2017 at 10:17 PM, George Diamantopoulos <georgediam(a)gmail.com
wrote:
> Sorry, I replied before I could read your second post.
>
> Ah, I can see now where this is going, although it's completely unfit for
> the use of kamailio I'm investigating. Thanks!
>
> On 2 August 2017 at 22:11, Jurijs Ivolga <jurijs.ivolga(a)gmail.com
wrote:
>
>> Hi George,
>>
>> I misread your email, sorry.
>>
>> In your case scenario is when somebody from outside tries to call user
>> registered in kamailio, by default it is allowed. We do not need to
>> challenge such request, because it is user from outside, not our subscriber
>> and by default kamailio allows such calls and in this case such call will
>> finish in location route and eventually will reach user.
>>
>> I hope I understood you and I didn't messed anything again. :)
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Wed, Aug 2, 2017 at 4:01 PM, George Diamantopoulos <
>> georgediam(a)gmail.com
wrote:
>>
>>> Hello again,
>>>
>>> Still getting familiar with kamailio, and I'm wondering about the AUTH
>>> route in the example configuration file. Here's a reducted-simplified
>>> version of it for reference (from git master, without IP AUTH and comments):
>>>
>>> ______________________________________________
>>> route[AUTH] {
>>> if (is_method("REGISTER") || from_uri==myself) {
>>> if (!auth_check("$fd", "subscriber",
"1")) {
>>> auth_challenge("$fd", "0");
>>> exit;
>>> }
>>> if(!is_method("REGISTER|PUBLISH"))
>>> consume_credentials();
>>> }
>>> if (from_uri!=myself && uri!=myself) {
>>> sl_send_reply("403","Not relaying");
>>> exit;
>>> }
>>> return;
>>> }
>>> ______________________________________________
>>>
>>> So the way I see it, what happens is the following:
>>>
>>> * All REGISTERs will be challenged
>>> * All SIP messages with kamailio's aliases in the "From" header
URI will
>>> be challenged
>>> * All SIP messages with no reference to kamailio's aliases in both R-URI
>>> and "From" header URI will be dropped
>>>
>>> The question is, what about messages that do not enter either of the two
>>> conditionals? For example, I expect the following to be very common:
>>>
>>> * Method: INVITE
>>> * R-URI: myself
>>> * From: username@"UAC's local IP address" (not myself)
>>> * To: myself
>>>
>>> So in the example above, the auth route will return without either
>>> having challenged or dropped the request, am I correct? This is because:
>>>
>>> * For the challenge: Method is not REGISTER and "From URI" is not
one of
>>> kamailio host's aliases (cumulatively)
>>> * For dropping after sending 403: "From URI" is not one of
kamailio's
>>> host's aliases (which calculates to true) but R-URI is
"myself"
>>>
>>> So I'm guessing we're expecting the challenge to come from elsewhere
in
>>> cases like the example above? Or is there something else I'm missing
here?
>>> Thanks!
>>>
>>> BR,
>>> George
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users(a)lists.kamailio.org
>>>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users(a)lists.kamailio.org
>>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>