date:20200925

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread Daniel Zanutti

Don't forget to deal with CSEQ increment on the authenticated INVITE.

Also we had problems when any in-dialog message is received, we have to
deal with CSEQ on all of them. =(

On Fri, Sep 25, 2020 at 12:30 PM johan  wrote:

> Jeff, be warned that the datafill for registrar is not obvious.
> On 25/09/2020 16:40, Jeff Pyle wrote:
>
> I am not route-advancing in a typical way, so my application of
> credentials is a bit different perhaps.
>
> The environment I'm in has a variety of customer-facing platforms, over a
> dozen at last count.  Some are for trunking, some hosted, some hybrid.  The
> platform I'm writing on OpenSIPS is a testing one that will allow us to
> send and receive test calls to and from all of them.  So, rather than
> having a bunch of registrations on every test phone for every person who
> might want to test, this allows each person to have one appearance to this
> platform and select which upstream platform they want to send a call to via
> dialed prefixes.
>
> I use the uac_registrant module, and its registrant table, to handle the
> platforms that require registrations and it works excellently.  At call
> time, I'm working on the scripting right now that will query the registrant
> table for the appropriate credentials based on where we've sent the call
> and apply them in the failure_route upon receiving a 401 or 407.
>
> Think of it this way:  when you configure a gateway in FreeSWITCH or a SIP
> peer in Asterisk's chan_sip, do you need to define the realm ahead of
> time?  No, you don't care; it's just a mechanism under the hood that's
> necessary to complete the transaction.  That's where I'm at in OpenSIPS.
> With Johan's parsing it looks like I'm about there, too.  Friggin' regex
> gets me every time.
>
>
> - Jeff
>
> On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin 
> wrote:
>
>> I think you do need to have credentials associated with the different
>> routes you have and load those properly. From your description, however, I
>> don’t understand why it is dependent on identifying the realm in the
>> response. If multiple downstream servers are all using the same realm (but
>> have different credentials?) then how are you differentiating based on the
>> realm value?
>>
>>
>>
>> The idea with uac_auth is that when you send, for example, to server
>> broadworks1 you would load all the possible valid credentials for
>> broadworks1, including the realm it will challenge with. When you then call
>> uac_auth() from failure route, it will look through all the loaded
>> credentials for one with a matching realm to the broadworks1 challenge and
>> use that. If the call fails for any reason to broadworks1 and then you
>> decide to route to server asterisk1, you would load all the possible
>> credentials for that server into the auth AVPs the same way and failure
>> route handling is the same.
>>
>>
>>
>> You could very well have a use case for verifying the realm in
>> failure_route; I’m not saying you don’t. I don’t see it from what you’ve
>> described, but I may be missing something. I think the reason there is no
>> variable for pulling the challenge realm value directly is because normally
>> with this mechanism it shouldn’t be needed.
>>
>>
>>
>> I would appreciate if someone could confirm that uac_auth() will match
>> the realm as I’m asserting. I’m 95% sure this is how it worked in my
>> testing, but that was a while ago and as I said the realm matching doesn’t
>> appear to be documented. I’d hate to be steering you down a wrong path.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users 
>> *Date: *Friday, September 25, 2020 at 10:15 AM
>> *To: *OpenSIPS users mailling list 
>> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
>> challenges
>>
>> Johan,
>>
>>   I will definitely try that.  Thank you!
>>
>>
>>
>> Ben,
>>
>>   The problem is I have multiple destinations with the same realm.  In my
>> case, several different Broadworks app servers.  I haven't checked them
>> exhaustively but I think they all reply with realm="BroadWorks" in their
>> authentication headers.  I've got some Asterisk boxes in here, and I think
>> they're all the domain of the SIP request URI in the case of an INVITE.  I
>> think I'll have to choose ahead of time which credentials go with which
>> route, no?  Unless I'm still not wrapping my head around how this is
>> supposed to work.
>>
>>
>>
>>
>>
>> - Jeff
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin 
>> wrote:
>>
>> Jeff,
>>
>>
>>
>> My point was that the uac_auth() is supposed to handle the realm matching
>> for you. If you simply load all of the auth data based on the call target
>> as you already plan to do, uac_auth() should look through that data for you
>> to find credentials with a matching realm. You don’t need to do that part
>> yourself in the script.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users 
>> *Date: *Thursday, September 24, 2020 at 11:14 PM
>> *To: *OpenSIPS users mailling list 
>>

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread johan


Jeff, be warned that the datafill for registrar is not obvious.

On 25/09/2020 16:40, Jeff Pyle wrote:
I am not route-advancing in a typical way, so my application of 
credentials is a bit different perhaps.


The environment I'm in has a variety of customer-facing platforms, 
over a dozen at last count.  Some are for trunking, some hosted, some 
hybrid.  The platform I'm writing on OpenSIPS is a testing one that 
will allow us to send and receive test calls to and from all of them.  
So, rather than having a bunch of registrations on every test phone 
for every person who might want to test, this allows each person to 
have one appearance to this platform and select which upstream 
platform they want to send a call to via dialed prefixes.


I use the uac_registrant module, and its registrant table, to handle 
the platforms that require registrations and it works excellently.  At 
call time, I'm working on the scripting right now that will query the 
registrant table for the appropriate credentials based on where we've 
sent the call and apply them in the failure_route upon receiving a 401 
or 407.


Think of it this way:  when you configure a gateway in FreeSWITCH or a 
SIP peer in Asterisk's chan_sip, do you need to define the realm ahead 
of time?  No, you don't care; it's just a mechanism under the hood 
that's necessary to complete the transaction.  That's where I'm at in 
OpenSIPS.  With Johan's parsing it looks like I'm about there, too.  
Friggin' regex gets me every time.



- Jeff

On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin > wrote:


I think you do need to have credentials associated with the
different routes you have and load those properly. From your
description, however, I don’t understand why it is dependent on
identifying the realm in the response. If multiple downstream
servers are all using the same realm (but have different
credentials?) then how are you differentiating based on the realm
value?

The idea with uac_auth is that when you send, for example, to
server broadworks1 you would load all the possible valid
credentials for broadworks1, including the realm it will challenge
with. When you then call uac_auth() from failure route, it will
look through all the loaded credentials for one with a matching
realm to the broadworks1 challenge and use that. If the call fails
for any reason to broadworks1 and then you decide to route to
server asterisk1, you would load all the possible credentials for
that server into the auth AVPs the same way and failure route
handling is the same.

You could very well have a use case for verifying the realm in
failure_route; I’m not saying you don’t. I don’t see it from what
you’ve described, but I may be missing something. I think the
reason there is no variable for pulling the challenge realm value
directly is because normally with this mechanism it shouldn’t be
needed.

I would appreciate if someone could confirm that uac_auth() will
match the realm as I’m asserting. I’m 95% sure this is how it
worked in my testing, but that was a while ago and as I said the
realm matching doesn’t appear to be documented. I’d hate to be
steering you down a wrong path.

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Friday, September 25, 2020 at 10:15 AM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges

Johan,

  I will definitely try that. Thank you!

Ben,

  The problem is I have multiple destinations with the same
realm.  In my case, several different Broadworks app servers.  I
haven't checked them exhaustively but I think they all reply with
realm="BroadWorks" in their authentication headers.  I've got some
Asterisk boxes in here, and I think they're all the domain of the
SIP request URI in the case of an INVITE.  I think I'll have to
choose ahead of time which credentials go with which route, no? 
Unless I'm still not wrapping my head around how this is supposed
to work.

- Jeff

On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin mailto:ben.new...@genesys.com>> wrote:

Jeff,

My point was that the uac_auth() is supposed to handle the
realm matching for you. If you simply load all of the auth
data based on the call target as you already plan to do,
uac_auth() should look through that data for you to find
credentials with a matching realm. You don’t need to do that
part yourself in the script.

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Thursday, September 24, 2020 at 11:14 PM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread Ben Newlin

Gotcha. I was missing the part where you want to accept any realm and don’t 
want to know the realm ahead of time. Interesting case. Thanks for explaining.

Ben Newlin

From: Users 
Date: Friday, September 25, 2020 at 10:41 AM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
I am not route-advancing in a typical way, so my application of credentials is 
a bit different perhaps.

The environment I'm in has a variety of customer-facing platforms, over a dozen 
at last count.  Some are for trunking, some hosted, some hybrid.  The platform 
I'm writing on OpenSIPS is a testing one that will allow us to send and receive 
test calls to and from all of them.  So, rather than having a bunch of 
registrations on every test phone for every person who might want to test, this 
allows each person to have one appearance to this platform and select which 
upstream platform they want to send a call to via dialed prefixes.

I use the uac_registrant module, and its registrant table, to handle the 
platforms that require registrations and it works excellently.  At call time, 
I'm working on the scripting right now that will query the registrant table for 
the appropriate credentials based on where we've sent the call and apply them 
in the failure_route upon receiving a 401 or 407.

Think of it this way:  when you configure a gateway in FreeSWITCH or a SIP peer 
in Asterisk's chan_sip, do you need to define the realm ahead of time?  No, you 
don't care; it's just a mechanism under the hood that's necessary to complete 
the transaction.  That's where I'm at in OpenSIPS.  With Johan's parsing it 
looks like I'm about there, too.  Friggin' regex gets me every time.

- Jeff

On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
I think you do need to have credentials associated with the different routes 
you have and load those properly. From your description, however, I don’t 
understand why it is dependent on identifying the realm in the response. If 
multiple downstream servers are all using the same realm (but have different 
credentials?) then how are you differentiating based on the realm value?

The idea with uac_auth is that when you send, for example, to server 
broadworks1 you would load all the possible valid credentials for broadworks1, 
including the realm it will challenge with. When you then call uac_auth() from 
failure route, it will look through all the loaded credentials for one with a 
matching realm to the broadworks1 challenge and use that. If the call fails for 
any reason to broadworks1 and then you decide to route to server asterisk1, you 
would load all the possible credentials for that server into the auth AVPs the 
same way and failure route handling is the same.

You could very well have a use case for verifying the realm in failure_route; 
I’m not saying you don’t. I don’t see it from what you’ve described, but I may 
be missing something. I think the reason there is no variable for pulling the 
challenge realm value directly is because normally with this mechanism it 
shouldn’t be needed.

I would appreciate if someone could confirm that uac_auth() will match the 
realm as I’m asserting. I’m 95% sure this is how it worked in my testing, but 
that was a while ago and as I said the realm matching doesn’t appear to be 
documented. I’d hate to be steering you down a wrong path.

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Friday, September 25, 2020 at 10:15 AM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
Johan,
  I will definitely try that.  Thank you!

Ben,
  The problem is I have multiple destinations with the same realm.  In my case, 
several different Broadworks app servers.  I haven't checked them exhaustively 
but I think they all reply with realm="BroadWorks" in their authentication 
headers.  I've got some Asterisk boxes in here, and I think they're all the 
domain of the SIP request URI in the case of an INVITE.  I think I'll have to 
choose ahead of time which credentials go with which route, no?  Unless I'm 
still not wrapping my head around how this is supposed to work.

- Jeff

On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
Jeff,

My point was that the uac_auth() is supposed to handle the realm matching for 
you. If you simply load all of the auth data based on the call target as you 
already plan to do, uac_auth() should look through that data for you to find 
credentials with a matching realm. You don’t need to do that part yourself in 
the script.

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Thursday, September 24, 2020 at 11:14 PM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
Good catch on

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread Jeff Pyle

I am not route-advancing in a typical way, so my application of credentials
is a bit different perhaps.

The environment I'm in has a variety of customer-facing platforms, over a
dozen at last count.  Some are for trunking, some hosted, some hybrid.  The
platform I'm writing on OpenSIPS is a testing one that will allow us to
send and receive test calls to and from all of them.  So, rather than
having a bunch of registrations on every test phone for every person who
might want to test, this allows each person to have one appearance to this
platform and select which upstream platform they want to send a call to via
dialed prefixes.

I use the uac_registrant module, and its registrant table, to handle the
platforms that require registrations and it works excellently.  At call
time, I'm working on the scripting right now that will query the registrant
table for the appropriate credentials based on where we've sent the call
and apply them in the failure_route upon receiving a 401 or 407.

Think of it this way:  when you configure a gateway in FreeSWITCH or a SIP
peer in Asterisk's chan_sip, do you need to define the realm ahead of
time?  No, you don't care; it's just a mechanism under the hood that's
necessary to complete the transaction.  That's where I'm at in OpenSIPS.
With Johan's parsing it looks like I'm about there, too.  Friggin' regex
gets me every time.


- Jeff

On Fri, Sep 25, 2020 at 10:25 AM Ben Newlin  wrote:

> I think you do need to have credentials associated with the different
> routes you have and load those properly. From your description, however, I
> don’t understand why it is dependent on identifying the realm in the
> response. If multiple downstream servers are all using the same realm (but
> have different credentials?) then how are you differentiating based on the
> realm value?
>
>
>
> The idea with uac_auth is that when you send, for example, to server
> broadworks1 you would load all the possible valid credentials for
> broadworks1, including the realm it will challenge with. When you then call
> uac_auth() from failure route, it will look through all the loaded
> credentials for one with a matching realm to the broadworks1 challenge and
> use that. If the call fails for any reason to broadworks1 and then you
> decide to route to server asterisk1, you would load all the possible
> credentials for that server into the auth AVPs the same way and failure
> route handling is the same.
>
>
>
> You could very well have a use case for verifying the realm in
> failure_route; I’m not saying you don’t. I don’t see it from what you’ve
> described, but I may be missing something. I think the reason there is no
> variable for pulling the challenge realm value directly is because normally
> with this mechanism it shouldn’t be needed.
>
>
>
> I would appreciate if someone could confirm that uac_auth() will match the
> realm as I’m asserting. I’m 95% sure this is how it worked in my testing,
> but that was a while ago and as I said the realm matching doesn’t appear to
> be documented. I’d hate to be steering you down a wrong path.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Friday, September 25, 2020 at 10:15 AM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> Johan,
>
>   I will definitely try that.  Thank you!
>
>
>
> Ben,
>
>   The problem is I have multiple destinations with the same realm.  In my
> case, several different Broadworks app servers.  I haven't checked them
> exhaustively but I think they all reply with realm="BroadWorks" in their
> authentication headers.  I've got some Asterisk boxes in here, and I think
> they're all the domain of the SIP request URI in the case of an INVITE.  I
> think I'll have to choose ahead of time which credentials go with which
> route, no?  Unless I'm still not wrapping my head around how this is
> supposed to work.
>
>
>
>
>
> - Jeff
>
>
>
>
>
>
>
>
>
> On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin  wrote:
>
> Jeff,
>
>
>
> My point was that the uac_auth() is supposed to handle the realm matching
> for you. If you simply load all of the auth data based on the call target
> as you already plan to do, uac_auth() should look through that data for you
> to find credentials with a matching realm. You don’t need to do that part
> yourself in the script.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 11:14 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've
> been looking at this too long.  I checked the module and that's exactly
> what it is.
>
>
>
> My hope was to load the uac_auth user/pass AVPs ahead of time from a DB
> based on where I knew I was sending the call, load the realm one in the
> failure route based on what comes back in the header, and then fire the
> uac_auth() function.

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread johan


how funny.  I think that BW runs internally opensips :-)

Bogdan surely knows.

On 25/09/2020 16:13, Jeff Pyle wrote:

Johan,
  I will definitely try that.  Thank you!

Ben,
  The problem is I have multiple destinations with the same realm.  In 
my case, several different Broadworks app servers.  I haven't checked 
them exhaustively but I think they all reply with realm="BroadWorks" 
in their authentication headers.  I've got some Asterisk boxes in 
here, and I think they're all the domain of the SIP request URI in the 
case of an INVITE.  I think I'll have to choose ahead of time which 
credentials go with which route, no?  Unless I'm still not wrapping my 
head around how this is supposed to work.



- Jeff




On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin > wrote:


Jeff,

My point was that the uac_auth() is supposed to handle the realm
matching for you. If you simply load all of the auth data based on
the call target as you already plan to do, uac_auth() should look
through that data for you to find credentials with a matching
realm. You don’t need to do that part yourself in the script.

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Thursday, September 24, 2020 at 11:14 PM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges

Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think
I've been looking at this too long.  I checked the module and
that's exactly what it is.

My hope was to load the uac_auth user/pass AVPs ahead of time from
a DB based on where I knew I was sending the call, load the realm
one in the failure route based on what comes back in the header,
and then fire the uac_auth() function. It looks like I may have to
manually extract the realm from whichever header comes in.  Not
ideal, but probably workable.

- Jeff

On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin mailto:ben.new...@genesys.com>> wrote:

This does not appear to be documented, but I believe
uac_auth() looks through the AVPs configured in the UAC_AUTH
module and uses the first one whose realm matches the
challenge realm. So in order to authenticate any challenge,
you must load all of the possible credentials into those AVPs.

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Thursday, September 24, 2020 at 9:53 PM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges

According to the docs, $ar provides the realm from the
“Authorization” or “Proxy-Authorization” headers. Not from the
”Proxy-Authenticate” header, which is what you have.

https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Thursday, September 24, 2020 at 9:31 PM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *[OpenSIPS-Users] learning the realm from
authentication challenges

I'm trying to recover the realm of an auth challenge to
OpenSIPS so I can respond to it with the uac_auth() function,
and that requires knowing the realm.  The docs say that $ar

should provide that, perhaps written like $(ar) to get
it in the right context.  I'm having some trouble getting the
data.

failure_route[relay_failure] {
...

        if (t_check_status("407")) {
                xlog("L_NOTICE", "[1] Proxy-Authenticate:
$(hdr(Proxy-Authenticate))\n");
                xlog("L_NOTICE", "[2] Auth Realm:
$(ar)\n");

xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
        }

...

}

The logs show:

/usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
realm="asterisk",
nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd",
qop="auth"
/usr/sbin/opensips[33044]: [2] Auth Realm reply: 
/usr/sbin/opensips[33044]: [3] Auth Realm: 

Is it possible to get the realm?  Is it possible to build a
response with uac_auth() for an arbitrary authentication
challenge?

This is on 3.1.0~20200923~88f89e941.

- Jeff

___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

___
Users mailing list
Users@lists.opensips.org

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread Ben Newlin

I think you do need to have credentials associated with the different routes 
you have and load those properly. From your description, however, I don’t 
understand why it is dependent on identifying the realm in the response. If 
multiple downstream servers are all using the same realm (but have different 
credentials?) then how are you differentiating based on the realm value?

The idea with uac_auth is that when you send, for example, to server 
broadworks1 you would load all the possible valid credentials for broadworks1, 
including the realm it will challenge with. When you then call uac_auth() from 
failure route, it will look through all the loaded credentials for one with a 
matching realm to the broadworks1 challenge and use that. If the call fails for 
any reason to broadworks1 and then you decide to route to server asterisk1, you 
would load all the possible credentials for that server into the auth AVPs the 
same way and failure route handling is the same.

You could very well have a use case for verifying the realm in failure_route; 
I’m not saying you don’t. I don’t see it from what you’ve described, but I may 
be missing something. I think the reason there is no variable for pulling the 
challenge realm value directly is because normally with this mechanism it 
shouldn’t be needed.

I would appreciate if someone could confirm that uac_auth() will match the 
realm as I’m asserting. I’m 95% sure this is how it worked in my testing, but 
that was a while ago and as I said the realm matching doesn’t appear to be 
documented. I’d hate to be steering you down a wrong path.

Ben Newlin

From: Users 
Date: Friday, September 25, 2020 at 10:15 AM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
Johan,
  I will definitely try that.  Thank you!

Ben,
  The problem is I have multiple destinations with the same realm.  In my case, 
several different Broadworks app servers.  I haven't checked them exhaustively 
but I think they all reply with realm="BroadWorks" in their authentication 
headers.  I've got some Asterisk boxes in here, and I think they're all the 
domain of the SIP request URI in the case of an INVITE.  I think I'll have to 
choose ahead of time which credentials go with which route, no?  Unless I'm 
still not wrapping my head around how this is supposed to work.


- Jeff




On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
Jeff,

My point was that the uac_auth() is supposed to handle the realm matching for 
you. If you simply load all of the auth data based on the call target as you 
already plan to do, uac_auth() should look through that data for you to find 
credentials with a matching realm. You don’t need to do that part yourself in 
the script.

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Thursday, September 24, 2020 at 11:14 PM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've been 
looking at this too long.  I checked the module and that's exactly what it is.

My hope was to load the uac_auth user/pass AVPs ahead of time from a DB based 
on where I knew I was sending the call, load the realm one in the failure route 
based on what comes back in the header, and then fire the uac_auth() function.  
It looks like I may have to manually extract the realm from whichever header 
comes in.  Not ideal, but probably workable.


- Jeff


On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
This does not appear to be documented, but I believe uac_auth() looks through 
the AVPs configured in the UAC_AUTH module and uses the first one whose realm 
matches the challenge realm. So in order to authenticate any challenge, you 
must load all of the possible credentials into those AVPs.

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Thursday, September 24, 2020 at 9:53 PM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
According to the docs, $ar provides the realm from the “Authorization” or 
“Proxy-Authorization” headers. Not from the ”Proxy-Authenticate” header, which 
is what you have.

https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Thursday, September 24, 2020 at 9:31 PM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: [OpenSIPS-Users] learning the realm from authentication challenges
I'm trying to recover the realm of an auth challenge to OpenSIPS so I can 
respond to it with the uac_auth() function, and that requires knowing the 
realm.  The docs say that

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread Jeff Pyle

Johan,
  I will definitely try that.  Thank you!

Ben,
  The problem is I have multiple destinations with the same realm.  In my
case, several different Broadworks app servers.  I haven't checked them
exhaustively but I think they all reply with realm="BroadWorks" in their
authentication headers.  I've got some Asterisk boxes in here, and I think
they're all the domain of the SIP request URI in the case of an INVITE.  I
think I'll have to choose ahead of time which credentials go with which
route, no?  Unless I'm still not wrapping my head around how this is
supposed to work.


- Jeff




On Fri, Sep 25, 2020 at 9:22 AM Ben Newlin  wrote:

> Jeff,
>
>
>
> My point was that the uac_auth() is supposed to handle the realm matching
> for you. If you simply load all of the auth data based on the call target
> as you already plan to do, uac_auth() should look through that data for you
> to find credentials with a matching realm. You don’t need to do that part
> yourself in the script.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 11:14 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've
> been looking at this too long.  I checked the module and that's exactly
> what it is.
>
>
>
> My hope was to load the uac_auth user/pass AVPs ahead of time from a DB
> based on where I knew I was sending the call, load the realm one in the
> failure route based on what comes back in the header, and then fire the
> uac_auth() function.  It looks like I may have to manually extract the
> realm from whichever header comes in.  Not ideal, but probably workable.
>
>
>
>
>
> - Jeff
>
>
>
>
>
> On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin  wrote:
>
> This does not appear to be documented, but I believe uac_auth() looks
> through the AVPs configured in the UAC_AUTH module and uses the first one
> whose realm matches the challenge realm. So in order to authenticate any
> challenge, you must load all of the possible credentials into those AVPs.
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 9:53 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *Re: [OpenSIPS-Users] learning the realm from authentication
> challenges
>
> According to the docs, $ar provides the realm from the “Authorization” or
> “Proxy-Authorization” headers. Not from the ”Proxy-Authenticate” header,
> which is what you have.
>
>
>
> https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6
>
>
>
> Ben Newlin
>
>
>
> *From: *Users 
> *Date: *Thursday, September 24, 2020 at 9:31 PM
> *To: *OpenSIPS users mailling list 
> *Subject: *[OpenSIPS-Users] learning the realm from authentication
> challenges
>
> I'm trying to recover the realm of an auth challenge to OpenSIPS so I can
> respond to it with the uac_auth() function, and that requires knowing the
> realm.  The docs say that $ar
>  should
> provide that, perhaps written like $(ar) to get it in the right
> context.  I'm having some trouble getting the data.
>
> failure_route[relay_failure] {
> ...
>
> if (t_check_status("407")) {
> xlog("L_NOTICE", "[1] Proxy-Authenticate:
> $(hdr(Proxy-Authenticate))\n");
> xlog("L_NOTICE", "[2] Auth Realm: $(ar)\n");
>
> xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
> }
>
> ...
>
> }
>
>
>
> The logs show:
>
> /usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
> realm="asterisk", nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd",
> qop="auth"
> /usr/sbin/opensips[33044]: [2] Auth Realm reply: 
> /usr/sbin/opensips[33044]: [3] Auth Realm: 
>
>
>
> Is it possible to get the realm?  Is it possible to build a response with
> uac_auth() for an arbitrary authentication challenge?
>
>
>
> This is on 3.1.0~20200923~88f89e941.
>
>
>
>
>
>
>
> - Jeff
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?

2020-09-25 Thread Ben Newlin

https://opensips.org/docs/modules/3.1.x/tm.html#param_disable_6xx_block

Ben Newlin

From: Users 
Date: Friday, September 25, 2020 at 5:58 AM
To: OpenSIPS users mailling list 
Subject: [OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?
Hello,

I want to fail-over my call on 6xx response and I use failure route for that 
but t_relay() gives below errors and reply with '500 No destination available 
(18/SL)'.

Sep 25 05:47:10 OLD-OVW-SBCA01 /usr/local/sbin/opensips[28174]: 
INFO:tm:t_forward_nonack: discarding fwd for a 6xx transaction
Sep 25 05:47:10 OLD-OVW-SBCA01 /usr/local/sbin/opensips[28174]: 
ERROR:tm:w_t_relay: t_forward_nonack failed

Anyone have an idea how I can resolve this?

Thanks & Regards
Diptesh Patel
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:+919898962659

Disclaimer
In addition to generic Disclaimer which you have agreed on our website, any 
views or opinions presented in this email are solely those of the originator 
and do not necessarily represent those of the Company or its sister concerns. 
Any liability (in negligence, contract or otherwise) arising from any third 
party taking any action, or refraining from taking any action on the basis of 
any of the information contained in this email is hereby excluded.

Confidentiality
This communication (including any attachment/s) is intended only for the use of 
the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. 
Unauthorized reading, dissemination, distribution, or copying of this 
communication is prohibited. Please inform originator if you have received it 
in error.

Caution for viruses, malware etc.
This communication, including any attachments, may not be free of viruses, 
trojans, similar or new contaminants/malware, interceptions or interference, 
and may not be compatible with your systems. You shall carry out virus/malware 
scanning on your own before opening any attachment to this e-mail. The sender 
of this e-mail and Company including its sister concerns shall not be liable 
for any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer problems.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread Ben Newlin

Jeff,

My point was that the uac_auth() is supposed to handle the realm matching for 
you. If you simply load all of the auth data based on the call target as you 
already plan to do, uac_auth() should look through that data for you to find 
credentials with a matching realm. You don’t need to do that part yourself in 
the script.

Ben Newlin

From: Users 
Date: Thursday, September 24, 2020 at 11:14 PM
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've been 
looking at this too long.  I checked the module and that's exactly what it is.

My hope was to load the uac_auth user/pass AVPs ahead of time from a DB based 
on where I knew I was sending the call, load the realm one in the failure route 
based on what comes back in the header, and then fire the uac_auth() function.  
It looks like I may have to manually extract the realm from whichever header 
comes in.  Not ideal, but probably workable.


- Jeff


On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin 
mailto:ben.new...@genesys.com>> wrote:
This does not appear to be documented, but I believe uac_auth() looks through 
the AVPs configured in the UAC_AUTH module and uses the first one whose realm 
matches the challenge realm. So in order to authenticate any challenge, you 
must load all of the possible credentials into those AVPs.

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Thursday, September 24, 2020 at 9:53 PM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: Re: [OpenSIPS-Users] learning the realm from authentication challenges
According to the docs, $ar provides the realm from the “Authorization” or 
“Proxy-Authorization” headers. Not from the ”Proxy-Authenticate” header, which 
is what you have.

https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6

Ben Newlin

From: Users 
mailto:users-boun...@lists.opensips.org>>
Date: Thursday, September 24, 2020 at 9:31 PM
To: OpenSIPS users mailling list 
mailto:users@lists.opensips.org>>
Subject: [OpenSIPS-Users] learning the realm from authentication challenges
I'm trying to recover the realm of an auth challenge to OpenSIPS so I can 
respond to it with the uac_auth() function, and that requires knowing the 
realm.  The docs say that 
$ar should 
provide that, perhaps written like $(ar) to get it in the right context. 
 I'm having some trouble getting the data.

failure_route[relay_failure] {
...
if (t_check_status("407")) {
xlog("L_NOTICE", "[1] Proxy-Authenticate: 
$(hdr(Proxy-Authenticate))\n");
xlog("L_NOTICE", "[2] Auth Realm: $(ar)\n");
xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
}
...
}

The logs show:

/usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest realm="asterisk", 
nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd", qop="auth"
/usr/sbin/opensips[33044]: [2] Auth Realm reply: 
/usr/sbin/opensips[33044]: [3] Auth Realm: 

Is it possible to get the realm?  Is it possible to build a response with 
uac_auth() for an arbitrary authentication challenge?

This is on 3.1.0~20200923~88f89e941.



- Jeff

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?

2020-09-25 Thread Liviu Chircu


On 25.09.2020 12:55, Diptesh Patel wrote:
I want to fail-over my call on 6xx response and I use failure route 
for that but t_relay() gives below errors and reply with '500 No 
destination available (18/SL)'.


Sep 25 05:47:10 OLD-OVW-SBCA01 /usr/local/sbin/opensips[28174]: 
INFO:tm:t_forward_nonack: discarding fwd for a 6xx transaction
Sep 25 05:47:10 OLD-OVW-SBCA01 /usr/local/sbin/opensips[28174]: 
ERROR:tm:w_t_relay: t_forward_nonack failed


Anyone have an idea how I can resolve this?


Hey, Diptesh!

That is the standard RFC behavior.  In real-life, you may want to 
disable this quirk and retry to a new gateway, by setting 
"disable_6xx_block" [1] to true.


Best regards,

[1]: https://opensips.org/docs/modules/3.2.x/tm.html#param_disable_6xx_block

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?

2020-09-25 Thread Diptesh Patel

Hello,

I want to fail-over my call on 6xx response and I use failure route for
that but t_relay() gives below errors and reply with '500 No destination
available (18/SL)'.

Sep 25 05:47:10 OLD-OVW-SBCA01 /usr/local/sbin/opensips[28174]:
INFO:tm:t_forward_nonack: discarding fwd for a 6xx transaction
Sep 25 05:47:10 OLD-OVW-SBCA01 /usr/local/sbin/opensips[28174]:
ERROR:tm:w_t_relay: t_forward_nonack failed

Anyone have an idea how I can resolve this?


Thanks & Regards
*Diptesh Patel*
Software Developer
Ecosmob Technologies Ltd,
Ahmedabad
Mo:*+919898962659*

-- 
*Disclaimer*
In addition to generic Disclaimer which you have agreed on our 
website, any views or opinions presented in this email are solely those of 
the originator and do not necessarily represent those of the Company or its 
sister concerns. Any liability (in negligence, contract or otherwise) 
arising from any third party taking any action, or refraining from taking 
any action on the basis of any of the information contained in this email 
is hereby excluded.



*Confidentiality*
This communication (including any 
attachment/s) is intended only for the use of the addressee(s) and contains 
information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, 
dissemination, distribution, or copying of this communication is 
prohibited. Please inform originator if you have received it in error.



*Caution for viruses, malware etc.*
This communication, including any 
attachments, may not be free of viruses, trojans, similar or new 
contaminants/malware, interceptions or interference, and may not be 
compatible with your systems. You shall carry out virus/malware scanning on 
your own before opening any attachment to this e-mail. The sender of this 
e-mail and Company including its sister concerns shall not be liable for 
any damage that may incur to you as a result of viruses, incompleteness of 
this message, a delay in receipt of this message or any other computer 
problems. 
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] does lua_exec supports async and launch

2020-09-25 Thread johan


does lua_exec supports async calls ?

If no, can you please indicate what needs to be added to have this 
support ?



wkr,


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] learning the realm from authentication challenges

2020-09-25 Thread johan


do this in failure_route


    if (is_method("INVITE"))
    {
    # mark that auth was performed
    setflag(8);
    # trigger again the failure route
    t_on_failure("missed_call_registrations");
    if ($(hdr(Proxy-Authenticate)))
    {
    $var(raw_auth) = $(hdr(Proxy-Authenticate));
    }
    if ($(hdr(WWW-Authenticate)))
    {
    $var(raw_auth) = $(hdr(WWW-Authenticate));
    }
    $var(reg_start) = "/(.*?)realm=\"//g";
    $var(reg_end) = "/\"(.*)//g";
    xlog("callid=$ci: Failure_route[missed_call_registrations]: Raw 
data $var(raw_auth)");

    $var(raw_auth) = $(var(raw_auth){re.subst,$var(reg_start)});
    $var(raw_auth) = $(var(raw_auth){re.subst,$var(reg_end)});
    xlog("callid=$ci: Failure_route[missed_call_registrations]: Got 
realm data $var(raw_auth)");

    $avp(uac_realm)=$var(raw_auth);
    # repeat the request with auth response this time
    xlog("callid=$ci: Failure_route[missed_call_registrations]:let 
us send authentication");
    xlog("callid=$ci: 
Failure_route[missed_call_registrations]:FAILUREROUTE_STATUS40X_UACAUTHINVITE_DEBUG_VARIABLES: 
AVP_UAC_REALM:$avp(uac_realm) AVP_UAC_USERNAME: $avp(uac_username) 
AVP_UAC_PASSWORD:$avp(uac_password)");

    uac_auth();

}

On 25/09/2020 05:13, Jeff Pyle wrote:
Good catch on Proxy-Authorization vs Proxy-Authenticate.  I think I've 
been looking at this too long.  I checked the module and that's 
exactly what it is.


My hope was to load the uac_auth user/pass AVPs ahead of time from a 
DB based on where I knew I was sending the call, load the realm one in 
the failure route based on what comes back in the header, and then 
fire the uac_auth() function.  It looks like I may have to manually 
extract the realm from whichever header comes in.  Not ideal, but 
probably workable.



- Jeff


On Thu, Sep 24, 2020 at 9:58 PM Ben Newlin > wrote:


This does not appear to be documented, but I believe uac_auth()
looks through the AVPs configured in the UAC_AUTH module and uses
the first one whose realm matches the challenge realm. So in order
to authenticate any challenge, you must load all of the possible
credentials into those AVPs.

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Thursday, September 24, 2020 at 9:53 PM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *Re: [OpenSIPS-Users] learning the realm from
authentication challenges

According to the docs, $ar provides the realm from the
“Authorization” or “Proxy-Authorization” headers. Not from the
”Proxy-Authenticate” header, which is what you have.

https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6

Ben Newlin

*From: *Users mailto:users-boun...@lists.opensips.org>>
*Date: *Thursday, September 24, 2020 at 9:31 PM
*To: *OpenSIPS users mailling list mailto:users@lists.opensips.org>>
*Subject: *[OpenSIPS-Users] learning the realm from authentication
challenges

I'm trying to recover the realm of an auth challenge to OpenSIPS
so I can respond to it with the uac_auth() function, and that
requires knowing the realm.  The docs say that $ar

should provide that, perhaps written like $(ar) to get it
in the right context. I'm having some trouble getting the data.

failure_route[relay_failure] {
...

        if (t_check_status("407")) {
                xlog("L_NOTICE", "[1] Proxy-Authenticate:
$(hdr(Proxy-Authenticate))\n");
                xlog("L_NOTICE", "[2] Auth Realm: $(ar)\n");

                xlog("L_NOTICE", "[3] Auth Realm: $ar\n");
        }

...

}

The logs show:

/usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest
realm="asterisk",
nonce="5f6d4214936ad820dbcd452e6bcd145777e458dd46dd", qop="auth"
/usr/sbin/opensips[33044]: [2] Auth Realm reply: 
/usr/sbin/opensips[33044]: [3] Auth Realm: 

Is it possible to get the realm? Is it possible to build a
response with uac_auth() for an arbitrary authentication challenge?

This is on 3.1.0~20200923~88f89e941.

- Jeff

___
Users mailing list
Users@lists.opensips.org 
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 2.4: high CPU usage by 2 processes

2020-09-25 Thread Alexey Kazantsev via Users


- also added ‘t_newtran();’ for each incoming REGISTER.
 
We’ve also noticed that CPU utilization remained high when
restarting OpenSIPS under high load.
 
CPU utilization became normal when 1) dropping sip traffic with firewall,
2) then restarting OpenSIPS (with no load), and 3) accepting sip traffic
after that.
 
---
BR, Alexey
http://alexeyka.zantsev.com/
 ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 2.4: high CPU usage by 2 processes

2020-09-25 Thread Alexey Kazantsev via Users


The problem seems to be fixed after 2 changes:
 
- adding ‘use_children 8’ to both listeners — external and internal
(from which the $fs is done)
- doing $fs="udp:10.229.3.33:5070"; after ‘mid_registrar_save’,
(earlier that was done before it, in one of cases in script).
 
Now the CPU utilization is OK.
 
---
BR, Alexey
http://alexeyka.zantsev.com/
 ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?

[OpenSIPS-Users] How to Solve 'Discarding fwd for a 6xx Transaction'?

[OpenSIPS-Users] does lua_exec supports async and launch

Re: [OpenSIPS-Users] learning the realm from authentication challenges

Re: [OpenSIPS-Users] 2.4: high CPU usage by 2 processes

Re: [OpenSIPS-Users] 2.4: high CPU usage by 2 processes

15 matches

Site Navigation

Mail list logo

Footer information