/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 1999 - 2006, Digium, Inc.
*
* Mark Spencer <markster@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*!
* \file
* \brief Implementation of Session Initiation Protocol
*
* \author Mark Spencer <markster@digium.com>
*
* See Also:
* \arg \ref AstCREDITS
*
* Implementation of RFC 3261 - without S/MIME, and experimental TCP and TLS support
* Configuration file \link Config_sip sip.conf \endlink
*
* ********** IMPORTANT *
* \note TCP/TLS support is EXPERIMENTAL and WILL CHANGE. This applies to configuration
* settings, dialplan commands and dialplans apps/functions
* See \ref sip_tcp_tls
*
*
* ******** General TODO:s
* \todo Better support of forking
* \todo VIA branch tag transaction checking
* \todo Transaction support
*
* ******** Wishlist: Improvements
* - Support of SIP domains for devices, so that we match on username@domain in the From: header
* - Connect registrations with a specific device on the incoming call. It's not done
* automatically in Asterisk
*
* \ingroup channel_drivers
*
* \par Overview of the handling of SIP sessions
* The SIP channel handles several types of SIP sessions, or dialogs,
* not all of them being "telephone calls".
* - Incoming calls that will be sent to the PBX core
* - Outgoing calls, generated by the PBX
* - SIP subscriptions and notifications of states and voicemail messages
* - SIP registrations, both inbound and outbound
* - SIP peer management (peerpoke, OPTIONS)
* - SIP text messages
*
* In the SIP channel, there's a list of active SIP dialogs, which includes
* all of these when they are active. "sip show channels" in the CLI will
* show most of these, excluding subscriptions which are shown by
* "sip show subscriptions"
*
* \par incoming packets
* Incoming packets are received in the monitoring thread, then handled by
* sipsock_read() for udp only. In tcp, packets are read by the tcp_helper thread.
* sipsock_read() function parses the packet and matches an existing
* dialog or starts a new SIP dialog.
*
* sipsock_read sends the packet to handle_incoming(), that parses a bit more.
* If it is a response to an outbound request, the packet is sent to handle_response().
* If it is a request, handle_incoming() sends it to one of a list of functions
* depending on the request type - INVITE, OPTIONS, REFER, BYE, CANCEL etc
* sipsock_read locks the ast_channel if it exists (an active call) and
* unlocks it after we have processed the SIP message.
*
* A new INVITE is sent to handle_request_invite(), that will end up
* starting a new channel in the PBX, the new channel after that executing
* in a separate channel thread. This is an incoming "call".
* When the call is answered, either by a bridged channel or the PBX itself
* the sip_answer() function is called.
*
* The actual media - Video or Audio - is mostly handled by the RTP subsystem
* in rtp.c
*
* \par Outbound calls
* Outbound calls are set up by the PBX through the sip_request_call()
* function. After that, they are activated by sip_call().
*
* \par Hanging up
* The PBX issues a hangup on both incoming and outgoing calls through
* the sip_hangup() function
*/
/*!
* \page sip_tcp_tls SIP TCP and TLS support
*
* \par tcpfixes TCP implementation changes needed
* \todo Fix TCP/TLS handling in dialplan, SRV records, transfers and much more
* \todo Save TCP/TLS sessions in registry
* If someone registers a SIPS uri, this forces us to set up a TLS connection back.
* \todo Add TCP/TLS information to function SIPPEER and SIPCHANINFO
* \todo If tcpenable=yes, we must open a TCP socket on the same address as the IP for UDP.
* The tcpbindaddr config option should only be used to open ADDITIONAL ports
* So we should propably go back to
* bindaddr= the default address to bind to. If tcpenable=yes, then bind this to both udp and TCP
* if tlsenable=yes, open TLS port (provided we also have cert)
* tcpbindaddr = extra address for additional TCP connections
* tlsbindaddr = extra address for additional TCP/TLS connections
* udpbindaddr = extra address for additional UDP connections
* These three options should take multiple IP/port pairs
* Note: Since opening additional listen sockets is a *new* feature we do not have today
* the XXXbindaddr options needs to be disabled until we have support for it
*
* \todo re-evaluate the transport= setting in sip.conf. This is right now not well
* thought of. If a device in sip.conf contacts us via TCP, we should not switch transport,
* even if udp is the configured first transport.
*
* \todo Be prepared for one outbound and another incoming socket per pvt. This applies
* specially to communication with other peers (proxies).
* \todo We need to test TCP sessions with SIP proxies and in regards
* to the SIP outbound specs.
* \todo ;transport=tls was deprecated in RFC3261 and should not be used at all. See section 26.2.2.
*
* \todo If the message is smaller than the given Content-length, the request should get a 400 Bad request
* message. If it's a response, it should be dropped. (RFC 3261, Section 18.3)
* \todo Since we have had multidomain support in Asterisk for quite a while, we need to support
* multiple domains in our TLS implementation, meaning one socket and one cert per domain
* \todo Selection of transport for a request needs to be done after we've parsed all route headers,
* also considering outbound proxy options.
* First request: Outboundproxy, routes, (reg contact or URI. If URI doesn't have port: DNS naptr, srv, AAA)
* Intermediate requests: Outboundproxy(only when forced), routes, contact/uri
* DNS naptr support is crucial. A SIP uri might lead to a TLS connection.
* Also note that due to outbound proxy settings, a SIPS uri might have to be sent on UDP (not to recommend though)
* \todo Default transports are set to UDP, which cause the wrong behaviour when contacting remote
* devices directly from the dialplan. UDP is only a fallback if no other method works,
* in order to be compatible with RFC2543 (SIP/1.0) devices. For transactions that exceed the
* MTU (like INIVTE with video, audio and RTT) TCP should be preferred.
*
* When dialling unconfigured peers (with no port number) or devices in external domains
* NAPTR records MUST be consulted to find configured transport. If they are not found,
* SRV records for both TCP and UDP should be checked. If there's a record for TCP, use that.
* If there's no record for TCP, then use UDP as a last resort. If there's no SRV records,
* \note this only applies if there's no outbound proxy configured for the session. If an outbound
* proxy is configured, these procedures might apply for locating the proxy and determining
* the transport to use for communication with the proxy.
* \par Other bugs to fix ----
* __set_address_from_contact(const char *fullcontact, struct sockaddr_in *sin, int tcp)
* - sets TLS port as default for all TCP connections, unless other port is given in contact.
* parse_register_contact(struct sip_pvt *pvt, struct sip_peer *peer, struct sip_request *req)
* - assumes that the contact the UA registers is using the same transport as the REGISTER request, which is
* a bad guess.
* - Does not save any information about TCP/TLS connected devices, which is a severe BUG, as discussed on the mailing list.
* get_destination(struct sip_pvt *p, struct sip_request *oreq)
* - Doesn't store the information that we got an incoming SIPS request in the channel, so that
* we can require a secure signalling path OUT of Asterisk (on SIP or IAX2). Possibly, the call should
* fail on in-secure signalling paths if there's no override in our configuration. At least, provide a
* channel variable in the dialplan.
* get_refer_info(struct sip_pvt *transferer, struct sip_request *outgoing_req)
* - As above, if we have a SIPS: uri in the refer-to header
* - Does not check transport in refer_to uri.
*/
/*** MODULEINFO
<depend>chan_local</depend>
***/
/*! \page sip_session_timers SIP Session Timers in Asterisk Chan_sip
The SIP Session-Timers is an extension of the SIP protocol that allows end-points and proxies to
refresh a session periodically. The sessions are kept alive by sending a RE-INVITE or UPDATE
request at a negotiated interval. If a session refresh fails then all the entities that support Session-
Timers clear their internal session state. In addition, UAs generate a BYE request in order to clear
the state in the proxies and the remote UA (this is done for the benefit of SIP entities in the path
that do not support Session-Timers).
The Session-Timers can be configured on a system-wide, per-user, or per-peer basis. The peruser/
per-peer settings override the global settings. The following new parameters have been
added to the sip.conf file.
session-timers=["accept", "originate", "refuse"]
session-expires=[integer]
session-minse=[integer]
session-refresher=["uas", "uac"]
The session-timers parameter in sip.conf defines the mode of operation of SIP session-timers feature in
Asterisk. The Asterisk can be configured in one of the following three modes:
1. Accept :: In the "accept" mode, the Asterisk server honors session-timers requests
made by remote end-points. A remote end-point can request Asterisk to engage
session-timers by either sending it an INVITE request with a "Supported: timer"
header in it or by responding to Asterisk's INVITE with a 200 OK that contains
Session-Expires: header in it. In this mode, the Asterisk server does not
request session-timers from remote end-points. This is the default mode.
2. Originate :: In the "originate" mode, the Asterisk server requests the remote
end-points to activate session-timers in addition to honoring such requests
made by the remote end-pints. In order to get as much protection as possible
against hanging SIP channels due to network or end-point failures, Asterisk
resends periodic re-INVITEs even if a remote end-point does not support
the session-timers feature.
3. Refuse :: In the "refuse" mode, Asterisk acts as if it does not support session-
timers for inbound or outbound requests. If a remote end-point requests
session-timers in a dialog, then Asterisk ignores that request unless it's
noted as a requirement (Require: header), in which case the INVITE is
rejected with a 420 Bad Extension response.
*/
#include "asterisk.h"
ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
#include <ctype.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <signal.h>
#include <sys/signal.h>
#include <regex.h>
#include <time.h>
#include "asterisk/network.h"
#include "asterisk/paths.h" /* need ast_config_AST_SYSTEM_NAME */
#include "asterisk/lock.h"
#include "asterisk/channel.h"
#include "asterisk/config.h"
#include "asterisk/module.h"
#include "asterisk/pbx.h"
#include "asterisk/sched.h"
#include "asterisk/io.h"
#include "asterisk/rtp.h"
#include "asterisk/udptl.h"
#include "asterisk/acl.h"
#include "asterisk/manager.h"
#include "asterisk/callerid.h"
#include "asterisk/cli.h"
#include "asterisk/app.h"
#include "asterisk/musiconhold.h"
#include "asterisk/dsp.h"
#include "asterisk/features.h"
#include "asterisk/srv.h"
#include "asterisk/astdb.h"
#include "asterisk/causes.h"
#include "asterisk/utils.h"
#include "asterisk/file.h"
#include "asterisk/astobj.h"
/*
Uncomment the define below, if you are having refcount related memory leaks.
With this uncommented, this module will generate a file, /tmp/refs, which contains
a history of the ao2_ref() calls. To be useful, all calls to ao2_* functions should
be modified to ao2_t_* calls, and include a tag describing what is happening with
enough detail, to make pairing up a reference count increment with its corresponding decrement.
The refcounter program in utils/ can be invaluable in highlighting objects that are not
balanced, along with the complete history for that object.
In normal operation, the macros defined will throw away the tags, so they do not
affect the speed of the program at all. They can be considered to be documentation.
*/
/* #define REF_DEBUG 1 */
#include "asterisk/astobj2.h"
#include "asterisk/dnsmgr.h"
#include "asterisk/devicestate.h"
#include "asterisk/linkedlists.h"
#include "asterisk/stringfields.h"
#include "asterisk/monitor.h"
#include "asterisk/netsock.h"
#include "asterisk/localtime.h"
#include "asterisk/abstract_jb.h"
#include "asterisk/threadstorage.h"
#include "asterisk/translate.h"
#include "asterisk/ast_version.h"
#include "asterisk/event.h"
#include "asterisk/tcptls.h"
#include "asterisk/strings.h"
/*** DOCUMENTATION
<application name="SIPDtmfMode" language="en_US">
<synopsis>
Change the dtmfmode for a SIP call.
</synopsis>
<syntax>
<parameter name="mode" required="true">
<enumlist>
<enum name="inband" />
<enum name="info" />
<enum name="rfc2833" />
</enumlist>
</parameter>
</syntax>
<description>
<para>Changes the dtmfmode for a SIP call.</para>
</description>
</application>
<application name="SIPAddHeader" language="en_US">
<synopsis>
Add a SIP header to the outbound call.
</synopsis>
<syntax argsep=":">
<parameter name="Header" required="true" />
<parameter name="Content" required="true" />
</syntax>
<description>
<para>Adds a header to a SIP call placed with DIAL.</para>
<para>Remember to use the X-header if you are adding non-standard SIP
headers, like <literal>X-Asterisk-Accountcode:</literal>. Use this with care.
Adding the wrong headers may jeopardize the SIP dialog.</para>
<para>Always returns <literal>0</literal>.</para>
</description>
</application>
<application name="SIPRemoveHeader" language="en_US">
<synopsis>
Remove SIP headers previously added with SIPAddHeader
</synopsis>
<syntax>
<parameter name="Header" required="false" />
</syntax>
<description>
<para>SIPRemoveHeader() allows you to remove headers which were previously
added with SIPAddHeader(). If no parameter is supplied, all previously added
headers will be removed. If a parameter is supplied, only the matching headers
will be removed.</para>
<para>For example you have added these 2 headers:</para>
<para>SIPAddHeader(P-Asserted-Identity: sip:foo@bar);</para>
<para>SIPAddHeader(P-Preferred-Identity: sip:bar@foo);</para>
<para></para>
<para>// remove all headers</para>
<para>SIPRemoveHeader();</para>
<para>// remove all P- headers</para>
<para>SIPRemoveHeader(P-);</para>
<para>// remove only the PAI header (note the : at the end)</para>
<para>SIPRemoveHeader(P-Asserted-Identity:);</para>
<para></para>
<para>Always returns <literal>0</literal>.</para>
</description>
</application>
<function name="SIP_HEADER" language="en_US">
<synopsis>
Gets the specified SIP header.
</synopsis>
<syntax>
<parameter name="name" required="true" />
<parameter name="number">
<para>If not specified, defaults to <literal>1</literal>.</para>
</parameter>
</syntax>
<description>
<para>Since there are several headers (such as Via) which can occur multiple
times, SIP_HEADER takes an optional second argument to specify which header with
that name to retrieve. Headers start at offset <literal>1</literal>.</para>
</description>
</function>
<function name="SIPPEER" language="en_US">
<synopsis>
Gets SIP peer information.
</synopsis>
<syntax>
<parameter name="peername" required="true" />
<parameter name="item">
<enumlist>
<enum name="ip">
<para>(default) The ip address.</para>
</enum>
<enum name="port">
<para>The port number.</para>
</enum>
<enum name="mailbox">
<para>The configured mailbox.</para>
</enum>
<enum name="context">
<para>The configured context.</para>
</enum>
<enum name="expire">
<para>The epoch time of the next expire.</para>
</enum>
<enum name="dynamic">
<para>Is it dynamic? (yes/no).</para>
</enum>
<enum name="callerid_name">
<para>The configured Caller ID name.</para>
</enum>
<enum name="callerid_num">
<para>The configured Caller ID number.</para>
</enum>
<enum name="callgroup">
<para>The configured Callgroup.</para>
</enum>
<enum name="pickupgroup">
<para>The configured Pickupgroup.</para>
</enum>
<enum name="codecs">
<para>The configured codecs.</para>
</enum>
<enum name="status">
<para>Status (if qualify=yes).</para>
</enum>
<enum name="regexten">
<para>Registration extension.</para>
</enum>
<enum name="limit">
<para>Call limit (call-limit).</para>
</enum>
<enum name="busylevel">
<para>Configured call level for signalling busy.</para>
</enum>
<enum name="curcalls">
<para>Current amount of calls. Only available if call-limit is set.</para>
</enum>
<enum name="language">
<para>Default language for peer.</para>
</enum>
<enum name="accountcode">
<para>Account code for this peer.</para>
</enum>
<enum name="useragent">
<para>Current user agent id for peer.</para>
</enum>
<enum name="chanvar[name]">
<para>A channel variable configured with setvar for this peer.</para>
</enum>
<enum name="codec[x]">
<para>Preferred codec index number <replaceable>x</replaceable> (beginning with zero).</para>
</enum>
</enumlist>
</parameter>
</syntax>
<description />
</function>
<function name="SIPCHANINFO" language="en_US">
<synopsis>
Gets the specified SIP parameter from the current channel.
</synopsis>
<syntax>
<parameter name="item" required="true">
<enumlist>
<enum name="peerip">
<para>The IP address of the peer.</para>
</enum>
<enum name="recvip">
<para>The source IP address of the peer.</para>
</enum>
<enum name="from">
<para>The URI from the <literal>From:</literal> header.</para>
</enum>
<enum name="uri">
<para>The URI from the <literal>Contact:</literal> header.</para>
</enum>
<enum name="useragent">
<para>The useragent.</para>
</enum>
<enum name="peername">
<para>The name of the peer.</para>
</enum>
<enum name="t38passthrough">
<para><literal>1</literal> if T38 is offered or enabled in this channel,
otherwise <literal>0</literal>.</para>
</enum>
</enumlist>
</