Course12:Advanced - SIP Provider: Difference between revisions
m (Protected "Course12:Advanced - SIP Provider" [edit=sysop:move=sysop]) |
|
(No difference)
|
Revision as of 12:31, 2 March 2016
This book will describe what a SIP provider is and the issues to keep in mind when connecting using an innovaphone PBX.
Overview
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 ) to the SIP Interfaces chapter in
SIP Profiles
The innovaphone SBC (that is, the SIP interfaces) therefore offer 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 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 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 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 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
- never vice versa (we ignore the rare conditions where a SIP provider is used in non-registered fashion)!
SIP Trunk security is by the SBC function that is part of the SIP interfaces.
- 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
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
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
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
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
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
Let's discuss some typical scenarios.
SBC in 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
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 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
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
Attaching the PBX directly to the internet is dangerous and thus not recommended.
Diagnostics & Troubleshooting
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.
- 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
P: Call is terminated when the other end answers the call. (SIP Error 415)
P: SIP Trunk doesn't register or all calls are rejected. (SIP Error 407/603)
P: Bad audio quality on SIP calls. (RTP packet lost events)
P: Call is established but no voice or only one way voice.
P: After performing a blind transfer the call is disconnected. (SIP Error 405/406)
Migration from ISDN
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
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.