Skip to main content

SIP Information & Settings

Below you can see basic or default settings that must be entered in each SIP device, in addition to the user information (user name and password). You can also find information about this in the customer center under the respective help. A little further down you will also find general information about TCP and encryption.

Please note that we already officially support IPv6 since 2014. This means that you no longer need any NAT or tunnel services if you have a native IPv6 connection (e.g. Deutsche Glasfaser customers) and use the corresponding FQDN’s of the servers.

The methods for determining the IP addresses of our SIP servers are DNS A Record, DNS NAPTR Record and DNS SRV Record.

What type of IP address do I have?

General setup info

IPv4 DualStack IPv6
Default settings
SIP registrar (also for SIP proxy/outbound) Server address (FQDN)
SIP registrar (also for SIP proxy/outbound) Server port 5060 5060 5060
ATTENTION! Only with encryption (must support your terminal device)
SIP registrar/outbound proxy TLS+SRTP (FQDN)
SIP registrar/outbound proxy TLS+SRTP server port 5061 5061
more settings
STUN server address (FQDN)
STUN Server port 3478 3478
STUN server port alternative 10000 10000
Other information you can enter only if you know what you are changing
DTMF Payload 101 101
NTP server (time server, FQDN)

Firewall info

Server service Server IPv4 Server IPv6 Protocol Ports from-to
SIP Registrar 2a04:2100:0:100::73 TCP+UDP+TLS 5060-5061
SIP Proxy/Outbound 2a04:2100:0:100::73 TCP+UDP+TLS 5060-5061
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535
RTP Media Relay 2a04:2100:0:300::/56 UDP 10000-65535

Service codes

Special numbers for customers are listed here.

The service codes are always valid for the SIP port from which you dial the codes. Please dial the numbers as listed, without area code or other numbers:

Internal number of the mailbox: 00038711111
External mailbox number: 0211-23706687
DTMF test module if there are problems with waiting loops: 00038799998
Echo test for playback of your audio to your phone: 00038799999

Service codes
*01 Mailbox menu
*02 Credit announcement in EUR/Cent
*10 Call number transmission on/off
*11 Mailbox on/off
*12 Charge announcement on/off
*20 Redirect on no reply on/off
*21 Turn on/off call forwarding when busy
*22 Switch on/off redirection in case of unreachable
*30 Pause queue agent
*31 Queue agent resume

Wake-up call

You can order a simple wake-up call by using the key codes from the table below.

Wake-up call
*55*HHMM# Order wake-up call HH = hours (24h format) MM=minutes
Example alarm clock at 7:30 *55*0730# The number is called 2 times in 5 minutes interval.
#55*HHMM# Cancel wake-up call HHMM previously set time e.g. 0730
*#55# Query for active wake-up calls. All active wake-up calls are announced

IPv4, IPv6, DualStack & DS-lite

The connection of your SIP end devices to the servers of is usually done via an IPv4 address. Since IPv4 addresses have become very scarce in the meantime due to the multitude of modern application possibilities, the new IPv6 protocol was launched a few years ago. Of course, has also supported IPv6 for many, many years. So you have an unrestricted choice.

However, IPv4 now exists in a large number of “different versions”. What is meant by this is how IPv4 is used differently by the respective Internet providers. Many providers no longer assign their customers a public IPv4 address, but only internal IPv4 addresses. If a public IPv4 address is assigned, it can also be reached from the outside, i.e. your end device, e.g. a FritzBox, receives this public IPv4 address and would thus be directly accessible from the outside via this address. An internal IPv4 address, on the other hand, is not, i.e. the Internet provider switches a router between its customers and the Internet here and makes several of its customers reachable under the same IP address from one public IPv4 address. However, this only works if the ports differ from each other, because only then can customers still be distinguished from each other.
The problem here is that connections without a public IP address are only accessible to a limited extent. Here, the SIP end device usually has to ensure that the connection to our SIP server is always kept open so that continuous accessibility is guaranteed. This is realized by the end devices with the so-called “Keep-Alive” function, which mainly has to be activated and/or slightly adjusted by yourself.

In addition to the classic IPv4 and IPv6 solutions, also offers the possibility to connect so-called DualStack connections. In the table at the top of this page you will find the different forms of connection. Sometimes you have to try a bit with these if it’s not quite clear on your end how you’re tethered yourself.

SIP Connections & SIP Trunks

At, all SIP end devices (IP phones, softphones, FritzBoxes, etc.) are connected via their own SIP connections (also called SIP accounts, extensions, sub-accounts). Thus, each of these end devices is connected to our server via a unique IP address and port, making it accessible to us. If two different end devices are connected with the same SIP access data, they alternate with the registration, i.e. sometimes one, sometimes the other device is registered and thus never both can be reached at the same time.

So here, if you want to manage multiple phone numbers and make them reachable independently, this must be realized via the same number of SIP connections. Accordingly, several SIP connections can also be entered in a FritzBox, for example, to ensure the use of different phone numbers independently of each other.

The SIP trunk is nothing more than an ordinary SIP connection, but it is exclusively associated with real PBXs. In contrast to conventional SIP terminals, the PBX also requires the phone number information of the dialed number in the incoming SIP packet, thus enabling routing to the correct extension. With, this is realized via the DDI function and is automatically available to all SIP connections created in DUStel business flex.

SIP over TCP and UDP

The Session Initiation Protocol(SIP) is a network protocol for establishing, controlling and terminating a communication session between two or more participants (source: Wikipedia). The signaling of SIP packets of a telephone call is usually handled via UDP (User Datagram Protocol). Data is divided into packets with a theoretical maximum size of up to 1500 bytes. However, this size is reduced or optimized to a usable size of about 1300 bytes, despite additional and further logical information. If such a package is sent, it contains both the sender’s and the recipient’s address. Unfortunately, however, there is no feedback to the sender whether the package has actually reached the recipient. As a result, when using UDP, additional care and control must be taken to ensure that a packet has actually reached the recipient. This happens in the SIP protocol by means of acknowledgement responses. In this case, an “INVITE” (call from A to B) is followed by a “TRYING”, then a “PROGRESS”, etc. . If a receipt is not received, the last package is sent again at intervals according to defined timers until a receipt is received. If this continues to fail, the session runs into a predefined timeout and is aborted.

With SIP over TCP (Transmission Control Protocol), the transport behaves fundamentally differently. Comparable to a “registered mail with return receipt”. TCP is more “robust” than UDP in many respects due to its concept, but unlike UDP it also has a certain amount of additional data (overhead) and requires more bandwidth than UDP for the same amount of user data. However, this is largely negligible in the case of SIP. The advantages of TCP is the architecture of the protocol itself. It contains built-in mechanisms to detect and resend “lost packets” autonomously. Likewise, a TCP connection is established in dedicated form. This means that before data is transmitted, the receiver already knows that it is coming. There are even more advantages of TCP, which are also easier to handle for NAT (Network Address Translation) and accordingly for firewalls than compared to UDP. Which is the “better” protocol does not really matter. It must meet the requirements for you as a customer. GmbH offers you the possibility to use either UDP or TCP as transmission protocol for SIP. The settings for this must be made exclusively in your respective terminal device. No setting is required on the part of

By the way, for the audio data, i.e. the actual phone call, UDP is generally used. The reason for this is, among other things, the significantly lower “overhead”, i.e. the large proportion of user data and the less time-intensive checks. A possible resending of packets makes rather less sense for a real-time application.

Encryption with TLS & SRTP

Anyone who fears for the security of their data transmitted on the Internet has been familiar with SSL (Secure Socket Layer) for decades. This is a certificate-based security system.

TLS stands for “Transport Layer Security”. As with SSL, any transport path (HTTP, e-mail, FTP or SIP) is secured via the TCP protocol. For telephony, this means that the packets responsible for establishing and terminating a telephone call, i.e. the SIP protocol, can be secured via TLS. However, the conversation (voice packets) itself is not encrypted with TLS (!!!). This runs over the unencrypted RTP stream by default. If the call is also to be encrypted, SRTP comes into play.

is possible in many different variants and stands for “Secure Real Time Protocol”. Only SRTP encrypts the voice data, i.e. the actual conversation. However, the key matching for the SRTP stream is normally done via the SDP header of the SIP protocol if no other mechanisms such as MIKEY are used, but this is done in plain text. Even if a secure key exchange is guaranteed with SRTP, this is still not completely sufficient, because the phone numbers, i.e. your CLIP and the number of the called party, are still transmitted unencrypted. Thus, a potential attacker does not know what you were talking about, but at least he knows who you were talking to.

In conclusion, an encrypted RTP stream in conjunction with unencrypted SIP packets increases the risk of getting hold of the master key and the two session keys that allow the SRTP stream to be decrypted.

The bottom line is that only a SIP session secured with TLS/SSL in conjunction with SRTP offers comprehensive protection, because access to the crypto keys for SRTP located in the SDP part of the SIP session are thus no longer readily visible.

Of course, GmbH therefore also offers SRTP in combination with TLS, over IPv4 and IPv6.