AdminGuide:Service:SIPSettings/en
Return to AdminGuide:Service
Description
The SIP settings panel contains the specification of telephone engine settings. The SIP protocol governs the communication between the exchange and the telephones and between the exchange and other gateways.
Configuration
The panel can be reached from the menu "PBX > SIP settings". In the case of a multitenant system, the panel is used by the PBX admin because even in a multitenant node, the SIP stack running on the machine is unique and shares settings among all tenants. The tenants, however, can independently perform the configuration of their own extensions/groups/queues/accounts.
- Enable pedantic check of SIP messages: this causes a stricter check of the formal correctness of SIP messages sent to the pbx to be carried out, and if this legal check indicates malformations within the SIP packet, it discards it.
This is a security measure to prevent malformed SIP packets from arriving at the exchange, creating malfunctions or attacks on the machine itself. In cases where one interfaces with providers (gateways, telephones) that create SIP messages that are not formatted entirely correctly, it may be helpful to disable the flag. In this case, message parsing is relaxed and made acceptable.
- DTMF mode: tones that can be sent during a telephone call to send commands or information to the other party. There are three modes provided in the SIP standard by which DTMFs sent by the other party or sent to the other party can be sent and acknowledged.
- RFC 2833: can be considered side-by-side with 4733, which recalls and extends 2833.
This mode provides that DTMF tones are sent as RTP event packets within the RTP stream of a call. DTMF tones take the same path as the audio stream, but are not sent as tones, but as RTP event packets. These RTP event messages are sent by sending an initial packet (beginning of the tone). Then, with periodicity typical of VoIP, another packet is sent that lengthens the duration of the tone. These RTP event' messages contain the number of keys pressed and the symbols *#.
Example:
The DTMF tone sent in RFC 2833 mode by the 10.0.20.100 central unit to the PBX can be displayed:
This incoming RTP is passed back from the pbx to the interlocutor.
The audio packet is sent to a stream that has a source and destination port that contains the RTP stream. When the station sends a DTMF in RTP event mode within the same stream, the port extremes do not change (the same as in the audio packet), but the payload type changes.
In the second case the payload type is 101 because the RTP event changes the payload type. Kalliope uses 101 by default for sending DTMFs.
The payload becomes explicit information of the key is pressed, the volume, and duration in samples.
UDP, in the case of a PBX with more than one network interface, causes VoIP service to be activated on all the interfaces in the PBX. A second network interface can be added, or VLAN tags can be added.
.png)
The duration is useful because if the central unit has to convert this DTMF, when sending it to the interlocutor in a format other than RFC 233, it should play it back for a corresponding duration. The setting in this panel applies to all SIP accounts defined in the "Internal and Accounts" panel and is used as the default setting for all incoming and outgoing lines.
Unlike accounts, in the panel, there is no ability to go and change DTMFs: when you send a DTMF to an account, you send it with SIP settings, and the same occurs when a SIP account sends a DTMF. Instead, you can change the DTMF mode in the Inbound lines panel or leave it as default.
This mode is often referred to as AVB (Attribute Value Pair) on other equipment.
- SIP INFO: is a mode that does not send RTP or RTP event messages, but an info type SIP message. The info is a type of SIP message that contains a payload containing the key and duration, is transmitted only once, and has a network path that follows that of the SIP signaling which is different from the path that the RTP flow takes.
- In-band: typed DTMF tones are sent as audio tones within the RTP stream.
If you analyze the tracks containing DTMF tones, you can find RTP only. So you cannot distinguish whether they are tones or not. The problem with DTMF transmission under audio tones is that if codecs other than G.711 are used, they introduce compression into the audio and distortion of the tones. While a conversation is understandable, recognition of these tones may fail.
Thus, the use of in-band DTMF mode is discouraged because if the RTP stream suffers degradation due to losses or congestion, the tones, even using G.711 are distorted and may not be recognized. Thus, the use of DTMF in audio is recommended only in conjunction with a compressed PCM a-low or PCM u-low codec, but it may still be error-prone.
The most commonly used mode is RFC 2833.
The following two fields are attributes that impact both SIP accounts and input and output lines; as in the case of DTMF mode, the next two are also modifiable from the default value in the input and output lines.
- Enable RPID (Remote Party ID) acceptance: enables COLP acceptance (named thus in the inbound and outbound lines).
Enabling causes it to extract the caller's identity from the FROM it sends and the PAI, RPID, etc. headers. This is a SIP header that carries additional information that identifies the caller. During a call, there are instances when the identifier of the person being talked to may change over time. The COLP feature causes the exchange to notify that the caller has changed; there are some cases where it is necessary to provide this information to the caller, and others where it is not. This flag causes it to accept from telephones connected to the exchange, the caller ID present in the RPID or PAI (P-Asserted-Identity) header.
N.B. At the output level, it is recommended that the entry be disabled since you do not want the pbx to change the identifier of the connected line.
- Send rpid mode: Send COLP mode (named so in the input and output lines).
It has three options: disabled / remote party ID / P-Asserted-Identity. In this case, the setting that is used for telephones and that is recommended is sending PAI. This flag causes the pbx to warn that the interlocutor being communicated with has changed, it sends a message that updates the information via the PAI header. The interlocutor change information is useful toward telephones, but generally, on an outgoing line it should be disabled.
N.B. If you go to make a trunk to another exchange where you configure remote extensions, in this case the line is not an outgoing trunk to an operator, but it is the interconnection to another exchange on which it is helpful to activate the COLP update mode.
The following three fields set the quality-of-service parameters for the service leaving the exchange. There are TOS hexadecimal values and priority codes in the network to decide which packets to make travel with priority over others in case of congestion. Thus, it ensures that audio and video streams receive priority over sending the mail.
- TOS SIP
- TOS Audio
- TOS Video
These values can be changed if the network in which the control panel is operating requires that different TOS values be used for audio, signaling, and/or video.
- Enable Video: to globally enable support for video calls.
- Maximum bitrate for video calls: attribute that applies only to video calls and determines the maximum bitrate that the exchange accepts and offers for video calls, by default it is 384 Kbps so as not to take up too much bandwidth. Often values can be raised to increase quality.
- Enable RTP encryption support (SRTP): enables at the pbx level the ability to allow encryption of RTP streams that generally travel in the clear (anyone who can intercept the RTP stream of the call can listen to its contents).
SRPT is a protocol that relies on the prior exchange of keys between the caller and called party; the flow is encrypted with a symmetric key cipher. The key is exchanged during call setup, and if a secure signaling transport protocol such as TLS is not used and TCP or UDP is used instead, it can be read in the cleartext on the SIP message. Enabling SRPT makes sense if coupled with a secure signaling protocol such as TLS.
'WARNING: Enabling SRTP in the SIP settings does not automatically enable the actual use of SRTP, but it does allow the module from SRPT support. You need to enable it in the Extensions and Accounts panel. Here, there is a checkmark "Enable SRPT": this way it can be inherited by all accounts that use that particular template.
The following two fields are not necessary to configure, except when you want to expose the service via WebRtc (via Web Socket) and specify a STUN server to acquire the information needed to shut down signaling properly and media.
N.B. STUN is a protocol used to distribute the public IP information a client uses behind a NAT. It is used by rtc (web phone) web clients to ensure that the central station knows what IP address to send media streams. It goes hand in hand with enabling transport (protocol for SIP signaling) via Web Socket. Once Secure Web Socket is allowed, there is a need to specify a STUN server, which the central office uses to learn which ports it will use for signaling and media.
- STUN server address
- STUN server mail
NAT Helper
This section is especially important for making the station available in access from the public.
- External host: public IP address.
- External host update period (sec.)
- External UDP port
- External TCP port
- External TLS port
- Local networks
All messages sent to networks marked as local use their private address as routed, while what is outside local networks uses the IP address you specify in the external host.
Predefined video codecs
To enable video call support, check the above "Enable video" box and select which video codecs are supported by the central unit.
Codec audio
Also, for audio, you can select which codecs are supported by the power plants.