Course11: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 (this version) | Course10 | Course12

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

Concept

A SIP provider offers his clients access to the PSTN. In order to connect to your provider you must have a SIP capable PBX or phone.

screenshot.png SIP provider scenario



As you can see the concept is very similar to an ISDN provider. The difference is that the last mile is covered by an IP connection instead of an ISDN line.

However this minor difference, will bring up a lot of new networking questions:
  • Is the network structure in use suited for this scenario?
  • How secure are my conversations, since they are now passing through the Internet?
  • Does the Internet connection posses enough bandwidth to handle the additional VoIP traffic?

Pro & Cons of a SIP provider

Since SIP as well as SIP Trunks are a new and very hyped technology. However before reading further into this book, you should know about the advantages and disadvantages of it when using innovaphone products.

Advantage:
  • lower hardware and license costs. In comparison to a connection via ISDN to the PSTN, when using SIP you don't need ISDN interface or DSPs. So you don't need the corresponding licenses and don't have hardware limitations by your ISDN lines.
  • Fast deployment, you could subscribe a Service, obtain a SIP account and start using the service in question of minutes.
  • Expandable, since we are not limited to hardware interfaces on the device and the bandwidth offer is increasing we could obtain a SIP Trunk with large number of channels with lower costs were many times the limitation it's your Internet bandwidth.
  • Worldwide connectivity, today we can obtain a SIP account from any Provider in the Internet with lower costs and even obtain/subscribe numbers of any country and connect to our PBX.
Disadvantage:
  • more interoperability issues.
  • possible quality problems resulting from insufficient bandwidth on your Internet connection
  • SIP is still changing very quickly (is in development) in comparison to a stable protocol like ISDN.
  • Security, since we are connected to the Internet many times to obtain this services this brings more concerns about security of our SIP accounts and even our PBX service of attacks from outside. It's not any more a point-to-point ISDN connection between customer and provider.

Network considerations - SIP and NAT

A company nowadays uses a NAT router to connect to the Internet. The NAT router must convert the private IP addresses of the internal network into public routable IP - addresses known in the public network. (i.e. Internet).
A SIP message contains information on the IP - address of the communicating endpoints. As the PBX is in a private network, it will generate SIP messages containing a private IP.

screenshot.png SIP NAT



As you can see in the picture above, the NAT router successfully translated the private IP address in the IP- and UDP header (blue marking). However the SIP-message still contains private IP - addresses (red marking), which the provider will not be able to handle, since they are not routable in a public IP network.

When you want to connect to a SIP provider, you must ensure that the provider will get the correct IP - address (i.e. your public ip). There are two possible solutions for this problem:
  • STUN
  • SIP-aware NAT router

STUN

STUN is a solution for NAT traversal of UDP packets. It introduces two new components in our network infrastructure, a STUN server in the public network and a STUN client in the private network.
The STUN client allows the SIP application (i.e. PBX) in the private network to learn its public ip address mapping assigned by the NAT router.

screenshot.png STUN



Call Flow



  1. The PBX sends a STUN message to the STUN server asking for its public ip address and UDP port mapping.
  2. The STUN server answers this request by simply inserting the senders IP address and port in the response message.
  3. The PBX can now use the received STUN information to compose a SIP message containing routable public IP addresses.
  4. The PBX and the SIP server can now communicate.
Please note that the RTP stream (red colour) in the graphic above, is not passing directly between the communicating IP endpoints (i.e. phone and SIP provider). This is because the PBX knows its own public address mapping but not the public address mapping of the registered phone. The SIP messages will therefore contain the public IP address mapping of the PBX, so the RTP stream must be redirect over the PBX. The innovaphone term for this procedure is called fish-help.png media relay (or RTP proxy).


Special Requirement



In order to STUN work properly the NAT Type must be "Full-Cone-UDP-NAT". You can find more information and how to detect the NAT Type done by your router in the wiki article fish-help.png SIP media problems caused by NAT Routers

Starting with v10SR15, STUN will additionally work also for routers with restricted cone NAT and port restricted cone NAT.

Using the built-in STUN Server


If an innovaphone box is used as internet router, it can be used as STUN server. This function must be enabled in fish-help.png IP4/NAT/General by ticking the Enable STUN check-mark.

If this has been done, both STUN clients from extern (through the internet) and intern (from your own private network) can use the box as STUN server to learn their own public IP address and port map.

SIP capable NAT router

Another solution for NAT traversal is the usage of SIP-aware NAT router. This type of router is also known as application layer gateway, because it is able to interpret and manipulate application layer protocols like SIP. Because the router knows about the mappings done at IP - and port address level, it can update the private address entries in the SIP message.

screenshot.png SIP-aware NAT router




As you can see in the picture above, the RTP streams can now pass directly between the communicating endpoints. As a result media relay is not needed, which preserves valuable resources for the PBX.

Keep in mind that by using this method you will create a 3 component interoperability requirement. Not only that the innovaphone PBX must be compatible to the SIP server of the provider, but both must also be compatible with the SIP application used by the router.

Network considerations - Security

When talking about SIP trunks, you have to evaluate two security aspects:
  • Firewall
  • Encryption

Firewall



If a firewall is involved you must keep in mind that not only the SIP - traffic must pass through the firewall, but also the RTP streams. In case that the firewall is SIP-aware, then it will probably support dynamic opening of RTP ports. This is possible because the firewall interprets the incoming SIP message and open ports according to the ones mentioned in the SIP (i.e. SDP body) message. If the firewall is not SIP-aware, then you must open up a port range according to the number of possible concurrent calls.

Encryption



innovaphone PBXs are capable of encrypting both the signalling (SIP) as well as the media (RTP) information. This is done by using SIPS for signalling , respectively SRTP for media encryption.


screenshot.png security concept




The picture above represents the recommended security scenario with innovaphone. Its principles are:
  • the connection to the SIP provider is done via SIPS
  • the RTP stream to the provider is encrypted via SRTP
  • all internal phones use H.323 for maximum support of PBX features
Since the connection to the provider is passing through an insecure medium (i.e. Internet), it is best to use the maximum security/encryption available. The internal traffic uses only SRTP to encrypt the media information and by thus it prevents eavesdropping attacks. The usage of SIPS as signalling protocol is not recommended for internal conversations. The reason behind this are missing PBX features when using SIP and the cumbersome maintenance of certificates on every VoIP device (i.e. phone, gateway).

Network considerations - 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.

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.

Choosing a SIP provider

So you checked all network prerequisites and thought about the pro and cons of a SIP provider and still want to use one big grin.

Lets try to set up a step by step procedure, to select the right provider for your project.

First evaluate how many external phone numbers are needed. Company or locations with about 10 users should use a DDI capable SIP provider. The DDI feature enables companies to have fewer lines than extensions, while still having a unique number for each extension, callable from outside the company.

screenshot.png DDI



As shown in the picture above DDI alows you the usage of one SIP trunk for an unlimited amount of internal extensions. If the DDI feature is not suported by your provider, you must configure one SIP trunk for every extension. Also when deciding against DDI, you are limited to 16 SIP - trunks per innovaphone gateway. This limitation results by the maximum number of configurable "Gateway Interfaces" for an innovaphone device.

The next step would be to check the support of the T.38 protocol by your provider. This is mandatory if you plan to use fax devices on this SIP trunk. Check for G.729 codec support if you expect bandwidth problems with your Internet link.

Also have a look at fish-help.png innovaphone's SIP interoperabiliy test description, since it might give you a hint about features you expect to work with your provider.

At last have a look at the fish-help.png tested SIP providers in our wiki. It is always best to use one of the recommended providers instead of using a unknown provider. You can find a comparison table of the most recent tested SIP Providers in our wiki.

SIP Providers Features Comparison Table:

Provider

Features

Score (%)

Test Date

Country

Codecs

T.38 Fax

SIP Tweaks

CLIP No Screen

Redundancy

Silverserver G711a/u No M.Relay+Stun No No 85.00 2011, June Austria
DirectCall G711a/u,G729 No Media Relay No No 78.77 2012, January Brazil
Unitel G711a/u Yes None Yes Yes 93.24 2012, August Denmark
Perustele Oy G711a/u,G729,G723 No M.Relay+Exc.Codec No Yes 83.90 2012, May Filand
TDC G711a/u,G729 Yes M.Relay+Exc.Codec Yes Yes 89.73 2013, January Filand
Acropolis G711a/u,G729 No None No Yes 89.20 2011, December France
Legos G711a/u,G729 Yes M.Relay+Exc.Codec No No 81.67 2012, May France
Voip-Telecom G711a/u,G729,G723 Yes Media Relay Yes Yes 97.50 2011, July France
Colt G711a/u,G729,G723 Yes M.Relay+Exc.Codec+Stun Yes Yes 98.00 2011, October Germany
QSC G711a/u,G729,G723,G722 Yes None Yes Yes 96.20 2012, October Germany
Toplink G711a/u,G729,G723 Yes None Yes Yes 96.00 2012, November Germany
Deltacom G711a/u,G729 No M.Relay+Exc.Codec No Yes 79.17 2012, June Italy
Planetel G711a/u,G729 Yes M.Relay+Exc.Codec No Yes 86.67 2012, June Italy
Trivenet G711a/u,G729,G722 Yes M.Relay+Exc.Codec+Stun No Yes 90.00 2012, September Italy
Netia SA G711a/u,G729 No None No Yes 88.00 2012, May Poland
Net2phone G711u,G723,G729 Yes M.Relay+Exc.Codec Yes Yes 82.70 2012, October Spain

Hardware Considerations

After preparing your network infrastructure for a SIP provider, you can now estimate the amount and type of needed gateways.

As already known from the previous chapter, it is critical that the chosen provider provider supports Direct Dial-In. If not you must plan one innovaphone gateway for every 16th extension (for IP302 ,IP305) in your installation. All other gateways support up to 32 extensions(GW-interfaces).

The next point to consider is the necessity of media relay for the SIP trunk. As discussed in the previous SIP and NAT chapter, the usage of media relay is in some scenarios inevitable. This feature is very CPU intensive and therefore limits the amount of concurrent calls that the innovaphone gateway can handle. As a rule of thumb you can say that the amount of concurrent SIP calls is equal to the amount of ISDN channels + 15% supported by the device.

SIP trunk configuration with innovaphone

Authentication by registration



To connect to a SIP provider you should normally use a SIP-GW interface. The special feature of this interface is that it can register at two different endpoints simultaneously. In this case it will register at the SIP provider as well as at the PBX , and by thus connect the two endpoints. Additionally the interface can be configured for media-relay and with exclusive codecs for a maximal interoperability to various providers.

screenshot.png SIP interface



The usage of the SIP interface is the recommended solution for connecting an innovaphone PBX to SIP providers.

Authentication by IP-address



Some SIP providers do not want the PBX to register at their server but authenticate their customers by the IP-address of the incoming IP packets. In this case you must use a VoIP-GW, configured as gateway without registration, to connect to the provider. Since this type of interface cannot be registered at two endpoints simultaneously, you must configure a second VoIP-GW to establish the connection to the PBX.

screenshot.png GW-interface



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 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 sohuld 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.


Summary

After reading this book you should remember the following points:

  • an ISDN trunk represents in most scenarios the better solution for a PSTN connection. Consider the pro & cons of SIP trunks.
  • always inspect the network infrastructure first . Keep an eye on the NAT router, the firewall and the available bandwidth of the Internet link.
  • use a SIP provider with DDI.


If you want more information on this issues have a look at our wiki:

fish-help.png RecProd SIP Provider
fish-help.png SIP Interop Test Description
fish-help.png How to use media-relay functionality for sip-registrations and how to configure sip-clients and sip-trunk
fish-help.png How to Connect to a VoIP Provider
fish-help.png SIP Media channel problems caused by NAT Routers
fish-help.png VOIP through NAT routers