25 Aug
2016
25 Aug
'16
3:42 p.m.
Trying to implement a way to authenticate outgoing INVITEs to endpoints
that need/want to. uac_auth in the initial failure route works fine when
there is only 1 registered user to send the INVITE to. But with at least
2 locations are available and 1 accepts the INVITE without
authentication, the 401 of the location that wants authentication isn't
processed in the failure route until a timeout is triggered (t_set_fr).
At that point the 401 is processed and a response generated with
Authentication header. But since t_set_fr invite timeout was exceeded it
is immediatly destroyed due to a CANCEL having been generated to the
location(s).
t=0:
t_set_fr(10000);
INVITE to A anb B
A responds 100 Trying,180 Ringing
B responds 401 Unauthorized
t=10s:
T_code=180, new_code=408
failure route status: 401
uac_auth()
INVITE with Authorization is build to B
CANCEL to A
INVITE to B is never send
Is this expected behaviour? Obviously I didn't expect this.
26 Aug
26 Aug
1:58 p.m.
Hello,
try to see if it works to do the authentication in the branch failure
event route. There you can do processing as soon as the 401 arrives --
it has to be tried to see if uac auth works fine there, if not probably
needs some tuning.
Cheers,
Daniel
On 25/08/16 15:42, Daniel Tryba wrote:
Trying to implement a way to authenticate outgoing
INVITEs to endpoints
that need/want to. uac_auth in the initial failure route works fine when
there is only 1 registered user to send the INVITE to. But with at least
2 locations are available and 1 accepts the INVITE without
authentication, the 401 of the location that wants authentication isn't
processed in the failure route until a timeout is triggered (t_set_fr).
At that point the 401 is processed and a response generated with
Authentication header. But since t_set_fr invite timeout was exceeded it
is immediatly destroyed due to a CANCEL having been generated to the
location(s).
t=0:
t_set_fr(10000);
INVITE to A anb B
A responds 100 Trying,180 Ringing
B responds 401 Unauthorized
t=10s:
T_code=180, new_code=408
failure route status: 401
uac_auth()
INVITE with Authorization is build to B
CANCEL to A
INVITE to B is never send
Is this expected behaviour? Obviously I didn't expect this.
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
29 Aug
29 Aug
11:22 a.m.
On Fri, Aug 26, 2016 at 01:58:57PM +0200, Daniel-Constantin Mierla wrote:
try to see if it works to do the authentication in the
branch failure
event route. There you can do processing as soon as the 401 arrives --
it has to be tried to see if uac auth works fine there, if not probably
needs some tuning.
Good idea, but uac_auth isn't allowed in such a block:
# kamailio -c
loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules/
0(46160) ERROR: <core> [cfg.y:3224]: yyparse(): misused command uac_auth
0(46160) : <core> [cfg.y:3368]: yyerror_at(): parse error in config file
/etc/kamailio/kamailio.cfg, line 617, column 12: Command cannot be used in the block
ERROR: bad config file (1 errors)
612: event_route[tm:branch-failure:authfailure] {
613: if (t_check_status("401|407") && $(avp(dst_au){s.len})>0
&& $(avp(dst_passwd){s.len})>0)
614: {
615: $avp(auser) = $avp(dst_au);
616: $avp(apass) = $avp(dst_passwd);
617: uac_auth();
618:
619: t_relay();
620: exit;
621: }
}
5:23 p.m.
Hello,
can you try to change the module exports for uac module and allow
uac_auth() for REQUEST_ROUTE or BRANCH_FAILURE_ROUTE (not sure right now
by heart which one is required) and see if it actually works. Then the
flags can be extended if all ok.
Cheers,
Daniel
On 29/08/16 11:22, Daniel Tryba wrote:
On Fri, Aug 26, 2016 at 01:58:57PM +0200,
Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
try to see if it works to do the authentication
in the branch failure
event route. There you can do processing as soon as the 401 arrives --
it has to be tried to see if uac auth works fine there, if not probably
needs some tuning.
Good idea, but uac_auth isn't allowed in such a block:
# kamailio -c
loading modules under config path: /usr/lib/x86_64-linux-gnu/kamailio/modules/
0(46160) ERROR: <core> [cfg.y:3224]: yyparse(): misused command uac_auth
0(46160) : <core> [cfg.y:3368]: yyerror_at(): parse error in config file
/etc/kamailio/kamailio.cfg, line 617, column 12: Command cannot be used in the block
ERROR: bad config file (1 errors)
612: event_route[tm:branch-failure:authfailure] {
613: if (t_check_status("401|407") &&
$(avp(dst_au){s.len})>0 && $(avp(dst_passwd){s.len})>0)
614: {
615: $avp(auser) = $avp(dst_au);
616: $avp(apass) = $avp(dst_passwd);
617: uac_auth();
618:
619: t_relay();
620: exit;
621: }
}
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
30 Aug
30 Aug
2:06 p.m.
On Mon, Aug 29, 2016 at 05:23:46PM +0200, Daniel-Constantin Mierla wrote:
can you try to change the module exports for uac
module and allow
uac_auth() for REQUEST_ROUTE or BRANCH_FAILURE_ROUTE (not sure right now
by heart which one is required) and see if it actually works. Then the
flags can be extended if all ok.
Patching uac.c fixes the problem (strangly enough it is REQUEST_ROUTE).
In the branch failure route the challenge is answered directly, so in
this scenario I have 2 endpoints ringing, one which requires
authentication and one that just accepts the INVITE as is.
2795
days inactive
2800
days old
4 comments
2 participants
participants (2)
-
Daniel Tryba -
Daniel-Constantin Mierla