Course12:Advanced - SIP Provider

From innovaphone wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
There are also other versions of this article available: Course11 | Course10 | Course12 (this version)

This book will describe what a SIP provider is and the issues to keep in mind when connecting using an innovaphone PBX.

Overview

Nowadays, PSTN access technology is moving more and more from TDM based solutions such as ISDN to IP-based solutions such as SIP trunks.

Generally, SIP trunks offer much the same functionality like ISDN trunks (and more than analogue trunks as they support richer signalling options). Also, in an innovaphone PBX system, they are configured very similar. Please refer (that is: read now wink) to the SIP Interfaces chapter in Gateway Interfaces.


SIP Profiles

Unfortunately, SIP trunk standardization is still in its early phase. As a result, there are a lot of minor and less minor kludges and pitfalls when it comes to interfacing to a SIP provider.

The innovaphone SBC (that is, the SIP interfaces) therefore offer screenshot.png various SIP tweaks options that need to be set correctly. In fact, it offers even a lot more, which are available through the Advanced text-field.

Unfortunately, there is little to no chance to select the proper options based on the documentation you get from the provider. To help here, SIP provider profiles are available. These are configuration forms specifically tailored for a single SIP provider. When you select the proper profile for the provider you are going to use, you only need to fill in the data specific for your account. All other configuration is done under the hood.

You will find the current screenshot.png list of supported providers on the lower end of the Gateway/SIP page. Selecting one opens the provider specific settings. When you save the form, a SIPx interface and its respective routes will be configured based on the magic wisdom implemented in the profile and the SIP interface will screenshot.png show the name of its profile.

If you are curious, you can always look in to the generic SIPx configuration form to see what the profile did. However, you can not change anything here (as it would probably conflict with the profile).

Changing a SIP Profile Entry into a generic SIPx Entry


If you want to change the configuration created by the profile, you can unlink the SIPx interface from the profile. You can do so by screenshot.png clicking on the Expert button in the profile form.

Note though that this will turn the entry in to a generic entry and the profile is no longer available to configure it. Of course you can simply delete and recreate it again using the profile.

Updating SIP Profile settings



SIP provider profiles create a particular configuration once you save the it from the profile's configuration dialogue. They do not change "under the hood", even if you install a new firmware that may include updated settings. To apply such updated settings, you need to open the provider's configuration dialogue and apply it using the OK button.

The SIP profile creates also automatically routing-table entries from and to the respective SIP-interface. An update of the SIP-profile by the OK button, will therefore also recreate these routing entries. As a result, modifications (e.g. CDPN-maps) of the profile-created-routes must be redone after updating the profile. To circumvent this problem, it is recommended to not modify the routes created by the profile but create additional routes for the own modifications.

SIP Provider Tests

SIP provider do differ substantially in terms of features and functions. This is why innovaphone performs a lot of SIP trunk testing. The results can be found in our wiki, see fish-help.png 3rdParty SIP Provider in our wiki.

SIP providers which have been tested February 2016 or later are usually also part of the nightly testing program. In this program, automated tests are executed on a regular basis to make sure the findings of the initial tests are still valid.

Security


Registration to a SIP provider is screenshot.png always initiated by the PBX

- never vice versa (we ignore the rare conditions where a SIP provider is used in non-registered fashion)!

All external calls are made in the context of this registration.

For the NAT router/firewall, the PBX registration to the provider is an outgoing UDP or TCP/TLS connection (depending on the SIP flavour used) and handled like any other outgoing connection (e.g. web site access). This also true for incoming calls!

SIP Trunk security is by the SBC function that is part of the SIP interfaces.

Often, there are discussions to secure such connections by a device called session border controller (SBC). The functions found in an SBC are implemented in the innovaphone SIP interfaces. which we therefore often refer to as "SBC" too:
  • Security Offloading:
    Functions such as e.g. internal encryption, but not towards the provider.

  • Media Pinholing:
    Transmission and reception of audio data through the NAT router and the firewall by use of mechanisms like ICE and STUN.

  • Transcoding:
    Negotiation and adaption of internal and external used different audio coders.
    As this causes unacceptable delay on speech (a.k.a. Jitter) we intentionally do not support this

  • Protocol translation:
    adaptation to different SIP protocol flavours

  • Header Manipulation:
    Adaption of required SIP-headers and called/calling party numbers

  • Media Anchoring:
    This is media forwarding to the correct internal endpoints.
    Known as Media Relay in innovaphone devices

Media Relay

The term Media Relay refers to a function built-in to the innovaphone SBC in the SIP interface where media data sent to and received from the SIP provider is always relayed through the innovaphone box running the SIP interface.

Without media relay, all media data (RTP) would flow directly from the endpoints (e.g. phones) to the SIP provider:




When media relay is enabled in the SIP interface however, all media would flow through the device running the SIP interface:




This of course impose network traffic- and CPU-load on the device doing media relay. So why is it useful nonetheless?

Fixing Media Switching Issues


With no media relay, if a call is transferred for example, the SIP provider needs to handle the situation where the remote media endpoint changes. A SIP provider should be able to handle this, but not all are. In this case, media relay helps, as the SIP provider does not see any change in the media endpoint

Fixing Encryption Issues


Many SIP providers do not support media encryption. If a customer has a security policy that mandates internal calls to be encrypted, media relay helps. The media data exchanged on the local end of the media stream (between the phone and the device doing the media relay) would be encrypted then, the media data flowing on the remote end (to/from the SIP provider) would be un-encrypted.

You could ask: isn't it useless to have the local part encrypted while the external part is un-encrypted anyway? Unfortunately, many SIP providers have issues when a caller tries to negotiate encryption and fail to turn it off during call setup. This often leads to calls with missing audio. Also, some devices mandate the use of encryption. WebRTC for examples enforces use of encryption (even a quite sophisticated form of encryption known as DTLS). In this case, no calls between the SIP trunk and such device is possible. Again, media relay helps.

Fixing DTMF Signalling Issues


Some functions in the PBX require DTMF signalling to work. Most prominently, the mobility functions (as discussed in Mobility) require the PBX to know all the DTMF tones sent by the mobile device.

Unfortunately, there are 2 types of DTMF handling
  • RTP DTMF
    In this case, the DTMF information is sent as a special media type as part of the media stream
  • SIP-INFO DTMF
    In this case, the DTMF information is sent using special headers as part of the SIP signalling

The innovaphone PBX does support both methods. However, if you take a look at the first picture on this page you will notice that in case of RTP DTMF the DTMF information can not be seen by the PBX (as the RTP - being part of the media stream - is never seen by the PBX). Unfortunately, you guessed it, most SIP providers do not support SIP-INFO DTMF. Again, media relay fixes the issue.

Fixing Firewall Issues


Firewall misconfiguration is one of the most popular reasons for "no media calls". The reason usually is that configuring the firewall to securely let all RTP traffic for all possible call destinations flow is difficult, to say the least.

Media relay helps, as when used, the media data is exchanged between two defined point only: the SIP provider and the device running media relay. This is obviously a much simpler setup to configure in a firewall.

STUN

Most SIP providers use NAT detection to guess the IP address and port they need to send media data to. In this case, media data (RTP) exchange magically works. However, some providers don't. In this case, it may be necessary to use STUN (and possibly media relay).

Fortunately, during our provider tests we find out if or if not your provider needs STUN. So if you use the respective SIP profile for this provider, it will just work.

To learn more about STUN and the related protocols, have a look at Reverse Proxy.

Please note that most if not all SIP providers do not support or use ICE or TURN (this is just if you have read about this in the Reverse Proxy book and ask yourself it is relevant to SIP provides). Then again, SIP provider don't need it anyway (as they always provide a public IP address).

QoS

When deciding to use a SIP provider you must also think about the available bandwidth of the used link to your Internet provider. You will need about 80 kbps in both directions (i.e. upstream and downstream) for a standard conversation using the G.711 codec. In case that you experience bandwidth problems you should consider using the codec G.729. This codec has a lower voice quality but only requires about an eighth as much bandwidth as G.711.

The best codec to use would be OPUS-NB, as it has the same quality as G.711 but requires the same bandwidth as G.729 only. However, we have not yet seen any provide that does support it.

Keep in mind that your Internet link is also used for other purposes (web surfing, email, file uploads) so you might want to prioritize the VoIP traffic in your network. innovaphone devices can mark IP traffic for prioritization using two methods, by using the Type of Service field of the IP - header or by using VLAN priority tagging.

Internet Access Scenarios

There are a number of internet access scenario out there in the field and they have some influence on how to set up the SIP-Interfaces.

Let's discuss some typical scenarios.

SBC in DMZ

Two routers (at least one of them performing NAT and potentially also including firewalls) are located in a Demilitarized Zone (DMZ):




The idea with a DMZ is that no traffic can be routed directly from the internet to the company LAN. Instead, all traffic is relayed only by a trusted entity in the DMZ in a (hopefully) controlled fashion.

You implement this by installing an innovaphone gateway platform (an IPVA or IP0011 would suit well) in the DMZ. Signalling traffic to a SIP provider is handled by the SBC (SIP-IFs) and RTP is handled by the SBC when media-relay is enabled for the SIP-interface.



SBC on Router

In many cases however, the customer does not have a DMZ. In this case, you would use a very similar approach: you install an innovaphone gateway platform like before in the DMZ. The difference would be that it also does the NAT Router job.




Please note that for the PBX and its related services, no NAT is required in this scenario as all traffic is relayed by the innovaphone box! However, in real life, you would still need to enable NAT on the box, as the customer will certainly want to use other services (such as e.g. outgoing web access) that require NAT.

SBC internally

In many cases, the internet access infrastructure is already set and cannot be changed. In this case, an existing NAT router will be used.

In this case, you would use a slightly different approach: you install an innovaphone gateway platform in the customer's LAN.




This configuration is recommended when you need to support a high number of concurrent SIP trunk calls with media relay. The load imposed by the media-relay function is then moved away from the PBX, allowing you to safely support a higher number of extensions.

SBC internally with PBX

It is also possible to modify the previous scenario such that the PBX runs on the same box.




This is in fact the most popular configuration as it creates small and simple setups. However, you need to keep in mind that media-relay does consume network- and CPU-load. Running an SBC with media relay on the same box the PBX runs on limits the number of extensions you can safely support on this box.

No-Nos

Just to clarify this:

You must not expose your PBX to the internet directly!




Attaching the PBX directly to the internet is dangerous and thus not recommended.

Diagnostics & Troubleshooting

The SIP trunk between innovaphone and other devices or SIP providers does not always work 100% at the first attempt. As a result, we should learn SIP signalling basics and also which diagnostics tools we could use in this case.

Usual Problems:
  • Media negotiation problems that could result in call failure.
  • SIP interoperability problems that could result in call failure.
  • No voice or one way voice due to problems of NAT or networking.
  • Calling Number Presentation problems because of a misformatted SIP header.
  • Bad voice quality as a result of RTP packet loss.
  • Unsupported SIP features/RFCs.
Diagnostics Tools:
  • Alarms/Events of the Gateway show informations like registration down, Packet loss, NAT issues. More information is found in the Operations Book
  • Remote Pcap of the Gateway. With wireshark we can analyse the full flow of the call and check the SIP signalling error messages when we have problems. List of SIP Response codes

Basic Examples:

P: Overlap dialling not working. Busy Signal.

S: When performing overlap dialling the PBX sends each digit immediately to the SIP provider. If the other end replies with SIP 404 Not found and terminates the call with a busy signal, it means that the SIP Provider doesn't support Overlap dialling (RFC 3578). We should always check if both SIP devices support the RFC/feature that we are testing, a list of innovaphone's supported SIP features can be found at fish-help.png Supported SIP Features and List of RFC's. To solve this problem, enable the option Force enblock in the outgoing route to the SIP provider.


P: Call is terminated when the other end answers the call. (SIP Error 415)

S: A call failure can have multiple/different causes, that's why checking the SIP Signalling in the pcap trace is important. In this case the SIP error message is 415 Unsupported Media Type. This happens when the communicating endpoints can't find a common codec or if a multiple offer of codecs it's not supported by one of the endpoints. To solve this problem, check what the supported codecs by the other end and configure the supported codec in the SIP trunk as exclusive coder. Also enable media-relay for this SIP trunk.

P: SIP Trunk doesn't register or all calls are rejected. (SIP Error 407/603)

S: Usually this is because of wrong login credentials (SIP 407) or because of an invalid SIP Invite message(wrong placement of username/number) (SIP 603). To solve this problem, double-check the credentials given by the SIP provider and if you are registering to the right device/address. Also you can use the fish-help.png SIP Interop Tweaks "From Header when Sending INVITE" at a GW/SIP-interface to change the way/mode the credentials are sent to the provider.

P: Bad audio quality on SIP calls. (RTP packet lost events)

S: If the fish-help.png Events - list contains many fish-help.png 0x00050002-RTP-Excessive loss of data entries, you should check your network for connectivity problems. Since there are many causes for this type of errors, there is also a wide-spread amount of solutions. You could check/measure the bandwidth available for VoIP calls, use smaller codec like G729 to use less bandwidth and limit the number of outgoing simultaneous calls to guarantee quality. Also you should implement QoS options in the network to give priority to voice traffic.

P: Call is established but no voice or only one way voice.

S: In a SIP call both ends exchange the RTP endpoint, so our IP phone will deliver his internal IP as RTP address to the SIP provider. Some SIP providers have NAT detection mechanisms that handle this call scenarios perfectly but others do not. In that case some extra configuration is necessary to solve this. You have to enable STUN at the SIP trunk and enable the media-relay flag at the interface.

P: After performing a blind transfer the call is disconnected. (SIP Error 405/406)

S: Innovaphone uses fish-help.png reverse media negotiation (late offer/answer) for call transfer. Even though this is a standard procedure(RFC 3261), some SIP proxies don't accept this mechanism/method. To solve this problem, media-relay and a exclusive codec must be configured at the SIP-interface.


Migration from ISDN

When migrating from a PSTN line based on ISDN to one based on SIP, several issues must be thought through.

Fax


When using an innovaphone Faxserver to fax over an innovaphone ISDN-interface, T.38 can be used. As a result, no DSPs (more specific the AudioFax feature of the Fax-interface) are needed.

When a SIP-interface is used instead of ISDN, it is not known if the remote endpoint supports T.38. Often SIP-providers support T.38, however most of them don't do T.38 transcoding. So if the remote endpoint (e.g. fax-device at another SIP-provider customer) doesn't support T.38, Audio FAX (i.e. fax over G.711a/u) must be used. As a result, you will need to make sure there are enough DSPs (2 per call) for your innovaphone Fax-interface available.

For more information on the Fax interface, have a look at the Faxserver.

Modem


Analogue or ISDN modem calls over a SIP-provider will not work in most cases, because of the added delay and jitter of the WAN-connection to the SIP-provider.
Therefore it is recommended to keep some of the ISDN-lines to connect the modems at the customer site.

CLIR/Clip No Screening


Here it depends on your SIP-provider if it is supported or not, often you will have to order the feature separately for your SIP-trunk. If there is a wiki-testreport for this provider, you can check beforehand if the feature is supported by this specific provider.

Path Replacement (Partial Rerouting)


In SIP terms and in the wiki-testreports this is called Redirection using "302 Moved Temporary". Again you can ask your SIP-provider to activate this feature, if supported.
In ISDN, Partial Replacement will help preserve free ISDN channels on your BRI-interface. In SIP, it will help save bandwidth - but only in case you are doing MediaRelay.