SIP information & settings

Your SIP end devices are usually connected to the dus.net servers via an IPv4 address. Since IPv4 addresses have become very scarce due to the large number of modern applications, the new IPv6 protocol was introduced a few years ago. Of course, dus.net has also supported IPv6 for many, many years. So you have an unlimited choice.

However, IPv4 now exists in a large number of "different versions". This refers to how IPv4 is used differently by the respective internet providers. Many providers no longer assign public IPv4 addresses to their customers, but only internal IPv4 addresses. If a public IPv4 address is assigned, it can also be reached from outside, i.e. your end device, e.g. a FritzBox, is assigned this public IPv4 address and can therefore be reached directly from outside via this address. An internal IPv4 address, on the other hand, is not, i.e. the Internet provider connects a router between its customers and the Internet and makes several of its customers accessible under the same IP address from a public IPv4 address. However, this only works if the ports are different from each other, as this is the only way to differentiate between customers.
The problem here is that connections without a public IP address can only be reached to a limited extent. In this case, 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 you usually have to activate and/or slightly adjust yourself.

In addition to the classic IPv4 and IPv6 solutions, dus.net also offers the option of connecting 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 is not quite clear on your side how you are connected.

At dus.net, all SIP end devices (IP telephones, softphones, FritzBoxes, etc.) are connected via their own SIP connections (also called SIP accounts, extensions, sub-accounts). This means that 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 device is registered, sometimes the other and therefore never both can be reached at the same time.

This means that if you want to manage several phone numbers and make them accessible independently of each other, 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 a normal SIP connection, but is only associated with the right telecommunications systems. In contrast to conventional SIP end devices, the PBX also requires the number information of the dialed number in the incoming SIP packet in order to enable routing to the correct extension. With dus.net, this is realized via the DDI function and is automatically available to all SIP connections created in DUStel business flex.

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 the 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, despite additional and further logical information, this size is reduced or optimized to a usable size of approx. 1300 bytes. If such a package is sent, it contains both the sender and recipient addresses. Unfortunately, however, there is no feedback to the sender as to whether the package has actually reached the recipient. As a result, when using UDP, additional care must be taken to ensure and check whether a packet has actually reached the recipient. This is done 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" and so on. If there is no acknowledgement, the last parcel is sent again at intervals according to defined timers until an acknowledgement is received. If there is still no acknowledgement, the session runs into a predefined timeout and is aborted.

With SIP via TCP (Transmission Control Protocol), the transport is fundamentally different. Comparable to a "registered letter with return receipt". Due to its concept, TCP is "more robust" than UDP in many respects, but in contrast to 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 advantage of TCP is the architecture of the protocol itself. It contains built-in mechanisms to automatically recognize and resend "lost packets". A TCP connection is also established in a dedicated form. This means that before data is transmitted, the recipient 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 in comparison to UDP. It doesn't really matter which protocol is the "better" one. It must meet the requirements for you as a customer. dus.net GmbH offers you the option of using either UDP or TCP as the transmission protocol for SIP. The settings for this must be made exclusively in your respective end device. No setting is required on the part of dus.net.

Incidentally, UDP is generally used for the audio data, i.e. the actual telephone call. One of the reasons for this is the significantly lower "overhead", i.e. the large amount of user data and the less time-consuming checks. Any forwarding of packets makes less sense in a real-time application.