[Home]

Summary:ASTERISK-27881: PBX calls via chan_sip TCP trunk now get authentification error
Reporter:Ian Gilmour (tuxian)Labels:
Date Opened:2018-05-30 03:07:43Date Closed:2018-08-27 07:02:56
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:13.21.0 Frequency of
Occurrence
Related
Issues:
is caused byASTERISK-27457 chan_sip: Guests disallowed via TCP (or TLS) if existing peer from same IP.
is duplicated byASTERISK-27945 TCP-Peer with insecure=port not found on incoming call
is duplicated byASTERISK-28688 Matching SIP TCP peer by IP with insecure=port regression
Environment:Ubuntu 16.04Attachments:( 0) patch-channels-chan_sip.c
Description:I have a PBX (type=peer) with a few extensions that forwards calls on to an Asterisk and from there the calls get routed to an external server. All worked fine with 13.20.0 but after upgrading to 13.21.0 I now see the call being rejected by Asterisk with authentification failures.

The PBX doesn't register with Asterisk - calls are accepted because they come from the defined PBX host IP address. The port the call originates from does not match the defined PBX port (it didn't when using 13.20.0 either and that worked fine).

I tried adding "insecure=port,invite" to the PBX trunk config with no effect.

The change in behaviour between 13.20 and 13.21 looks to be related to mods made for ASTERISK-27457.
Comments:By: Asterisk Team (asteriskteam) 2018-05-30 03:07:46.381-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Richard Mudgett (rmudgett) 2018-05-30 12:20:55.734-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected and the location of documentation that led you to that expectation.
3. The behavior you actually encountered.

To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

[2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Ian Gilmour (tuxian) 2018-05-31 11:18:40.133-0500

users.conf contains:

{noformat}
;-------------------------------------------------------------------
; PBX Trunk
;-------------------------------------------------------------------
[def-pbx-codecs](!)
; audio codecs supported
allow=!all,opus,ulaw,alaw,gsm,speex
; video codecs supported
videosupport=yes
allow=h264
;-------------------------------------------------------------------

;-------------------------------------------------------------------
[def-pbx-novideo-codecs](!)
; audio codecs supported
allow=!all,opus,ulaw,alaw,gsm,speex
;-------------------------------------------------------------------

;-------------------------------------------------------------------
; SIP trunk to PBX
; uses one of the codec sets defined above
[PBX](def-pbx-codecs)
;-------------------------------------------------------------------
; SIP trunk to PBX
; uses one of the codec sets defined above
[PBX]
type=peer
defaultuser=PBX
callerid="Gateway" <>
context=localOutgoingPBX
host=192.168.1.52
port=5060
secret=
remotesecret=
encryption=no
transport=tcp,udp
insecure=port,invite
{noformat}

Sample call to to Asterisk (2) from SIP client (101) connected to a PBX.
The PBX (192.168.1.52) is configured to forward the call on to Asterisk (192.168.1.43), using a TCP trunk.
Enabling sip debug gives the following Asterisk debug:

{noformat}
<--- SIP read from TCP:192.168.1.52:46340 --->
INVITE sip:2@192.168.1.43:5060 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.52:5060;rport;branch=z9hG4bKPj41f9e5f6-e38a-478a-b86f-3f25918e7ef5;alias
From: "Ian" <sip:101@192.168.1.52>;tag=11a5a243-3cbf-4c9e-85ae-378893ea8672
To: <sip:2@192.168.1.43>
Contact: <sip:asterisk@192.168.1.52:5060;transport=TCP>
Call-ID: ddbb432f-46cb-4570-94e4-ac7a075a1692
CSeq: 24123 INVITE
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800
Min-SE: 90
Max-Forwards: 70
User-Agent: FPBX-14.0.3.2(13.18.4)
Content-Type: application/sdp
Content-Length: 337

v=0
o=- 503644369 503644369 IN IP4 192.168.1.52
s=Asterisk
c=IN IP4 192.168.1.52
t=0 0
m=audio 12086 RTP/AVP 0 8 3 111 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
<------------->
--- (15 headers 16 lines) ---
Sending to 192.168.1.52:46340 (no NAT)
Sending to 192.168.1.52:46340 (no NAT)
Using INVITE request as basis request - ddbb432f-46cb-4570-94e4-ac7a075a1692
No matching peer for '101' from '192.168.1.52:46340'

<--- Reliably Transmitting (no NAT) to 192.168.1.52:46340 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TCP 192.168.1.52:5060;branch=z9hG4bKPj41f9e5f6-e38a-478a-b86f-3f25918e7ef5;alias;received=192.168.1.52;rport=46340
From: "Ian" <sip:101@192.168.1.52>;tag=11a5a243-3cbf-4c9e-85ae-378893ea8672
To: <sip:2@192.168.1.43>;tag=as2410abf6
Call-ID: ddbb432f-46cb-4570-94e4-ac7a075a1692
CSeq: 24123 INVITE
Server: Asterisk PBX 13.21.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="7162128f"
Content-Length: 0
{noformat}

Switching PBX to send via a UDP trunk (rather than TCP) with the same Asterisk config results in a successful call.

Looking at the ASTERISK-27457 modification I suspect using TLS will also fail for the same reason.

The failed TCP and TLS calls would have worked using Asterisk 13.20.0 (even without the *insecure=port,invite* in the config).
By: Richard Mudgett (rmudgett) 2018-05-31 12:08:07.679-0500

Yep.  Looks like ASTERISK-27457 causes the regression.  Probably the only solution is to change the matching to optionally match port regardless of transport using the insecure=port option.

Please be aware that chan_sip is in extended support and only supported by the community so response times will reflect that.
By: Ian Gilmour (tuxian) 2018-05-31 12:22:58.465-0500

Yep - as expected, changing (chan_sip.c: 34192):
{noformat}
(AST_TRANSPORT_UDP | AST_TRANSPORT_WS | AST_TRANSPORT_WSS)) &&
{noformat}
to:
{noformat}
(AST_TRANSPORT_UDP | AST_TRANSPORT_WS | AST_TRANSPORT_WSS | AST_TRANSPORT_TCP | AST_TRANSPORT_TLS)) &&
{noformat}
and adding:
{noformat}
insecure=port,invite
{noformat}
to the PBX config fixes the issue with TCP (and I suspect TLS).

By: Dan Lukes (dan_lukes) 2018-07-11 18:08:01.094-0500

I has been affected by the same issue, analyzed it with no prior knowledge of this ticket and found the same solution as mentioned by Ian Gilmour.
channels/chan_sip.c, function peer_ipcmp_cb_full() - SIP_INSECURE_PORT is honored for UDP, WS and WSS only. List of AST_TRANSPORT_... shall be extended to contain TCP and TLS as suggested above.

"insecure=port" is enough for peers to be recognized again.
By: Richard Mudgett (rmudgett) 2018-07-11 18:51:24.212-0500

Thanks for the contribution! If you'd like your contribution to be included faster, you should submit your patch for code review by the Asterisk Developer Community. To do so, please follow the Code Review [1] instructions on the wiki. Be sure to:
* Verify that your patch conforms to the Coding Guidelines [2]
* Review the Code Review Checklist [3] for common items reviewers will look for
* If necessary, provide tests for the Asterisk Test Suite that verify the correctness of your patch [4]

When ready, submit your patch and any tests to Gerrit [5] for code review.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Code+Review
[2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
[3] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist
[4] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
[5] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage


By: Joshua C. Colp (jcolp) 2018-08-02 04:45:47.793-0500

[~traud] I believe a comment was done on Github about this but I can't seem to find it right now. This is an issue tracking the regression from the chan_sip matching change you did.
By: Friendly Automation (friendly-automation) 2018-08-27 07:02:57.730-0500

Change 9861 merged by Jenkins2:
chan_sip: improved ip:port finding of peers for non-UDP transports.

[https://gerrit.asterisk.org/9861|https://gerrit.asterisk.org/9861]
By: Friendly Automation (friendly-automation) 2018-08-27 07:05:12.607-0500

Change 9860 merged by Jenkins2:
chan_sip: improved ip:port finding of peers for non-UDP transports.

[https://gerrit.asterisk.org/9860|https://gerrit.asterisk.org/9860]
By: Friendly Automation (friendly-automation) 2018-08-27 07:18:18.304-0500

Change 9858 merged by George Joseph:
chan_sip: improved ip:port finding of peers for non-UDP transports.

[https://gerrit.asterisk.org/9858|https://gerrit.asterisk.org/9858]
By: Friendly Automation (friendly-automation) 2018-08-27 07:43:37.650-0500

Change 9859 merged by Jenkins2:
chan_sip: improved ip:port finding of peers for non-UDP transports.

[https://gerrit.asterisk.org/9859|https://gerrit.asterisk.org/9859]