List of Tables
List of Examples
TLS, as defined in SIP RFC 3261, is a mandatory feature for proxies and can be used to secure the SIP signalling on a hop-by-hop basis (not end-to-end). TLS works on top of TCP. DTLS, or TLS over UDP is already defined by IETF and may become available in the future.
The TLS support was originally developed by Peter Griffiths and posted as a patch on SER development mailing list. Thanks to Cesc Santasusana, several problems were fixed and some improvements were added.
The TLS support was simultaneously added in both projects. In SER, the support was committed in a separate “experimental” CVS tree, as patch to the main CVS tree. In OpenSIPS, the support was integrated directly into the CVS tree, as a built-in component, and is part of stable OpenSIPS since release >=1.0.0.
Starting with OpenSIPS 2.1, the TLS has been moved to a separate transport module, that implements the more generic Transport Interface.
By the increased number of providers the SIP world is continuously growing. More users means more calls and more calls means a high probability for a user to receive calls from totally unknown people or, in the worst case, to receive unwanted calls. To prevent this, a defense mechanism must be adopted by the SIP provider. Since only the called user is fully able to classify a call as being unwanted, the SIP server, based on all information regarding the call should notify the user about the desirability of the call. Information like the caller domain, the received source or the incoming protocol can be very useful for a SIP server to establish the nature of the call.
As this information is quite limited, is very improbable for a server to be able detect the unwanted calls - there are many calls that it cannot predict anything about its status (neutral calls). So, instead on alerting the called user about unwanted calls, the server can notify the user about calls that are considered trusted - calls for which the server is 100% sure there are not unwanted.
So, a trust concept must be defined for SIP servers. Which calls are trusted and which are not? A call is trusted if the caller can be identify as a trustable user - a user about we have reliable information.
Since all the user from its domain are authenticated (or should be), a SIP server can consider all the calls generated by its user as trusted. Now we have to extend the trust concept to the multi-domain level. A mutual agreement, between several domains, can establish a trusting relationship. So, a domain (called A) will consider also as trusted calls all the calls generated by user from a different domain (called B) and vice-versa. But just an agreement is not enough; since the authentication information is strictly limited to a domain (a domain can authenticate only its own user, not the user from other domains), there is still the problem of checking the authenticity of the caller - he can impersonate (by a false FROM header) a user from a domain that is trusted.
The answer to this problem is TLS (Transport Layer Security). All calls via domain A and domain B will be done via TLS. Authentication in origin domain plus TLS transport between domains will make the call 100% trusted for the target domain.
For such a mechanism to work, the following requirements must be met:
all UA must have set as outbound proxy their home server.
all SIP servers must authenticated all the calls generated by their own users.
all SIP servers must relay the calls generated be their user to a trusted domain via TLS.
Based on this, a server can classify as trusted a call for one of its user only if the call is also generated by one of its users or is the call is received from a trusted domain ( which is equivalent with a call received via TLS). Untrusted call will be calls received from users belonging to untrusted domains or from users from trusted domains, but whose calls are not routed via their home server (so, they are not authenticated by there home servers).
Once the server is able to tell if the call is trusted or not, the still open issue is about the mechanism used by server to notify the called user about the nature of the incoming call.
One way to do it is by remotely changing the ringing type of the called user's phone. This can be done by inserting special header into the INVITE request. Such feature is supported by now by several hardphones like CISCO ATA, CISCO 7960 and SNOM. This phones can change their ringing tone based on the present or content of the "Alert-Info" SIP header as follows:
CISCO ATA - it has 4 pre-defined ringing types. The Alert-Info header must look like “Alert-info: Bellcore-drX EOH” where X can be between 1 and 4. Note that 1 is the phone default ringing tone.
CISCO 7960 - it has 2 pre-defined ringing types and the possibility of uploading new ones. The “Alert-Info” header must look like “Alert-info: X EOH” where X can be whatever number. When this header is present, the phones will not change the ringing tone, but the ringing pattern. Normally, the phone rings like [ring.........ring..........ring] where [ring] is the ringing tone; if the header is present, the ringing pattern will be [ring.ring.........ring.ring........]. So, to be able to hear some difference between the two patterns (and not only as length), its strongly recommended to have a highly asymmetric ringing type (as the pre-defined are not!!).
SNOM - The “Alert-Info” header must look like “Alert-info: URL EOH"” where URL can be a HTTP URL (for example) from where the phone can retrieve a ringing tone.
All these parameters can be used from the opensips.cfg file, to configure the behavior of OpenSIPS-TLS.
Not specific to TLS. Allows to specify the protocol (udp, tcp, tls), the IP address and the port where the listening server will be.
The default port to be used for all TLS related operation. Be careful as the default port impacts both the SIP listening part (if no port is defined in the TLS listeners) and the SIP sending part (if the destination URI has no explicit port).
If you want to change only the listening port for TLS, use the port option in the SIP listener defintion.
Default value is 5061.
Send CRLF pong (\r\n) to incoming CRLFCRLF ping messages over TLS. By default it is enabled (1).
Default value is 1 (enabled).
Drop CRLF (\r\n) ping messages. When this parameter is enabled, the TLS layer drops packets that contains a single CRLF message. If a CRLFCRLF message is received, it is handled according to the tls_crlf_pingpong parameter.
Default value is 0 (disabled).
The maximum number of chunks that a SIP message is expected to arrive via TLS. If a packet is received more fragmented than this, the connection is dropped (either the connection is very overloaded and this leads to high fragmentation - or we are the victim of an ongoing attack where the attacker is sending the traffic very fragmented in order to decrease server performance).
Default value is 4.
Example 1.5. Set tls_max_msg_chunks parameter
...
modparam("proto_tls", "tls_max_msg_chunks", 8)
...
2.1. | Where can I post a question about TLS? |
Use one (the most appropriate) of the OpenSIPS mailing lists:
Remember: first at all, check if your question wasn't already answered. | |
2.2. | How can I report a bug? |
Accumulate as much as possible information (OpenSIPS version, opensips -V output, your OS (uname -a), OpenSIPS logs, network dumps, core dump files, configuration file) and send a mail to http://lists.opensips.org/cgi-bin/mailman/listinfo/devel Also you may try OpenSIPS's bug report web page: http://www.opensips.org/pmwiki.php?n=Development.Tracker | |
2.3. | How can I debug ssl/tls problems? |
Increase the log level in opensips.cfg (log_level=4) and watch the log statements in syslog. Install the ssldump utility and start it. This will give you a trace of the ssl/tls connections. | |
2.4. | What is the difference between the TLS directory and the TLSOPS module directory? |
The code in the TLS directory implements the TLS transport layer. The TLSOPS module implements TLS related functions which can be used in the routing script. | |
2.5. | Where can I find more about OpenSIPS? |
Take a look at http://www.opensips.org/. | |
2.6. | Where can I post a question about this module? |
First at all check if your question was already answered on one of our mailing lists:
E-mails regarding any stable OpenSIPS release should be sent to
If you want to keep the mail private, send it to
| |
2.7. | How can I report a bug? |
Please follow the guidelines provided at: https://github.com/OpenSIPS/opensips/issues. |
Table 3.1. Top contributors by DevScore(1), authored commits(2) and lines added/removed(3)
| Name | DevScore | Commits | Lines ++ | Lines -- | |
|---|---|---|---|---|---|
| 1. | Bogdan-Andrei Iancu (@bogdan-iancu) | 46 | 19 | 1453 | 795 |
| 2. | Eseanu Marius Cristian (@eseanucristian) | 45 | 5 | 55 | 2133 |
| 3. | Razvan Crainea (@razvancrainea) | 36 | 19 | 564 | 634 |
| 4. | Ionut Ionita (@ionutrazvanionita) | 23 | 6 | 883 | 557 |
| 5. | Liviu Chircu (@liviuchircu) | 7 | 4 | 13 | 88 |
| 6. | Bogdan Chifor | 5 | 2 | 141 | 1 |
| 7. | Vlad Paiu (@vladpaiu) | 4 | 2 | 84 | 3 |
| 8. | Julián Moreno Patiño | 3 | 1 | 1 | 1 |
(1) DevScore = author_commits + author_lines_added / (project_lines_added / project_commits) + author_lines_deleted / (project_lines_deleted / project_commits)
(2) including any documentation-related commits, excluding merge commits. Regarding imported patches/code, we do our best to count the work on behalf of the proper owner, as per the "fix_authors" and "mod_renames" arrays in opensips/doc/build-contrib.sh. If you identify any patches/commits which do not get properly attributed to you, please submit a pull request which extends "fix_authors" and/or "mod_renames".
(3) ignoring whitespace edits, renamed files and auto-generated files
Table 3.2. Most recently active contributors(1) to this module
| Name | Commit Activity | |
|---|---|---|
| 1. | Bogdan-Andrei Iancu (@bogdan-iancu) | Feb 2015 - Jun 2018 |
| 2. | Liviu Chircu (@liviuchircu) | Mar 2015 - Jun 2018 |
| 3. | Razvan Crainea (@razvancrainea) | Feb 2015 - Sep 2017 |
| 4. | Julián Moreno Patiño | Feb 2016 - Feb 2016 |
| 5. | Eseanu Marius Cristian (@eseanucristian) | Sep 2015 - Sep 2015 |
| 6. | Bogdan Chifor | Aug 2015 - Aug 2015 |
| 7. | Ionut Ionita (@ionutrazvanionita) | Mar 2015 - Apr 2015 |
| 8. | Vlad Paiu (@vladpaiu) | Mar 2015 - Mar 2015 |
(1) including any documentation-related commits, excluding merge commits
Last edited by: Bogdan-Andrei Iancu (@bogdan-iancu), Liviu Chircu (@liviuchircu), Razvan Crainea (@razvancrainea), Eseanu Marius Cristian (@eseanucristian), Vlad Paiu (@vladpaiu), Ionut Ionita (@ionutrazvanionita).
doc copyrights:
Copyright © 2015 www.opensips-solutions.com
Copyright © 2013 Secusmart GmbH
Copyright © 2006 enum.at
Copyright © 2005 Voice Sistem SRL
Copyright © 2005 Cesc Santasusana