A. Voice Mail must have the feature to dial the number (commonly called Out Dial or Remote Pager Notify)

Transcription

1 The Ascom VoIP Gateway is connected to the PBX using a PRI, and is capable of diverting calls to Voice Mail for No Answer, Busy, or No Response. The Voice Mail system should be capable of turning on the Message Waiting Indication (MWI) on the Ascom Handset when a message is left for a user in the Voice Mail system. To do this, the Voice Mail must be able to: 1. Dial a predetermined number 2. Wait for a certain amount of time (or upon connection) 3. Dial the MWI string to activate the function on the Ascom handset In order to accomplish this, several things must be in place: A. Voice Mail must have the feature to dial the number (commonly called Out Dial or Remote Pager Notify) B. Voice Mail should be able to put pauses in the dialing string C. Voice Mail should be able to dial * as a valid DTMF digit D. Ascom Gateway needs a Message Waiting Object E. A complete speech path must be in place upon connection While items A, B, and D are usually in place, there sometimes arises an issue with items C and E. Sequence of events and description of the function Someone dials an Ascom phone. Upon determining that the Ascom phone is busy, switched off, or not answered, the VoIP Gateway redirects the call to the Voice Mail system and the proper mail box. After a voice mail is left for the user, the VM must dial the activation string. For example, the MWI object in the VoIP GW is 8298, and the Ascom Phone is The voice mail must dial 8298, wait for connect (or pause 3 4 seconds), and then using DTMF send *1*3456. The *1* instructs the VoIP Gateway to activate the MWI for the user The VoIP Gateway then sends (using h323) a message to the handset, which activates the MWI function. The Handset (or IPDECT) must be set up so that a call back to check their messages turns the MWI off. This is either a handset setting (i75) or a DECT Supplementary Service Setting (IP-DECT). Page 1 of 6

2 Handling Item (C) In the event that the Voice Mail system cannot dial * as a DTMF Digit, then it must be programmed to dial 8298, wait for connect (or pause 3 4 seconds), then send 3456 in DTMF. For this case, the Ascom VoIP Gateway can be programmed to dial the *1* using the incoming routing tables. On each incoming PRI route, define a MAP1 with the Number IN = 8298, and the Number Out = 8298^*1*. See the screen shot below: This instructs the Gateway to accept the incoming call over PRI 1 with a dialed digit of 8298, dial internally 8298 (the MWI object number) and after connect (^) switch to DTMF and dial *1*. After connection, the Voice Mail system sends the Ascom handset the number to trigger the icon for. Page 2 of 6

3 Handling Item (E) It has happened on some systems that the Q931 call flow messages are not being sent in the sequence that the PBX expects them, and so it does not switch the speech path through. The symptoms are: From an Ascom phone, dial the MWI object. Call is connected, music is heard, and MWI can be manually triggered by dialing *1*xxxx (activate) or *2*xxxx (deactivate). From a PBX desk phone, dial the MWI object. Call is connected, but there is no music, and dialing the activate/deactivate string does not work. The VoIP Gateway GUI will show a connected call. This is because specifications for this function are subject to implementation by the specific PBX. The spec is ETSI document ETS , Annex N. (See the last page of this document). To work around this, you will need to create another VoIP GW PBC Object, called Waiting Queue: Assign a long name, name, and phone number. Set the Alert time box to 1, and set a DTMF digit (* in this example) to dial the actual MWI object number (in this example, 8299). See the following screen shot. Page 3 of 6

4 On the incoming PRI route, insert a new MAP 1, and set the Number IN = 8298, Number Out = 8298^*. This specifies that when a call comes in over PRI1 with dialed digits = 8298, we connect the call to the Waiting Queue Object. After Connect (^), we dial DTMF *. The Waiting Object transfers the call to the MWI object. The VM then dials *1*xxxx to activate the MWI. If the VM cannot dial the *1*, then we can set the incoming route to dial ^**1*. You will not see these in the syslog trace. Page 4 of 6

5 To verify that it is working, open up the Diagnostics Logging, and select Gateway Calls and Gateway Routing. Click OK, then click the blue syslog link below the OK button. Place a call from a desk phone. You should hear music (possibly a short missed note or two which is due to the transfer happening). On your screen you should see the call, and a line with B:X CALL 0 B:X 3519->8298 G711A,20(0,0,0)/G711A,20(0,0,0) PRI1:3519:->RP1:8298: Enter the activation code (either *1*xxxx or just xxxx if the Route Table was programmed to dial the *1* for you. If you need assistance, please call Technical Service at ASCOM ( ) and select Option 3 from the menu. Page 5 of 6

6 The following is a copy of the ETS Annex N document (highlighted where necessary) Annex N (Normative): Procedures for establishment of bearer connection prior to call acceptance N.1 General For some applications, it is desirable to allow the completion of the transmission path associated with a bearer service prior to receiving call acceptance. In particular, the completion of the backward direction of the transmission path prior to receipt of a CONNECT message from the called user may be desirable to: a) allow the called user to provide internally-generated tones and announcement that are sent in-band to the calling user prior to answer by the called user; or b) avoid speech clipping on connections involving an NT2 where delays may occur in relaying the answer indication within the called user equipment. The procedures described in this annex are only applicable to the speech and 3.1 khz audio bearer services. NOTE: The definition of necessary mechanisms (if any) with Signalling System No. 7 to avoid any potential undesirable charging implications remain for further study. N.2 Procedures As a network option, completion of the transmission path prior to receipt of a call acceptance indication may be provided in one of three ways: a) On completion of successful channel negotiation at the destination interface; or, b) On receipt of a message containing an indication that in-band information is being provided; or, c) Not at all; i.e. this option is not supported by the network. When criterion (a) is used to determine that the transmission path should be established, the network shall connect, as a minimum, the backward side of the transmission path upon receipt of either a CALL PROCEEDING message or an ALERTING message containing an acceptable B-channel indication. When criterion (b) is used to establish the transmission path, the network shall connect, as a minimum, the backward side of the transmission path upon receipt of either an ALERTING message or a PROCESS message containing progress indicator #8 "in-band information or appropriate pattern now available" or progress indicator #1 "call is not end-to-end ISDN; further call progress information may be available in-band", respectively. The network providing the early completion of the transmission path in the backward direction may choose to support only one of the methods (a) or (b) above. The network may choose to further restrict which message(s) will result in establishment of the transmission path. These restrictions may be imposed on a per-interface basis to provide an administrative means for limiting potential misuse of the early connection capabilities. ETSI Requirement: In ISDNs conforming to this ETS, the procedures described in this annex are optional. ISDNs which choose to implement these procedures must ensure that they are not used on incoming international calls. Page 6 of 6