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

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 1500 bytes. However, this size is further reduced by additional and further logical information to a usable size of about 1300 bytes. If such a package is sent, it contains both the sender’s and the recipient’s address. Unfortunately, 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. An “INVITE” (call from A to B) is followed in this case by a “TRYING”, then a “PROGRESS” and so on. If an acknowledgement is missing, the last package is sent again at intervals according to defined timers until an acknowledgement 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 recipient already knows that it is coming. There are 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 for decades. SSL stands for “Secure Socket Layer”, but doesn’t say much at first. 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.

SRTP is different in nature and comes in many different flavors.
stands for “Secure Real Time Protocol” which means that the voice data is encrypted. This key matching is done in plain text via an SDP header of the SIP protocol, if no other mechanisms like(MIKEY, etc.) are used. Even if a secure key exchange is guaranteed with SRTP, this is only half the communication that is secure. Your phone numbers i.e. your CLIP and the number of the called party are transmitted unencrypted. Thus, a potential attacker does not know what, but at least with whom you have spoken.

The consequence that an RTP stream that is to be encrypted exchanges the key exchange between the two endpoints in clear text is thus straightforward. This allows the RTP stream to be decrypted again at any time and relatively easily. You only need the master key and the two session keys.

The conclusion is that a SIP session secured with TLS/SSL (the signaling of a telephone call) is only capable of enabling SRTP that is secure in every respect. This is because access to the crypto keys for SRTP located in the SDP part of the SIP session are no longer readily visible.

This is the reason why GmbH enables SRTP in combination with TLS. We offer you a way to encrypt your telephony completely.