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.
General setup info
|SIP registrar (also for SIP proxy/outbound) Server address (FQDN)||proxy.dus.net||proxy3.dus.net||proxyV6.dus.net|
|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)||secure.dus.net||–||secureV6.dus.net|
|SIP registrar/outbound proxy TLS+SRTP server port||5061||–||5061|
|STUN server address (FQDN)||stun.dus.net||stun.dus.net||–|
|STUN Server port||3478||3478||–|
|STUN server port alternative||10000||10000||–|
|Other information you can enter only if you know what you are changing|
|NTP server (time server, FQDN)||ntp.dus.net||ntp.dus.net|
|Server service||Server IPv4||Server IPv6||Protocol||Ports from-to|
|RTP Media Relay||188.8.131.52||2a04:2100:0:300::/56||UDP||10000-65535|
|RTP Media Relay||184.108.40.206||2a04:2100:0:300::/56||UDP||10000-65535|
|RTP Media Relay||220.127.116.11||2a04:2100:0:300::/56||UDP||10000-65535|
|RTP Media Relay||18.104.22.168||2a04:2100:0:300::/56||UDP||10000-65535|
|RTP Media Relay||22.214.171.124||2a04:2100:0:300::/56||UDP||10000-65535|
|RTP Media Relay||126.96.36.199||2a04:2100:0:300::/56||UDP||10000-65535|
|RTP Media Relay||188.8.131.52||2a04:2100:0:300::/56||UDP||10000-65535|
Special numbers for dus.net 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
|*02||Credit announcement in EUR/Cent|
|*10||Call number transmission 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|
You can order a simple wake-up call by using the key codes from the table below.
|*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|
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. dus.net 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 dus.net.
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 dus.net GmbH enables SRTP in combination with TLS. We offer you a way to encrypt your telephony completely.