Should you need to set up a unit or app not covered in this knowledge base, here are explanations of various settings and potential pitfalls you may encounter. For a general overview of the tech, our friends at Comrex have published an excellent SIP primer

• Username, Auth Username or User ID, and Password are the username/password combinations you have chosen for your sip.audio accounts.
• Domain or Realm is the part of your SIP address after the '@', 'sip.audio'. If no proxy server setting is offered, you must use 'proxy.sip.audio' here to ensure the correct server is chosen. Your SIP address will still be 'username@sip.audio'. In such a scenario, 'proxy2.sip.audio' cannot be used.
• Server or Proxy is the machine you register with, it should be set to 'proxy.sip.audio'. For client side redundancy or in the unlikely case of wider outage, 'proxy2.sip.audio' can be used to register to a different server location. We use geo-location with our nameservice to always point you to a local server, so the actual IP addresses these names resolve to vary by region.
• STUN or ICE aid in NAT traversal and should be enabled if present. Among other things, they allow endpoints behind NAT to detect their public IP address. If no STUN server is offered by the manufacturer, please use 'stun.sip.audio'.
• TURN allows relaying of media streams if a direct connection cannot be established. It is similar to our 'smart' and 'pass-thru' relay features, which solve the same problem. As such, TURN is not needed and we do not offer a server for it.
• RTCP or AVPF enables quality feedback through the RTP Control Protocol, allowing the sender to adjust stream characteristics under adverse conditions. Ideally it is not needed and may pose compatibility problems with some devices. However, if it works, its use is recommended.
• Transport, or a choice between UDP, TCP and TLS is an option, which applies only to the signalling layer, not media. Since most firewalls do not support UDP fragmentation, it is possible to run into issues with packet sizes. We recommend the use of TCP to avoid this.
• Codecs and codec order define which codecs may be used and how they are prioritized. For best results, we recommend Opus to be enabled and set with the highest priority. G.722 should be included for improved compatibility. G.711, also called PCMA, PCMU, alaw or ulaw, should be present at the lowest priority to prevent transcoding of POTS calls.
• Bitrate limit or bandwidth restrict the bandwidth allowance of the media stream. Many codecs work on a fixed bitrate, but this setting is useful for Opus or AAC. While higher bitrates offer better fidelity, they can also increase the risk of congestion and lost packets on some networks, especially mobile data. For remote contributions, Opus offers good quality at 32 kbit/s already with 64 kbit/s being more than sufficient. For audio production, 128 kbit/s are recommended.
• Echo Cancellation, Rate Control, Audio Processing, Normalization, Gain Control, Noise Suppression and similar settings are intended for consumer setups, generally degrade fidelity and should not be used in a professional environment. They may provide benefits in some situations, for example when a smartphone without an external microphone is used. Test them thoroughly before using them.
• Encryption, SRTP, ZRTP or DTLS prevent eavesdropping on the stream in transit. Both endpoints need to understand the employed type of encryption, and unfortunately few pro-grade devices support this. Our 'smart' relay mode can decrypt SRTP and DTLS if an endpoint does not support it, but the second leg of the call is then no longer protected. ZRTP is by nature end-to-end encrypted and cannot be translated, so all your devices must support it and you must use sip.audio in 'pass-thru' mode or without relaying.

• If your client cannot register, double check not only username, password, and proxy address, but also the domain or realm, as it is part of the password verification process. Make sure it is all lowercase. Also, try using 'proxy.sip.audio' for the domain. 'proxy2.sip.audio' is not a valid replacement for the domain and must only be used in a separate proxy setting.
• Calls not reaching the other end can be caused by application layer gateways (ALG) or "SIP helpers" built into many routers and firewalls. Those are meant to help legacy SIP devices, which do not support modern NAT-traversal mechanisms. Unfortunately this day and age, they often do more harm than good and should be disabled.
• No or one-way audio is almost always a firewall issue, especially when NAT is involved. Make sure STUN and/or ICE is enabled and a STUN server is configured. Try using sip.audio's 'smart' or 'pass-thru' relay options. NATted endpoints rarely work without a relay. If your firewall includes application layer helpers for SIP or RTP, disable them.

If you have used a device or software not yet documented in this knowledge base, please share your findings with us.