[Home]

Summary:ASTERISK-24428: Document that Asterisk will use the default SIP ports (5060 for TCP, 5061 for TLS) if the extern option variants aren't used
Reporter:sstream (sstream)Labels:
Date Opened:2014-10-17 01:53:40Date Closed:2020-04-21 10:20:21
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:SVN 1.8.32.0 11.12.0 12.7.0 13.0.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Ubuntu 14.04, OpenWrt 14.07Attachments:
Description:Using Asterisk 11.12 server behind NAT (router) and Android SIP client (Acrobits or CSipSimple) with the following condition.
- Router local IP: 192.168.0.1
- Router domain: sip.example.net (using DNS like DynDNS)
- Asterisk server local IP: 192.168.0.2
- SIP protocol: TLS, port=10000 (not default due to security reason)
- RTP: port=10001 to 10008
- Android phone has a global IP.

In router's setting, I opened ports 10000-10008 (TLS and RTP) and forwarded them to Asterisk server IP (192.168.0.2).
---
<sip.conf>
externhost=sip.example.net
localnet=192.168.0.0/255.255.255.0

tlsenable=yes
tlsbindaddr=0.0.0.0:10000
tlscertfile=…
---
<rtp.conf>
rtpstart=10001
rtpend=10008
---

Under above condition, there is no problem for registration, connection, calling and talking.
However, Asterisk cannot detect disconnection. (can't disconnect).

I traced a log and found;
---
SIP/2.0 100 Trying
Via: SIP/2.0/TLS xxx.xxx.xx.0:xxxxx;branch=;received=;rport=
From: <sips:xxx@ sip.example.net:10000>;tag=xxx
To: <sips:yyy@ sip.example.net:10000>
Call-ID: xxxxx
CSeq: 1 INVITE
Server: Asterisk PBX 11.12.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:yyy@x.xx.xx.xx:5061;transport=TLS>
Content-Length: 0
---

In "Contact:" line (2nd line from the bottom), port “5061” suddenly appears, which I never used.

This problem only occurs under TLS with non-default port (not 5061).
There is no problem under UDP, even though  non-standard port is set (ex. bindport=10000).

For testing, in “sip.h”, I changed
#define STANDARD_TLS_PORT 5061
to
#define STANDARD_TLS_PORT 10000
and compiled.
As a result, I confirmed that Asterisk works properly (detect disconnection).

In conclusion, it is better to make an option like “tlsbindport” in sip.conf and make it work like UDP.

Thank you.
Comments:By: Matt Jordan (mjordan) 2014-10-28 09:25:34.697-0500

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Rusty Newton (rnewton) 2014-11-13 17:22:29.830-0600

[~sstream] can you attach a pcap along with the debug that Matt requested? Preferably of both before your patch and after.
By: Walter Doekes (wdoekes) 2014-11-14 02:18:57.208-0600

Looks to me like reporter provided all the necessary info.

Apparently the Contact-addr-info-port doesn't get the tlsbindaddr port.

Reporter pointed us to STANDARD_TLS_PORT, which is used here:
{noformat}
       ourport_tls = STANDARD_TLS_PORT;
{noformat}

{noformat}
static void *_sip_tcp_helper_thread(struct ast_tcptls_session_instance *tcptls_session)
...
                       if (tcptls_session->ssl) {
                               set_socket_transport(&req.socket, SIP_TRANSPORT_TLS);
                               req.socket.port = htons(ourport_tls);
                       } else {
                               set_socket_transport(&req.socket, SIP_TRANSPORT_TCP);
                               req.socket.port = htons(ourport_tcp);
                       }
{noformat}

If I may venture a guess, I'd say that that port is wrong. (It should take the port from the actual socket, not from the default.)
And it probably gets assigned into {{ourip}} somewhere along the way, finally ending up in the Contact header.

Browsing along, it looks like the ourip would be set here:
{noformat}
static void ast_sip_ouraddrfor(const struct ast_sockaddr *them, struct ast_sockaddr *us, struct sip_pvt *p)
...
               /* no remapping, but we bind to a specific address, so use it. */
...
               case SIP_TRANSPORT_TLS:
                       if (!ast_sockaddr_is_any(&sip_tls_desc.local_address)) {
                               ast_sockaddr_copy(us,
                                                 &sip_tls_desc.local_address);
                       } else {
                               ast_sockaddr_set_port(us,
                                                     ast_sockaddr_port(&sip_tls_desc.local_address));
                       }
                       break;
{noformat}

Or, in case there is remapping going on, it would end up here:

{noformat}
                       case SIP_TRANSPORT_TLS:
                               ast_sockaddr_set_port(us, externtlsport);
                               break;
{noformat}

In that case, the fix would be to set this in sip.conf and be done with it:

{noformat}
externtlsport=10000
{noformat}

That would mean that the default is wrong, and that externtlsport should ideally default to the tlsbindaddrport. Changing that however, would be backwards incompatible.

----

h1. Summarizing

* I think there is something fishy with this setting {{req.socket.port = htons(ourport_tls)}}.
* But, reporter probably only needs to set {{externtlsport=10000}} to fix his particular problem. (See his localnet setting.)
* However, that he needs to set it at all seems counter intuitive.

(Disclaimer: just browsing the source.)
By: Walter Doekes (wdoekes) 2014-11-14 02:20:25.279-0600

[~sstream], can you check if setting {{externtlsport=10000}} fixes your problem?
By: sstream (sstream) 2014-11-17 16:56:24.356-0600

Thank you, Walter.
I confirmed that it works.
However, I need to set both as follows.
---
externtlsport=10000
tlsbindaddr=0.0.0.0:10000
---

If I set only "externtlsport=10000", a SIP client cannot even register.

I feel that it is redundant and not straightforward.
Again, it seems better to make "tlsbindport", which is just a same function as above 2 settings.

Anyway, thank you for your help.
By: Walter Doekes (wdoekes) 2014-11-18 01:50:14.389-0600

Ok. Thanks for confirming.

Your problem is these:
{noformat}
externhost=sip.example.net
localnet=192.168.0.0/255.255.255.0
{noformat}

If you weren't behind NAT, you wouldn't have had any problems.

Since it is behind NAT, Asterisk has no idea at all which port will be listening on the outside. Like I said, it's counter intuitive that it "guesses" the default port (5061) instead of the local port (port-bit of the tlsbindaddr). I agree that it would make more sense to default to the tlsbindaddr-port, but it's still a guess.

And, changing this now causes backwards compatibility issues with others who have relied on this setting. Perhaps a bit of documentation would be appropriate. "If you use extenhost/externaddr, make sure you set the extern*port as well..."

Matt? Rusty? Thoughts?
By: Matt Jordan (mjordan) 2014-11-18 08:07:30.208-0600

I will say that the {{externtlsport}}/{{externtcpport}} settings are two of those settings that are a bit odd, but - as [~wdoekes] pointed out - somewhat necessary for NAT settings. I do agree that it is counterintuitive to have Asterisk 'guess' with the default TLS (or TCP port, as I would guess it has the same problem) as opposed to what was explicitly set in the {{*bindaddr}} field.

Personally, I'd go with:
# Documenting it slightly better in {{sip.conf.sample}} that Asterisk will use the default SIP ports (5060 for TCP, 5061 for TLS) if the {{extern}} variants aren't used in release branches
# If an improvement is to be made, do it in trunk. [~wdoekes] is right that someone may be relying on this behaviour, as odd as it is.

By: Rusty Newton (rnewton) 2014-11-18 15:37:20.427-0600

I'm going to open this issue up for the documentation bit. If someone decides to work a patch then open up a separate issue and link it to this one as related. I supposed there will be some discussion about an improvement if that happens and we don't want to crowd it all onto here.
By: sstream (sstream) 2014-11-20 18:05:35.930-0600

Please note.
When I do not use TLS, single setting "bindport=10000" works perfectly with behind NAT.

Only in the case of TLS, we need both "externtlsport=10000" and "tlsbindaddr=0.0.0.0:10000".

I feel this is inconsistent.

By: Friendly Automation (friendly-automation) 2020-04-21 10:20:25.287-0500

Change 14297 merged by George Joseph:
chan_sip: externhost/externaddr with non-default TCP/TLS ports.

[https://gerrit.asterisk.org/c/asterisk/+/14297|https://gerrit.asterisk.org/c/asterisk/+/14297]
By: Friendly Automation (friendly-automation) 2020-04-21 10:20:54.199-0500

Change 14296 merged by George Joseph:
chan_sip: externhost/externaddr with non-default TCP/TLS ports.

[https://gerrit.asterisk.org/c/asterisk/+/14296|https://gerrit.asterisk.org/c/asterisk/+/14296]
By: Friendly Automation (friendly-automation) 2020-04-21 10:21:31.007-0500

Change 14295 merged by George Joseph:
chan_sip: externhost/externaddr with non-default TCP/TLS ports.

[https://gerrit.asterisk.org/c/asterisk/+/14295|https://gerrit.asterisk.org/c/asterisk/+/14295]
By: Friendly Automation (friendly-automation) 2020-04-21 10:21:53.637-0500

Change 14275 merged by George Joseph:
chan_sip: externhost/externaddr with non-default TCP/TLS ports.

[https://gerrit.asterisk.org/c/asterisk/+/14275|https://gerrit.asterisk.org/c/asterisk/+/14275]