Difference between revisions of "SynIPR FAQ"

Latest revision as of 11:39, 12 May 2015

What protocols and RTP codecs do SynIPR support now?

Supported protocol:

For SynCTI Ver. 5.3.2.7: SIP, CISCO SCCP, AVAYA H323, SHORTEL MGCP, H323, PANASONIC MGCP, TOSHIBA MEGACO, SIEMENS H323, ALCATEL, MITEL, LG Nortel.

For other versions, refer to the section “1.23.9.2 Supported Protocol” in SynCTI Programmer's Manual.pdf.

Supported RTP Codec: G.711A, G.711U, G.729A/B、G.722.

Note: The supported protocols mentioned above are all standard. Any protocol, if encrypted, will be not supported.

Can SynIPR work under Linux?

Yes. For a 64-bit Linux operating system, you shall use SynCTI Ver. 5.3.2.3 or above versions.

Can SynIPR run on virtual machines?

SynIPR can run on virtual machines as long as the following conditions are met:

1) The USBKey can be recognized;

2) The network card is mapped;

3) The HASP has been installed correctly.

Can SynIPR work under Win8 operating system?

Yes. But you are required to use SynCTI Ver. 5.3.2.3 or above versions as it adopts winpcap 4.1.3. Win8 operating system does not support winpcap versions below 4.1.3.

What are the commonly used events to start/stop recording in SynIPR programming?

Generally, the application will start recording upon the detection of the event E_RCV_IPR_MEDIA_SESSION_STARTED and stop recording upon the detection of the event E_RCV_IPR_MEDIA_SESSION_STOPED. Also, you can designate other events to start and stop recording according to actual requirements.

Can SynIPR obtain callerID and calleeID?

Yes. If the monitoring protocol supports the call control events under the D-channel events, the callerID and the calleeID can be obtained via the parameters szCallerId and szCalledId in the structure tagIPR_CALL_INFO of the pvBuffer pointer in such call control events as DST_CALL_IN_PROGRESS, DST_CALL_ALERTING and DST_CALL_CONNECTED. If the monitoring protocol does not support the call control events, the callerID and calleeID can be obtained via the pointer pvBuffer in the LCD events under the D-channel events.

How to judge the call direction in SynIPR?

If the monitoring protocol supports the call control events under the D-channel events, the call direction can be judged via the parameter CallSource in the structure tagIPR_CALL_INFO of the pvBuffer pointer in such call control events as DST_CALL_IN_PROGRESS, DST_CALL_ALERTING and DST_CALL_CONNECTED.

What is the difference between the two monitoring modes "Monitor by Station" and "Monitor All"?

“Monitor by Station” means to monitor designated stations, while “Monitor All” indicates to monitor all calls.

Can a SynIPR channel be bound with a designated IP phone?

Yes. You can bind a SynIPR channel to an IP phone by the following method: define a Station and add such information as the IP address, MAC address and port of the designated IP phone to the Station. Then invoke the function SsmIPRAddStationToMap to add the Station to the map list.

=What to do to increase/decrease the amount of SynIPR channels or to prolong the time of authentication?

Please feel free to contact our salespersons for authentication upgrade.

Why does the application detect the event E_RCV_IPR_AUTH_OVERFLOW (authentication overflow)? How to deal with it?

Possible causes:

1) A call has multiple sessions (such as a call with multiple parties or a call conference) and the total amount of sessions is larger than the authenticated number.

2) Due to network topology or PBX configuration, the monitoring port is transmitting or receiving messages of the current protocol other than the signaling messages. The driver mistakes such messages for active Stations. Thus, the total amount of Stations is larger the authenticated number.

For case 2), we recommend that you select the “Monitor by Station” mode to monitor the designated extension/IP address/MAC address.

Why does the recorded file come out silent?

Possible Causes:

1) Fail to invoke the function SsmIPRSendSession.

2) The mirroring port does not duplicate the RTP data, which leads to the loss of RTP packages.

3) The RTP codec of the monitored IP phone is not supported by Synway’s driver. You shall modify the RTP codec to a supported one.

To confirm the actual cause of the problem, you shall send such information as the API log of the application, the network data package captured by wireshark or similar software and the configuration files to our technicians to further analyze the problem.

Why does the recorded file only contain one party's voice?

Possible Causes:

1) The mirroring port only sends one party’s RTP package.

2) The two sides of the conversation use different RTP codecs either of which is not supported by Synway’s driver. In such case, you shall modify the configurations of the phone.

To confirm the actual cause of the problem, you shall send such information as the API log of the application, the network data package captured by wireshark or similar software and the configuration files to our technicians to further analyze the problem.