[SR-Users] Kamailio example configuration: auth section incomplete?

[Jurijs Ivolga]

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 at 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 at 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 at 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 at lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>> _______________________________________________
>> Kamailio (SER) - Users Mailing List
>> sr-users at lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170802/f75adc26/attachment.html>