Course10:Advanced - Gateway Interfaces: Difference between revisions
m (Protected "Course10:Advanced - Gateway Interfaces" [edit=sysop:move=sysop]) |
m (Protected "Course10:Advanced - Gateway Interfaces" ([Edit=Allow only administrators] (indefinite) [Move=Allow only administrators] (indefinite))) |
(No difference)
|
Latest revision as of 12:00, 12 October 2023
This book describes all gateway interfaces configurable with innovaphone and their different working modes.
Overview
Interfaces
As already discussed in the innovaphone overall Product Design book in your iCE basic training course, the relay (as configured in the Gateway/General tabs) is the software component within innovaphone devices that handles access to various physical or external interfaces (such as e.g. ISDN basic rate, primary rate or analogue FXS). It manages the interface in terms of status and physical configuration and provides the necessary protocols (such as ISDN, QSIG, CAS, POTS) to implement both signalling and media channel.
The relay main functions are
- providing a connection to the PSTN
- providing a connection to third party devices and PBXs via ISDN, VoIP or analog lines
- providing supplementary services like:
- supply audio media via HTTP streams
- supply different dial tones (needed for example in the soft migration scenario)
- supply a PBX with a conference server
- provides an alternative Call Server software called Gatekeeper, needed for special scenarios like PBX trunking
For calls from the PBX to the interfaces and vice versa, the call signalling protocols are translated and the media data is converted as required.
Aside from its physical interfaces, the relay also supports a number of further interface types, such as SIP trunks, virtual interfaces and the conferencing engine.
As the PBX cannot maintain any outgoing registrations itself, interfaces that require a registration themselves (such as SIP trunks where the subscriber needs to register with the provider) can be handled by the relay too. In this case, it will maintain 2 parallel VoIP registrations, one to the SIP provider and one to the PBX. The SIP provider registration is then treated just like any physical interface. This pair of registrations is known as a SIP interface.
The TEST, ECHO and TONE interfaces are known as virtual interfaces. Calls to these will be terminated locally in the relay.
Virtual interfaces will never originate calls. Calls directed to these interfaces will play music on hold (TEST), dial-tones (TONE) or echo any incoming media (ECHO).
The HTTP interface (a.k.a webmedia) will connect any call and will retrieve the media stream played to the caller from a (possibly remote) web server. Custom music on hold or announced played in IVR type situations can thus be provided by customers on a web server (either an innovaphone gateway with CF card or a standard web server such as IIS or Apache).
Some of the gateways feature a conferencing engine that provides mixing capabilities for a number of calls (currently up to 60, depending on the gateway used).
Call Routing
In many cases, calls from interfaces to on-behalf registrations are straight back and forth without any manipulation. However, in certain scenarios, call routing can be more sophisticated.
The relay's routing table provides a very powerful mechanism to configure the call routing depending on the called and calling party numbers, as well as the interfaces involved. Many call properties, such as calling and called party numbers can be manipulated as well. Call alternatives can be implemented, for example to fall back to an emergency trunk line when your standard trunk line is not available.
This book is about the interfaces the relay provides. There is another book on the same topic discussing the routing engine.
Physical Interfaces
ISDN Interfaces
For ISDN BRI and PRI interfaces, the most important settings are the NT or TE mode and the ISDN protocol (set in the
The signalling protocol (set in the
The two QSIG flavours are only used if you connect to a legacy ISDN PBX using a tie line. Unfortunately, there are a number of different setups for QSIG connections. This will be discussed in a later chapter of this book.
For basic rate interfaces (BRI, a.k.a. S0, especially in Germany), you need to specify also if your interface runs in point-to-point or point-to-multipoint mode.
Point-to-multipoint refers to the fact that you can attach multiple terminal equipment interfaces to the one network termination interface. This was intended to connect multiple (up to 8) ISDN phones to your carrier trunk line. However, even if you connect only one terminal equipment interface to your trunk line (e.g. your innovaphone gateway only), your NT interface may be in point-to-multipoint mode. So you need to find out from your carrier which mode it is in.
As a point-to-multipoint interface can support multiple devices, it is not just a cable, but it is defined as a digital bus. This must be wired properly and termination resistors have got to be present. However, since in many installations there is just one device attached to the network termination interface and a straight CAT-3 (or better) patch cable is used, the termination is often missing. This will result in unreliable communication. You may thus turn on the 100 Ohm Termination property in the
Nowadays, the more important difference between both modes is that a point-to-multipoint interface has up to 10 subscriber numbers assigned. These may or may not be assigned sequentially (that is, you may have subscriber numbers 12340, 12341, ..., 12349 if you are lucky. You may however have assigned a number of unrelated numbers such as 12345, 37261, 98263, ...). In contrast, point-to-point interfaces usually have a subscriber number range assigned (e.g. 12300 to 12399).
Analogue Interfaces
There is rarely a need to change anything in the physical settings of the analogue interfaces.
You may however want to change the Busy on Busy / No Call Waiting or No Call Transfer on Hook-On properties in the Signalling tab.
VoIP interfaces
Let us first have a look at the VoIP interfaces defined in
In the same way as ISDN interfaces lead the world of classical telephony, VoIP interfaces (GW1-12) (as configured in the
They can represent different types of equipment:
- an innovaphone PBX
- other innovaphone gateways
- VoIP terminal equipment, for example IP telephones (uncommon, preferred to be registered in the PBX)
- third-party VoIP gateways, as a gateway to telephone switches for analog lines (FX0) for example.
- Third party VoIP Pbx´s
- further gatekeepers for call control
- and others
The Protocol Configuration
- H.323
- SIP
- TSIP
- SIPS
The protocol options depend on if you choose H.323 or one of the SIP flavours. Therefore, if you try to change the protocols, you will see that the menu options differ between H.323 and SIP. For this reason, you should always delete all settings when changing the protocol, to ensure that you don't run into problems from previously configured settings.
For both H.323 and SIP various Interop Tweaks are available. As the name suggests, these are workarounds for interoperability problems and you should not use any of them unless you experience such problems.
The Registration Mode
In unregistered mode, a VoIP interface just sends calls to the far end when necessary. Similarly, it accepts calls from the far end at any time. It is not necessary for the interface to identify itself to the far end (nor vice versa). As a result, no access credentials such as user/account-name or password have to be configured. This mode is selected using Gateway without Registration. Please note that this mode will also accept incoming calls from the far end.
In registered mode, there is a client/server relationship between the interface and the far end and the client must establish a session with the server prior to any call sent. This process is known as registration. To set up the registration, credentials such as account and password may be required. This mode is selected using Register as Endpoint or Register as Gateway. The difference between them is subtle and applies only to the H.323 protocol. The information is sent to the far end as part of the registration request. The far end (usually a gatekeeper) may or may not use this information. innovaphone devices (both the relay's gatekeeper and the PBX) ignore it. When H.323 is used, all entries in the Alias List table are sent to the far end and the Password from the Authorization box is used. Depending on the gatekeeper used, you may need to specify both Name and Number. For the innovaphone PBX, either is sufficient. When SIP is used, the first Name entry in the Alias List table is used as registration id, and the Name and Password properties from the Authorization box are used for authentication. In many cases, the name used for registration and the account used for authentication will be identical. In such cases, you may leave the Name property in the Authorization box empty
The latter 2 modes define an interface that registers itself with the far end. However, it is also possible to accept registrations from the far end instead (reversing the client/server relationship). This mode is selected using Gatekeeper / Registrar and requires a special license. All entries in the Alias List are accepted as registering accounts, but all of them need to use the same Password from the Authorization box.
The remaining mode, ENUM is an extension of the Gateway without Registration mode. It performs an ENUM lookup on a call-by-call base to find the appropriate far end for each outgoing call. Incoming calls are treated like Gateway without registration mode interfaces. Like all gateway modes, ENUM is available for both SIP and H.323. However, a single ENUM interface will talk either SIP or H.323, depending on the Protocol setting. So if you want to support calls from and to both SIP and H.323, you will need to define multiple ENUM-type GW interfaces.
SIP interfaces in Gateway without Registration mode and H.323 interfaces in Gatekeeper mode support call restriction using the Mask property. By default, only incoming calls from the IP address specified in the Address property are allowed. If a network mask is specified, calls from all addresses in the same network are allowed. This is useful when for example a SIP proxy uses a farm of IP interfaces to send calls. ENUM interfaces always allow incoming calls from any IP address (that is, they behave as if the Mask property would be set to 0.0.0.0).
Finding the far End
When using H.323 with Gateway without Registration, the far end simply is determined by the IP address given as Address.
When using H.323 with Register as Endpoint or Register as Gateway, the far end is determined by the IP address given as Address too. Also, if an alternate Address is specified and the registration with the primary Address fails, the alternate address is tried (providing a redundant fall-back mechanism exists). However, if no Address is given, gatekeeper discovery will be performed.
When using SIP both with Gateway without Registration, Register as Endpoint and Register as Gateway, the remote end is determined by analysing the Domain and Address properties. Usually, you simply specify the domain name your SIP provider gave to you. A fall-back mechanism is only used if the domain is given, a SIP SRV record is retrieved and there is an alternate server specified in the DNS response.
Media Properties
Local Network Coders are negotiated when the far end is within the local network as defined in the Local Networks settings of the
Both ends of a call will negotiate one of the implemented voice codecs. Each side can suggest its preferred codec (defined in General Coder Preference and Local Network Coder), still allowing all others . However, when the Exclusive property is set, any other codec will be rejected. This makes sense in special scenarios, for example fax or modem calls.
There is a special, non-voice codec called T.38 which provides for reliable fax G3 transmission. This will be offered and accepted only if the Enable T.38 property is set.
It is pretty important to understand that media properties are effective only if the media channel actually is terminated in or passes through the device. As discussed in the VoIP Protocols books in your iCE Basic Training course, media channels are established end-to-end, whereas signalling connections are established hop-by-hop. So media properties are ineffective if the media channel does not terminate within the device. Obviously, calls to or from local interfaces (such as ISDN and POTS) will have their media channel terminated here, so the media properties apply. The same is true for all the virtual interfaces (such as TONE, TEST, ECHO and CONF). For the HTTP interface (which provides access to pre-recorded voice streams on a web server) this might be less obvious though. Finally, for calls where media-relay is applied to (either because the Media-Relay property is set in the media properties or because Private Networks have been defined in the
PCM Mode
This PCM mode helps you save DSP channels. Then a DSP channel is only needed for call setup. As soon as it can be determined that the call will end up in the same device it originated from and the device has a PCM bus available (depending on the gateway model) and the Enable PCM property is set on both ends, the DSP channel is released. No DSP is then needed for the remainder of a PCM call.
For most calls, PCM mode provides better performance, eliminating the delay and QoS issues associated with carrying media over IP. This is especially true for modem and fax (if not using T.38) calls. The only drawback is that there is no echo cancellation and DTMF detection done on the media channel.
Here is an example:
Call comes in on a gateway's ISDN interface, gets routed to an innovaphone PBX (installed on another gateway) - and then back (because the call can not be delivered to this PBX) to the same gateway where the incoming call arrived and out on another ISDN interface towards a legacy PBX.
"Gateway without registration" Scenario
The example shows a connection between 2 legacy PBX´s via innovaphone gateways via IP.
Other examples include amongst others
- a SIP provider that does not need registration (for example Tele2 sweden sip trunk)
- a third party device that works without registration (example Linksys FXO gateway)
With this mode, no configuring of registration name/number is needed as there is no registration. This configuration suffices calling between both sides.
As you have no registration (no RAS registration data) you might experience an unpleasant behaviour - because the gateway never knows if the other side is "up and running " or not. So any call attempt will take a time-out before re-routing (if configured) can take place. This will cause extra delays in call processing.
Also, this mode cannot be used for QSIG tunnelling (see the QSIG chapter later in this book).
"Register as ..." Scenario
However, the same mechanism can be used e.g. to integrate an innovaphone gateway to a 3rd party gatekeeper. In the example below, an IP6000 is used as an ISDN PRI gateway for a Cisco call manager.
"Gatekeeper/Registrar" Scenario
One prominent example is (possibly multi-point) legacy PBX-trunking with QSIG tunnelling over IP:
Please note that you must make sure that there are no 2 gatekeeper instances with the same gatekeeper ID within a single network. If for example, site A would run a PBX in addition, its gatekeeper ID (known as System Name in the
There are certain limitations involved when you use the Gatekeeper / Registrar mode. This mode is not intended to manage a large number of registering clients. It is OK to have 50 clients, but for larger number of clients you will need to use the PBX. This is due to 2 facts: call routing is slightly less performing and the size of the configuration data is limited: In the Alias list section you specify the name and/or number of the registering clients (their registration credentials). The total size of the resulting config file (all lines starting with config change) must not exceed 64kB. Also, the total line length of a config file line must not exceed 2048 byte and finally the number of words on a config line is limited. So if you run into a configuration size problem, you can try to use shorter aliases, or split it into 2 GWx entries. As a rule of thumb you can add up to 32 aliases to one gatekeeper.
SIP Interfaces
Open Federation and Closed Federation, as the name suggests, will be used to setup Federation scenarios(see the
Virtual Interfaces
TEST
The gateways have an internal TEST interface. It only makes sense to use it as a destination for a call. If a call arrives at the TEST interface, it is connected and the hold music stored in the non-volatile memory is played. Subsequently dialled digits are ignored.
TONE
The gateways have an internal TONE interface. It only makes sense to use it as a destination for a call. If a call arrives at the TONE interface, it is not forwarded, but the dial tone configured for the interface is played (the incoming call is acknowledged with SETUP_ACK and a media channel is set up). The call is rejected if a further digit is dialled or if the original call contained other digits already dialled. The TONE interface can be used to play a caller a public dial tone, even though the call has not yet been connected to a genuine public exchange line. This happens particularly with least-cost-routing scenarios, where the call can only be switched once some of the dialled digits have been analysed. The TONE interface can process a number of calls simultaneously. The dial tone played is set in the gateway/interfaces, there are different TONE types (for different countries).
That interface is also important for SIP trunks because there is no "dial tone" played as is the case with ISDN.
HTTP
The non-configurable, internal interface HTTP is only usable as the destination for a call. If a call is received on this interface, music on hold, an announcement or some other spoken information is played from a web server.
ECHO
This is for testing purpose. A route to an ECHO interface, and calling to this interface creates an echo, so you can hear yourself, mainly used for DECT deployment
CONF
The CONF interface is used for conferencing solutions, see
FAX
On v10 we released the FAX Server application and with this a new Interface it's available. It's called FAX and it's used together with the innovaphone Faxserver application. More information in
Registered Interfaces
This configuration option is an easy way to register interfaces with an innovaphone PBX. It creates an implicit H.323 or SIP registration along with 2 straight routes between the interface and the VoIP interface:
This configuration method is much simpler and less error prone and thus strongly recommended.
The implicit VoIP interfaces are named R plus the first letter of the interface involved plus T plus the index of the interface (optional). So for the TEL2 interface of an IP800, the implicit VoIP interface would be called RT2.
CDPN/CGPN Maps
The following maps can be defined:
- CGPN-In: inbound calling party number
- CDPN-In: inbound called party number
- CGPN-Out: outbound calling party number
- CDPN-Out: outbound called party number
Interface maps are used to "normalize" numbers received from (or, less likely, sent to) interfaces so that within the routing engine all numbers from all interfaces have the same format. Moreover, the routing engine just deals with numbers as digit strings. However, from the ISDN, numbers come in various flavours, such as international, national, subscriber or unknown (you know that from the basic training), known as type of number. Interface maps are used to re-format such numbers to pure digit strings, e.g.
- international 497031730090 -> 00497031730090
- subscriber 730090 -> 07031730090
Multiple maps can be defined for a single type of mapping (e.g. CGPN-In). This is useful as numbers may be presented in different formats. This is the case with ISDN interfaces for example.
The maps defined for the ISDN trunk line interface in this example are as follows:
- Calling Party In (CGPN-In). These are the numbers of the calling party for calls from the ISDN into the gateway. Numbers flagged as international (e.g. 437206200680) will have 00 prefixed (resulting in 00437206200680). Numbers flagged as national (e.g. 51142356) will have 0 prefixed (resulting in 051142356). All other numbers (such as 730090 flagged as subscriber or 07031730090 flagged as unknown) will be left unchanged. As a result, the numbers are seen by the routing engine just like a user would dial them (excluding a PBX trunk access prefix)
- Called Party In (CDPN-In). These are the called numbers for calls from the ISDN into the gateway, in other words, your local extension called. Numbers flagged as national (such as 70317300915) will have 703173009 stripped, leaving extension 15. Numbers flagged as subscriber (such as 7300915) will have 73009 stripped, leaving extension 15. All other numbers are left unchanged, however, these should not appear on this trunk anyway. Note though that in a paranoid world, your ISDN carrier could send the called party number flagged as international (e.g. 4970317300915). This however is very unlikely and we have never seen such behaviour. If it happens to you, simply add a CDPN-In map for such numbers
- Calling Party Out (CGPN-Out). These are the numbers of the calling party for calls from the gateway to the ISDN. Numbers starting with 00 (such as 00437206200680) will have the 00 removed and will be flagged as international (resulting in 437206200680). Numbers starting with 0 (such as 0703173009) will have the 0 removed and will be flagged as national (resulting in 703173009). All other numbers (which are assumed to be local PBX extensions) will have the trunk line's subscriber number prefixed and be flagged as subscriber
- No maps are applied to the Called Party Number Out (which are the called numbers for calls from the gateway to the ISDN), assuming that the calling user simply dialled the right number
- unknown 0043 -> 010900043
The maps also translate the numbering plan identification properly. In our example, outgoing calling numbers (sent to the ISDN carrier) are set to have the ISDN numbering plan. Calls originating from the innovaphone PBX will always carry the Private numbering plan identification.
SIP and Type of Address / Numbering Plan Identification
SIP does not know about the phone number type of number and numbering plan properties. However, the innovaphone SIP stack implementation will present an otherwise digit-only user part of a URI which starts with a plus (+) sign (e.g. +497031730090) as an international type. All others will be presented as unknown type of number.
H.323 and Type of Address / Numbering Plan Identification
H.323 (being a descendant of Q.931) fully supports the type of number and numbering plan properties like ISDN does.
Automatic Maps
Number mapping can be tricky and it is more than easy to make a mistake here. This is why there is a very convenient configuration short-cut available called Interface Maps in the interface configuration dialogue.
This is for interfaces connecting to a traditional ISDN trunk line. You just need to select point-to-point or point-to-multipoint interface style, define your ISDN trunk line parameters (such as subscriber number and area code) and the maps are created automatically. Since it is so much easier to use, this method is strictly recommended!
QSIG
QSIG Interworking
QSIG Interworking is a feature of the innovaphone H.323 and SIP protocol stacks. The feature allows to translate H.323 and SIP supplementary services into QSIG supplementary services and vice-versa. So having a legacy PBX connected with an innovaphone gateway via QSIG and an e.g. innovaphone PBX we can interwork features between both, like name display, call diversion, call transfer, call completion and path replacement. H.323 to QSIG interworking supports more features than SIP to QSIG interworking, so this is the recommended protocol to use for connecting multi-brand legacy PBXs.
There are various interworking configuration tips with third party PBX´s like
AAstra/Ericsson MD110 interworking
Alcatel Omni PCX interworking
Hicom 150/HiPath 300 interworking
HiPath4000 interworking in our wiki.
QSIG Tunnelling
QSIG Tunnelling is a loose term we use for QSIG Generic Functional Procedures. This is essentially a method to communicate proprietary features through a non-proprietary tunnel via QSIG. So the method to establish this tunnel is defined, but the content communicated through the tunnel is not.
When 2 PABXs use QSIG tunnelling, they exchange proprietary information through a standard mechanism. In practice this means that the two (or more) PABXs need to be of the same brand. However, we can take advantage because we can implement the tunnel mechanism without understanding the proprietary features sent within.
For this to work, we need to establish an RAS-based connection, that is, a registration to the other side. The RAS protocol lets us exchange information so that we know there is innovaphone gear on both ends. If we detect this, we can send QSIG generic function packets via H.323. This works thus only with VoIP interfaces in Register as ... mode and only via H.323.
On the ISDN/QSIG level, there is no need for a special configuration as generic functions are a defined part of QSIG. So it is up to the PABX to use tunnelling or not. In fact, you will see that this is configured within the legacy PBX (e.g. in a Hicom/HiPath, this mode is known as Cornet-NQ).
Having said this, QSIG tunnelling obviously cannot be "interworked" (as the features communicated within the tunnel are not understood by the gateways).
QSIG Trunking
QSIG trunking is used when connecting 2 or more different PBX´s of different types (via IP). It differs from the 2 modes above in a way that neither the QSIG tunnelling mechanism is used nor interworking is applied. As a result, this will work with SIP and Gateway without Registration mode VoIP interfaces too. However, only basic call features will be available.
Fax/Modem bypass
Fax/modem bypass is currently supported by the IPxx10, IP30X and IP22, 24, 28 series.
When fax or modem signals are detected, the channel automatically switches from the current voice coder to a high bit-rate coder such as G.711 coder (according to the parameter FaxModemBypass). In addition, the channel is automatically reconfigured.
To transport analog modem data via a RTP channel, the following requirements must be fulfilled:
1) A network connection with no packet loss
2) A frame size of 20 ms is required
3) Disable T.38 on the TELx port where the modem is connected
4) Enable G711A or G711U exclusively
Please read also the wiki article on gateway synchronisation.
Troubleshooting
To see if modem bypass is in use, open the URL http://gateway-ip-address/debug.xml on your device and enable the following trace flags:
DSP
DSP control messages
DSP data messages
DSP pcm trace
TCP/UDP Traffic
You have to start the trace (wireshark), while the modem transports its data. The trace will contain the information "switch to modem bypass", if modem bypass is used.