********************************************************************* * PIKA Warp 2.0.5.8 Engineering Build Readme File * ********************************************************************* IMPORTANT! PLEASE NOTE THIS IS A SPECIAL ENGINEERING RELEASE The files in this patch have been tested by the R&D department to verify issue resolution and general sanity only. ------------------- RELEASE INFORMATION ------------------- PATCH REQUIREMENTS: AoH 2.7.7.6, GrandPrix 2.7.7.4, chan_pika 3.6.5.7 REASON FOR RELEASE: See issues resolved below. POTENTIAL ISSUES: None FILES AFFECTED: Requires build and re-flash of persistent and ramdisk images COMMENTS: Combines AoH 2.7.7, GrandPrix 2.7.7, chan_pika 3.6.5 and Warp fixes. --------------- ISSUES RESOLVED --------------- --------------- Issues resolved in chan_pika 3.6.5 --------------- 6395: Calling from an extension (FXS, SIP, etc) to a mobile doesn't work properly. The problem is that the CO doesn't CONNECT the call before playing a message and GrandPrix/chan_pika couldn't receive the audio before being answered. - The PKX_EVENT_CALL_EARLYMEDIA event is now handled and changes the Asterisk channel state to UP, allowing the audio to go back and forth. Also, the new PKX_TCallInfo.interworkingPresent value will be stored during the INCOMING_CALL event and the EARLY_MEDIA message will be sent back, enabling the audio path for any necessary inband data (message, ringback, etc). --------------- Issues resolved in GrandPrix 2.7.7 --------------- 6395: GrandPrix wasn't prepared to handle the interworking present information if it is available nor sending the Early Media notification back to the CO. -GrandPrix will now handle the interworking present information: * For BRI: PKH_CSTKConnIndication.interworking * For PRI: PKH_TISDNProgressIndIE.progressDescription -The PKX_TCallInfo received a new field called interworkingPresent. If, during an incoming call, this field is set, the caller side must generate the media indicator (ringback, etc...). 6424: An FXO call cannot be terminated after a transfer attempt failed due to an invalid number string or if the called number was busy. Once the original call is resumed, the user is unable to drop the original call because GrandPrix failed to re-seize the channel resources properly. -The fix includes ensuring that dtmf detection and tone detection are re-enabled when the call is resumed. The fix also includes changes to GPTest to ensure the proper call is release when the calls are dropped with a transfer cause. 6461 GrandPrix issues an incorrect response to a Re-INVITE message, "500 Internal Server Error", if a supported codec type is not found in the payload. This invalid response causes GrandPrix to terminate the call. -If a supported codec type is not found in a Re-INVITE message, GrandPrix will respond with a "415 Unsupported Media Type" message. The original connection will not be modified allowing the remote side to decide whether to continue with the initial setup or terminate the call. ----------------- Issues resolved in PADS 2.0.4 ------------------ 6280: The Warp LCD has a problem with the phone and trunk icons in that the phone icon sometimes disappears and the trunk icon does not always light up when in use. - Astmanproxy has been moved to autorun so that it is started before Asterisk. The handshaking mechanism between chan_pika and astmanproxy has been improved in version 1.0.0.6 of astmanproxy. astmanproxy.mk has been updated to retrieve the latest version. --------------- Issues resolved in chan_pika 3.6.4 --------------- 6218: When making an outgoing call to some numbers using the BRI interface, it is possible not to receive the ringback. This is caused because the network is indicating that the device should provide the ringback. - The information received from the network is reported by GP to the application (chan_pika) using the PKX_CALL_EARLY_MEDIA event. Therefore, chan_pika was modified to handle this event properly, asking Asterisk to generate the ringback. 6243: The audio path stops working (in one direction) after performing a transfer from a natively bridged call to non natively bridged extensions. - The nativebridged flag in the pika_pvt struct is not correctly cleared when performing the transfer. The fix is that during the masquerade portion of the transfer, the private struct is updated and the nativebridge flag is cleared. 6322: If an outgoing call is dropped as soon as the called party answers, Asterisk crashes. This is due to the SPEECH_OFF event handler using a pointer before testing if it is valid. If the call is dropped too soon, the SPEECH_OFF event could be raised after the object is destroyed. - The pointer is no longer used the if the oject is destroyed first. 6060: When an error occurs before starting the fax sending/receiving, all resources are kept open, which can cause Asterisk to crash. - When an error occurs, all resources are now checked and then released. --------------- Issues resolved in GrandPrix 2.7.6 --------------- 6206: The FXO port is shown as "IN_USE" in Asterisk and cannot be recovered unless we reconnect the cable or restart the machine. The problem seems to occur when the call is dropped during the ring. Grandprix doesn't properly handle disconnections during the ring. - To fix this, it was necessary to modify the drop() method in the CTrunkCall class. The drop() method accepts calls in the DETECTED and OFFERED states and, when in those states, calls the disconnected() event instead. This allows the channel to disconnect properly when the drop() method is called during the ring. 6248: GrandPrix SIP calls are not disconnected after issuing a PKX_CALL_TransferBlind API call. If the remote user agent fails to respond to the REFER message sent by GrandPrix to initiate the blind transfer operation, the SIP call is left connected and no feedback is provided to the user on the outcome of the transfer request. - Once the blind transfer operation has been initiated, GrandPrix will disconnect the SIP call as soon as possible. If the remote agent fails to respond to the REFER message, GrandPrix will disconnect the call as soon as the specified timer expires. The user will be provided feedback on the outcome of the blind transfer request as a disconnect cause code. In such case that the remote agent failed to respond to the REFER message, the cause will be set to "timed out". 6305: The RTP media resources are not cleaned up properly if a CANCEL message is received by GrandPrix after a 200 OK final response has been issued. The SIP channel becomes unusable and subsequent calls handled by this channel fail to connect because the RTP stream is already activated. - CANCEL messages are ignored by GrandPrix if the incoming call is not in the OFFERED or ALTERTING state. A 200 OK response is always sent back to the remote agent to acknowledge the CANCEL message. In such case that the user has already called the PKX_CALL_Answer API and GrandPrix has issued a final 200 OK response to the INVITE message but before the CANCEL message is received, GrandPrix will ignore the CANCEL and will wait for an ACK message to complete the INVITE transaction. If the ACK is not received within the alloted time, the call will be terminated with a BYE message and the SIP channel will be freed up. The disconnect cause code will be set to "timed out". --------------- Issues resolved in chan_pika 3.6.3 --------------- 5681: Polarity reversal on analog lines is not handled correctly in the channel driver. - Since GP won't consider the call answered by speech detection if it is not set in the configuration files, chan_pika will wait for the PKX_EVENT_CALL_CONNECTED to start monitoring the SPEECH_OFF event. This will allow scenarios where there is audio before answer. 5685: Asterisk 'hints' functionality was not implemented in chan_pika. - The devicestate callback was created to check the FXS status and send the correct values to Asterisk. This is only available in Asterisk >= 1.4. 6162: Some configuration settings from the [audio] section of pika.conf are not read in correctly during initial startup and a 'pika reload' must be performed to change them. - Due to changes in chan_pika, some functions ended up being called in the wrong order, such as pika_audio_init(). All functions are now being called in the correct order and the audio port is setup correctly. 6186: The calling party continues to hear the ringback even if the call was dropped without answer. This only happens when receiving an incoming call via the BRI interface, ringing directly to a SIP extension (DID) and this extension doesn't answer. - In chan_pika, it was necessary to add a new test for STATE_ACCEPTED in pika_hangup(). This allows the call to be dropped properly. 6233: Documentation - Release Notes had the wrong link for fpga files. Links to fpga files have been corrected. --------------- Issues resolved in GrandPrix 2.7.5 --------------- 5914: Speech detection is enabled by the recording function. However, when recording is stopped by the PKX_CHANNEL_Stop API, speech detection is disabled without checking what other media operations may be using this feature. - Speech detection is monitored by the tone detection object which increments a counter every time speech detection is requested and decrements the counter when it is no longer needed. The record operation disabled speech detection regardless of the counter value. It has now been modified to respect the speech detection counter. 6186: When a BRI port receives an incoming call and the called party hangs up the call right after the call is accepted, the caller will continue to hear ringing. The ALERT_RQ command is sent, but the link isn't in the UP state yet so the call cannot be cleared properly, keeping the caller party ringing. - The CBriCall class was modified to raise the PKX_EVENT_CALL_ACCEPTED event only after the link state is UP. This ensures that the CSTK messages are sent when necessary, clearing the call. --------------- Issues resolved in chan_pika 3.6.2 --------------- 5330: When Asterisk receives an incoming call, it is sometimes necessary to store the number with the leading zeroes. For chan_zap, this is done using the internationalprefix and nationalprefix available in zapata.conf file - (0), (00). GrandPrix does not currently retrieve this information from AoH so there is no way for chan_pika to make use of it. - GrandPrix has been modified to retrieve the Called and Calling Party Number information element from an ISDN message (BRI or PRI). The information retrieved, such as Number Type and Number Plan, is now available in the PKX_TCallInfo structure. New configuration options added to pika.conf (chan_pika): internationalprefix nationalprefix These options are available but not included by default in pika.conf: localprefix privateprefix unknownprefix 6126: When making a BRI outgoing call, the user cannot hear the ring back tone in their SIP or FXS phone. This is caused by the fact that chan_pika enables the audio path as soon as the dial command starts, enabling the audio from the telco, which isn't always true in digital lines. - The solution here is to let Asterisk generate the ring back tones when a BRI port is used. Basically the audio path will be established only when the call is answered. 6159: Performing a hookflash on an fxs phone does not behave as expected. There is no dialtone and the call is answered by the default dialplan after a while. This is caused because the PKX_CHANNEL_PlayTonePattern() function sets the MaxDigits parameter to 1 but there is no call to PKX_CHANNEL_ClearDigits(). Therefore, the second call to PKX_CHANNEL_PlayTonePattern() uses the last digits from the previous call in the GP internal buffer. - Add PKX_CHANNEL_ClearDigits() before PKX_CHANNEL_PlayTonePattern() to ensure that the digit buffer is empty. 6169: Audio path isn't restored after the user returns from a hook flash without making the transfer. - Chan_Thread (which controls the dialtone, etc) calls PKX_CHANNEL_Stop() function and waits for its completion. 6170: With the solution implemented for TT 6126, the ring back is also heard when there is no cable connected to the BRI spans. - The ring back was inserted into the ALERTING event handler. --------------- Issues resolved in GrandPrix 2.7.2 --------------- 5330: When Asterisk receives an incoming call, it is sometimes necessary to store the number with the leading zeroes. For chan_zap, this is done using the internationalprefix and nationalprefix available in zapata.conf file - (0), (00). GrandPrix does not currently retrieve this information from AoH so there is no way for chan_pika to make use of it. - GrandPrix has been modified to retrieve the Called and Calling Party Number information element from an ISDN message (BRI or PRI). The information retrieved, such as Number Type and Number Plan, is now available in the PKX_TCallInfo structure. 6024: Incoming SIP calls originated from an Alcatel PBX fail to connect. GP responds to the SIP INVITE message with a 180 RINGING message, however the 200 OK message fails to be sent out because GP is waiting on a provisional response acknowledgment message. - According to voip-info.org, PRACK implementation problems are seen in the field. A SIP UA indicates support for this standard by including a "Supported: 100rel" or "Required: 100rel" as a SIP header. Several major SIP stacks, have shown problems with it, at least in some older releases. The SIP headers claim to support it or require it, but when you send them a non-100 1xx message, they don't PRACK it. A new configuration value has been added to the reliable_provisional_response sip_user agent configuration key to allow users to ignore the "Supported: 100rel" or "Required: 100rel" headers if they know that their remote stack does not support it. Changes to configuration parameters: Configuration file and section: pikagp_aoh.cfg, section sip_users Parameter name: reliable_provisional_response Values: enabled, disabled and ignored (NEW) Default Value: disabled 6025: The GrandPrix dll is not unloaded properly when the PKX_SYSTEM_Close() API function is called. - The FreeLibrary() system call has been added to the PKX_SYSTEM_Close() API function. The dll will now unload properly. Note that this applies to Microsoft Windows only. 6048: The play operation stops unexpectedly after a PKX_EVENT_CHANNEL_UNDERFLOW_PLAY event is generated. Any subsequent buffers added are ignored unless the play operation is restarted by the user application. - GrandPrix attempts to pause the play operation when an underflow event is received from AoH. If timing is perfect this pause attempt becomes a full stop. The play function has been modified so that it does not stop the AoH play operation unless the user application has called the PKX_CHANNEL_Stop() API function. 6049: BRI spans show ready if in PMP mode when endpoint is set to false. - GrandPrix was incorrectly considering TE state F3 to mean that the span was 'enabled'. The code now considers state F3 to just carry forward the previous state of enabled/disabled. 6100: GrandPrix trunk channels do not connect if a SIT tone is received after dialing the callee's number. - A new configuration value has been added to the answer trunk section configuration key in the product file. This allows users of these channels to connect if a SIT tone is detected on the line. The answer configuration key now supports the following values: speech, sit, pr, any and none. Changes to configuration parameters: Configuration file and section: pikagp_aoh.cfg, section trunk Parameter name: answer Values: speech, sit (NEW), pr, any, none Default Value: speech 6106: GrandPrix is unable to disconnect a SIP call after the call has been cancelled when a stateless proxy is used. - An invalid branch ID field was being included in the CANCEL and ACK message received from the stateless proxy. GrandPrix has been modified to enable a timer after replying to the CANCEL message. If a valid response has not been received after the timer has expired, GrandPrix will disconnect the call properly, freeing up the SIP channel. 6130: Grandprix isn't handling the DTMF caller id information properly. Based on ETSI EN 300 659-1 standards section B.4: The start code for calling number shall be either DTMF "A" or "D". The "D" can inform a "redirected from" number only if there was an "A" before it. Grandprix considers the "D" as a "redirected from" number, even if the caller id format is only DxxxxxxxxxxxxC, which is an acceptable format for a standard caller id. - GrandPrix was modified to allow the DxxxxxxxxxxxxC format to indicate a diverting number only after receiving a previous caller id (with "A" or "D"). Otherwise, this information will be used as the caller id information. 6139: GrandPrix channels are entering into an unusable state after a PKH_EVENT_TRUNK_ABOVE_THRESHOLD event followed by a PKH_EVENT_TRUNK_HOOKFLASH event is received from AoH. The later event is causing GrandPrix to crash when accessing a NULL pointer. - The pointer is now checked before attempting to access it. Also, a check has been added to the CTrunkCall::hookflash() routine. It will now ignore the PKH_EVENT_TRUNK_HOOKFLASH event if the call is in the disconnected state and no transfer has been initiated using the PKX_CALL_Tranfer API. ------------------- CONTACT INFORMATION ------------------- For support issues, phone or e-mail our Customer Care department at the following: Tel: +1-613-591-1555 FAX: +1-613-591-9295 Email: support@pikatech.com ============================================================== Copyright 2008 PIKA Technologies Inc. TRADEMARKS PIKA is a registered trademark of PIKA Technologies Inc. All other trademarks, product names and company names and/or logos cited herein, if any, are the property of their respective holders. DISCLAIMER This document is provided to you for informational purposes only and is believed to be accurate as of the date of its publication, and is subject to change without notice. PIKA Technologies Inc. assumes no responsibility for any errors or omissions in this document and shall have no obligation to you as a result of having made this document available to you or based upon the information it contains. ==============================================================