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 <jo...@democon.be> 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 <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 <users-boun...@lists.opensips.org> >> *Date: *Friday, September 25, 2020 at 10:15 AM >> *To: *OpenSIPS users mailling list <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 <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 <users-boun...@lists.opensips.org> >> *Date: *Thursday, September 24, 2020 at 11:14 PM >> *To: *OpenSIPS users mailling list <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 <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 <users-boun...@lists.opensips.org> >> *Date: *Thursday, September 24, 2020 at 9:53 PM >> *To: *OpenSIPS users mailling list <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 <users-boun...@lists.opensips.org> >> *Date: *Thursday, September 24, 2020 at 9:31 PM >> *To: *OpenSIPS users mailling list <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 >> <https://www.opensips.org/Documentation/Script-CoreVar-3-1#toc6> should >> provide that, perhaps written like $(<reply>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: >> $(<reply>hdr(Proxy-Authenticate))\n"); >> xlog("L_NOTICE", "[2] Auth Realm: $(<reply>ar)\n"); >> >> xlog("L_NOTICE", "[3] Auth Realm: $ar\n"); >> } >> >> ... >> >> } >> >> >> >> The logs show: >> >> /usr/sbin/opensips[33044]: [1] Proxy-Authenticate: Digest >> realm="asterisk", nonce="5f6d42140000936ad820dbcd452e6bcd145777e458dd46dd", >> qop="auth" >> /usr/sbin/opensips[33044]: [2] Auth Realm reply: <null> >> /usr/sbin/opensips[33044]: [3] Auth Realm: <null> >> >> >> >> 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 >> > > _______________________________________________ > Users mailing > listUsers@lists.opensips.orghttp://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