Hi Peter,
In TCP, you cannot control the port used to fire a new TCP connection -
this is selected by the kernel. Still, the UAS side will reply back to
the originating port (as the trace shows). The fact the uac_registrant
does not see the 401 is not necessarily because of the TCP connection,
but rather because of some SIP transactional issue - the reply does not
match the requests, so the TM module does not deliver the reply to
uac_registrant.
Do you see any logs from OpenSIPS about the incoming 401 reply ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html
On 04/21/2017 12:21 PM, Peter Baines (lists) wrote:
Hi Bogdan,
Yes you are correct, it is a retransmission.
I've specifed port 5060 as the forced_socket in the registrant table
but opensips (1.2.3.4 below) doesn't use it. Is there a way to force
uac_registrant to use 5060, or alternatively make the uac_registrant
module listen for replies on whatever port it decides to open ?
T 2017/04/21 11:05:26.960562 1.2.3.4:52945 <http://1.2.3.4:52945> ->
4.3.2.1:5060 <http://4.3.2.1:5060> [AP]
REGISTER sip:imsreg.example.com <http://imsreg.example.com> SIP/2.0.
T 2017/04/21 11:05:27.381976 4.3.2.1:5060 <http://4.3.2.1:5060> ->
1.2.3.4:52945 <http://1.2.3.4:52945> [AP]
SIP/2.0 401 Unauthorized.
mysql> SELECT * FROM registrant \G
*************************** 1. row ***************************
id: 1
registrar: sip:imsreg.example.com <http://imsreg.example.com>
proxy: NULL
aor: sip:[email protected]
<mailto:sip%3a%[email protected]>
third_party_registrant: NULL
username: [email protected]
<mailto:[email protected]>
password: 123
binding_URI: sip:[email protected]
<mailto:sip%3A%[email protected]>
binding_params: NULL
expiry: NULL
* forced_socket: tcp:1.2.3.4:5060 <http://1.2.3.4:5060>*
1 row in set (0.00 sec)
Thank you,
Peter
On 21 April 2017 at 09:53, Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>> wrote:
Hi Pete,
Looking to the logs, I see only one line :
Apr 21 09:58:56 dev01 /usr/local/opensips_2.2/sbin/opensips[4766]:
DBG:uac_registrant:reg_tm_cback: tm [0x7f2ceb70b2f0] notification
cb for FAKED_REPLY [408] reply at [1492761536]
The "reg_tm_cback" is the TM callback used to report back to the
uac_registrant module the reply code for the sent REGISTER. And I
see there a 408 timeout :-/ .....
Even more, the "run_reg_tm_cback" function (that triggers the
build of the auth hdr) does not show up logging anything (and
there are some debug over there).
So, are you sure that the 401 is actually received ? maybe the
second REGISTER is actually a retransmission of the first one ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com <http://www.opensips-solutions.com>
OpenSIPS Summit May 2017 Amsterdam
http://www.opensips.org/events/Summit-2017Amsterdam.html
<http://www.opensips.org/events/Summit-2017Amsterdam.html>
On 04/21/2017 11:14 AM, Peter Baines (lists) wrote:
Hello,
I am trying to use the uac_registrant module (2.2) to register
via TCP but when it recieves the 401 it is not adding the
Authorization header.
It does work with UDP so I get:
REGISTER -> 401 (with WWW-Authenticate) -> REGISTER (with
Authorization) -> 200 OK
However when I tell it to use TCP it doesn't add the
Authorization header: UPDATE registrant SET forced_socket =
'tcp:1.2.3.4:5060 <http://1.2.3.4:5060>';
REGISTER -> 401 (with WWW-Authenticate) -> REGISTER (no
Authorization) -> 403 Forbidden
I've included the debug log for the failing TCP REGSITER attempt:
https://pastebin.com/gigJkWZX
Regards,
Peter
_______________________________________________
Users mailing list
[email protected] <mailto:[email protected]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users