iTime Report post Posted 05/04/2012 05:04 PM Dear support, Our client switched to the new board D/480 JCT as they wanted to use T-1 connection. Now the problem is that caller ID is only arrived to VoiceGuide when a call is made "within the system." Most of cases, the callerID (RV_CIDNumber) value is empty. The Telecom technician said it is avaialble but VoiceGuide is not capturing it because he sees the number in ChannelD. (I attached ChannelD log he sent. You can see the phone number 714393...., but not in the voiceguide log, "0504_1110_vgEngine.txt") I also attached additional log that has captured one callerID. ("0504_0558_vgEngine_CIDCaptured.txt". the caller ID is ending 3998) Please let me know what to do in order to see caller ID all the time. I am not certain at this point if I have to do something on VoiceGuide Configuration, or ask them to check their phone lines. I attach the VoiceGuide Config file just in case. Thanks a lot for your great support in advance! Log_CallerIDIssue.zip Share this post Link to post
SupportTeam Report post Posted 05/07/2012 12:09 AM Now the problem is that caller ID is only arrived to VoiceGuide when a call is made "within the system." Can you please explain in more detail what do you mean when you say "the call is made "within the system."" Is the T1 trunk coming from the PBX, and the "within the system" calls are the calls that are made from a PBX extension? If yes then this would suggest that the CallerID field is correctly read in, but the PBX is not forwarding the CallerID on when external calls are routed over to the T1 trunk. With what tool/application was the ChannelDLog.txt ISDN trace file made? Was the trace made on the T1 trunk that is plugged into the Dialogic card (ie. T1 between PBX and Dialogic), or on the T1 between Telco and PBX ? The VoiceGuide traces show that the CallerID and DNIS values set on incoming calls were changing from call to call, but when CallerID data was supplied in ISDN SETUP message it was read in by VoiceGuide. 090535.986 6 2 1 cid LastCidMessage values [6512663998,,63466] 101018.404 6 2 1 cid LastCidMessage values [,,6179963466] 101054.998 6 2 1 cid LastCidMessage values [,,612816825063466] 110805.726 6 2 1 cid LastCidMessage values [,,63466] Share this post Link to post
iTime Report post Posted 05/07/2012 08:18 PM Can you please explain in more detail what do you mean when you say "the call is made "within the system.""Is the T1 trunk coming from the PBX, and the "within the system" calls are the calls that are made from a PBX extension? The answer is "YES." With what tool/application was the ChannelDLog.txt ISDN trace file made?Was the trace made on the T1 trunk that is plugged into the Dialogic card (ie. T1 between PBX and Dialogic), or on the T1 between Telco and PBX ? The client said that the trace was made from the PBX box and this log was made by a technician. (I could not ask him what application he used for.) So, I guess CallerID is forwarded correctly from TemoCo to PBX, but not from PBX to the Dialogic card. Is there any way that I can prove that the callerID is not made to the Dialogic card in these cases? (i.e. checking logs made by the Dialogic card?) What would be your suggestion in this case? (I am trying to convince our customer to investigate/trace further signals between the PBX and the dialogic card.) Thank you very much for your help. Share this post Link to post
SupportTeam Report post Posted 05/08/2012 03:20 AM s there any way that I can prove that the callerID is not made to the Dialogic card in these cases? (i.e. checking logs made by the Dialogic card?) VoiceGuide can tell Dialogic to start doing an ISDN trace report. Please see: http://www.voiceguide.com/vghelp/source/html/configisdnsetup.htm : VoiceGuide ISDN Tracing VoiceGuide can also trace the ISDN D-channel messages. A file titled ktTelControl_TraceSelect.txt needs to be placed in "C:\" with the contents of the file indicating which Dialogic's board D-channel is to be traced. Example contents should be: isdn_trace_dtiB1 which indicates which interface board should have it's D-channel traced. VoiceGuide will create the traces in "C:\", with the traces named something like this: isdn_trace_dtiB1_0325_203334.log Traces can be converted into readable format using Dialogic's ISDTRACE.EXE utility. The trace is created by Dialogic drivers directly. VoiceGuide plays no part in creating that trace aside from telling Dialogic to start doing it. The trace usually captures the first few calls after service is started. Suggest starting a trace and making an external an internal call, and posting the Dialogic ISDN traces along with VoiceGuide's vgEngine and ktTel traces. After the trace is captured delete the ktTelControl_TraceSelect.txt file and restart the VoiceGuide service, as this ISDN tracing should not be done on live system, its intended use is for testing/verification only. The previously supplied VoiceGuide traces were showing that the format of CallerID and DNIS values set on incoming calls were changing from call to call, which may indicate that PBX settings that affect the way CallerID and DNIS is forwarded were being worked with as well(?). You may need to speak to customer's PBX administrator regarding this. Share this post Link to post
iTime Report post Posted 05/08/2012 08:51 PM I tried to obtain the log from Dialogic by following the instruction you mentioned, but no file was created. I created "ktTelControl_TraceSelect.txt" in "C:\", stopped both dialogic card and VoiceGuide. Restarted Dialogic card and VoiceGuide, then called and hung up. There was no file log file created in "C:\" folder. What did I do wrong? I attached the TraceSelect.txt file and Config.xml file just in case. Thanks. ISDN_TraceNotWorking.zip Share this post Link to post
SupportTeam Report post Posted 05/08/2012 09:15 PM Could you please post the ktTel trace file which captures system startup while the ktTelControl_TraceSelect.txt file was present in "C:\" ? Share this post Link to post
iTime Report post Posted 05/08/2012 11:20 PM The file is very long: Sorry, I could not chop it down. The test was performed between around 1:00 and 2:00 PM. Thanks again! TelLog_DuringTracing.zip Share this post Link to post
SupportTeam Report post Posted 05/09/2012 12:45 AM Looks like the ISDN tracing option was for some reason disabled in version that is installed on your system.Please update system to this version of VoiceGuide:[old link deleted]To update please stop VG service and install new version over the top of old one.Then start the service, place the calls, stop the service and see if the trace file was created in C:\Please post traces as before. Share this post Link to post
SupportTeam Report post Posted 05/09/2012 01:07 AM For reference, here is an example ISDTRACE generated readable trace showing incoming call with CallerID and DNIS PROTOCOL TYPE : PRI NET5 TRACE START TIME (MM/DD/YYYY) : 5/9/2012, 11:2:52.62 Time Stamp : 5/9/2012, 11:4:40.462 RECEIVE Command=1 SAPI=0x00 TEI=0x00 0x00 0x00 Information Dest=0 CR=0x0001 SETUP(0x05) 1: SENDING COMPLETE(0xa1) 1: BEARER CAPABILITY(0x04) 2: IE Length(0x03) 3: 1------- Extension Bit -00----- Coding Standard ---00000 Info. Transfer Cap. 4: 1------- Extension Bit -00----- Transfer Mode ---10000 Info. Transfer Rate 5: 1------- Extension Bit -01----- Layer 1 Indent ---00011 User Info. Layer 1 1: CHANNEL ID(0x18) 2: IE Length(0x03) 3: 1------- Extension Bit -0------ Interface ID Present --1----- Interface Type ---0---- Spare ----1--- Preferred/Exclusive -----0-- D-Channel Indicator ------01 Info. Channel Sel. 3.2: 1------- Extension Bit -00----- Coding Standard ---0---- Number Map ----0011 Channel/Map Element 4: 1------- Extension Bit -0000001 Channel Number/Slot Map 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0e) 3: 0------- Extension Bit -010---- Type Of Number ----0000 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 456456456456 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x09) 3: 1------- Extension Bit -010---- Type of Number ----0000 Numbering plan ID 12341234 Number Digit(s) Time Stamp : 5/9/2012, 11:4:40.462 TRANSMIT Response=1 SAPI=0x00 TEI=0x00 0x01 0x02 Receive Ready Time Stamp : 5/9/2012, 11:4:40.462 TRANSMIT Command=0 SAPI=0x00 TEI=0x00 0x00 0x02 Information Orig=1 CR=0x8001 CALL PROCEEDING(0x02) 1: CHANNEL ID(0x18) 2: IE Length(0x03) 3: 1------- Extension Bit -0------ Interface ID Present --1----- Interface Type ---0---- Spare ----1--- Preferred/Exclusive -----0-- D-Channel Indicator ------01 Info. Channel Sel. 3.2: 1------- Extension Bit -00----- Coding Standard ---0---- Number Map ----0011 Channel/Map Element 4: 1------- Extension Bit -0000001 Channel Number/Slot Map Time Stamp : 5/9/2012, 11:4:40.462 RECEIVE Response=0 SAPI=0x00 TEI=0x00 0x01 0x02 Receive Ready Time Stamp : 5/9/2012, 11:4:40.502 TRANSMIT Command=0 SAPI=0x00 TEI=0x00 0x02 0x02 Information Orig=1 CR=0x8001 CALL CONNECT(0x07) Time Stamp : 5/9/2012, 11:4:40.502 RECEIVE Response=0 SAPI=0x00 TEI=0x00 0x01 0x04 Receive Ready Time Stamp : 5/9/2012, 11:4:40.502 RECEIVE Command=1 SAPI=0x00 TEI=0x00 0x02 0x04 Information Dest=0 CR=0x0001 CALL CONNECT ACKNOWLEDGE(0x0f) Time Stamp : 5/9/2012, 11:4:40.502 TRANSMIT Response=1 SAPI=0x00 TEI=0x00 0x01 0x04 Receive Ready Time Stamp : 5/9/2012, 11:4:50.502 RECEIVE Command=1 SAPI=0x00 TEI=0x00 0x01 0x05 Receive Ready Time Stamp : 5/9/2012, 11:4:50.502 TRANSMIT Response=1 SAPI=0x00 TEI=0x00 0x01 0x05 Receive Ready Time Stamp : 5/9/2012, 11:4:53.822 RECEIVE Command=1 SAPI=0x00 TEI=0x00 0x04 0x04 Information Dest=0 CR=0x0001 CALL DISCONNECT(0x45) 1: CAUSE(0x08) 2: IE Length(0x02) 3: 1------- Extension Bit -00----- Coding Standard ---0---- Spare ----0010 Location 4: 1------- Extension Bit -0010000 Cause Value Time Stamp : 5/9/2012, 11:4:53.822 TRANSMIT Response=1 SAPI=0x00 TEI=0x00 0x01 0x06 Receive Ready Time Stamp : 5/9/2012, 11:4:53.822 TRANSMIT Command=0 SAPI=0x00 TEI=0x00 0x04 0x06 Information Orig=1 CR=0x8001 RELEASE(0x4d) Share this post Link to post
iTime Report post Posted 05/09/2012 10:23 PM Thanks for the new version and the explanation. I was able to run the patch and obtain the trace file from the dialogic. Please take a look at the trace files. You will see two phone numbers in "....170459.res" file and one in "...170625.res" file. They look a bit different, but the it proves that the Dialogic card is cpaturing callerIDs even calls from outside of the PBX box. (I could not obtain trace for calls within their system) I also added VoiceGuide logs as an attachment. FYI, this Dialogic card is 24 ports, but the VG license they bought is only for 12. (if this matters...) Please let me know how I can make VoiceGuide detect the callerIDs. Thanks. VG_Trace.zip Share this post Link to post
SupportTeam Report post Posted 05/09/2012 11:47 PM The ktTel trace posted stops at 17:05:57 Could you please post the ktTel trace excerpt that covers the call made at 17:12:02 (for which we have the vgEngine and Dialogic traces) ? Share this post Link to post
iTime Report post Posted 05/10/2012 12:43 AM Woops.. Here you go again. Thank you. 0509_ktTel.zip Share this post Link to post
SupportTeam Report post Posted 05/10/2012 01:21 AM Thanks for that.We made some changes to software.Please update system to this version of VoiceGuide:[old link deleted]To update please stop VG service and install new version over the top of old one.Then start the service, place the calls, and stop the service.Please post traces as before. Share this post Link to post
iTime Report post Posted 05/10/2012 04:51 PM Please find the attached logs collected with the new version of VG as instructed. Two calls were made as before: cid is still empty in the VG log, but the trace shows the caller IDs. Thanks a lot. VG_Trace_0510.zip Share this post Link to post
iTime Report post Posted 05/10/2012 09:44 PM Another set of tracing and VG log files just in case... Thanks. VG_Trace_0510_2.zip Share this post Link to post
SupportTeam Report post Posted 05/11/2012 03:03 AM Are internal calls (calls from extensions on PBX) still result in CallerID being retrieved OK by Dialogic/VoiceGuide? If yes then can you please make an internal test call (during which the CallerID is retrieved correctly) and post the Dialogic ISDN traces and ktTel traces. We can then see what is the difference between the way PBX presents the CallerID details on internal and external calls. Can you please advise the PBX Brand/Model ? Share this post Link to post
SupportTeam Report post Posted 05/11/2012 10:04 AM External call ISDN traces look fine, so it is a bit puzzling as to why the Dialogic API responds that it has not received the CallerID number. Comparison with the traces from internal calls should show up the differences, hence the need to see traces from the working 'internal' calls. The following next steps are proposed. 1. Make traces of internal calls on current system. Save the the ISDN and VoiceGuide traces as before. 2. Stop VoiceGuide and Dialogic services, exit all Dialogic programs and uninstall Dialogic drivers. Do NOT save Dialogic configuration at uninstall. 3. Restart system 4. Install Dialogic drivers again 5. Restart system. 6. Select NI2 as the ISDN protocol in DCM, and enable Dialogic tracing (see below). If any other changes are made to Dialogic config then please advise of those. 7. Make two calls into system - internal and external. 8. Collect system snapshot by running C:\Program Files\Dialogic\bin\its_sysinfo.cfg 9. Post Snapshot (.ZIPed), Dialogic RTF traces, ISDN traces, and VoiceGuide traces capturing the call. --------------------------------------- Dialogic logging can be enabled by editing the file: C:\Program Files\Dialogic\cfg\RtfConfigWin.xml Backup RtfConfigWin.xml and then edit it, setting all the entries to "1" in the sections: <!-- Global Call Springware ISDN Translation Layer --> <!-- ISDN Library --> <!-- ISDN Technology Formatter Library --> like below: <!-- Global Call Springware ISDN Translation Layer --> <Module family="SPWR" name="spwrgcis" state="1" technology="PSTN"> <MLabel name="APPL" state="1"/> <MLabel name="DEBG" state="1"/> <MLabel name="INFO" state="1"/> <MLabel name="INTF" state="1"/> <MLabel name="WARN" state="1"/> <MLabel name="EXCE" state="1"/> <MLabel name="ERR1" state="1"/> </Module> <!-- ISDN Library --> <Module family="SPWR" name="libisdnr4.dll" state="1" technology="media"> <MLabel name="APPL" state="1"/> <MLabel name="DEBG" state="1"/> <MLabel name="INFO" state="1"/> <MLabel name="INTF" state="1"/> <MLabel name="WARN" state="1"/> <MLabel name="ERR1" state="1"/> <MLabel name="ERR2" state="1"/> </Module> <!-- ISDN Technology Formatter Library --> <Module family="SPWR" name="isdnspan" state="1" technology="media"> <MLabel name="INTF" state="1"/> <MLabel name="APPL" state="1"/> <MLabel name="INFO" state="1"/> <MLabel name="DEBG" state="1"/> <MLabel name="WARN" state="1"/> <MLabel name="EXCE" state="1"/> <MLabel name="ERR1" state="1"/> </Module> Save modified file. Issue command: rtftool reload after saving the file. the log files will be saved in C:\Program Files\Dialogic\log\ (sample RTF trace attached that captures incoming call with CallerID number set) rtf_isdn_incoming.zip Share this post Link to post
iTime Report post Posted 05/11/2012 08:23 PM Phew~ that required quite an effort to collect all the requested data. Please find the attached files: I saved them in separate folders. The call ending "3433" is the one that shows callerID correctly. (it is from "within the system.") Calls starting "714..." are outside their organization. Other calls are called within their organization, but not within the PBX box. The call by "3433" number was made around 2:41 PM. I hope you could find a solution for this weired issue this time. Thanks a lot! Traces_0511.zip Share this post Link to post
SupportTeam Report post Posted 05/11/2012 08:37 PM Thanks for these, we'll look at them now. Can you advise the PBX Brand/Model ? Share this post Link to post
iTime Report post Posted 05/11/2012 08:41 PM 6. Select NI2 as the ISDN protocol in DCM, and enable Dialogic tracing (see below). If any other changes are made to Dialogic config then please advise of those. I did not change anything but the ISDN protocal during installation as instructed. One thing that bothered me though is that Windows Device manager did not find the correct driver for the board even after installing the driver, and the driver was marked with yellow exclamation mark. I had to click "update driver" then Windows found and installed it. (Not sure if it was a correct behavior.) And because of the hardware issue (as I mentioned at the beginning of this thread), the client had to switch the power dial on the board when inserting to the ePCI slot, and Windows event viewer shows the following warning all the time: "Genload.exe Power Requirement was not met but the user had the power override on, for board in slot0, bus 36, Power Required is 15, and actual power provided is 0" I am not sure if these will interest you, but I am writing these things for just in case. Thanks. Share this post Link to post
SupportTeam Report post Posted 05/11/2012 08:48 PM Could you please advise: - Windows Version - PBX Brand/Model Share this post Link to post
iTime Report post Posted 05/11/2012 09:00 PM It is Windows 2003 Server. I asked the customer PBX model: I will let you know when available. Share this post Link to post
iTime Report post Posted 05/14/2012 03:42 PM The brand/Model of PBX is: Siemens Hicom 300H 80EP Thanks. Share this post Link to post
SupportTeam Report post Posted 05/15/2012 02:58 AM There are a couple of differences between the ISDN flags set on the 'internal' and 'external' incoming calls The 'external' calls (on which the CallerID is NOT read) have: "Numbering Plan" set to "Private" (1001) "Screening Indicator" is set to "User Provided Not Screened" (00) The 'internal' calls (on which the CallerID is read in properly) have "Numbering Plan" set to "National" (0001) "Screening Indicator" is set to "Network provided" (11) Can you please ensure that when the PBX sends the 'external' calls to Dialogic card the "Numbering Plan" is set to "National" (0001). To make the SETUP messages CALLING PARTY NUM segment the same as on the 'internal' calls, the "Screening Indicator" should be set to "Network provided" (11) on 'external' calls as well, but this probably not necessary. Extract of SETUP messages arriving into system: Time Stamp : 5/11/2012, 14:25:58.728 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 7143932211 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63501 Number Digit(s) Time Stamp : 5/11/2012, 14:29:48.608 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 6516953767 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) Time Stamp : 5/11/2012, 14:35:16.768 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x07) 3: 0------- Extension Bit -100---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 62255 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) Time Stamp : 5/11/2012, 14:37:23.248 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 7145976558 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63501 Number Digit(s) Time Stamp : 5/11/2012, 14:41:38.568 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----0001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------11 Screening Indicator 6512663433 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) 1: LOW LAYER COMP.(0x7c) 2: IE Length(0x03) 3: 1------- Extension Bit -00----- Coding Stabdard ---00000 Info. Transfer Cap. 4: 1------- Extension Bit -00----- Transfer Mode ---10000 Info. Transfer Rate 5: 1------- Extension Bit -01----- Layer 1 Indent ---00010 User Info. Layer 1 Time Stamp : 5/11/2012, 14:55:37.688 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 6517664000 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) Time Stamp : 5/11/2012, 14:55:38.128 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 6517664001 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) Time Stamp : 5/11/2012, 15:0:45.568 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 6517664000 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) Time Stamp : 5/11/2012, 15:1:19.448 1: CALLING PARTY NUM(0x6c) 2: IE Length(0x0c) 3: 0------- Extension Bit -010---- Type Of Number ----1001 Numbering Plan ID 3a: 1------- Extension Bit -00----- Presentation Indicator ---000-- Spare ------00 Screening Indicator 6517482510 Number Digit(s) 1: CALLED PARTY NUM(0x70) 2: IE Length(0x06) 3: 1------- Extension Bit -010---- Type of Number ----0001 Numbering plan ID 63466 Number Digit(s) VoiceGuide software log extract, showing for which calls Dialogic drivers were able to supply the CallerID number: 142558.718 5348 2 ev GCEV_OFFERED crn=2800001 (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 142558.718 5348 2 not retrieved: UUI 142558.718 5348 2 not retrieved: ANI 142558.718 5348 2 not retrieved: ORIGINATION_ADDRESS 142558.718 5348 2 not retrieved: CALLNAME 142558.718 5348 2 ani: orig: name: dnis: 63501 dest: 63501 142943.065 5348 2 ev GCEV_OFFERED crn=280000d (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 142943.065 5348 2 not retrieved: UUI 142943.065 5348 2 not retrieved: ANI 142943.065 5348 2 not retrieved: ORIGINATION_ADDRESS 142943.065 5348 2 not retrieved: CALLNAME 142943.065 5348 2 ani: orig: name: dnis: 63466 dest: 63466 143506.675 5348 2 ev GCEV_OFFERED crn=280000e (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 143506.675 5348 2 not retrieved: UUI 143506.675 5348 2 not retrieved: ANI 143506.675 5348 2 not retrieved: ORIGINATION_ADDRESS 143506.675 5348 2 not retrieved: CALLNAME 143506.675 5348 2 ani: orig: name: dnis: 63466 dest: 63466 143712.395 5348 2 ev GCEV_OFFERED crn=280000f (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 143712.395 5348 2 not retrieved: UUI 143712.395 5348 2 not retrieved: ANI 143712.395 5348 2 not retrieved: ORIGINATION_ADDRESS 143712.395 5348 2 not retrieved: CALLNAME 143712.395 5348 2 ani: orig: name: dnis: 63501 dest: 63501 144126.879 5348 2 ev GCEV_OFFERED crn=2800010 (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 144126.879 5348 2 not retrieved: UUI 144126.879 5348 2 not retrieved: CALLNAME 144126.879 5348 2 ani: 6512663433 orig: 6512663433 name: dnis: 63466 dest: 63466 145525.480 5348 2 ev GCEV_OFFERED crn=2800011 (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 145525.496 5348 2 not retrieved: UUI 145525.496 5348 2 not retrieved: ANI 145525.496 5348 2 not retrieved: ORIGINATION_ADDRESS 145525.496 5348 2 not retrieved: CALLNAME 145525.496 5348 2 ani: orig: name: dnis: 63466 dest: 63466 145525.933 5348 4 ev GCEV_OFFERED crn=2800002 (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 4) 145525.933 5348 4 not retrieved: UUI 145525.933 5348 4 not retrieved: ANI 145525.933 5348 4 not retrieved: ORIGINATION_ADDRESS 145525.933 5348 4 not retrieved: CALLNAME 145525.933 5348 4 ani: orig: name: dnis: 63466 dest: 63466 150033.358 5348 2 ev GCEV_OFFERED crn=2800012 (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 150033.358 5348 2 not retrieved: UUI 150033.358 5348 2 not retrieved: ANI 150033.358 5348 2 not retrieved: ORIGINATION_ADDRESS 150033.358 5348 2 not retrieved: CALLNAME 150033.358 5348 2 ani: orig: name: dnis: 63466 dest: 63466 150107.216 5348 2 ev GCEV_OFFERED crn=2800013 (ktTel_SR60 v7.3.1, May 10 2012 11:33:56) (setting hli->crn for line 2) 150107.216 5348 2 not retrieved: UUI 150107.216 5348 2 not retrieved: ANI 150107.216 5348 2 not retrieved: ORIGINATION_ADDRESS 150107.216 5348 2 not retrieved: CALLNAME 150107.216 5348 2 ani: orig: name: dnis: 63466 dest: 63466 Dialogic RTF log extract, for two calls, first which shows error returned when trying to retrieve CallerID, second that shows CallerID returned OK. 05/11/2012 14:25:58.718 5168 5348 spwrgcis INTF gcis dtiB1T1 <:::: gcis_GetANI(2, 0x80000001, 0xce1fe10) entry 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll APPL <:::: cc_GetANI(0x80000001, 0xce1fe10) entry 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll DEBG ----- IsdnGetCRNEntry(Crn:0x80000001, lpCallInfo:0xcbd9aec) returns TRUE 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- cc_GetANI(CRN:0x80000001) on LineDev:2 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnSetLastError(LineDev:2, nNewError:0x303) returns success 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll ERR1 dtiB1T1 ::::> cc_GetANI(Crn:0x80000001) returns 0x303 due to (szNetworkANI[0] == '') 05/11/2012 14:25:58.718 5168 5348 spwrgcis ERR1 gcis dtiB1T1 ::::> gcis_GetANI() returns -1 due to cc_GetANI(0x80000001) failed 05/11/2012 14:25:58.718 5168 5348 gc ERR1 gclib dtiB1T1 ::::> gc_GetANI(crn:0x2800001h, ani:) - returns:-1 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll DEBG ::::> cc_geterror() returns: 0x303 05/11/2012 14:25:58.718 5168 5348 spwrgcis DEBG gcis find_cclib_error_index(0x303) returns: 0x76 05/11/2012 14:25:58.718 5168 5348 spwrgcis INTF gcis gcis_ErrorValue() returns gc_error: 0x303 with cc_error:x89 05/11/2012 14:25:58.718 5168 5348 spwrgcis INTF gcis gcis_GetCallInfo(0x80000001, 0x107, 0xce1fe74) entry 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll APPL <:::: cc_GetANI(0x80000001, 0xce1fe74) entry 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll DEBG ----- IsdnGetCRNEntry(Crn:0x80000001, lpCallInfo:0xcbd9af0) returns TRUE 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- cc_GetANI(CRN:0x80000001) on LineDev:2 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnSetLastError(LineDev:2, nNewError:0x303) returns success 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll ERR1 dtiB1T1 ::::> cc_GetANI(Crn:0x80000001) returns 0x303 due to (szNetworkANI[0] == '') 05/11/2012 14:25:58.718 5168 5348 spwrgcis ERR1 gcis gcis_GetCallInfo() returns -1 due to cc_GetANI(0x80000001) failed 05/11/2012 14:25:58.718 5168 5348 gc ERR1 gclib ::::> gc_GetCallInfo(crn:0x2800001h, info_id:263) - returns;-1 05/11/2012 14:25:58.718 5168 5348 libisdnr..ll DEBG ::::> cc_geterror() returns: 0x303 05/11/2012 14:25:58.718 5168 5348 spwrgcis DEBG gcis find_cclib_error_index(0x303) returns: 0x76 05/11/2012 14:25:58.718 5168 5348 spwrgcis INTF gcis gcis_ErrorValue() returns gc_error: 0x303 with cc_error:x89 05/11/2012 14:25:58.718 5168 5348 spwrgcis INTF gcis gcis_GetCallInfo(0x80000001, 0x102, 0xce1ffa0) entry 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll APPL <:::: cc_GetANI(0x80000010, 0xce1fe10) entry 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll DEBG ----- IsdnGetCRNEntry(Crn:0x80000010, lpCallInfo:0xcbd9aec) returns TRUE 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- cc_GetANI(CRN:0x80000010) on LineDev:2 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll dtiB1T1 APPL dtiB1T1 ::::> cc_GetANI(Crn=0x80000010) return 0 (szANI:6512663433) 05/11/2012 14:41:26.879 5168 5348 spwrgcis INTF gcis dtiB1T1 ::::> gcis_GetANI() returns 0 with ANI:6512663433 05/11/2012 14:41:26.879 5168 5348 spwrgcis INTF gcis gcis_GetCallInfo(0x80000010, 0x107, 0xce1fe74) entry 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll APPL <:::: cc_GetANI(0x80000010, 0xce1fe74) entry 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll DEBG ----- IsdnGetCRNEntry(Crn:0x80000010, lpCallInfo:0xcbd9af0) returns TRUE 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- cc_GetANI(CRN:0x80000010) on LineDev:2 05/11/2012 14:41:26.879 5168 5348 libisdnr..ll dtiB1T1 APPL dtiB1T1 ::::> cc_GetANI(Crn=0x80000010) return 0 (szANI:6512663433) Numbering Plans: Unknown = 0000 ISDN Numbering Plan E.164 = 1000 Data Numbering Plan X.121 = 1100 Telex Numbering Plan F.69 = 0010 National Numbering Plan = 0001 Private Numbering Plan = 1001 Reserved = 1111 Share this post Link to post
SupportTeam Report post Posted 05/16/2012 11:08 PM Dialogic sample app gc_basic_call_model can be used as well to verify Dialogic cards reporting of CallerID. The gc_basic_call_model app can be found in C:\Program Files\Dialogic\demos\basic_call_model File gc_basic_call_model.cfg needs to be edited before running the demo app. More instructions on gc_basic_call_model can be found here: http://www.dialogic.com/~/media/manuals/docs/globalcall_demo_v2.pdf Share this post Link to post
iTime Report post Posted 05/17/2012 05:49 PM Our client stated it is not possible to change the "numbering plan" as you have suggested, explaining their system as below. (Please see the quote box for the comment from their telecom technician) Do you have any other solutions for this issue? Our client says the signal carries CallerIDs to the Dialogic card, and you say Dialogic card does not provide CallerID to VoiceGuide, and we seemed to get lost here. Would it also be possible for you to provide a direct communication channel (such as email) to our client as they want to discuss with you directly? Thank your for your prompt support again. Ramsey County telecom is using 11 pbx (Siemens cbx) for they telecommunications network. The system are all integrated into 1 private system the end user can access other user through out the campus with 5digits dialing via of internal Isdn tie line (Cornet). This show the exten and name of the calling party at the called exten. The pbx where the server resides is off a remote pbx using the private network and is routing to the time server the call are being forward on a private network M 05 SETUP I 04 BEARER CAPABILITY.......Len= 3 90 Coding Standard...........CCITT Transfer Capa.....3.1 kHz audio 90 Transfer Mode...........Circuit Transfer Rate.........64 kbit/s A2 Layer 1 Protocol..........u-law I 18 CHANNEL ID..............Len= 3 A9 Indicated Channel.....Exclusive Channel Selection............B1 Channel Identifier.....Not D-CH I 1E PROGRESS INDICATOR......Len= 2 8A Coding Standard...........CCITT Location.Network beyond interwo rking point 83 Desc:...Orig call addr non-ISDN I 6C CALLING PARTY NUMBER....Len= 12 29 Type of Address........National Numbering Plan ID.......Private 80 Presentation Ind........Allowed Screen Ind....user-not screened 6128168250 I 70 CALLED PARTY NUMBER.....Len= 6 A1 Type of Number..National Number Numbering Plan ID..........ISDN 63466 Hex:02 01 0A 08 08 02 31 6D 05 04 03 90 90 A2 18 03 A9 83 81 1E 02 8A 83 6C 0C 29 80 36 31 32 38 31 36 38 32 35 30 70 06 A1 36 33 34 36 36 Share this post Link to post
SupportTeam Report post Posted 05/17/2012 09:58 PM Can you please run Dialoigc's gc_basic_call_model sample application and place two calls into the system - one external and one internal. (VoiceGuide service would need to be stopped first) Then please post the gc_basic_call_model applications output. To enable the ISDN channel it should be sufficient too make this change in the gc_basic_call_model.cfg file : in this section "For ISDN Protocols" change this: ############################################################################################## # For ISDN Protocols # Board #1 #dtiB1T1 ISDN In NONE 1234567 0 # # Board #2 #dtiB2T1 ISDN Out NONE 1234567 0 ############################################################################################## to this: ############################################################################################## # For ISDN Protocols # Board #1 dtiB1T1 ISDN In NONE 1234567 0 # # Board #2 #dtiB2T1 ISDN Out NONE 1234567 0 ############################################################################################## ie. just remove the "#" at the beginning of the "dtiB1T1 ..." line. After placing the call just hang up after a few rings or when call is answered. As this demo script opens the 1st channel on T1 only then you would need to ensure that calls arrive on the 1st channel. The traces showing previous calls show that it should. Please post the results and any other questions/comments in this thread, so that all information regarding this issue is in one thread. Share this post Link to post
iTime Report post Posted 05/18/2012 12:31 AM I have no problem running the sample application as you requested, but the point is: will it prove that our client's phone system is faulty or abnormal that they should change something? I need to provide that kind of information in order to convince their Telecom Technicians. Please let me know what this application is to prove. I will try to do my homework in the meantime. Thanks. Share this post Link to post
SupportTeam Report post Posted 05/18/2012 03:02 AM Running the Dialogic's own test application will confirm how the CallerID is received by Dialogic card/drivers when the incoming calls (internal and external) are made. Forgot to mention before that we will also need to see the Dialogic RTF logs capturing the incoming (internal and external) calls while the Dialoigc's gc_basic_call_model sample application is running. The gc_basic_call_model output and the RTF logs need to be viewed together. When we see those logs we can better see where the fault lies. Share this post Link to post
iTime Report post Posted 05/18/2012 11:04 PM I was able to collect log files for an "External" call and post it here first. I will try to collect files for an "Internal" call when our client is available. Please let me know if you find anything new from this log. Thanks. GCLogs_ExternalCall.zip Share this post Link to post
SupportTeam Report post Posted 05/19/2012 12:27 AM We can see that when using Dialogic's gc_basic_call_model demo app the same issue is occurring. On these 'external' calls where the Numbering Plan is set to 'Private' the Dialogic's drivers are not retrieving the CallerID information from ISDN SETUP message and/or not reporting the CallerID information when asked for it. This would need to be raised with Dialogic, which is usually done through the card supplier. As the Dialogic card that is used on this system was not purchased through VoiceGuide, the card supplier needs to be contacted and the issue raised with them. Once card supplier can demonstrate Dialogic's gc_basic_call_model demo app correctly retrieving/reporting the CallerID information then VoiceGuide software will also be able to receive the CallerID information on those calls. gc_basic_call_model trace extract: 05/18 15:28:21.338 [MISC]: ********* Received a GC event ********* 05/18 15:28:21.338 [EVENT]: GCEV_OFFERED 05/18 15:28:21.338 [sTATE]: GCST_NULL is the current GC call state 05/18 15:28:21.338 [GC_APICALL]: gc_GetCallInfo(crn=0x2800001) Success - called party = 63501 05/18 15:28:21.338 [GC_APICALL]: gc_GetCallInfo(crn=0x2800001) Failure - calling party not available 05/18 15:28:21.338 [GC_APICALL]: gc_AcceptCall(crn=0x2800001, mode=EV_ASYNC) Success 05/18 15:28:21.338 [sTATE]: GCST_OFFERED is the new GC call state after processing the event RTF log entry: 05/18/2012 15:28:21.338 5920 2912 isdnspan INTF isdnntfentry dtiB1T1 <==== NTFI_GetAsyncResults: Calling Formatter Function IsNtf_Recv_WaitCall 05/18/2012 15:28:21.338 5920 2912 isdnspan INFO isdnntfentry dtiB1T1 <---- DevArea Reply: 05 00 36 00 3a 00 03 81 - VarDataSize=272 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 INTF dtiB1T1 <==== IsdnWaitCallReplyHandler(2, 0x169110) 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll DEBG <---- IsdnFillIEData(0x169214, 58, 0x10eff28, 0x16a7c8, 0x824) entry 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- IsdnFillIEData() on LineDev:2 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnFillIEData() with BEARER_CAPABILITY_IE 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll DEBG ----> IsdnCopyChannelIDIE(0x16921b, 0x16a7c8) returns 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnFillIEData() with CHANNEL_ID_IE 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll DEBG ----- IsdnCopyCalledNumberIE(0x169221, 0x16a7c8), ie_len:5 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnFillIEData() with CALLED_NUMBER_IE 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnFillIEData() - nNumIEs = 0,nTotalLength=36 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- IsdnFillIEData() - lpIE_BLK->length=36 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----> IsdnFillIEData(LineDev:2) returns new event:0x824 05/18/2012 15:28:21.338 5920 2912 spwrgcis DEBG gcis_internal dtiB1T1 <==== gcis_ProcessGCEvent(2, 0x824, 21, 0x10eff28, 0x0) entry 05/18/2012 15:28:21.338 5920 2912 spwrgcis INFO gcis_internal dtiB1T1 ----- Sending GCEV_DETECTED before CCEV_OFFERED 05/18/2012 15:28:21.338 5920 2912 spwrgcis INFO gcis_internal dtiB1T1 ----- Processed CCEV_OFFERED 05/18/2012 15:28:21.338 5920 2912 spwrgcis DEBG gcis_internal dtiB1T1 ----- CC event:0x824 mapping to GC event:GCEV_OFFERED(0x824) 05/18/2012 15:28:21.338 5920 2912 spwrgcis DEBG gcis_internal dtiB1T1 ----- Sending event:GCEV_OFFERED(0x824) 05/18/2012 15:28:21.338 5920 2912 spwrgcis DEBG gcis_internal dtiB1T1 ====> gcis_ProcessGCEvent() returns 0 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ====> IsdnWaitCallReplyHandler(LineDev:2, Crn:0x80000001) posts event:0x824(CCEV_OFFERED, EDT_SUCC) in (dwErrorCode=0) and (CW_Flag=FALSE) 05/18/2012 15:28:21.338 5920 2912 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ====> IsdnWaitCallReplyHandler(LineDev:2, Crn:0x80000001) returns. 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_GetCRN(0x12ec88, 0x2f6f2b0) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll APPL <:::: cc_GetCRN(0x12ec88, 0x2f6f2b0) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll APPL ::::> cc_GetCRN(*Crn=0x80000001) return 0 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_GetCRN() returns 0 with *crn:0x80000001 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis dtiB1T1 <:::: gcis_GetUsrAttr(2, 0x12ecc4) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll dtiB1T1 APPL dtiB1T1 <:::: cc_GetUsrAttr(2, 0x12ec48) 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll dtiB1T1 APPL dtiB1T1 ::::> cc_GetUsrAttr(LineDev:2) return 0 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis dtiB1T1 ::::> gcis_GetUsrAttr() returns 0 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_GetExtEvtDatap(0x12ec60, 0x2f6f2b0) returns 0 with *extEvtDatap:0x0 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_GetCallInfo(0x80000001, 0x108, 0x12dfa8) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll APPL <:::: cc_GetDNIS(0x80000001, 0x12dfa8) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll DEBG ----- IsdnGetCRNEntry(Crn:0x80000001, lpCallInfo:0x12dec0) returns TRUE 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- cc_GetDNIS(CRN:0x80000001) on LineDev:2 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll dtiB1T1 APPL dtiB1T1 ::::> cc_GetDNIS(Crn=0x80000001) return 0 (szDNIS:63501) 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_GetCallInfo() returns 0 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_GetCallInfo(0x80000001, 0x107, 0x12df28) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll APPL <:::: cc_GetANI(0x80000001, 0x12df28) entry 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll DEBG ----- IsdnGetCRNEntry(Crn:0x80000001, lpCallInfo:0x12deac) returns TRUE 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll dtiB1T1 DEBG dtiB1T1 ----- cc_GetANI(CRN:0x80000001) on LineDev:2 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll dtiB1T1 INFO dtiB1T1 ----- IsdnSetLastError(LineDev:2, nNewError:0x303) returns success 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll ERR1 dtiB1T1 ::::> cc_GetANI(Crn:0x80000001) returns 0x303 due to (szNetworkANI[0] == '') 05/18/2012 15:28:21.338 5920 5700 spwrgcis ERR1 gcis gcis_GetCallInfo() returns -1 due to cc_GetANI(0x80000001) failed 05/18/2012 15:28:21.338 5920 5700 gc ERR1 gclib ::::> gc_GetCallInfo(crn:0x2800001h, info_id:263) - returns;-1 05/18/2012 15:28:21.338 5920 5700 libisdnr..ll DEBG ::::> cc_geterror() returns: 0x303 05/18/2012 15:28:21.338 5920 5700 spwrgcis DEBG gcis find_cclib_error_index(0x303) returns: 0x76 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_ErrorValue() returns gc_error: 0x303 with cc_error:x89 05/18/2012 15:28:21.338 5920 5700 spwrgcis INTF gcis gcis_CRN2LineDev(0x80000001, 0x12de8c, 0x12de88) entry Share this post Link to post
iTime Report post Posted 05/24/2012 03:51 PM I have been talking to the Dialogic support team and they mentioned the same thing that "Private" numbering plan is the issue. They also suggested using another API (see below) as "work around." The numbering plan being private is the reason why gc_GetCallInfo API is displaying number not available. Did you try using the gc_GetANI( ) API? Share this post Link to post
SupportTeam Report post Posted 07/25/2012 10:46 PM Entire contents of the ISDN SETUP message are now available to VG Script using $RV[iSDN_SETUP] CallerID information can be extracted from $RV[iSDN_SETUP] regardless of the numbering plan used. Share this post Link to post
