The device supports the following new PSTN features:
1. Configurable Numbering Type and Plan for ISDN Connected Number:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
In previous releases, the Connected Number IE (interworked from SIP 200 OK P- Asserted-Identity header to the ISDN Q.931 Connect message) was hard-coded [Numbering Type = 0 (unknown) and Plan = 0 (unknown)]. However, for some ISDN variants (e.g., 4ESS), Type = unknown (0) is not a valid value and the Connected Number is rejected by the PSTN stack.
In this releases, the device now allows the configuration of the Numbering Type and Plan of the Connected Number IE using two new parameters, ConnectedNumberType and ConnectedNumberPlan. The default value is 0 for both (i.e., unknown).
Relevant parameters: ConnectedNumberType; ConnectedNumberPlan.
2. Interworking QSIG Facility Message with callTranferComplete to SIP UPDATE:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports interworking of the QSIG Facility message with
callTranferComplete invoke application protocol data unit (APDU), to SIP UPDATE message with P-Asserted-Identity and optional Privacy headers. The
redirectionNumber and redirectionName in the callTRansferComplete invoke is derived from the P-Asserted-Identity and Privacy headers. This feature is supported in the IP- to-Tel and Tel-to-IP directions. The new parameter, EnableQSIGTransferUpdate is used to enable this feature.
For example, assume A and C are PBX call parties, and B is the SIP IP phone: a. A calls B; B answers the call.
b. A places B on hold, and calls C; C answers the call.
c. A performs a call transfer (the transfer is done internally by the PBX); B and C are connected to one another.
In the above example scenario, the PBX updates B that it is now talking with C. The PBX updates this by sending a QSIG Facility message with callTranferComplete invoke APDU. The device interworks this message to a SIP UPDATE message containing a P-Asserted-Identity header with the number and name derived from QSIG callTranferComplete redirectionNumber and redirectionName.
Mediant 2000 & Mediant 3000
3. PSTN Support using Software Upgrade Key:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports enabling and disabling PSTN functionality using a Software Upgrade Key. Therefore, the device can now be offered as a standalone IP-to-IP Media Gateway. As supported in previous releases, the Software Upgrade Key can also be used to activate a standalone PSTN-IP Media Gateway, or a combined GW/IP- to-IP Media Gateway.
•
When the PSTN functionality is disabled, the relevant PSTN menus and pages are not displayed: • PSTN Settings • SS7 Configuration 4. Sigtran Configuration
QSIG MWI-to-IP Interworking Interrogation:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports the interworking of QSIG Message Waiting Indication (MWI) to IP, by introducing a new parameter (MWIInterrogationType) in the Trunk Group Settings table. This parameter determines the device's handling of MWI Interrogation messages, as described below.
This feature provides interworking between an ISDN PBX with voice-mail capabilities and a softswitch, which requires information on the number of messages waiting (i.e., MWI) for a specific user.
a.
The process for sending the MWI status upon request from a softswitch is as follows: b.
The softswitch sends a SIP SUBSCRIBE message to the device.
c.
The device responds by sending an empty SIP NOTIFY to the softswitch, and then sending an ISDN Setup message with Facility IE containing an MWI Interrogation request to the PBX.
d.
The PBX responds by sending to the device an ISDN Connect message
containing Facility IE with an MWI Interrogation result, which includes the number of voice messages waiting for the specific user.
e. The SIP NOTIFY messages are sent to the IP Group defined by the new parameter NotificationIPGroupID.
The device sends another SIP NOTIFY to the softswitch, containing this MWI information.
•
Therefore, the device can be configured to disable this feature, or enable it with one of the following support:
•
Responds to MWI Activate requests from the PBX by sending SIP NOTIFY MWI messages (i.e., does not send MWI Interrogation messages).
•
Sends MWI Interrogation messages, but does not use their results. Instead, waits for MWI Activate requests from the PBX.
Sends MWI Interrogation messages, uses their results, and uses the MWI Activate requests.
5.
Relevant parameters: MWIInterrogationType; TrunkGroupSettings; EnableMWI;
NotificationIPGroupID.
Configuration of Redirect Number Screening Indicator:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now allows you to configure a value for the Redirect Number Screening Indicator in ISDN Setup messages for IP-to-Tel calls.
Relevant parameter: SetIp2TelRedirectScreeningInd 6.
.
SIP-ISDN Interworking “tgrp” DoD UCR 2008 Parameters:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
When a hotline call is setup between the softswitch and the device, the indication that the call is a hotline call is required in order to meet the hotline screening requirements of the terminating subscriber’s switch. This indication is provided by the SIP "tgrp" parameter and the ISDN optional “Off-hook Indicator" Information Element (IE). The device now supports interworking of this SIP indication with the ISDN indication. For Tel-to-IP calls, the SIP "tgrp" to ISDN Q.931 mapping is shown in the table below:
SIP "tgrp" Value Q.931 Bearer Capability Off Hook IE (Optional) No label Speech
ccdata unrestricted 64 Kbit/s
hotline Speech Voice
hotline-ccdata unrestricted 64 Kbit/s Data
•
The Hotline Feature is applicable only for the ISDN NI-2 variant and is defined according to the UCR-2008 specification. This feature is enabled by setting the UseSIPTGRP parameter to 3. If enabled, the device performs the following interworking between SIP INVITE and ISDN Setup:
♦
For IP-to-ISDN calls:
The device interworks the SIP tgrp=hotline parameter (received in INVITE) to ISDN Setup with the Off Hook Indicator IE of “Voice”, and “Speech” Bearer Capability IE. Note that the Off Hook Indicator IE is described in UCR 2008 specifications.
Mediant 2000 & Mediant 3000
♦ The device interworks the SIP tgrp=hotline-ccdata parameter (received in INVITE) to ISDN Setup with an Off Hook Indicator IE of “Data”, and with “Unrestricted 64k” Bearer Capability IE. The following is an example of the INVITE with tgrp=hotline-ccdata:
INVITE sip:1234567;tgrp=hotline-ccdata;[email protected] SIP/2.0
•
♦
For ISDN-to-IP calls:
♦
The device interworks ISDN Setup with an Off Hook Indicator of “Voice” to SIP INVITE with “tgrp=hotline;trunk-context=dsn.mil” in the Contact header.
♦
The device interworks ISDN Setup with an Off Hook indicator of “Data” to SIP INVITE with “tgrp=hotline-ccdata;trunk-context=dsn.mil” in the Contact header.
If ISDN Setup does not contain an Off Hook Indicator IE and the Bearer Capability IE contains “Unrestricted 64k”, the outgoing INVITE includes “tgrp=ccdata;trunk-context=dsn.mil”. If the Bearer Capability IE contains “Speech”, the INVITE in this case does not contain tgrp and trunk-context parameters.
7.
Relevant parameter: UseSIPTgrp.
Interworking SIP with ISDN ETSI, QSIG CONP and CNIR Supplementary Services: Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410 •
The device now supports interworking between SIP and ISDN ETSI or QSIG's Connected Name Identification Presentation (CONP) and Calling/Connected Name Identification Restriction (CNIR) supplementary services.
Interworking of QSIG Calling Name: The device already supports (in the previous release) interworking of the QSIG Calling Name, including its privacy
(presentation = allowed or restricted) to SIP P-Asserted-Identity and Privacy headers (ISO 13868). The Privacy=id header in the outgoing INVITE describes the privacy for both calling number and calling name. If one of these ISDN parameters contains the value "presentation=restricted", then the Privacy=id header is included in the INVITE.
•
In the IP-to-Tel direction, if the device receives a SIP INVITE containing a Privacy=id header, both calling number and calling name privacy are set to restricted.
• Interworking of ETSI/QSIG Connected Name: If the device receives a P- Asserted-Identity header in the 200 OK response that contains also the Display name, the Display name is interworked to the ETSI/QSIG Connected Name, including its Presentation (allowed or restricted).
In the Tel-to-IP direction, if the device receives an ISDN Connect message containing Connected Name and Connected Line Number, these parameters are interworked to the SIP P-Asserted-Identity header in the 200 OK response. If one of these parameter includes presentation=restricted, a "Privacy: id" header is added to the 200 OK.
8.
Relevant parameter: AssertedIdMode. SIP Overlap Dialing for ISDN:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410 •
The device now supports the interworking of ISDN overlap dialing to SIP, based on RFC 3578.
•
Interworking ISDN overlap dialing to SIP (Tel to IP): The device sends collected digits each time they are received (initially from ISDN Setup and then from subsequent Info Q.931 messages) to the IP, using subsequent SIP INVITE messages. You can also define the minimum number of overlap digits to collect before sending the first SIP message (INVITE) for routing the call, using the new parameter MinOverlapDigitsForRouting.
Interworking SIP to ISDN overlap dialing (IP to Tel): For each received INVITE pertaining to the same dialog session, the device sends an ISDN Setup (and subsequent ISDN Info Q.931 messages) with the collected digits to the Tel side. For all subsequent INVITEs received, the device sends a SIP 484 "Address Incomplete" response to the IP in order to maintain the current dialog session and to receive additional digits from subsequent INVITEs.
9.
Mediant 2000 & Mediant 3000
ISDN-to-IP Calling Number Modification using Dial Plan:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports changing the Calling Party Number value (source number) in the received ISDN incoming call when sending to IP, using the Dial Plan file. For this feature, the Dial Plan file supports the following syntax:
<ISDN Calling Party Number>,0,<new calling number>
The Dial Plan file can also include a range for the source number, using the syntax: [x-y].
Below is an example of such a configuration in the Dial Plan file: [ PLAN1 ]
; specific received number changed to 04343434181. 0567811181,0,04343434181
; number range that changes to 04343434181. 056788118[2-4],0,04343434181
The device adds the newly manipulated calling number to the URI user part in the From header and to the Contact header in the SIP INVITE sent to the IP side. For example, a received Calling Number Party of 0567811181 that is changed to
04343434181 (see Dial Plan file example above) is sent to the IP with a SIP INVITE as follows:
Via: SIP/2.0/UDP 211.192.160.214:5060;branch=z9hG4bK3157667347 From: <sip:[email protected]:5060>;tag=de0004b1 To: sip:[email protected]:5060 Call-ID: [email protected] CSeq: 1 INVITE Contact:<sip:[email protected]:5060;transport=udp> • Notes: •
Tel-to-IP routing is performed on the original source number if the parameter 'Tel to IP Routing Mode' is set to 'Route calls before manipulation'.
•
Tel-to-IP routing is performed on the modified source number as defined in the Dial Plan file if the parameter 'Tel To IP Routing Mode' is set to 'Route calls after manipulation'.
10.
Source number Tel-to-IP manipulation is performed on the modified source number as defined in the Dial Plan file.
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now allows you to mute in-band DTMF detection until the device receives the full destination number from the ISDN (for Tel-to-IP calls). With ISDN overlap dialing, DTMF digits can be sent in-band in the voice stream, or out-of-band using Q.931 Info messages. If Q.931 Info messages are used for overlap dialing, the DTMF in-band detector must be disabled.
Note that when at least one digit is received from the ISDN (Setup), the device stops playing a dial tone.
12. ECT and TBCT Network Side:
Relevant parameter: MuteDTMFInOverlap.
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now also supports Network side (in addition to already supported User side) ISDN supplementary services:
• ETSI ECT (Explicit Call Transfer, ETS-300-369) • NI2 TBCT (Two B-channel Transfer, GR-2865-CORE)
This feature provides interworking of TBCT and ECT path replacement for IP-to-ISDN calls. The device sends a SIP REFER message to the remote call party if such a path replacement is received from the PRI/BRI side (e.g., from a PBX).
Relevant parameter: EnableNetworkISDNTransfer.
13. TBCT for Verizon GTD-5 Switch (Based on FSD 01-02-40AG):
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports the NI2 TBCT for Verizon GTD-5 EAX switch (General Telephone Digital Number 5 Electronic Automatic Exchange). This ISDN
Supplementary Service (User side) is based on FSD 01-02-40AG specification. This digital central office telephone circuit Class-5 switching system is used in the former GTE service areas and by many smaller telecommunications service providers. TBCT allows the user on a PRI to request the GTD-5 EAX to connect two independent calls on the user's interface. If the request is accepted, the controller is released from the calls and the other two users are directly connected.
Mediant 2000 & Mediant 3000
14. Call Deflection for Euro ISDN and QSIG:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports Call Deflection (ETS-300-207-1) for Euro ISDN and QSIG (ETSI TS 102 393) for Network and User sides, which provides IP-ISDN interworking for call forwarding (call diversion) when the device receives a 302.
In previous releases, upon receipt of a Facility message with Call Rerouting invoke method from the PSTN, the device initiated a SIP transfer process by sending a SIP 302 response in response to the remote SIP entity's INVITE message. The device then responded with a Disconnect message to the PSTN side.
In this new feature, the opposite direction is now also supported, i.e., the call forward is performed by the PSTN side instead of the SIP side. When the device sends the INVITE message to the remote SIP entity and receives in response a SIP 302, the device sends to the PSTN a Facility message with the same Facility IE mentioned above and waits for the PSTN side to disconnect the call.
Relevant parameter: CallReroutingMode. 15. T310 Timer for Euro ISDN Variants:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports the configuration of the T310 timer for DMS and Euro ISDN variants, using the new parameter ISDNTimerT310. This parameter replaces the old ISDNDmsTimerT310 that was used for DMS variants. The ISDNDmsTimerT310 will be obsolete in future releases.
When both the parameters ISDNDmsTimerT310 and ISDNTimerT310 are configured, the value of the parameter ISDNTimerT310 prevails.
Relevant parameter: ISDNTimerT310. 16. Multi-CAS Variants per Trunk:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports the configuration of different CAS variants per CAS trunk, by using the parameter CasChannelIndex. This parameter defines the loaded CAS table per B-channel pertaining to a CAS trunk. This parameter is assigned a string value and can be set in one of two formats:
Below is an example ini file for configuring a T1 CAS trunk (Trunk 5) with several CAS variants: ProtocolType_5 = 7 CASFILENAME_0='E_M_FGBWinkTable.dat' CASFILENAME_1='E_M_FGDWinkTable.dat' CASFILENAME_2='E_M_WinkTable.txt' CasChannelIndex_5 = ‘0,0,0,1,1,1,2,2,2,0,0,0,1,1,1,0,1,2,0,2,1,2,2,2’ CASDelimitersPaddingUsage_5 = 1
Below is an example ini file for configuring an E1 CAS trunk (Trunk 5) with several CAS variants:
ProtocolType_5 = 8 CASFILENAME_2='E1_R2D'
CASFILENAME_7= E_M_ImmediateTable_A-Bit.txt' CasChannelIndex_5 = ‘1-10:2,11-20:7,21-31:2’
Relevant parameter: CasChannelIndex. 17. Fractional CAS Trunk:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports the configuration of a fractional CAS trunk in deployments where the device is connected to only a single trunk and the device's DSP resources are insufficient to support a full CAS trunk.
18. Performance Monitoring for Number of Active Calls per Trunk/Trunk Group:
Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now supports performance monitoring of the number of active calls per Trunk and Trunk Group. These performance monitoring include the following: • Established Tel-to-IP calls per Trunk (Tel2IPTrunkEstablishedCalls) • Established IP-to-Tel calls per Trunk (IP2TelTrunkEstablishedCalls)
• Established Tel-to-IP calls per Trunk Group (Tel2IPTrunkGroupEstablishedCalls) • Established IP-to-Tel calls per Trunk Group (IP2TelTrunkGroupEstablishedCalls) 19. Collect Call Indication in INVITE for ISDN-to-SIP Calls:
Mediant 2000 & Mediant 3000 Mediant 2000 Mediant 3000 with TP-6310 Mediant 3000 HA with TP-6310 Mediant 3000 with TP-8410 Mediant 3000 HA with TP-8410
The device now adds a new proprietary SIP header, "X-Siemens-Call-Type: collect- call" to outgoing INVITE messages in response to received ISDN calls that are collect calls. This feature was developed for Brazil and is supported only for the Euro ISDN protocol. The device identifies these ISDN collect calls according to the Reverse Charging Indication IE in Setup messages.