LanScape
Version Information - LanScape VOIP Media Engine™
“Allow your customers to do what they do best, communicate.” ™
VOIP
Media Engine - Release Notes1
(See
end of document for footnote information)
Version History:
v6.0.1.21
1)
Fixed a possible memory leak issue when transmitting provisional 183 Session Progress
SIP messages. The possible memory leak was SIP content dependant so most users
will not be affected. Customers not having session progress messages enabled in
the SDK will also not be affected.
2)
SIP interoperability improvements when interfacing with Avaya Call Manager and Session
Manager deployments. The following changes have been implemented:
Added the "Supported: timer" SIP header in the following messages if it appears in the received INVITE:
180 Ringing
183 Session Progress
200 OK
Added the "Session-Expires:" SIP header to 200 OK if the incoming INVITE requests requires it.
Updated the SDK to make sure all Record-Route headers received in INVITE requests are echoed in all 18x provisional responses and the final 200 OK response for incoming calls.
Changed the SDK so that Record-Route headers in INVITE responses are all on individual header lines. This approach is easier to read while debugging and may remove a possible Avaya sensitivity to Record-Route header formatting.
Propagated all History-Info headers in SIP responses when
receiving INVITE requests.
v6.0.1.20
1)
SDK version v6.0.1.20. This release represents general updates to the SDK code
base. If you are upgrading from a previous version of the VOIP SDK, you must
rebuild your software against this current version.
2)
Updated SIP message parsing to support extended domain names such as yourdomain.us.to.
This change primarily affects SIP “To:” headers.
3)
Via header SIP interoperability improvements. This version of the SDK includes
enhancements to Via header handling and parsing. Changes have been implemented
that ensure all “Via:” SIP headers received are used in any required SIP
responses. Via headers now also fully support optional and extended parameters.
Via header parameter with and without values are supported. This change will
enhance interoperability with some Avaya SIP equipment among others.
v6.0.0.19
1)
Updated the SIP parser engine to enhance the handling of optional parameters
associated with “Record-Route:” SIP headers. The media engine was properly
parsing the optional parameters for received SIP messages but on some occasions
would not echo the parameters in transmitted SIP responses.
v6.0.0.18
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
DTMF OFF event fix.
The media engine was updated to ensure that when a call is terminated, the
phone lines will receive a DTMF OFF event if the last DTMF event received was
an ON event. Also added code to properly reinitialize received phone line DTMF
state so we do not send DTMF OFF event as the result of a previous dangling
DTMF ON event for a previous call.
3)
Add extra DTMF event information.
Allow media engine DTMF events that get sent to a remote event logger to also
contain the ON/OFF state and the DTMF digit name. This makes development and
debugging easier.
4)
Fix DTMF OFF synchronization.
When RFC2833 DTMF digits are turned OFF, this change allows the API code to
wait until the RTP transmitter knows the DIGIT is really OFF. This change
solves another issue associated with possibly not transmitting DTMF digits
under certain loading conditions.
5)
Receive IVR multithreading update.
This update allows an internal critical section to protect the receive IVR
format/rate converter from being used during Rx IVR open/close operations. This
resolves a reported multithreading issue.
6)
Mono managed code wrapper changes.
Code changes have been implemented into the media engine managed code wrapper
assembly that will allow it to be used under the Linux and Mac OS X Mono
runtime.
7)
Subscribe/Notify memory corruption fix.
Updated the SUBSCRIBE/NOTIFY capabilities of the media
engine to remove a memory corruption issue that existed.
8)
Un-Subscribe notify handle update.
Updated how the media engine sends event data to the user when receiving an
un-subscribe request. Previously, the user would receive a notify handle when
they accepted a subscribe request. This handle would normally have to be closed
by the app at some point by calling the CloseNotifyHandle() API proc. This
behavior is all normal.
What has been updated is how un-subscribe capabilities
function. When an un-subscribe is received, the media engine no longer passes
the application code a new notify handle for the unsubscribe. The notify handle
for the un-subscribe phase is now NULL. I this way, the app does not have to
call CloseNotifyHandle() API proc for the original notify handle AND for this
secondary (un-subscribe) handle. This change was implemented based on user
feedback.
9)
Speex Codec Support.
This version of the media engine includes support for the Speex codec. Narrow
band 8kHz and wide band 16kHz functionality is supported. All encoding/decoding
modes of narrow and wide band are supported and can be used by application
software.
The speex codec capability can be enabled/disabled on a per phone line basis.
In addition, encoder/decoder parameters can also be specified individually for
any phone line.
Application software can enable the speex codec for any
call in conjunction with one or more of the previously defined codecs. If
required, both narrow band and wide band speex can be used at the same time in
call setup.
For detailed information, see the new API procedure SetSpeexCodecParameters().
To enable the speex codec for your phone lines, see the SetAudioMediaFormat() or
SetAudioMediaFormats() API procedures.
Searching the software developer’s reference for the word speex will also give
you additional information.
10)
SIP stack memory leak fix.
Updated the media engine SIP stack to remove a possible memory leak associated
with SIP parsing code.
11)
New software code base in support of future multiplatform capability.
This version of the media engine is based on the multi-platform code base that
will allow the LME to run natively on Mac OS X and Linux.
v6.0.0.17
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Support multiple parameters in SIP URIs and at the end of Contact headers. For
example:
Contact: <sip:333@192.168.1.2:5062;
session=1-1;abc=2;ParamWithNoValue1>;zxc=123;isfocus;+g.poc.talkburst;
x-inst="VGVzdCBDYWxsIERhdGEgZnJvbSB0aGUgVlBob25lIGFwcC4="
The SIP URI parameters are:
session=1-1
abc=2
ParamWithNoValue1
and the Contact header parameters are:
zxc=123
isfocus
+g.poc.talkburst
x-inst="VGVzdCBDYWxsIERhdGEgZnJvbSB0aGUgVlBob25lIGFwcC4="
With this update, all parameters can be a single parameter
name or an assignment such as param=value.
3)
Support muting the received RTP audio on a per phone line basis using the API:
TELEPHONY_RETURN_VALUE VOIP_API MutePlaybackAudio(
SIPHANDLE hStateMachine,
BOOL PlaybackAudioMuted
);
4)
Support muting the locally recorded audio using the API:
TELEPHONY_RETURN_VALUE VOIP_API MuteRecordAudio(
SIPHANDLE hStateMachine,
BOOL RecordAudioMuted
);
5)
Allowed SDP media descriptor transport values to be case insensitive. This will
allow for greater SIP interoperability when communicating with other SIP
devices.
For example:
This => m=audio 40338 RTP/AVP 97
Is the same as => m=audio 40338 rtp/avp 97
and...
This => m=application 40342 UDP TBCP
Is the same as => m=application 40342 udp TBCP
6)
Two of the Media Engine's supported SIP messages did not encode authorization
credentials when responding to WWW-Authenticate challenges. The SIP messages
did encode the "proxy auth" forms of the auth info but not the other
401 related "auth info". The offending SIP messages that have been
fixed are:
Notify
Subscribe
7)
Added the encoding of the following SIP headers:
Accept:
Accept-Encoding:
Accept-Language:
to the following SIP messages:
Notify
Refer
Subscribe
These headers were not being encoded into the SIP messages
specified above.
8)
Updated the managed code wrapper to use a "strong name". The
"strong name" is used to uniquely identify the manage code assembly.
v6.0.0.16
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
"Engineering Release" expiration detection.
This version of the media engine allows VOIP applications to determine if the media engine is time bombed ("engineering release") or a standard product image. This capability has been added in an effort to allow customers to better track time bombed engineering release that may be deployed into their network environments.
v6.0.0.15
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
VOIP Media Engine multi-core restart deadlock fix.
Under certain situations, the media engine may deadlock if repetitively
restarted on multi-core host machines. The bug would occur if local multimedia
recording has been enabled in the media engine (for example, in soft phone
applications) and if the application repetitively called the
ReStartSipTelephony() API procedure.
v6.0.0.14
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Support phone line record delay.
This version of the media engine allows VOIP applications to specify a phone line record delay when enabling call recording for each phone line. This capability is useful to applications that want to control the amount of truncation that is applied to recorded phone line audio sample blocks or record files.
3)
Removed unnecessary release build SIP assertions.
This version of the media engine removes two unnecessary release build assertions that may fire when constructing a final INVITE ACK that is sent back to the destination of an outgoing call.
v6.0.0.13
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Brekeke SIP server SIP inter-op support - Mishandling of INVITE requests.
INVITE requests (that also contain authentication
information) that are sent to Brekeke SIP servers must have the same
"From:" header tag as the original INVITE that was challenged in the
first INVITE attempt. If the "From:" header tag is not the same as
the original challenged INVITE, the Brekeke SIP server will hair-pin the
secondary INVITE request immediately back to the media engine. Though not
considered a bug, LanScape has updated the media engine so that LanScape
customers do not experience this issue when using the media engine with Brekeke
SIP server products.
v6.0.0.12
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Improved the ability of the media engine to detect mangled or mal-formed SIP
URIs when initiating outgoing calls or performing unattended call transfers.
3)
Registration NAT discovery improvements.
The media engine has the ability to use registration
cycles in conjunction with the SIP "received=" and "rport"
header values in order to register the media engine WAN IP address and
firewall/router translated SIP port value. This software update improves the
media engine's ability to offer this functionality with a host of recently
tested VOIP service provider and SIP servers.
4)
Local transmit audio playout path improvements.
This version of the media engine includes improved support
for local audio playout to phone lines and to the local playback loop back
input. Improved playout logic and time scaling algorithms are employed to
ensure the lowest possible transmit audio latency while at the same time
ensuring timely unbroken transmit audio. With this update, local multimedia
hardware is completely decoupled from the timing requirements of the media
engine to ensure continuous streaming transmit audio.
5)
INVITE retransmissions.
This version of the media engine includes improved support
for INVITE retransmissions during call setup. INVITE transmissions now use an
exponential back off algorithm for all INVITE retransmissions.
6)
Terminate phone sounds on aborted call line.
The media engine will now terminate local telephony sounds
for a phone line that is receiving an incoming call when the call is aborted by
the API prior to transmitting the SIP required to abort the incoming call. This
modification is required to remove a race condition between phone line
manipulations of telephony sounds when the media engine calls itself.
7)
Bug fix for aborting a call when media engine calls itself in proxy mode.
If the media engine calls itself and then aborts the call
using the AbortIncomingCall() API procedure, it was possible that the second
line used in the call would not respond to the "480 Temporarily
Unavailable Here" SIP message that is sent to the first phone line. This
issue has been fixed.
8)
Support recording call audio in full duplex, Tx only or Rx only.
The media engine now supports the ability to record phone
line call audio in full duplex (both receive and transmit audio digitally
mixed), transmit only audio or receive only audio. Call recording can be
enabled to present sample block buffers to the VOIP application or call audio
can be recorded directly to a file (wav file or raw PCM sample data).
9)
Support the generation of outgoing call ring back tone only when a SIP 180
message is received.
The media engine now supports the ability to sound the
outgoing call ring back tone immediately after the transmission of the first
INVITE request for the call or not until the reception of a "180
Ringing" SIP message. The VOIP application can control this behavior by
calling the SetRingbackType() API procedure. By default, the media engine will
sound the ring back tone for an outgoing call immediately after the first
INVITE request is transmitted.
v6.0.0.11
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Digital mixer dead lock bug fix.
Removed a bug associated digital mixer input line locking. Under certain situations and depending on the type of mixer input line codecs used, internal digital mixer logic could deadlock. This issue has been fixed.
3)
Digital mixer performance improvements.
This version of the VOIP Media Engine contains optimized
digital mixer code. The digital mixer capabilities of the media engine now
perform at the same level while using less CPU cycles as compared to previous
media engine versions.
v6.0.0.10
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
RFC2833 DTMF packet logging bug fix.
Fixed a bug associated with RFC2833 DTMF transmit logging. If the user's application encrypts the entire RTP packet and the RTP packet contains RFC2833 DTMF, the transmit DTMF logging feature will try to log the encrypted RTP packet which is wrong. With this change, the media engine will always log the unencrypted media engine generated DTMF RTP packet.
3)
RFC2833 DTMF receiver bug fix.
Under certain situations and depending on how RFC2833 out-of-band DTMF digit time stamps are received, the media engine may not process DTMF OFF events properly. This bizarre situation could occur if the far end of the call that generated the DTMF digit RTP packets uses the same RTP time stamp for all DTMF RTP packets (consecutive ON and OFF events) while at the same time not sending RTP audio simultaneously with the DTMF events. This bug has been fixed.
4)
Exposed the undocumented API procedure FilterReceivedRtpPackets and
FILTER_RECEIVED_RTP_PACKETS enumeration.
The media engine by default performs certain RTP packet filtering functions of received RTP media packets. This is done in an effort to minimize RTP packet spoofing and to ensure call quality.
This version of the media engine exposes a previously undocumented API procedure and structure that allows VOIP application software to change the default RTP packet filtering behavior for each media engine phone line.
This is especially useful when a VOIP application is required to process received fully encrypted RTP packet data. In this case, the VOIP application will want to use this new API procedure to disable default received RTP packet filtering.
5)
Updated iLBC codec support.
This version of the media engine contains an update to the iLBC codec support. Under certain situations (large dynamic range), it was possible for an internal codec computation to overflow and thus cause a noticeable noise level in received iLBC audio. This issue has been removed.
6)
Improved iLBC codec execution.
This version of the media engine contains an iLBC codec update that minimizes computation burden. This updated iLBC codec execute approximately 20% faster using the same host hardware.
7)
Internal changes in support of 64 bit media engine product offering.
This version of the media engine contains code changes that will allow the media engine to be ported over to 64 bit Windows hosts. Additional 64 bit changes are to follow this release.
v6.0.0.9
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Non-English language (Chinese) file I/O bug fix.
This version of the media engine includes a fix that addresses a file I/O issue when running the media engine on Windows hosts that are not English language versions. The media engine would generate an exception due to mishandling full path file names that contained simplified Chinese characters in the path. As a result of this bug, VOIP applications would not execute. This issue has been fixed.
v6.0.0.8
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Added support for phone line prefix string in phone line record file names
This version of the media engine adds support for a phone line prefix string that will now be part of all phone line record file names. With this update, it is possible for phone line recorded audio data to be associated with the recording phone line long after the call recording has terminated.
3)
Support phone line record file names using millisecond accurate system time
instead of meaningless long GUID identifiers.
This update allows the media engine to create unique phone line record file names that do not use a long meaningless GUID for the base file name but instead use the start record time accurate to within 1 Ms.
4)
Organization header fix.
Removed an unnecessary space character that was being inserted when SIP messages contained the “Organization:” header. An extra space character was being inserted immediately after the "organization" SIP header and the header data. This bug has been fixed.
5)
Bug fix associated with generating individual phone line SIP logs.
Under certain timing situations, the media may not log provisional 1xx responses and the final 2xx response for INVITE requests that are associated with a call hold/unhold operation. This issue has been fixed. Normal SIP logging function were not effected by this issue.
6)
Added support for variable parameter handling in “Record-Route:” SIP headers.
This version of the media engine adds support for handling
a variable number of parameters embedded in “Record-Route:” SIP headers. If one
or more parameter values are detected in record route headers, they will be
used in “Route:” headers seamlessly, in the same order and without
modifications. This capability will enhance call setup and teardown.
This update will apply to all customers who SIP inter-op with VOIP
equipment/gateways that are supplied by Sonus Networks. At the time of this
release, Bandwidth.com and Vonage are examples of VOIP service providers that
use Sonus gateway equipment.
7)
Improved WAN IP address handling for registrations and call operations.
The media engine allows VOIP applications to specify the use of a WAN IP address via the API when being deployed behind NAT routers and/or firewalls. This version of the media engine adds improved WAN IP address handling in an effort to greatly improve SIP interoperability with other SIP devices.
v6.0.0.7
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Fixed GetDigitalAudioInputDevice() API procedure enumeration error.
The GetDigitalAudioInputDevice() API procedure could not enumerate all multimedia audio input devices if the number of audio output devices did not match (is less than) the number of audio input devices. This issue has been fixed.
v6.0.0.6
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
Minimize digital mixer locking.
Internal digital mixer code uses a critical section to
temporarily lock access to mixer input and output lines when digital mixing
operations are being performed. This change allows the mixer code to minimize
locking when the mixer logic determines that the main mixer thread must sleep
for a specific time duration. This change will allow other threads to run more
smoothly.
v6.0.0.5
1)
Updates and corrections to the Software Developer's Reference and to the .NET
Class Reference.
2)
The media engine has the undocumented ability to dump app received RTP packets
using a hex dump format. This version of the media engine adds the source IP
address and port of the RTP packet to the logged information. This capability
is used by LanScape support to help diagnose RTP receive media related issues.
3)
This version of the media engine support loading RTP packet information into
RTP transceivers for testing. RTP packet info gets loaded from RTP hex dump
files that can be generated by the media engine when calls are active. Lanscape
support uses this capability to help diagnose media related issues.
4)
Allowed the media engine to detect received RTP packets that do not have the
proper packet size and payload types for the negotiated call. The media engine
will now handle RTP packets of this type and not attempt to process them as
received media.
5)
Added the following values to the RTP_TRANSCEIVER_STATISTICS structure so that
applications can determine if calls experienced any RTP payload
"type" errors or payload size errors.
DWORD NumRxPacketPayloadErrors;
DWORD NumRxPacketSizeErrors;
6)
For internal use: Added two undocumented API procedures that will allow
received RTP packets having errors to either be filtered or processed as media.
The current filtering functions allow enable or disable on RTP packet size
errors and payload ID errors. These undocumented API procedures are used by
LanScape support to help determine the cause of received media related issues
in the field.
7)
For internal use: Allowed the media engine to log to a hex dump file all
received RTP packets that do not have the proper packet size and payload ID for
the negotiated call. These RTP hex dump files are used by LanScape support to
determine possible media related issues.
8)
For internal use: Added an undocumented API procedure that will allow the media
engine to write raw RTP sample data for receive and transmitted RTP packets
directly to disk.
v6.0.0.4
1)
Updates and corrections to the Software Developer's Reference and to the .NET
class reference.
2)
Updated the media Engine to generate proper header information in RTP receiver
hex dump files. The RTP receiver hex dump files are used internally by LanScape
to diagnose possible RTP receiver issues.
3)
Muting incoming phone ring sound.
Added the MuteIncomingPhoneRing member to the INCOMING_CALL_INITIALIZED_DATA structure. This structure is passed to application software when the application processes the SipIncomingCallInitialized immediate event.
The application can set the MuteIncomingPhoneRing member
to a non zero value to mute the incoming phone ring sound for the call.
4)
Allow the application to mute local DTMF digit tone playback when DTMF digits
are received.
The media engine now allows VOIP applications to mute local DTMF tone playback when DTMF digits are received on a digit-by-digit basis. This capability can be applied to all received DTMF digits individually. The media engine supports this capability by adding the MuteLocalDtmfTonePlayback member to the DTMF_EVENT_DATA structure that gets passed to the VOIP application when incoming DTMF digit ON/OFF transitions are detected.
This capability is especially useful for applications that communicate signaling via DTMF sequences where you do not want the user to hear the DTMF signaling.
5)
C# Managed code sample bug fixes.
The IP address in the C# sample application code's
settings dialog would not be initialized with the last known good selected IP
address. This bug has been fixed.
v6.0.0.3
1)
Incoming calls that are not routed through the configured SIP proxy may not
connect properly.
If the media engine is configured to use a SIP proxy and it receives an incoming call directly from another SIP user agent (i.e. the call is not being set up via the SIP proxy route), the call may not connect properly. This issue has been fixed.
2)
Added support to allow VOIP applications to fully encrypt/decrypt all SIP
messages the media engine handles.
This version of the media engine supports application encryption of all ready-to-be-transmitted SIP messages and decryption of all received SIP messages. Applications can use whatever encoding/decoding process as required in conjunction with the SipModifySipMessage immediate event and the ModifySipMessage() API procedure.
The primary purpose of this capability is to allow the VOIP application to completely obfuscate SIP message I/O.
3)
Changed the case of generated SIP "Call-ID" headers to lower the
probability of SIP inter-op issues.
The media engine will now use the following case when generating call id headers: "Call-ID". This conforms to the examples depicted in SIP RFC3261. Prior to this version, the media engine used "Call-Id".
4)
Application specified "User-Agent:" header values not being used in
transmitted "100 Trying" and "180 Ringing" SIP messages.
A previous version of the media engine introduced the SetUserAgentInfo() API procedure. This procedure allows the user's VOIP application to specify specific values that will be used when the media engine places "User-Agent:" headers in SIP messages. In other words, applications can now specify the SIP User-Agent header values.
A bug was identified that cause the application specified user agent headers not to be properly added to "100 Trying" and "180 Ringing" SIP messages. This bug has been fixed.
v6.0.0.2
1)
Fixed an internal access violation on multi-core host machines. Depending on
execution timing, internal “audio de-bounce” logic handling may attempt to
delete a critical section object that had not been initialized.
v6.0.0.1
1)
Updates and corrections to the Software Developer's Reference and to the .NET
class reference.
2)
This version of the VOIP Media Engine contains an update that will allow it to
gracefully process 401 and/or 407 REGISTER request authentication challenges
that do not contain a “Call-Id:” SIP header in the challenge response.
This change is not a bug fix but an enhancement that will allow the media
engine to work with ill-behaving SIP registrars that do not place a Call-Id SIP
header in the authentication challenge responses.
v6.0.0.0
1)
Updates and corrections to the Software Developer's Reference.
2)
VOIP Media Engine versions v5.12.8.2 through v5.12.8.14 have not released to the
general public. These product versions were released to specific customers as
“engineering releases”. This latest version of the media engine incorporates
all changes, enhancements and bug fixes for the above specified versions.
3)
Final 2008 updates associated with allowing the media engine to fully scale on
multi-core host machines. Internal threading and memory allocation changes
implemented will allow the media engine to scale in a more linear fashion
relative to previous versions of the product. As higher density host machines
become available, LanScape will continue to improve on the multi-processor
performance and scalability of the media engine.
4)
Added a new wave file API procedure SetLoopRead().
The SetLoopRead() API procedure was added to the media
engine's wave file support. It allows continuous loop reading of sample block
data from wave files. The capability is useful for streaming wave file sample
block data to phone line transmit IVR channels in addition to other uses.
5)
Removed possible access violation in internal digital mixer subsystem.
The media engine incorporates digital mixing
functionality. This version of the media engine removes a possible NULL pointer
assignment that could cause an application access violation.
6)
Removed possible application crash when using Tx IVR outputs and when handling random incoming G729 and G711 calls.
Depending on the timing of how the application closed Tx IVR channels for phone lines and depending on the timing of how the media engine receives G729 and G711 based incoming calls, there existed a possibility that a new incoming G729 call may use the old G711 codec from a previous call on the same phone line. This situation would result in an access violation and application crash. This issue has been fixed.
7)
Added new API procedure GetRtpTransceiverStatistics().
The API procedure GetRtpTransceiverStatistics() was added
to the media engine to give a VOIP application a quick (low CPU overhead) method
of determining RTP transceiver activity. With this API procedure, applications
can determine total number of transmitted and received RTP media packets in
addition to RTP packet error counters. On such use for this API procedure is to
periodically read received RTP packet counters to determine if a media session
timeout has occurred.
8)
Parameter "PlaybackLocally" ignored when calling API procedure StartDtmfTone().
When commanding DTMF tone generation, the "PlaybackLocally" parameter was being ignored. This caused DTMF tones to always be played on the host's local multimedia hardware (if multimedia hardware support has been enabled). This bug has now been fixed.
9)
Added new API procedure SetUserAgentInfo().
The SetUserAgentInfo() API procedure was added to the
media engine to allow application software the ability to specify the
information that gets transmitted via the "User-Agent:" SIP header
value.
10)
Removed a possible application crash when terminating calls on phone lines that use iLBC 30Ms frame sizes.
Under certain situations and system loading, an access
violation could be experienced if an iLBC 30Ms frame size call is terminated
and the media engine is still in the process of transmitting RTP media data for
the call. This timing issue could cause an application crash in the form of an
access violation because an internal "block time converter" required
by the RTP transmit logic is no longer available. This issue has been fixed.
11)
Updated the media engine to better handle WWW and Proxy authentication challenges.
This version of the VOIP Media Engine has been updated to handle case differences in the "authentication type" Digest when being challenged by far end SIP devices and/or servers. Now when a far end SIP device or server challenges the media engine, any case is acceptable regarding the authentication type requested.
12)
Sample application can now be built using Visual Studio
2008.
13)
Trial license product images now allows up to 12 instances of the VOIP Media
Engine to run at the same time. Each instance of the media engine can support
up to 64 concurrent phone lines.
v5.12.8.14 (Final v5 product image)
1)
Updates and corrections to the Software Developer's Reference.
2)
Improve media engine sdp media attribute parsing.
Added additional tests to sdp media attribute parsing code
to remove possible access violations when parsing non conforming media
attributes.
3)
Added support for non existing media attributes in SDP for received INVITE
requests and 2xx responses.
The media engine now supports SIP devices that do not add "a=rtpmap" SDP media descriptors when initiating or receiving calls. Prior to this version, the media engine could not handle missing media descriptors for negotiated codec types. This version resolves this issue. In particular, the media engine is now able to interact with the "Sip Communicator" user agent (http://sip-communicator.org).
v5.12.8.13
1)
Updates and corrections to the Software Developer's Reference.
2)
Removed possible receive IVR access violation on multi-core hosts.
When terminating the media engine with one or more calls
that are active and while the VOIP application is receiving receive IVR phone
line streaming audio data, there was a possibility of generating an access
violation on multi-core host machines. This issue has been fixed.
3)
Allowed phone line receive volume setting to be applied to recorded and vu
meter audio levels.
Now when applications set the phone line receive audio
level using the SetPhoneLineVolume() API procedure, the receive audio levels
for recorded audio and received VU meter audio are also set. Prior versions of
the media engine did not alter the received recorded audio level or the
received vu meter level.
4)
REGISTER authentication challenge updates for improved SIP interoperability.
This version of the media engine contains updates that will allow for improved interoperability when registering with SIP registrar servers and other REGISTER endpoints.
This change directly affects the ability of the media engine to register with Sipfoundry's sipX v3.10.2 and higher PBX server platforms running on Linux.
When REGISTER cycles are challenged by the registrar server, the media engine will retry the REGISTER request with the computed required authentication credentials. The secondary REGISTER that is sent to the REGISTER server will maintain the same "From:" header tag value as the original REGISTER request. This will allow the REGISTER server to accept the request.
v5.12.8.12
1)
Updates and corrections to the Software Developer's Reference.
2)
The VOIP Media Engine may ignore new incoming calls having the same call ID as
a previous incoming call that was ignored or aborted.
If a previous incoming call was ignored using the
SipIncomingCallInitialized immediate event or aborted using the
AbortIncomingCall() API procedure, the media engine would ignore subsequent
incoming calls that have the same call ID. This issue has been fixed.
3)
Call hold request that receives a "408 Request Timeout" response may
terminate the call.
If the media engine performed a call hold request of a call and the far end or SIP proxy returned a "408 Request Timeout" response, the media engine could terminate the call instead of simply allowing the call hold re-INVITE to time out. This issue has been fixed.
v5.12.8.11
1)
Internal call history update for ignored incoming calls.
The media engine internally maintains a short term call history in order to process incoming SIP messages properly. Under some deployments, it was reported that if the user's VOIP application terminated or ignored incoming SIP calls via the media engine, the far end device may immediately retry the call using the same call ID but with a different "From:" header tag. The internal call history was basing its logic only on call ID and would therefore not map new calls for a previously retried call prior to having the internal call history updated. This particular code change allows for improved SIP interoperability with the customers IP based PBX.
v5.12.8.10
1)
Updates and corrections to the Software Developer's Reference.
2)
Re-invite record route header parse bug.
Fixed a bug associated with detecting the route host from Record-Route headers that are parsed from INVITE "200 OK" responses. Without this fix, re-invites may be sent to the wrong destination IP address when using record route headers.
3)
Conference session ID bug fix.
The media engine contained a bug that would allow it to logically wire phone
lines into conference sessions that did not have the same conference session
IDs as set by the SetConferenceGroupIds() API procedure. This issue has been
fixed.
4)
UDP receive and transmit buffer size modifications to allow executing under Linux operating systems using Wine.
Updated how the media engine applies UDP receive and
transmit buffer sizes so that the media engine can execute under Linux using
Wine v1.1.3 and higher. Wine is the Windows emulation layer. For more information,
see http://www.winehq.org.
v5.12.8.9
1)
Updates and corrections to the Software Developer's Reference.
2)
Fixed Access Violation in RTP transmitter logic.
Fixed an uninitialized pointer in RTP transmitter logic that could cause an
access violation if internal DTMF is disabled but supported (enabled) by
license files and when the app filters transmitted RTP packets.
v5.12.8.8
1)
Updates and corrections to the Software Developer's Reference.
2)
This version of the VOIP Media Engine contains software updates that address choppy/broken multimedia audio playback issues.
Depending on the underlying multimedia hardware and drivers installed in Windows Vista hosts machines, it was possible that the media engine would play back telephony sounds and streaming phone line audio in a discontinuous manner (i.e. choppy or broken audio playback). This issue was also detected on some Windows XP Pro machines as well.
This latest version has the ability to handle non periodic sample block multimedia playback and handle non "real time" behavior of multimedia audio hardware and drivers. It contains additional logic to time scale audio playback streams to remove discontinuous audio playback.
Also addressed in this release is the ability to overcome
issues associated with multimedia hardware record and playback rates that are
not the same for the same sampling frequency.
v5.12.8.7
1)
Updates and corrections to the Software Developer's Reference.
2)
Removed possible access violation when transmitting final ACK responses for outgoing SIP INVITE requests.
This version of the media engine removes a possible access
violation that was associated with transmitting final ACK responses to outgoing
INVITE requests. It was possible for the media engine to improperly compute an
internal address location if INVITE responses in the range of 400 to 699
arrived after the media engine decided that the call leg had already been
properly terminated. If the media engine received additional “late” INVITE
responses for a past call, an access violation could occur. This issue has been
fixed.
v5.12.8.6
1)
Updates and corrections to the Software Developer's Reference.
2)
Fixed a bug in Ms (millisecond) accurate absolute SIP log
time stamps.
A bug has been fixed that was associated with Ms accurate absolute SIP log time
stamps. It was possible, due to a rounding error that absolute time stamps
could have a value of 0 to 1000 Ms instead of 0 to 999 Ms. This issue has been
fixed.
3)
Multi-core conferencing deadlock issue fixed.
This version of the media engine includes a fix that will
remove a possible deadlock situation when running the media engine on
multi-core host hardware platforms and when quickly transitioning phone line
"into" and "out of" conference mode.
4)
Multi-core conferencing optimizations.
The media engine now includes logic optimizations that
will allow individual phone lines to transition to and from conference mode
much faster and with less CPU overhead. This will improve overall call handling
throughput.
v5.12.8.5
1)
Updates and corrections to the Software Developer's Reference.
2)
Improved the time stamp resolution of individual phone
line SIP logging to files.
The media engine has the ability to log SIP messages to log files on a per
phone line basis. Log file time stamp resolution now has +/-1 Ms logging
accuracy and SIP logs now contain absolute time stamps in addition to relative
time stamps.
3)
Changed the way the media engine's CSeq SIP header value is computed during INVITE requests in order to improve Asterisk SIP interoperability.
This version of the media engine contains an update that
ensures the uniqueness of CSeq header values in all transmitted INVITE requests.
Doing so will ensure that Asterisk servers will not ignore secondary INVITE
requests that are very quickly received due to "407 Proxy Authentication
Required" challenges.
v5.12.8.4
1)
Updates and corrections to the Software Developer's Reference.
2)
Added the ability to mute received and transmitted phone line audio on a per phone line basis.
Added the ability to mute the playback of received phone line audio on a per phone line basis. By default, all received phone line audio is played back to local multimedia hardware if multimedia hardware support has been enabled in the media engine. The new SetMuteReceivedPhoneLineAudio () API procedure now allows application software to selectively mute the playback of phone line received audio. Application software can also call the GetMuteReceivedPhoneLineAudio () API procedure to query the state of phone line received audio playback.
Phone line transmitted audio can also be muted on a per phone line basis. The SetMuteTransmitPhoneLineAudio() and GetMuteTransmitPhoneLineAudio() API procedures have been added to support this capability.
Muting transmit or received audio does not alter the state
of SIP phone calls and does not generate SIP requests or responses.
3)
Fixed access violation when conferencing is turned OFF.
Under certain execution situations, an unhandled access violation could be
thrown by the operating system when call conferencing is turned OFF. This bug
has been fixed.
4)
Added new startup error return value:
SipRtpTxMixerThreadStartError.
Added the new media engine startup error return value
SipRtpTxMixerThreadStartError. This new return value was added so that phone
line transmit mixer start errors would be reported accurately and not fall
under a previous “catch-all” error code return value.
5)
Fixed incoming call RTP port assignment errors when executing on multi core CPU platforms.
This version of the media engine contains a bug fix that is associated with RTP port assignments for incoming calls.
Under certain situation when processing a large number of
incoming calls and when running the media engine on a multi core host (i.e. a
multi-processor host), RTP port assignment logic could assign the same RTP port
to two different incoming concurrent calls. This would result in one of the
calls generating the SipSocketBindError event during internal RTP call setup
which would make one of the calls fail. This bug has been fixed.
6)
Faster call setup and initializations.
This version of the media engine incorporates RTP transceiver changes that
greatly reduce call setup times. With these current changes, it is possible
that 2000 milliseconds (2 seconds) can be removed from each call setup. This
greatly improves call setup times for high line density deployments.
7)
VOIP Media Engine now passes release 1 and release 2 of the PROTOS SIP Test Suite.
This version of the media engine has been updated to pass
Release 1 and 2 of the PROTOS test suite.
8)
Fixed access violation when local audio is ON and conferencing is OFF.
This version of the media engine fixes an access violation
that may occur when local multimedia audio is enabled and multi-line
conferencing capability is turned OFF.
v5.12.8.3
1)
Updates and corrections to the Software Developer's Reference.
2)
The following two registration global events have been
renamed to improve naming consistency:
Old Event Names:
SipRegistrationIntervalError
SipRegistrationTimeOut
New Event Names:
SipRegisterIntervalError
SipRegisterTimeOut
3)
The following global event notifications have been added to the media engine to
allow VOIP applications to monitor registration cycles when the media engine
un-registers with SIP registrars:
SipUnRegisterTrying
SipUnRegisterSuccess
SipUnRegisterTimeOut
SipUnRegisterErrorBadCredentials
SipUnRegisterError
SipUnRegisterNetworkError
SipUnRegisterAuthorizationError
4)
This version of the media engine supports the IsUserNameRegistered() API
procedure. This new API procedure allows VOIP applications to query the
registration status of phone line user names (extensions) as they are
registered with an optionally configured SIP registrar server.
5)
Removed possible access violation when calling GetIncomingCallInfo() API
procedure.
If an incoming call was answered and then terminated by the far end very
quickly, the application could call the GetIncomingCallInfo() API procedure and
possibly generate an access violation. This issue has been resolved.
6)
Removed possible access violation when calling GetActiveCallInfo() API
procedure.
If an incoming call was answered and then terminated by the far end very
quickly, the application could call the GetActiveCallInfo() API procedure and
possibly generate an access violation. This issue has been resolved.
7)
Removed possible deadlock situation in RTP receivers when under heavy load.
If the media engine is very heavily loaded and incoming calls are received and
then quickly terminated (terminated in 1 second or less), and if the media
engine runs out of phone lines for the total number of INVITE requests pending,
there was a possibility of deadlocking the RTP receiver for a phone line. This
issue has been fixed.
8)
Incoming subscription bug that caused memory to be reclaimed twice.
If the VOIP Media Engine received a SIP SUBSCRIBE request and the VOIP
application dose not want to accept the incoming request, the media engine
would process the SUBSCRIBE request as normal. However, an internal data
structure was being freed twice. This bug has been removed in order to improve
operating system stability.
9)
200 OK SIP responses to SUBSCRIBE requests did not contain a "To:"
header tag.
If the media engine has been instructed to accept a SUBSCRIBE request by the
VOIP application, the “200 OK” SIP response that gets transmitted did not
contain a Tag parameter in the “To:” header field. This bug has been fixed.
10)
Renamed the GetNumberOfActiveCalls() API procedure to
GetNumberOfCallsInProgress()
The GetNumberOfActiveCalls() API procedure has been renamed to
GetNumberOfCallsInProgress(). This has been done to better describe true
nature of the API procedure.
11)
Updated the media engine’s ability to detect RTP media conflicts using the
SipReceivedRtpMediaConflict event
The media engine has the ability to detect received RTP media from different IP
addresses than what is negotiated in the SIP protocol. The media engine has
been updated to support both session and media level IP detection from request
and response SDP.
12)
Phone call conference deadlock issue.
Fixed a deadlock issue that was associated with placing phone lines into
conference mode. It was possible for the media engine to experience a deadlock
situation under the following scenario:
1)
An application worker thread detects an incoming phone call and goes off hook to answer the call.
2)
The application then calls the ConferenceLine() API procedure to place the phone line into a conference session during the processing of the SipInCall state.
3)
At the same time the internal ConferenceLine() API logic is executing, the far end of the call terminates the call. If the execution of the internal conferencing logic and the call terminate logic are "just right", one of two situations could occur. Either internal call thread logic would start to deadlock or the application thread that called the ConferenceLine() API procedure could deadlock. The internal condition that caused the deadlock to occur was associated with two sections of internal logic waiting on the same completion event.
This dead lock issue has now been resolved.
13)
Conference events more closely mirror the behavior of call hold events when
terminating calls.
Prior versions of the media engine would send to the application the
SipInConferenceOff and SipInCall events when a call is terminated and the phone
line was in a conference session. For example, the following events would be
sent to an application for a phone line that is initially “in a call” and has
been added to a conference session and has been terminated either by hanging up
the call or honoring a received BYE request:
SipInCall
SipInConferenceOn
SipInConference
SipByeReceived
SipSendByeAck
SipInConferenceOff
SipInCall
SipCallComplete
SipOnHook
Some developers found that receiving a second SipInCall event as the result of transitioning the call out of conference mode was too confusing.
In order for conferencing event to be more symmetrical relative to Hold/UnHold events, the final SipInConferenceOff and SipInCall events have been removed when a phone line experiences the above scenario. Now, when a call terminates that is in an active conference session, the following events will be sent to the application:
SipInCall
SipInConferenceOn
SipInConference
SipByeReceived
SipSendByeAck
SipCallComplete
SipOnHook
This makes conferencing event behavior identical to call hold event behavior.
14)
Added a new API that allows applications to filter specific events from remote
event logs.
The FilterEventLogServerEvents() API procedure can be called to specify
one or more remote event log events you want filtered. Events that are filtered
will not be sent to a remote event log server even though you have an event log
server enabled. The primary purpose of this API procedure is to allow
application software to filter out any events that are not important for the
current operation you are investigating or debugging. A good use of this API
procedure is to filter out all SipModifySipMessage immediate events.
15)
Resolved media engine indefinitely hanging upon termination when lines are in
“Busy Out” state.
If any phone line is placed into the busy out state and the media engine is
terminated, the media engine will not shut down properly and appear to hang
forever. This issue has been fixed.
16)
Added the SetCallCancelTimeout() API procedure.
The SetCallCancelTimeout() API procedure has been added to allow applications
to control how long the media engine will wait for outgoing call CANCEL
responses from the far end of the call. Prior to this release, the media engine
used a hard coded timeout value.
When the media engine transmits a CANCEL request for an outgoing call, it expects to receive a "200 OK" response for the transmitted CANCEL request and a "487 Transaction Terminated" response for the initial INVITE request. Note that the "487 Transaction Terminated" response received will also be answered by a final ACK from the media engine.
The media engine will wait the "CallCancelTimeout" as set by the API procedure for the "200 OK" response. It will also wait the "CallCancelTimeout" for the "487 Transaction Terminated" response. The order of these responses does not matter. If the media engine does not receive both expected responses, the phone call will proceed with cancel termination. If the responses arrive after the timeout as set by the API procedure, the responses will be ignored.
17)
Fixed SIP log time stamp error.
The relative time stamps for the first transmitted and received SIP log entries
were incorrect. This issue has been fixed.
18)
Added absolute time stamp to all SIP log output.
All SIP log generated data now includes absolute time stamp information accurate to within +/-1Ms of when the Sip packets were received or transmitted. This will help when debugging SIP inter-op related issues.
v5.12.8.2
1)
Various updated and correction to the Software Developer's reference.
2)
DTMF generator and decoder updates.
Enhanced the DTMF decoder support in the media engine in an effort to allow
customers to manipulate decoder characteristics. This release also includes
support for the v6 media engine fully integrated in-band and RFC2833 DTMF support
soon to be released. The primary benefits resulting from these changes are that
customers will not have to request special DTMF decoder tuning tables from
LanScape support. The other primary advantage is using the fully integrated
DTMF support greatly simplifies VOIP application development.
The following new API procedures have been added:
Stand-alone in-band DTMF detection:
BOOL VOIP_API DtmfDecoderSetSignalThreshold(HDTMFDECODER hDtmfDecoder, double DtmfDecoderSignalThresholdDb);
BOOL VOIP_API DtmfDecoderGetSignalThreshold(HDTMFDECODER hDtmfDecoder, double *pDtmfDetectSignalThresholdDb);
BOOL VOIP_API DtmfDecoderSetTwist(HDTMFDECODER hDtmfDecoder, double ForwardTwistDb, double ReverseTwistDb);
BOOL VOIP_API DtmfDecoderGetTwist(HDTMFDECODER hDtmfDecoder, double *pForwardTwistDb, double *pReverseTwistDb);
void VOIP_API DtmfDecoderSetMinimumDigitOnTime(HDTMFDECODER hDtmfDecoder, DWORD MinimumDigitOnTimeMs);
DWORD VOIP_API DtmfDecoderGetMinimumDigitOnTime(HDTMFDECODER hDtmfDecoder);
Internal (fully integrated) in-band and RFC2833 DTMF detection:
TELEPHONY_RETURN_VALUE VOIP_API SetInBandDtmfSignalThreshold(
SIPHANDLE hStateMachine,
int PhoneLine,
double DtmfDecoderSignalThresholdDb
);
TELEPHONY_RETURN_VALUE VOIP_API GetInBandDtmfSignalThreshold(
SIPHANDLE hStateMachine,
int PhoneLine,
double *pDtmfDetectSignalThresholdDb
);
TELEPHONY_RETURN_VALUE VOIP_API SetInBandDtmfTwist(
SIPHANDLE hStateMachine,
int PhoneLine,
double ForwardTwistDb,
double ReverseTwistDb
);
TELEPHONY_RETURN_VALUE VOIP_API GetInBandDtmfTwist(
SIPHANDLE hStateMachine,
int PhoneLine,
double *pForwardTwistDb,
double *pReverseTwistDb
);
TELEPHONY_RETURN_VALUE VOIP_API SetInBandMinimumDigitOnTime(
SIPHANDLE hStateMachine,
int PhoneLine,
DWORD MinimumDigitOnTimeMs
);
TELEPHONY_RETURN_VALUE VOIP_API GetInBandMinimumDigitOnTime(
SIPHANDLE hStateMachine,
int PhoneLine,
DWORD *pMinimumDigitOnTimeMs
);
3)
Added the following three new members to the DTMF_DETECT_DATA and
DTMF_EVENT_DATA structures. These values allow the VOIP application to obtain
detected in-band DTMF frequency power values in addition to average noise
power.
double Freq1MagDb;
double Freq2MagDb;
double AverageNoiseMagDb;
v5.12.8.1
1)
Some upcoming changes associated with the v6 media engine software are present
in the SipTelephoneApi.h API header file. Make sure your VOIP application
builds do not define the SUPPORT_INTEGRATED_DTMF macro when building your VOIP
solution.
2)
Various updates and improvements to the Software
Developer's Reference.
3)
Added new API proc LogPhoneLineSipMessages() to support
SIP logs for individual phone lines.
4)
Added the media engine return value SipConferenceNotEnabled value. This value
gets returned by the ConferenceLine() and SetConferenceGroupIds() API
procedures when the API procedures are called and conferencing is not enabled.
5)
The following stand alone DTMF generator API procedures have been renamed in
order to remove API name clashing with upcoming future media engine
capabilities. We fully regret this inconvenience. The new API procedure name
changes are as follows:
Old Names/prototypes:
BOOL VOIP_API StartDtmfTone(HDTMFGENERATOR hDtmfGenerator, DTMF_TONE DtmfTone, DWORD DurationMs);
void VOIP_API WaitForToneCompletion(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API StopDtmfTone(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API SetDtmfAmplitude(HDTMFGENERATOR hDtmfGenerator, int Amplitude);
New Names/prototype:
BOOL VOIP_API StartDtmfGeneratorTone(HDTMFGENERATOR hDtmfGenerator, DTMF_TONE DtmfTone, DWORD DurationMs);
void VOIP_API WaitForDtmfGeneratorToneCompletion(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API StopDtmfGeneratorTone(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API SetDtmfGeneratorAmplitude(HDTMFGENERATOR hDtmfGenerator, int Amplitude);
6)
API procedures that are associated with outgoing call sounds have been renamed
in order to remove API name clashing with upcoming future media engine
capabilities and to improve naming consistency. We fully regret this
inconvenience. The new API procedure name changes are as follows:
Old Names/prototypes:
TELEPHONY_RETURN_VALUE VOIP_API EnableDtmfDigits(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableBusySignal(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableErrorSignal(SIPHANDLE hStateMachine, BOOL EnableState);
New Names/prototypes:
TELEPHONY_RETURN_VALUE VOIP_API EnableOutgoingDtmfDigits(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableOutgoingBusySignal(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableOutgoingErrorSignal(SIPHANDLE hStateMachine, BOOL EnableState);
7)
Jitter compensation RTP packet bug:
If jitter compensation for a phone line is enabled, it was possible that not
all received RTP media packets would be sent to an application's receive IVR
callback procedure while the jitter comp algorithm is engaged. The number of
missed packets is equal to the specified API jitter comp time in milliseconds
divided by the RTP payload time per packet.
Also if phone line loop back echo is enabled, it was also possible that not all RTP packets would be looped back for retransmission out the phone line.
This issue has now been fixed. Now regardless of the
internal state of phone line receive jitter compensation, all RTP packets will
be forwarded to the application's receive IVR callback procedure and all RTP
packets will be echoed out the phone line if required.
8)
Multiple line registrations using 3CX PBX.
A bug was fixed in the media engine that was associated
with performing multiple line registrations to the 3CX PBX. The media engine
would experience a parse error when receiving proxy authentication challenges
from the 3CX PBX. This bug would not allow multiple lines of the media engine
to be registered at the same time with the PBX. This issue has been fixed.
9)
Support “annexb” SDP format tag for G729 based codecs:
The media engine now supports the SDP format descriptor
“annexb=yes” and “annexb=no” that is used when initiating or receiving VOIP
calls. This helps to improve interoperability with SIP/RTP/VOIP equipment from
other vendors and completely removes G729/G729A and G729B codec clashing when
call endpoints do not default to using the same G729 codec type.
10)
Allow dynamically changing the SIP "Display name" for phone lines:
This version of the media engine supports a new API
procedure called SetPhoneDisplayName(). Application software can use this
procedure to dynamically change the display name for any phone line prior to
making outgoing calls. Note that prior to this release, the media engine
already allowed dynamically changing the phone line “user name”/”extension”
using the SetPhoneName() API procedure.
11)
Playback delay build up when using Tx IVR outputs.
When playing back sample block data to phone line transmit IVR outputs, the actual time to play all application supplied samples would be proportionately longer (approximately 0.2% longer) than the total time of the sample data.
The longer the continuous playback of sample data to Tx IVR outputs, the more accumulated playback delay would be introduced. This did not affect the sonic quality of the Tx IVR data but caused application developers to worry that their Tx IVR playback data would somehow be altered in pitch or frequency content.
This version of the media engine incorporates changes to
internal digital mixers that will completely remove all previously noticed
playback delay build up when using any of the Tx IVR outputs.
12)
The Sequence and TimeStamp values in raw received RTP headers are no longer
automatically converted from network byte order (big endian) to native (little
endian).
13)
Phone line internal transmit mixer fix:
If a phone call is initiated and then quickly terminated
immediately after entering in “in call” state, it was possible for the phone
line’s internal transmit mixer logic to not enter the blocking state. Even
though no voice data would be mixed, the internal thread logic could still
execute every 20Ms even though the previous phone call was terminated. This bug
simply caused additional unnecessary loading on the host CPU and no other side
effect. This bug has now been fixed thus improving overall VOIP application
performance and CPU utilization.
14)
Added the parameter pTotalNumSampleBytes to the OpenWaveFile() API proc so app
code can determine how many total sample bytes are in the wave file.
TELEPHONY_RETURN_VALUE VOIP_API OpenWaveFile(
SIPHANDLE hStateMachine,
char *pWaveFileName,
int BytesPerWaveBuffer,
HWAVEFILE *pWaveFileHandle,
int *pBytesPerSample,
DWORD *pTotalNumSampleBytes
);
15)
Opening Microsoft 8kHz 4 bit ADPCM wave files caused heap corruption:
If a VOIP application would try to open a Microsoft 8kHz 4
bit ADPCM wave file using the built in media engine wave file support, the
global heap could get corrupted. This issue has been fixed.
16)
Updated the media engine to allow "200 OK" responses to include
RFC2833 DTMF "telephone-event" format specifiers in support of DTMF
digits 0-16. Previous versions of the media engine had the
"telephone-event" format specifier in transmitted INVITE requests but
not in "200 OK" responses. The following SIP messages show what is
now generated by the media engine (see items in RED).
INVITE sip:333@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;rport;branch=z9hG4bK05b54c2b
From: "Test Phone" <sip:333@ps>;tag=5b4fe04;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:333@ps>
Contact: <sip:333@192.168.1.2:5066>;x-inst="VGVzdCBDYWxsIERhdGEgZnJvbSB0aGUgVlBob25lIGFwcC4="
Call-Id: 5a46dcac-7593-46e7-8076-94d27eae327a-00003bd0@192.168.1.2
CSeq: 11889747 INVITE
Max-Forwards: 70
Organization: 2456E5FD-DC94-417D-BDF7-55A654EFB9E5
Proxy-Authorization: Digest algorithm=md5,nonce="32db76a9f4b0836dcf462639562a7c07",opaque="92db7091bcf042e0d9572a6a5163f62b",realm="ps",response="676969f2456f751ae7c69cb10c34541f",uri="sip:333@ps",username="guest"
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 221
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
v=0
o=333 95745296 95745296 IN IP4 192.168.1.2
s=LanScape
c=IN IP4 192.168.1.2
t=0 0
m=audio 20006 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=ptime:20
a=fmtp:101 0-16
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:5060;received=192.168.1.2;branch=z9hG4bKf733fcbce1f31aae7f5b20d85cce4947a.0
Via: SIP/2.0/UDP 192.168.1.2:5066;received=192.168.1.2;rport=5066;branch=z9hG4bK05b54c2b
Record-Route: <sip:192.168.1.2>
From: "Test Phone" <sip:333@ps>;tag=5b4fe04;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:333@ps>;tag=5b50dde
Call-Id: 5a46dcac-7593-46e7-8076-94d27eae327a-00003bd0@192.168.1.2
CSeq: 11889747 INVITE
Contact: <sip:333@192.168.1.2:5066>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 1
Content-Length: 230
Content-Type: application/sdp
v=0
o=LanScape 2147483647 2147483647 IN IP4 192.168.1.2
s=LanScape
c=IN IP4 192.168.1.2
t=0 0
m=audio 20000 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=ptime:20
a=fmtp:101 0-16
v5.12.8.0
1)
This image contains a fix for applications receiving multiple
SipReceivedRtpMediaConflict events. Due to a coding error, applications were
receiving this event for each received RTP packet that was in violation of the
call’s negotiated SIP endpoint parameters. With this update, applications will
only receive a single SipReceivedRtpMediaConflict event during a call.
2)
Added support for multiple remote SIP and event log
servers. This way real time SIP and event information can be sent to more than
one SIP or event log server.
3)
Fixed a possible dead lock situation when hammering on the
subscription API. It was possible for the TriggerSubscription() API procedure
to take longer than normal to return if many subscription requests (greater
than 10) were triggered at the same time and simultaneously from different
threads.
4)
The Sequence and TimeStamp values in raw received RTP headers are now converted
from network byte order (big endian) to native (little endian). This helps the
app and minimizes confusion when viewing raw RTP payloads.
v5.12.0.0 through v5.12.7.x
Notes:
Product revisions in this range consisted of product enhancement, changes and
bug fixes in addition to customer requested custom development. All changes to
the product from revisions v5.12.0.1 through v5.12.7.X have been merged back
into the current main product branch and are now part of the base product.
Version history for these revisions will be lumped together. As of the final
v5.12.7.X product image, LanScape will begin to publish all standard product
revision changes with proper version descriptions as they occur in order to
better support developers and customers wishing to upgrade to newer product
versions.
New Features and
Capabilities:
1)
Added new API procedure GetRtpTransceiverStatistics().
The API procedure GetRtpTransceiverStatistics() was added to the media engine
to give a VOIP application a quick (low CPU overhead) method of determining RTP
transceiver activity. With this API procedure, applications can determine total
number of transmitted and received RTP media packets in addition to RTP packet
error counters. On such use for this API procedure is to periodically read
received RTP packet counters to determine if a media session timeout has
occurred.
2)
Changed the way the media engine’s CSeq SIP header value is computed during
INVITE requests in order to improve Asterisk SIP interoperability.
This version of the media engine contains an update that ensures the uniqueness
of CSeq header values in all transmitted INVITE requests. Doing so will ensure
that Asterisk servers will not ignore secondary INVITE requests that are very
quickly received due to “407 Proxy Authentication Required” challenges.
3)
Allow the application to query registered user names (extensions).
This version of the media engine supports the IsUserNameRegistered() API
procedure. This new API procedure allows VOIP applications to query the
registration status of phone line user names (extensions) as they are
registered with an optionally configured SIP registrar server.
4)
Complete integrated support for both in-band and RFC2833 DTMF generation and
decoding.
This version of the VOIP Media Engine contains complete and fully integrated
support for both in-band and RFC2833 DTMF generation and decoding. VOIP
applications can chose to use no DTMF or any combination of in-band and/or
RFC2833 DTMF on a per phone line basis. All aspects of this powerful DTMF
behavior can be controlled via the API.
Using RFC2833 based DTMF in your VOIP applications will ensure the best possible DTMF interoperability and performance as compared to using in-band DTM techniques.
In application instances that demand support for in-band DTMF detection and generation, the media engine allows the VOIP app huge control over in-band DTMF signaling characteristics. VOIP applications can specify and control DTMF signal thresholds, forward and reverse twist and specify minimum digit ON time for improved talk off and noise immunity.
With this new enhanced capability, supporting either in-band
or out-of-band RFC2833 DTMF generation and decoding in a VOIP application is
incredibly simple and "rock solid".
5)
Allow dynamically changing the SIP "Display name" for phone lines.
This version of the media engine supports a new API procedure called SetPhoneDisplayName(). Application software can use this procedure to dynamically change the display name for any phone line prior to making outgoing calls. Note that prior to this release, the media engine already allowed dynamically changing the phone line “user name”/”extension” using the SetPhoneName() API procedure.
6)
Internal threading changes.
This version of the VOIP Media Engine has been updated to incorporate an updated internal multi-threading model. Thread logic has been simplified and many critical sections and serialization paths have been removed.
What this means is that your VOIP applications will be
able to process many more VOIP calls per second as compared to previous
versions of the product using the same identical hardware platform.
7)
New Multi-session conference call capabilities.
The VOIP Media Engine™ now supports simple and complex multi-session call conferencing capabilities. In the simplest case, the media engine can be used in its default state to conference all lines into the same single default conference call group. In more complex conference call scenarios, the VOIP application has the ability to define whatever conferencing relationships exist between all phone lines. There are no limitations regarding the conferencing relationship between individual phone lines or between separate logical conference groups. In fact, separate logical conference groups may overlap if your application requires this capability.
The conferencing capability of the VOIP Media Engine™ centers around the concept of call conference IDs. Call Conference IDs are the same thing as conference session IDs. A conference session is simply a logical grouping of two or more phone lines that fully share media with one another - full duplex.
The conferencing relationships between individual phone
lines are completely controlled by your VOIP application by assigning logical
conference session IDs to phone lines. Phone lines that share similar call
conference IDs will be logically "wired together" internally inside
the media engine when the phone line is placed into the conference state using
the ConferenceLine API procedure. Conference session IDs are assigned to
individual phone lines using the SetConferenceGroupIds API procedure.
Conference IDs can be assigned to any phone line anytime as long as the phone
line is not already in a conference session.
8)
Allow multiple SIP log and event log servers to be configured.
Multiple remote SIP log and event log servers can now be configured.
If you need to send real time SIP log information to more than one remote SIP log server, application software can call the SetSipLogServer() API procedure any number of times to specify one or more SIP log servers.
If you need to send real time media engine event log
information to more than one remote event log server, application software can
call the SetEventLogServer() API procedure any number of times to specify one
or more event log servers. The media engine start-up parameters also support
configuring multiple event log servers.
9)
"Make Call" APIs now detect "line already in use" state
earlier.
This version of the media engine includes updates to all of the "make call" API procedures. These updates allow VOIP applications to “early detect” if another application thread is already in the process of making a call on the outgoing phone line. This helps to simplify application development and reduce unnecessary thread blocking for synchronous call operations.
10)
Improved call processing throughput - New faster call processing for server
applications.
This release of the media engine now supports faster call processing as compared to previous versions of the product. This new capability is focused at high line count VOIP server applications (greater than 128 lines) that need to process call as fast as possible.
What this means is this: As your application boots the media engine, the media engine will allocate all required phone line threads, events and memory resources at boot time instead of creating the needed resources “on demand” every time a call is started. When all call thread, memory and operating system resources are pre-allocated, calls are processed much faster.
11)
Improved network transmit capabilities.
This version of the VOIP Media Engine has improved network transmit capabilities that effect both SIP session and RTP media UDP transmissions. In summary, these changes allow the VOIP Media Engine to handle large call volumes more efficiently and large SUBSCRIBE/NOTIFY operations without having to report interim errors to the application.
The benefits of these changes are as follows:
SIP transactions:
When the host system is heavily loaded and the VOIP Media Engine is managing large call volumes (For example: 64 to 512 or greater concurrent lines active), SIP protocol packets that need to be sent will be retried automatically when the host system starts to run out of operating system internal network transmit buffers. Prior to these changes, the VOIP Media Engine would return error status or error events back to the VOIP application. This would be detected by the application as failed outgoing calls, failed subscribe or notify operations or possibly failed registration cycles. The primary advantage however is that incoming and outgoing call handling capability and robustness is greatly enhanced due to these network programming changes.
RTP media transmissions:
Similarly to the changes above that effect SIP
transmissions, RTP media transmissions benefit from the same internal changes.
What this means is that RTP jitter and delays will be reduced or completely
diminished as the result of heavy system loading when transmitting RTP media
payloads to the far end of the call.
12)
Improved startup and termination characteristics for high volume server
applications.
This release of the media engine has improved startup and termination behavior. The changes allow for quicker startup and termination when being used by high volume server applications that may experience incoming call hammering (due to large call volumes).
13)
Added new immediate event and structure to help resolve RTP NAT media issues.
The SipReceivedRtpMediaConflict immediate event has been added. The purpose of this event is to allow VOIP server applications to detect and instruct the media engine on how to handle a specific class of RTP NAT media issues.
If you are developing a server based VOIP application (PSTN gateway, IVR server, etc) using the media engine, this capability may be of interest to you. The media engine will send this event to application software any time it is detected that media is not coming from a call endpoint based on negotiated SIP media IP addresses and port values.
Application software can process this event and instruct the media engine on how media should be exchanged thus overriding negotiated SIP media setup for calls.
When application software receives this event, it also
gets the address of the new RECEIVED_RTP_MEDIA_CONFLICT structure. Application
software can then inspect this structure to obtain additional information
relating to the media conflict.
14)
Added support for call state recording.
Call state recording allows VOIP applications to view all call states a phone line progresses through as the call is being connected and terminated. This capability is most useful while developing and debugging your VOIP application.
If your VOIP call fails, all you have to do is enable call state recording and all the state transitions for the phone line will be recorded for the duration of the call. The call state list that is created can be inspected to locate error states that may help you in determining the exact cause of the call failure. This is especially useful if your application asynchronously uses the media engine API.
Call state recording can also be used to show you the call states that a phone line transitions through during normal call operations. This ability can be used as a learning tool to better understand the calls states of the VOIP Media Engine.
The following new API procedures have been added to support this capability:
SetCallStateRecording()
GetNumRecordedCallStates()
GetRecordedCallStates()
ClearRecordedCallStates()
15)
Added a new API that allows applications to filter specific events from remote
event logs.
The FilterEventLogServerEvents() API procedure can be
called to specify one or more remote event log events you want filtered. Events
that are filtered will not be sent to a remote event log server even though you
have an event log server enabled. The primary purpose of this API procedure is
to allow application software to filter out any events that are not important
for the current operation you are investigating or debugging. A good use of
this API procedure is to filter out all SipModifySipMessage immediate events.
16)
Added additional members to the ACTIVE_CALL_INFO structure.
Added raw INVITE and 2xx response SIP messages to the ACTIVE_CALL_INFO structure. This gives application software additional information associated with call setup.
17)
Added new immediate event to allow application to assign phone line to incoming
calls.
The new SipIncomingCallAssignPhoneLine immediate event has been added to the media engine. Application software can process this event in order to force the media engine to assign the incoming call to a specific available phone line as determined by the application. Useful when developing conference call servers where conference session IDs are set up and fixed for each line. This event also allows application software to terminate the incoming call immediately similarly like the legacy SipIncomingCallInitialized event.
This new event type also defines the new ASSIGN_INCOMING_PHONE_LINE data structure. When application software processes this event, it will also gain access to this new call data structure.
18)
Removed restrictions on API procedures relative to when they can be called by
application software.
This version of the media engine has been updated to remove restrictions on API procedures relative to when they can be called by application software. This reduces the possibility of application dead locking. It also allows developers additional freedom when calling API procedures from directly within the media engine main event callback handler (thread).
19)
Added Call ID string to phone line call information structures.
In an effort to allow application programmers the ability
to better correlate SIP messages to specific phone lines, the SIP Call ID has
been added to the following call related structures: SIP_INCOMING_CALL_INFO,
SIP_OUTGOING_CALL_INFO and SIP_ACTIVE_CALL_INFO.
20)
Media Engine now supports negotiated G729/G729A RTP media larger than 20Ms.
The VOIP Media Engine now handles G729/G729A RTP media packets larger than 20Ms. The actual size of the G729/G729A media packets is now negotiated at SIP call setup time. The media engine will always default to using 20Ms G729 RTP block sizes when initiating outbound calls. If the destination endpoint changes the default packet time (i.e. the “ptime=” value in the session sdp), the media engine will adapt to the new packet time as required. G729/G729A RTP packets can now be 20Ms or any other greater value. Negotiated resolution is one byte of sample data which is 1Ms for 8kHz G729/G729A codecs.
21)
Added 2 new Phone line events.
Added the following 2 new phone line events: SipMemoryError and SipThreadCreationError.
These events can be sent to application software if the media engine detects memory or internal thread start errors while processing outgoing or incoming phone calls.
22)
Minimizing virtual memory requirements.
A new section entitled "Minimizing virtual memory requirements" has been added to the VOIP Media Engine Software Developer's Reference.
This new section describes simple methods developers can
use to drastically lower the virtual memory requirements of the media engine
and the VOIP application. This information is important for developers who are
using phone line densities 128 lines or greater and who are developing server
based VOIP applications. This is a "must read" for all VOIP
developers.
23)
Improved low virtual memory performance.
The media engine has been improved to better handle low virtual memory situations. The ability to handle and recover from low memory or exhausted memory situations is an on going effort. This product version handles many more internal low memory situations which could otherwise cause access violations.
24)
Greatly improved call processing throughput when not using audio out multimedia
hardware.
Call processing throughput for incoming and outgoing calls has greatly been improved.
When application software disables multimedia audio output usage, the media engine no longer performs unnecessary checks and attempts to generate local audio telephony sounds such as outgoing phone ring, incoming phone ring, far end error or busy, etc.
Theses new enhancements allow the media engine to remove noticeable incoming and outgoing call processing delays that would lower overall call processing throughput. Previous to this release, applications may notice call processing delay mostly when answering incoming phone calls. The delay would occur between the reception of “180 Ringing” provisional responses and immediately before going off hook to answer the incoming call. Secondarily, outgoing calls would experience a slight call processing delay at the point where the media engine notifies the application using the SipStartOutgoingRing event. All VOIP applications will now be able to process a greater number of calls per minute due to these recent changes.
25)
Applications can now directly transmit generic UDP packet data via the media
engine.
The media engine now allows applications to directly send generic UDP data or
application defined SIP packets using the UDP server port of the media engine.
This is useful if applications want to send application specific data to a
remote log server or if applications want to create and transmit their own SIP
messages.
For further information see the SendUdpDatagram() and
SendUdpDatagramUsingSipPort() API procedures in the VOIP Media Engine
Developer’s Reference.
26)
Inter-op tested with the latest version of Asterisk PBX (v1.4.21.2).
This latest version of the VOIP Media Engine has been
inter-op tested with the latest version of Asterisk PBX v1.4.22.1. Subtle but
important updates have been performed on the media engine to ensure optimal
performance with Asterisk.
27)
Added new return error codes to StartSipTelephony() and ReStartSipTelephony()
API procedures.
Added the SipUdpRxBufferSizeError and
SipUdpTxBufferSizeError return values to StartSipTelephony() and
ReStartSipTelephony() API procedures. These two additional error return values
will inform application software of possible SIP UDP buffer sizing errors when
the media engine is started or restarted.
28)
Application created DTMF generators and decoders are now cleaned up by the
media engine.
If your VOIP application media engine DTMF generators
and/or decoders, the media engine will now make sure the resources used by
these elements are recovered when the media engine terminates or restarts.
Improved handle validation has also been improved.
29)
Improved interoperability associated with SDP ptime value and 30Ms iLBC only
calls.
For calls being initiated by the media engine that use 30Ms iLBC frame sizes and only have a single codec selected, the SDP ptime parameter was always being set to 20. It now gets set to 30. This has been done to improve interoperability with some devices that use the ptime SDP value instead of using the required iLBC mode parameter in the media attribute for the call.
Note that if mixing 20Ms and 30Ms codec types in a SIP
INVITE (i.e. having multiple codecs selected), the ptime value will be set to
20Ms even if a 30Ms iLBC codec is being offered as a possible media type in the
INVITE.
30)
New interoperability - Cisco-SIPGateway/IOS-12.x.
This latest version of the LanScape VOIP Media Engine has now been tested to interoperate with Cisco SIP VOIP Gateways (IOS-12.x). For further information, see the following URL:
http://www.cisco.com/en/US/products/ps6831/products_data_sheet0900aecd804110a2.html
31)
New interoperability - Cisco/Linksys SPA3102 PSTN gateway.
This latest version of the LanScape VOIP Media Engine has now been tested to interoperate with Linksys SPA3102 SIP VOIP Gateways.
32)
New interoperability - ENTICE VoIP Gateway.
This latest version of the LanScape VOIP Media Engine has now been tested to interoperate with ENTICE SIP VoIP Gateways.
33)
New interoperability - 3CX PBX.
This latest version of the LanScape VOIP Media Engine has now been tested to interoperate with the 3CX PBX. (http://www.3cx.com)
34)
New interoperability - sipX PBX.
This latest version of the LanScape VOIP Media Engine has
now been tested to interoperate with the sipX PBX. (http://www.sipfoundry.org)
35)
New interoperability - Mitel 3300 IP PBX.
This latest version of the LanScape VOIP Media Engine has now been tested to interoperate with Mitel 3300 IP PBXs. (http://www.mitel.com)
36)
New interoperability - CyberData VOIP Speakers.
This version of the VOIP Media Engine has been inter-op tested with CyberData SIP/RTP VOIP speakers. For further details regarding these cool SIP devices, see the following URL:
http://www.cyberdata.net/support/voip/ceilingspeaker.html
37)
Improved API procedure CloseRxIvrChannel().
The API procedure CloseRxIvrChannel() has been improved.
The API procedure is now more robust regarding being passed invalid handles.
38)
Improved API procedure CloseTxIvrChannel().
The API procedure CloseTxIvrChannel() has been improved. The API procedure is
now more robust regarding being passed invalid handles.
39)
Improved API procedure DestroyDtmfDecoder().
The API procedure DestroyDtmfDecoder() has been improved. The API procedure is now more robust regarding being passed invalid DTMF decoder handles.
40)
Improved API procedure DestroyDtmfGenerator().
The API procedure DestroyDtmfGenerator() has been improved. The API procedure is now more robust regarding being passed invalid DTMF generator handles.
41)
Improved API procedure GetNotifyChallengeErrorData().
The API procedure GetNotifyChallengeErrorData() has been improved. The API procedure is now more robust regarding being passed invalid notify handles.
42)
Improved API procedure GetSubscribeChallengeErrorData().
The API procedure GetSubscribeChallengeErrorData() has been improved. The API procedure is now more robust regarding being passed invalid subscription handles.
43)
SIP log files and remote SIP logging has been updated.
SIP log files and remote SIP logging has been updated. All logged SIP protocol messages now include a message ID number for easier reference. This helps when debugging SIP protocol related errors.
44)
The VOP Media Engine can now initiate a call to itself.
This version of the VOP Media Engine can now initiate a call to itself. Pervious versions did not allow this due to an internal limitation on how call dialogs (i.e. call legs) were being handled.
This capability is extremely useful when developing and
debugging your VOIP application call handling logic and is also required for
some call attendant based VOIP applications.
45)
Improved Subscribe/Notify internal handle validation.
Improved the way in which the media engine processes
Subscribe/Notify internal handle validation. With this new improvement, the
media engine will be able to detect invalid notify handles that are passed to
the media engine from application software. This primary goal of this change is
to minimize access violations that may be generated internally within the media
engine as the result of improper or faulty application software.
46)
Added additional intelligence to registration logic.
Additional intelligence has been added to the media engine’s registration logic. The media engine will now internally track when successful registrations are completed. In this way, an unneeded un-register delay can be avoided when the VOIP application un-registers in the case that the proxy/registrar is unavailable.
47)
GetLineStatus() API procedure now returns SipFarEndHoldOn state.
The GetLineStatus() API procedure now returns SipFarEndHoldOn state when the far end of a call places the call on hold. Previously, the media engine would return the SipInCall status back to the application when the far end placed the call on hold. This new status capability was added for consistency.
The SipFarEndHoldOn and SipFarEndHoldOff events that are sent to application software still behave as normal.
48)
Media Engine phone name and display name can accept new characters.
The media engine has been updated to accept new phone names and phone display names.
The name you assign to phone lines of the telephony engine can contain any alphanumeric characters, (a-z, A-z or 0-9), and any of the following characters: dash (-), underscore (_), period (.), exclamation point (!), tilde (~) or asterisk (*). Also, the phone name must not contain any "white space" characters.
The display name string you assign to the telephony engine
can contain any of the following ASCII character code values: (0x20 - 0x21),
(0x23 - 0x3B), 0x3D, (0x3F - 0x5B), (0x5D - 0x7E).
49)
Simplified redistribution model.
The ability to redistribute the media engine has been greatly
simplified. Now end user can redeploy the media engine however they want.
Generally a user would simply add the media engine to their own installer image
and install it wherever they require. The legacy method of having to use a
LanScape “redistribution installer” has been made obsolete.
50)
Installer image updates.
Completely redesign of the product install package. The install operation is now consistent between all supported operating systems.
51)
Added GetOutgoingCallErrorInfo() API procedure.
Added the GetOutgoingCallErrorInfo() API procedure. Application software can call this new API procedure to obtain the following error information that is associated with outgoing calls:
SIP response status code.
SIP response reason phrase.
The complete received SIP response message.
52)
Applications can now program registration retry time delay.
For applications that need to register with a SIP
registrar server, the media engine now allows application software to specify
the time delay to wait in between failed registration attempts. Application
software can now call the RegistationErrorRetryTime() API procedure to change
this time interval.
53)
RTP media stream encryption - Applications can now access all received and
"ready to be transmitted" RTP media packets.
The media engine has been updated to allow applications to obtain raw access to
all received and "ready to be transmitted" RTP media packets.
This capability is primarily used by application software to encode/decode RTP media packets that are associated with a call. In other words, applications can use this functionality to encrypt RTP media streams for a call.
54)
Active calls and "ready to be answered calls" are now terminated when
the media engine terminates.
Note: This enhancement affects only those applications that do not terminate phone calls prior to terminating the media engine.
If an application terminates the media engine while active phone calls are in progress, the phone calls will be properly terminated before the media engine terminates.
Likewise, if there are calls waiting to be answered, the
media engine will terminate the waiting calls by sending a “480 Temporarily
Unavailable” reply to the far end of the call.
55)
Multimedia audio inputs and outputs can programmatically be selected
independently.
This version of the VOIP Media Engine allows application software to independently specify the multimedia audio input and output device that will be managed by the media engine without having to change operating system “preferred audio device” settings.
Prior to this, if an application wanted to use an audio input from one device and an audio output from another device, the operating system would have to be configured to select the preferred audio input (on multimedia device 1) and preferred audio output (on multimedia device 2). The Media Engine would then be instantiated specifying the value SIP_USE_PREFERED_AUDIO_DEVICE for the start up parameter ZeroBasedAudioDeviceId in the START_SIP_TELEPHONY_PARAMS structure.
What was needed was a way to programmatically select
independent multimedia audio inputs and outputs that may reside on different
multimedia audio devices without having to modify default operating system
settings. This enhancement allows application software to do just that.
56)
Made all API procedure and callback procs use __stdcall calling convention.
Made all VOIP Media Engine™ API and callback procedures
use the __stdcall calling convention. This will allow the widest possible
number of languages to use the media engine API/DLL natively.
57)
Authentication credentials now support a "wild card" realm.
Authentication credentials now support a "wild card" realm. What this means is that you can specify a single authentication user name and password for all VOIP realms that will challenge your media engine application.
Specifying authentication user name and password for a wild card realm can be intermixed with specifying user names and passwords for specific known realms.
Bug Fixes:
1)
Parameter “PlaybackLocally” ignored when calling API procedure StartDtmfTone().
When commanding DTMF tone generation, the
“PlaybackLocally” parameter was being ignored. This caused DTMF tones to always
be played on the host’s local multimedia hardware (if multimedia hardware
support has been enabled). This bug has now been fixed.
2)
Improve media engine sdp media attribute parsing.
Added additional tests to sdp media attribute parsing code
to remove possible access violations when parsing non conforming media
attributes.
3)
Removed possible receive IVR access violation on multi-core hosts.
When terminating the media engine with one or more calls
that are active and while the VOIP application is receiving receive IVR phone
line streaming audio data, there was a possibility of generating an access
violation on multi-core host machines. This issue has been fixed.
4)
Call hold request that receives a "408 Request Timeout" response may
terminate the call.
If the media engine performed a call hold request of a
call and the far end or SIP proxy returned a "408 Request Timeout"
response, the media engine could terminate the call instead of simply allowing
the call hold re-INVITE to time out. This issue has been fixed.
5)
Conference session ID bug fix.
The media engine contained a bug that would allow it to
logically wire phone lines into conference sessions that did not have the same
conference session IDs as set by the SetConferenceGroupIds() API procedure. This
issue has been fixed.
6)
Re-invite record route header parse bug.
Fixed a bug associated with detecting the route host from
Record-Route headers that are parsed from INVITE "200 OK" responses.
Without this fix, re-invites may be sent to the wrong dest IP address when
using record route headers.
7)
Fixed possible Access Violation in RTP transmitter logic.
Fixed an uninitialized pointer in RTP transmitter logic
that could cause an access violation if internal DTMF is disabled but supported
(enabled) by license files and when the app filters transmitted RTP packets.
8)
Removed possible access violation when transmitting final ACK responses for
outgoing SIP INVITE requests.
This version of the media engine removes a possible access violation that was associated with transmitting final ACK responses to outgoing INVITE requests. It was possible for the media engine to improperly compute an internal address location if INVITE responses in the range of 400 to 699 arrived after the media engine decided that the call leg had already been properly terminated. If the media engine received additional “late” INVITE responses for a past call, an access violation could occur. This issue has been fixed.
9)
Multi-core conferencing deadlock issue fixed.
This version of the media engine includes a fix that will remove a possible deadlock situation when running the media engine on multi-core host hardware platforms and when quickly transitioning phone line “into” and “out of” conference mode.
10)
Fixed a bug in Ms accurate absolute SIP log time stamps.
A bug has been fixed that was associated with Ms accurate
absolute SIP log time stamps. It was possible, due to a rounding error that
absolute time stamps could have a value of 0 to 1000 Ms instead of 0 to 999 Ms.
This issue has been fixed.
11)
Fixed an access violation when local audio is ON and conferencing is OFF.
This version of the media engine fixes an access violation
that may occur when local multimedia audio is enabled and multi-line
conferencing capability is turned OFF.
12)
Fixed incoming call RTP port assignment errors when executing on multi core CPU
platforms.
This version of the media engine contains a bug fix that is associated with RTP port assignments for incoming calls.
Under certain situation when processing a large number of
incoming calls and when running the media engine on a multi core host (i.e. a
multi-pocessor host), RTP port assignment logic could assign the same RTP port
to two different incoming concurrent calls. This would result in one of the
calls generating the SipSocketBindError event during internal RTP call setup
which would make one of the calls fail. This bug has been fixed.
13)
Fixed SIP log time stamp error.
The relative time stamps for the first transmitted and received SIP log entries were incorrect. This issue has been fixed.
14)
Fixed access violation when conferencing is turned OFF.
Under certain execution situations, an unhandled access
violation could be thrown by the operating system when call conferencing is
turned OFF. This bug has been fixed.
15)
Resolved media engine indefinitely hanging upon termination when lines are in
“Busy Out” state.
If any phone line is placed into the busy out state and
the media engine is terminated, the media engine will not shut down properly
and appear to hang forever. This issue has been fixed.
16)
Resolved conference call thread deadlock issue.
This version of the media engine fixes a particularly nasty thread deadlock
issue that was associated with placing phone lines into conference mode. It was
possible for the media engine to experience a deadlock situation under the
following scenario:
1)
An application worker thread detects an incoming phone call and goes off hook to answer the call.
2)
The application then calls the ConferenceLine() API procedure to place the phone line into a conference session during the processing of the SipInCall state.
3)
At the same time the internal ConferenceLine() API logic is executing, the far end of the call terminates the call. If the execution of the internal conferencing logic and the call terminate logic are “just right”, one of two situations could occur. Either internal call thread logic would start to deadlock or the application thread that called the ConferenceLine() API procedure could deadlock. The internal condition that caused the deadlock to occur was associated with two sections of internal logic waiting on the same completion event.
This dead lock issue has now been resolved.
17)
Updated the media engine’s ability to detect RTP media conflicts using the
SipReceivedRtpMediaConflict event.
The media engine has the ability to detect received RTP media from different IP
addresses than what is negotiated in the SIP protocol. The media engine has
been updated to support both session and media level IP detection from request
and response SDP.
18)
200 OK SIP responses to SUBSCRIBE requests did not contain a "To:"
header tag.
If the media engine has been instructed to accept a
SUBSCRIBE request by the VOIP application, the “200 OK” SIP response that gets
transmitted did not contain a Tag parameter in the “To:” header field. This bug
has been fixed.
19)
Incoming subscription bug that caused memory to be reclaimed twice.
If the VOIP Media Engine received a SIP SUBSCRIBE request
and the VOIP application dose not want to accept the incoming request, the
media engine would process the SUBSCRIBE request as normal. However, an
internal data structure was being freed twice. This bug has been removed in
order to improve operating system stability.
20)
Removed possible deadlock situation in RTP receivers when under heavy load.
If the media engine is very heavily loaded and incoming calls are received and then quickly terminated (terminated in 1 second or less), and if the media engine runs out of phone lines for the total number of INVITE requests pending, there was a possibility of deadlocking the RTP receiver for a phone line. This issue has been fixed.
21)
Removed possible access violation when calling GetActiveCallInfo() API
procedure.
If an incoming call was answered and then terminated by
the far end very quickly, the application could call the GetActiveCallInfo()
API procedure and possibly generate an access violation. This issue has been
resolved.
22)
Removed possible access violation when calling GetIncomingCallInfo() API
procedure.
If an incoming call was answered and then terminated by
the far end very quickly, the application could call the GetIncomingCallInfo()
API procedure and possibly generate an access violation. This issue has been
resolved.
23)
Playback delay build up when using Tx IVR outputs.
When playing back sample block data to phone line transmit IVR outputs, the actual time to play all application supplied samples would be proportionately longer (approximately 0.2% longer) than the total time of the sample data.
The longer the continuous playback of sample data to Tx IVR outputs, the more accumulated playback delay would be introduced. This did not affect the sonic quality of the Tx IVR data but caused application developers to worry that their Tx IVR playback data would somehow be altered in pitch or frequency content.
This version of the media engine incorporates changes to
internal digital mixers that will completely remove all previously noticed
playback delay build up when using any of the Tx IVR outputs.
24)
Multiple line registrations using 3CX PBX.
A bug was fixed in the media engine that was associated
with performing multiple line registrations to the 3CX PBX. The media engine
would experience a parse error when receiving proxy authentication challenges
from the 3CX PBX. This bug would not allow multiple lines of the media engine
to be registered at the same time with the PBX. This issue has been fixed.
25)
Jitter compensation RTP packet bug.
If jitter compensation for a phone line is enabled, it was possible that not all received RTP media packets would be sent to an application’s receive IVR callback procedure while the jitter comp algorithm is engaged. The number of missed packets is equal to the specified API jitter comp time in milliseconds divided by the RTP payload time per packet.
Also if phone line loop back echo is enabled, it was also possible that not all RTP packets would be looped back for retransmission out the phone line.
This issue has now been fixed. Now regardless of the
internal state of phone line receive jitter compensation, all RTP packets will
be forwarded to the application’s receive IVR callback procedure and all RTP
packets will be echoed out the phone line if required.
26)
Phone line internal transmit mixer fix.
If a phone call is initiated and then quickly terminated immediately after entering in “in call” state, it was possible for the phone line’s internal transmit mixer logic to not enter the blocking state. Even though no voice data would be mixed, the internal thread logic could still execute every 20Ms even though the previous phone call was terminated. This bug simply caused additional unnecessary loading on the host CPU and no other side effect. This bug has now been fixed thus improving overall VOIP application performance and CPU utilization.
27)
User specified unsupported SIP headers may not be allowed in status responses.
If an application handles the SipModifySipMessage
immediate event and then attempts to add non standard unsupported SIP headers
to SIP status response messages, the media engine may not maintain the
unsupported SIP headers when the SIP status message gets transmitted. This
issue has been fixed. Now any and all unsupported or non standard SIP headers
that are added by the application will be transmitted along with the status
message.
28)
SUBSCRIBE/NOTIFY Event header parse error.
When using the SUBSCRIBE/NOTIFY support of the media
engine, specifying an event parameter string that contains one or more comma
characters may cause “Event:” header parse errors. The parse error would
manifest itself as returning only a partial string for the specified parameter
string. This bug has been fixed.
29)
Low memory situation may make outgoing calls to hang.
Under extremely low memory situations (no virtual memory
available), outgoing calls could possible hang if no more virtual memory is
available. This issue has been fixed.
30)
Random call terminations.
Under certain situations and system loading, phone calls
may appear to terminate randomly. This issue was due to an internal phone line
state flag that was not being set properly for all phone lines when the system
is handling a higher than average load. This bug would cause phone lines that are
in the process of setting up a new call to transition to the “on hook” state if
another line was at the point of terminating another call. This issue has now
been fixed.
31)
HIGH CPU load and input call hammering may cause incoming calls to generate access
violations.
Under high CPU loading and when performing “receive call hammering” on the media engine, incoming call flooding may generate an access violation.
This bug was found after performing incoming call hammering on the media engine for large line configurations (i.e. line densities 128 or greater). Basically, incoming call hammering tests the ability of the media engine to handle an incoming flood of calls while at the same time placing outgoing calls.
Basically a critical section of multi-threaded code was
not being protected. As a phone line was in the process of being terminated, a
new incoming or outgoing call may be assigned to the same line. This in turn
corrupted the new call phone line state data. This problem has now been fixed.
32)
The "PhoneLine" parameter in main event callback for immediate events
is now valid.
The “PhoneLine” parameter of the main event handler will now be set to the proper zero based phone line index when the media engine transmits SIP messages and the app wants to process the SipModifySipMessage event.
Before this update, the “PhoneLine” event parameter was
always a value of -1 for transmitted SIP messages that are related to a phone
line. This would force application software to perform or maintain a mapping of
call leg information for a phone line and manually keep track of what SIP
messages belong to what phone line. Now this is done for the application by the
media engine.
33)
Changes associated with “qop” authentication challenges.
The media engine has been updated to use non double quoted
“nonce count” values and non double quoted “auth” parameter values when
responding to qop digest authentication challenges. This will improve
interoperability and allows the media engine to be compliant with the latest Digest
authentication RFC.
34)
StartPhoneLineRecording() reported an error when specifying root drive with
trailing back slash.
The StartPhoneLineRecording() API procedure reported an error when specifying a root drive path specification that uses a trailing back slash. This bug has now been fixed.
The record path can be any root drive specification or any
other valid existing file path. The file paths can end in a backslash or not.
Trailing slashes no longer matter.
35)
Outgoing call makes phone line disable when receiving SipFarEndIsBusy.
Fixed a bug in outgoing phone line logic when
SipFarEndIsBusy is received. Under certain situations the phone line would
enter into a “disabled” sate where the SipOnHook line state would not be
reached. Once this situation was reached by the phone line, no API call could
clear or reset the phone line. This issue has been resolved.
36)
Possible access violation when terminating calls.
Under certain situations, the media engine may generate an access violation when terminating a phone call depending on system load and the number of phone lines that are actively in the “in call” state. An internal transmit mixer format and rate conversion block was being uninitialized before all transmit mixer operations were completed for the specific phone line. The internal race condition that existed which caused this issue has been fixed.
37)
Single instance media engine could not be restarted when experiencing an error.
If a single instance media engine is started and it gets
an error, application software could not restart the media engine because its
instance locking mechanism would report that an instance was already running.
The only way to clear this situation would be to restart the VOIP application.
This bug has been fixed.
38)
API procedure AddAuthorizationCredentials() will not add duplicate
authentication credentials.
API procedure AddAuthorizationCredentials() will not add
duplicate authentication credentials if called multiple times with the same
authentication values. Doing so will make sure that authorization credentials
are removed for each single call to the DeleteAuthorizationCredentials() API
procedure. Prior to this release, the AddAuthorizationCredentials() API
procedure would allow adding duplicate authentication credentials which was
incorrect.
39)
Possible telephony sound deadlock fixed.
If the VOIP media engine is being used to call itself or
if an outgoing call and an incoming call are processed just at the right
moment, it is possible that the media engine would enter into a multi-threading
deadlock state. This would only occur if multimedia audio is enabled in the
media engine. The problem was associated with how the media engine manages
telephony sounds for all lines. This issue has been fixed.
40)
Call hold timeout when receiving far end error.
When placing calls on hold or when removing calls from
hold, the hold/un-hold operation would act as though it would time out waiting
for a “200 OK” SIP response from the far end SIP device if a response was
received that was not a “200 OK” response. This has now been fixed. Now
hold/un-hold will only time out if the far end SIP device does not respond at
all.
41)
Incoming call "hammering" under heavy system load may cause
application exceptions.
When the media engine is processing a large number of
incoming calls (incoming call "hammering") and the system is heavily
loaded, the media engine may cause an application exception and crash. This is
due to the media engine trying to reuse a phone line before it has properly
been reinitialized after terminating a previous call. This issue has been
fixed.
42)
Possible memory leak if application does not close Tx IVR outputs before
termination when calls are active.
A possible memory leak exists if the VOIP application does
not close all of its transmit IVR (Tx IVR) outputs before termination while
phone calls are active. Now if phone calls are active and there are opened Tx
IVR outputs, the media engine will catch this situation and close them. This
solves the associated memory leaking problem on application exit.
43)
Possible improper Route list being transmitted during final ACK for hold and
un-hold Re-INVITE operations.
Under certain conditions and depending on how "Record-Route:" headers are assigned in received SIP response messages, the media engine may compute an improper Route list header when sending out the final ACK to Re-INVITE responses that are received from other SIP devices during call hold and call un-hold operations.
Normally the result of this “Record-Route” bug would be
that the configured domain proxy (if used) would unnecessarily forward the
final ACK down the record route chain that was used during initial call setup.
This is generally harmless but definitely not required. Fixing this bug removes
the proxy’s ability to forward the final ACK unnecessarily.
44)
Handling multiple WWW-Authenticate and Proxy-Authenticate headers in SIP
responses.
If the media engine authenticates with a proxy server and
then also authenticates with the call endpoint while sending out SIP requests,
under certain situations multiple redundant authentication headers could be
placed into secondary outgoing requests. This bug has been fixed.
45)
Multi-level (multi-realm) authentication bug fix.
Under certain situations, the media engine may not compute
and add all authentication credentials for SIP messages if being challenged by
2 or more authentication realms at the same time. This could occur while
transmitting SIP message requests to other SIP endpoints when the SIP message
requests pass through 2 or more authentication realms. In some situations, all
authentication SIP headers (WWW-Authenticate or Proxy-Authenticate) for all
challenging realms may not be added to SIP message retransmissions. This issue
has been fixed.
46)
Challenge response inter-op issue and bug fix.
In some situations when the media engine would challenge
SIP messages coming from specific user agents, the challenge response could be
malformed. This bug has been fixed.
47)
Terminate call deadlock issue.
Under certain situations and depending on system load, calling the TerminateCall() API procedure may cause an internal call thread deadlock or possibly place a media engine phone line in an improper call state. Once either of these situations occurs, the phone lime may not be useable until the media engine gets restarted. This issue has been fixed.
48)
DeleteAuthorizationCredentials() API procedure always returned FALSE.
The DeleteAuthorizationCredentials() API procedure always
returned FALSE. This bug has been fixed. Now the procedure will return TRUE
when the authentication credentials are deleted from the internal media engine
credential list. It will return FALSE if the authentication credentials to
delete could not be found in the internal media engine credential list.
49)
Possible malformed SIP "To:" header in SUBSCRIBE requests.
Possible malformed SIP "To:" header in SUBSCRIBE requests
Under certain configurations, the “To:” SIP header that is
located in media engine’s SUBSCRIBE requests may not contain a host part in the
"To:" header URI. This would occur if no proxy and domain name is
configured. This problem has been fixed.
50)
Possible access violation when calling RecreateNotifyHandle() API procedure.
A possible access violation (processor exception 0xC0000005) could occur when calling the RecreateNotifyHandle() API procedure to reconstitute a previously archived event notification handle. The access violation would only occur if the original record route information for the event subscription was not formatted properly as per the SIP RFC.
This is an esoteric an highly unlikely problem that most
users should not be effected. None the less, this bug has been fixed.
51)
StartPhoneLineRecording record path issue.
If the record directory path that is specified in the StartPhoneLineRecording() API procedure contained a back slash as its final character, then no recorded audio file would be created when phone call recording goes active. This bug has been fixed.
52)
CopounterPath X-Lite soft phone bug fixes.
The media engine has been updated to handle some obscure issues associated with the CounterPath X-Lite soft phones. Particularly the:
CounterPath X-Lite 3.0, X-Lite release 1006e stamp 34025
This soft phone generates improper
"Content-Length" SIP headers for call INVITEs and needlessly adds
multiple connection headers in the invite SDP. An issue was fixed that would
cause the media engine to generate an access violation because the soft phone
used the token "IPV4" instead of "IP4" in one of its
multiple its SDP connection headers. The media engine will now handle this
situation gracefully.
53)
Authentication fix when multiple registration names configured.
When multiple registration names (phone extensions) are
configured, the media engine would use the first registration name as the
“usename=” parameter in all challenge requests as the result of receiving
REGISTER “401 Unauthorized” challenge responses. This would cause some
registration severs to not be able to authenticate REGISTER challenge requests
from the media engine. This issue has been fixed.
54)
Software example bug fixes.
Removed a bug in the common shared module PhoneSetingsDlg.cpp. The ReadLicenseImage() member in class PhoneSetingsDlg did not convert the last byte of license data properly. This bug was fixed even though it has no effect on the license data that is passed to the media engine.
Fixed a bug in the PhoneBase.cpp module that called the wrong virtual member function of the inheriting super class. Now when the SipFarEndHoldOn event is detected, the FarEndHoldOn() virtual member function is called. When the SipFarEndHoldOff event is detected, the FarEndHoldOff() virtual member function is called.
Updated the DtmfGeneratorCallback() procedure in the
single line phone example app to remove the possibility of an infinite loop
when the phone is placed on hold and a DTMF keypad key is pressed.
55)
GetIncomingCallInfo() may return invalid URI for the initiator of a call.
API procedure GetIncomingCallInfo() may return an invalid URI for the initiator
of a call in the pSrcUrl member for structure SIP_INCOMING_CALL_INFO. This
problem has been fixed.
56)
Developer Reference documentation changes.
Updated the VOIP Media Engine Developer’s Reference. Included documentation updates and corrected minor documentation errors.
57)
Redistribution installer updates and fixes.
The redistribution installer has been updated in order to fix a problem associated with installing the image from an administrator’s account and then accessing the VOIP Media Engine from other lower privileged user accounts.
Under certain situations, the Media Engine would not
function when accessed from non-administrator user accounts. This issue has
been resolved.
58)
Possible improper RTP far end media IP address decoded for calls going to split
PSTN gateways/boundary controllers.
For certain VOIP deployment that use PSTN gateway devices (or other NAT
traversal solutions such as border Session Controllers) that perform session
handling on one IP address and RTP media streaming on other IP address, the
media engine may decode the wrong RTP media IP address from INVITE or "200
OK" SDP content.
Due to a subtle bug, the media engine would decode RTP media IP address using the SDP "o=" header (the "session origination" header) instead of using the far end RTP media information contained in the "c=" header (the "connection" header).
This bug has been fixed.
59)
Proxy-Authorization SIP headers may become corrupt when applications modify
outgoing SIP messages.
If an application modifies outgoing SIP messages by handling the
SipModifySipMessage media engine event, transmitted “Proxy-Authorization:” SIP
headers may become corrupt if they exist in the SIP message being modified.
No other outgoing SIP headers are affected by this bug. Only “Proxy-Authorization:” headers.
This problem has been fixed.
60)
Access violation when local playback audio is disabled.
If application software disables local audio playback, it should not call the following two API procedures:
SetLocalAudioLoopback()
SetLocalAudioLoopbackVolume()
Doing so will cause an access violation. The reason being is the internal master playback mixer that is responsible for mixing all data streams before final playback via multimedia hardware is not initialized when local audio playback is disabled.
This issue has been fixed. Now if an application disables
local audio playback and calls these two API procedures, the procedures will
return SipCallFailure.
Api Changes:
Note: The API changes mentioned here may have an impact on your source code. We
try to limit making any changes in the VOIP Media Engine API but in cases of
refinement, adherence to namespaces or improvements in the product, we
sometimes have to make changes that modestly impact your project. We regret any
inconvenience this may cause you.
1)
Renamed two registration global events to improve naming consistency.
The following two registration global events have been renamed to improve naming consistency:
Old Event Names:
SipRegistrationIntervalError
SipRegistrationTimeOut
New Event Names:
SipRegisterIntervalError
SipRegisterTimeOut
2)
Renaming of outgoing call telephony sound API procedures.
API procedures that are associated with outgoing call sounds have been renamed in order to remove API name clashing with upcoming future media engine capabilities and to improve naming consistency. The new API procedure name changes are as follows:
Old Names/prototypes:
TELEPHONY_RETURN_VALUE VOIP_API EnableDtmfDigits(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableBusySignal(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableErrorSignal(SIPHANDLE hStateMachine, BOOL EnableState);
New Names/prototypes:
TELEPHONY_RETURN_VALUE VOIP_API EnableOutgoingDtmfDigits(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableOutgoingBusySignal(SIPHANDLE hStateMachine, BOOL EnableState);
TELEPHONY_RETURN_VALUE VOIP_API EnableOutgoingErrorSignal(SIPHANDLE hStateMachine, BOOL EnableState);
3)
Renaming of DTMF generator API procedures.
The following stand alone DTMF generator API procedures have been renamed in order to remove API name clashing with upcoming future media engine capabilities:
Old Names/prototypes:
BOOL VOIP_API StartDtmfTone(HDTMFGENERATOR hDtmfGenerator, DTMF_TONE DtmfTone, DWORD DurationMs);
void VOIP_API WaitForToneCompletion(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API StopDtmfTone(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API SetDtmfAmplitude(HDTMFGENERATOR hDtmfGenerator, int Amplitude);
New Names/prototypes:
BOOL VOIP_API StartDtmfGeneratorTone(HDTMFGENERATOR hDtmfGenerator, DTMF_TONE DtmfTone, DWORD DurationMs);
void VOIP_API WaitForDtmfGeneratorToneCompletion(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API StopDtmfGeneratorTone(HDTMFGENERATOR hDtmfGenerator);
BOOL VOIP_API SetDtmfGeneratorAmplitude(HDTMFGENERATOR
hDtmfGenerator, int Amplitude);
4)
Renamed the GetNumberOfActiveCalls API procedure to GetNumberOfCallsInProgress.
The GetNumberOfActiveCalls API procedure has been renamed
to GetNumberOfCallsInProgress. This has been done to better describe true
nature of the API procedure.
5)
New conferencing API return value.
Added the media engine return value
SipConferenceNotEnabled value. This value gets returned by the ConferenceLine()
and SetConferenceGroupIds() API procedures when the API procedures are called
and conferencing is not enabled.
6)
Windows 9X and Windows NT 4.x operating systems no longer supported.
Support for Microsoft Windows 9X and Windows NT 4.x
operating systems has been discontinued. This means we have stopped development
and testing for all versions of Windows 95, 98, Me and all Windows NT 4.x.
Please contact LanScape support for further details if required.
7)
Media Engine "phone line mode" has been removed to simplify phone
line logic.
The PHONE_LINE value from the LINE_MODE enumeration has been removed to reduce developer confusion and to simplify the understanding of media engine phone line behavior. Now all phone lines act independently of each other for all phone line operations. The LINE_MODE enumeration is used when the media engine is started.
Additional information:
The Media Engine API defines the LINE_MODE enumeration. This line mode enumeration is used to tell the media engine how to manage functions between phone lines. Originally there were two modes of media engine operation - PHONE_LINE mode and SWITCH_LINE mode. In “phone line mode”, certain call operations (hold, conference) would affect the state of other phone lines. For example, if you had call #1 active and you answered call #2 on another line, call #1 would automatically transition to the hold state when you answer call #2. If you had multiple calls punched down into a conference session, taking one of the conference lines out of conference into normal “in call” state would cause all the other conference lines to be placed on hold.
The automatic manipulation of phone lines using the “phone line” mode was originally meant to simplify the development of soft phones. However feedback from customers showed that it caused more confusion than anything.
In “switch line mode”, all phone lines act independently
from one another all the time. This is the only line mode this version of the
media engine supports. This greatly simplifies understanding default phone line
behavior.
8)
Added the RandomlyAssignIncomingCallsToPhoneLines API procedure.
The RandomlyAssignIncomingCallsToPhoneLines() API procedure has been added to the VOIP Media Engine. This API procedure will allow application software to change the way incoming calls are mapped to available phone lines. This API procedure is similar to the RandomlyAssignIncomingCallsToPhoneLines startup parameter. Using this API procedure, application software can control how incoming calls are mapped to available phone lines (i.e. either sequentially or random).
9)
SetCallTerminateTimeout() API procedure can now be called with a zero value
timeout.
The SetCallTerminateTimeout() API procedure can now be called with a zero value timeout using the CallTerminateTimeoutMs parameter.
This ability be useful when the media engine has many calls active and you want to terminate the media engine quickly, Setting the value for the CallTerminateTimeoutMs parameter to zero and calling the SetCallTerminateTimeout() API procedure before terminating the media engine will result in faster shutdown.
10)
MakeCallUri() and MakeCall() API procedures detect memory errors.
The MakeCallUri() and MakeCall() API procedures have been updated to return the status SipMemoryError when a memory error has been detected when initiating an outgoing call.
Prior to this release, the media engine would return the
“catch all” SipCallFailure error status.
11)
Added SipOutgoingCallStateError API return value.
The SipOutgoingCallStateError API return value has been added to the media engine. This value will be returned by the MakeCallUri() and MakeCall() API procedures if the outgoing call could not be started due to an internal media engine state error.
Prior to this, the media engine would simply return the
"catch all" SipCallFailure error status when an internal state error
was detected.
12)
Added SipBadSipUri API return value.
The SipBadSipUri API return value has been added to the media engine. This value will be returned by the MakeCallUri() API procedure if the call destination URI is not valid. This change will allow applications to immediately detect bad call URIs when making outgoing calls.
Prior to this, the media engine would simply return the
"catch all" SipCallFailure error status making it hard for
application developers to detect the real cause of an outgoing call failure due
to bad SIP URIs.
13)
Added SetReceivedUnsolicitedNotifyState() API procedure.
Added the SetReceivedUnsolicitedNotifyState() API procedure to allow application software to enable the reception of unsolicited incoming SIP NOTIFY messages. With this capability enabled, application software will be notified of all unsolicited NOTIFY requests the media engine receives. The application will also have access to the parameters of the NOTIFY even(s) and access to the raw NOTIFY SIP message that was received.
Some SIP server architectures use unsolicited NOTIFY
requests to indicate system events and status. Notably, Asterisk PBX uses
unsolicited NOTIFY messages to indicate to a SIP device that voice mail
messages are waiting.
14)
Added GetNumActiveCalls() API procedure.
Added the GetNumActiveCalls() API procedure to allow
application software to directly interrogate the media engine for the current
number of calls that are active. Active calls are those calls that are in the
"in call" state and actively exchanging media.
15)
Added structure NOTIFY_TYPE.
The NOTIFY_TYPE structure has been added to the API to
allow the media engine to inform the application about the type of NOTIFY
request that is received.
16)
Updated the NOTIFY_REQUEST.
Updated the structure to allow access to received NOTIFY SIP messages. When applications are sent an event indicating that a NOTIFY SIP message has been received, the application will now be able to fully access the received SIP message using the NOTIFY_REQUEST structure that is passed to application software.
Updated the structure to allow application software to be able to detect if the received NOTIFY request is the result of a subscription or if the received NOTIFY request is unsolicited. This is accomplished via the new NOTIFY_TYPE structure.
Added the structure member UnsolicitedNotifyResponse. It
is used only when receiving unsolicited NOTIFY requests. Application software
can set this value to a valid SIP response code. If the applications wants to
inform the sender that the NOTIFY was accepted, it should be set to 200. If an
error response is desired, it should be set in the range of 400-699 depending
on the specific SIP error response desired. Generally a 481 error response is
acceptable.
17)
Added a new member to the CHALLENGE_AUTHENTICATION structure.
Added the new member ChallengeUserName to the
CHALLENGE_AUTHENTICATION structure. This will allow the media engine to pass to
the VOIP application the authentication user name for incoming authentication
responses. Now all VOIP applications can authenticate using a user name and a
defined realm instead of simply authenticating to just a defined realm.
18)
BusyOutLine() API procedure returns additional error values.
The BusyOutLine() API procedure will now return to the
caller the SipCallAlreadyInProgress error value when an attempt is made to busy
out a phone line when call activity is present. Phone lines can be busied out
only when the phone line is on hook.
19)
Added new return values to StartSipTelephony() API procedure.
In support of pre-allocating call related threads and memory resources, the StartSipTelephony() API procedure may now return two additional error indications:
SipCallThreadStartFailure:
A required internal call related event could not be created.
SipCallThreadStartEventFailure:
Indicates that a call thread could not be pre-allocated at
start up. This generally is the result of running out of process memory.
20)
Added parameter to OpenWaveFile() API procedure.
The int *pBytesPerSample parameter was added to the
OpenWaveFile() API procedure. Adding this parameter will allow calling
applications software to quickly determine the "byteness" of wave
file sampled data.
21)
New members added to structure SIP_ACTIVE_CALL_INFO.
The AudioFormatRtp and VideoFormatRtp members were added
to this structure so that VOIP applications could easily access the raw RTP
media types for phone calls. Note: Video is not yet supported in the media
engine but will be in a future release.
22)
New member added to structure IVR_RECOGNITION_DATA.
The BOOL SamplesInByteArray member value has been added to
the IVR_RECOGNITION_DATA structure. This member value will allow application
callback procedures to quickly determine if received IVR sample block data is
in the form of a byte (8 bit) sample array or a short (16 bit) sample array.
Now application software need not worry about correlating received sample type
with sample bit length.
23)
SetPhoneLineVolume API procedure now supports both Tx and Rx volume.
The SetPhoneLineVolume API procedure now supports both Tx and Rx volume levels. What this means is that VOIP application software can call this API procedure to set the volume levels for either transmitted voice data or received voice data.
24)
Added parameter to InitializeMediaEngine() API procedure
The "ThreadStackSizeInBytes" parameter was added to the
InitializeMediaEngine() API procedure. Adding this parameter will allow all
VOIP applications to programmatically specify the stack size associated with
internal VOIP Media Engine threads. Depending on what features and how many
lines your media engine is creating, adjusting the stack size down from its
default value can vastly save process memory when your VOIP applications
executes. This in turn can have a positive impact on call processing
performance and overall application process memory foot print.
25)
Added parameter to GetAudioOutSampleBlockSize() API procedure.
A new parameter was added to the GetAudioOutSampleBlockSize()
API procedure. The BOOL *pSamplesInByteArray parameter will allow application
software to easily determine if the media engine is expecting audio output
sample block data to be in the form of a byte (8 bit) element buffer or a short
(16 bit) element buffer.
26)
Added parameter to GetTxIvrSampleBlockSize() API procedure.
A new parameter was added to the GetTxIvrSampleBlockSize()
API procedure. The BOOL *pSamplesInByteArray parameter will allow application
software to easily determine if the media engine is expecting Tx IVR sample
block data to be in the form of a byte (8 bit) element buffer or a short (16
bit) element buffer.
27)
Added parameter to OpenRxIvrChannel() API procedure.
A new parameter was added to the OpenRxIvrChannel() API procedure. The BOOL *pSamplesInByteArray parameter will allow application software to easily determine if received IVR sample data is being passed back to the application as a byte (8 bit) element buffer or a short (16 bit) element buffer.
28)
Added new parameters to AbortIncomingCall() API procedure.
Additional parameters were added to the AbortIncomingCall() API procedure to allow application software to be able to specify the SIP response "Status-Code" and "Reason-Phrase" that is used in the SIP message response header that is sent back to the initiator of the call.
Prior to this release, the AbortIncomingCall() API procedure could be called to send a "480 Temporarily Unavailable" SIP response to the initiator of the call. Now application software can specify whatever response status code and reason phrase that makes sense for the specific application.
For application software that used the prior version of the AbortIncomingCall() API procedure, the equivalent call to the new API procedure would be as follows:
AbortIncomingCall(hMediaEngine,ZeroBasedPhoneLine,480,"Temporarily Unavailable");
The API procedure will also make sure application software specifies a status code for one of the following SIP status code categories:
Request Failures: 400 to 499
Server Failures: 500 to 599
Global Failures: 600 to 699
29)
Changes to the START_SIP_TELEPHONY_PARAMS structure.
Changes have been made to the START_SIP_TELEPHONY_PARAMS structure that is used to specify media engine configuration and startup values
Important Note: Make sure to update your application source code to initialize these new structure members before starting this new version of the VOIP Media Engine™. Not initializing startup parameters in the START_SIP_TELEPHONY_PARAMS structure may lead to undesirable behavior.
The following changes have been made:
New structure variables:
a)
Selecting audio IN and OUT on different multimedia devices:
In an effort to completely and programmatically allow application software the ability to specify any multimedia input and output device, the ZeroBasedAudioDeviceId has been replaced by the following two values:
int ZeroBasedAudioInDeviceId,
int ZeroBasedAudioOutDeviceId,
With these two new values, application software can now programmatically select any input or output multimedia device channel without the need to alter operating system "preferred audio device" settings via the Windows control panel. This new capability makes selecting audio IN and OUT channels simpler for application software when the IN and OUT channels reside on different multimedia hardware devices.
b)
Reducing memory requirements:
Added member MaxMixerLinebuffers to the startup structure. This value will allow application programs to control how much memory is used for internal audio mixing operations. It also controls how much internal audio data gets buffered prior to digital mixing operations at various points in the media engine’s audio signal paths. To reduce memory requirements, values as low as 2 can be specified for this parameter. Each mixer line buffer contains 20Ms worth of audio data. The default value for this parameter internally is 64.
c)
Programmatically specifying the max RTP UDP packet size.
Added member MaxRtpPacketLength to the startup structure. This value will allow application programs to specify the maximum number of bytes that can be transmitted and received in any RTP UDP data packet. Primarily used when application software encodes transmitted RTP data and as the result of the encoding process, generates RTP UDP packets that are larger than normal RTP packets.
In addition: If an application encodes/decodes RTP media packets, the value specified by this parameter determines the maximum RTP buffer size of the RTP packets that are sent to the application.
d)
Enabling phone line initialization events at startup.
Added member SendLineInitializedEvents to the startup structure. This value will allow application programs to enable or disable the ability of the media engine to send phone line initialize events to the application during startup. If enabled, the media engine will send the SipLineInitialized PHONE_LINE_NOTIFICATION event to the application for each phone line created by the media engine. Large line applications generally use this to drive a GUI progress display when the VOIP application starts.
e)
Allow application software to specify the use of sequential RTP media ports or random RTP media ports.
Added member UseSequentialRtpPorts to the startup structure. This value will allow the media engine to either use random RTP media ports or sequentially assigned media ports. The use of sequential RTP media ports can be useful when debugging VOIP applications. Alternatively, using random RTP media ports may improve security.
f)
Allow application software to specify how the VOIP Media Engine assigns incoming calls to available phone lines.
The new startup value RandomlyAssignIncomingCallsToPhoneLines has been added. Setting this startup value to non zero (TRUE) will allow the media engine to randomly assign incoming phone calls to any available phone line that is already not in use. If you are developing a server based VOIP application, you should set this value to non zero. Doing so will yields slightly better call handling performance and throughput. For all other application such as soft phones or non server based VOIP application, you can set this value to zero (FALSE).
g)
Added the SipUdpReceiveBufferSizeInBytes startup parameter. This value allows application software to specify the low level SIP UDP receive buffer size that is used by the media engine. Application software can increase this value in the event that SIP UDP packets are lost due to Windows UDP receive buffering limitations. Setting the proper receive buffer size will allow the media engine to process calls as fast as possible. Normally this value can be specified to be zero. In this case, the media engine will compute its value based on startup parameters and line density.
h)
Added the SipUdpTransmitBufferSizeInBytes startup parameter. This value allows application software to specify the low level SIP UDP transmit buffer size that is used by the media engine. Setting the proper transmit buffer size will allow the media engine to process calls as fast as possible. Normally this value can be specified to be zero. In this case, the media engine will compute its value based on startup parameters and line density.
i)
Added the MaxSipMessageReceiveFifoLength startup parameter. This value allows application software to specify the maximum number of SIP messages that the media engine will hold in its receive fifo queue. If the media engine receive fifo is filled, application software will sent the global notification event NewSipSessionReceiveOverrun. In this case, the fifo depth should be increased or the media engine application should be hosted on a faster server machine.
j)
In support of configuring multiple remote event log servers, the startup parameters EnableEventLogServer, pEventLogServer and EventLogServerPort have been changed to EnableEventLogServers, pEventLogServerList and pEventLogServerPortList. These updated parameters allow application software to specify one or more remote event log servers that will receive real time media engine events. The new parameters are null terminated ASCII strings that specify remote server address and port information.
30)
Changed the name of the SipSubscribeNetworkError event to SipSubscriptionNetworkError.
Changed the name of the SipSubscribeNetworkError event
notification event to SipSubscriptionNetworkError so the name is more
consistent with other SUBSCRIBE event names.
31)
Added new structure definitions in support of raw RTP access.
Two new structures have been added to the media engine API. These new structures are used when application software enables raw access to transmitted and received RTP media data.
RTP_HEADER
This structure defines the layout of RFC1889 compliant RTP packet headers.
RAW_RTP_DATA
This structure is used to pass RTP packet information to application software.
Applications can use the information in this structure to
directly modify the contents of any and all received or "ready-to-be"
transmitted RTP packets.
32)
Added the LogPhoneLineSipMessages() API procedure.
The LogPhoneLineSipMessages API procedure has been added
to allow applications to generate SIP log files for individual phone lines. Useful
for debugging SIP session related problems.
33)
Added the SetCallCancelTimeout() API procedure.
The SetCallCancelTimeout() API procedure has been added to allow applications to control how long the media engine will wait for outgoing call CANCEL responses from the far end of the call. Prior to this release, the media engine used a hard coded timeout value.
When the media engine transmits a CANCEL request for an outgoing call, it expects to receive a "200 OK" response for the transmitted CANCEL request and a "487 Transaction Terminated" response for the initial INVITE request. Note that the "487 Transaction Terminated" response received will also be answered by a final ACK from the media engine.
The media engine will wait the
"CallCancelTimeout" as set by the API procedure for the "200
OK" response. It will also wait the "CallCancelTimeout" for the
"487 Transaction Terminated" response. The order of these responses
does not matter. If the media engine does not receive both expected responses,
the phone call will proceed with cancel termination. If the responses arrive
after the timeout as set by the API procedure, the responses will be ignored.
34)
Added the SetPhoneLineVuMeterCallback() API procedure.
The new SetPhoneLineVuMeterCallback() API procedure has been added to allow application software the ability to receive digitally mixed phone line sample block data. This data can be used by application software to drive VU meter display elements. The sample data that is passed to the application using the specified callback is similar to recorded phone line audio data but does not require the phone line record functions to be enabled.
Generally a VOIP application will take the sample block
data that is passed via a user defined callback procedure and perform either
rectification+averaging or simply pass the data through a running average
filter to drive VU meter GUI elements.
35)
Added the EnableRawRtpPacketAccess() API procedure.
The new EnableRawRtpPacketAccess() API procedure has been
added to allow application software the ability to access all raw RTP media
packets entering or leaving the VOIP Media Engine. RTP media packets are sent
to application software using a standard callback mechanism.
36)
Added the SipRtpReceiveBufferTooSmall event.
Added the SipRtpReceiveBufferTooSmall event. This event
can be sent to application software in the event that an RTP media packet is
received that is too large to process.
37)
Added the SipIncomingCallAborted event.
Added the SipIncomingCallAborted event. This event will be
sent to application software when the application aborts an incoming phone call
using the AbortIncomingCall() API procedure.
v5.12.0.0
New Features and
Capabilities:
1)
Improved interoperability with other SIP software and devices.
LanScape is always performing SIP interoperability testing with its VOIP products. This version of the VOIP Media Engine™ has been put through another extensive round of interoperability testing to ensure the highest degree of operations with SIP devices and software from other manufacturers. The following SIP devices and soft phones have been added to the SIP interoperability list:
SIP desktop phones:
Avaya 4600 series IP telephones (Release 2.2):
4601 IP Telephone
4602 IP Telephone
4610SW IP Telephone
4620 IP Telephone
4621SW IP Telephone
4622SW IP Telephone
4625 IP Telephone
4630SW IP Screenphone
Avaya 4690 IP Speakerphone
SwissVoice:
IP10S SIP phone
Linksys-Sipura:
SPA841 SIP Business phone
SPA941 SIP Business phone
Grandstream Networks
Budgetone 101 SIP phone
Budgetone 102 SIP phone
GXP-2000 Enterprise IP Telephone
Polycom SoundPoint® IP Family of Desktop Phones:
SoundPoint® IP 300
SoundPoint® IP 301
SoundPoint® IP 500
SoundPoint® IP 501
SoundPoint® IP 600
SoundPoint® IP 601
Snom VOIP Phones:
Snom 300 IP phone
Snom 320 IP phone
Snom 360 IP phone
SIP Soft phones:
Xten-Counterpath EyeBeam v1.1 voice and video soft phone
Polycom PVX 8.0.1 voice and video soft phone
Snom 360 v5.3
sipXphone (Pingtel) v2.6.0.27
eStara SoftPHONE v3.0.0.18
Other:
Asterisk PBX.
Axon Virtual PBX Software and soft phones.
2)
Complete easy to use call recording using any phone line.
Phone line call recording now supported! When this capability is enabled, the VOIP Media Engine™ will automatically handle all tasks associated with digitally mixing and writing recorded sample audio to multimedia audio files. The call recording capabilities also allow application software to access the recorded sample audio blocks in real time if required.
Call recording can be enabled/disabled at any time and on a per phone line basis.
Recorded audio data can be written to multimedia sample data files using Raw 8k PCM samples or it can be written as wave formatted file image. The recorded audio data files can then be used at a later time for whatever the application requires.
This capability is extremely useful when developing soft
phones, VOIP messaging systems or answering machine applications.
3)
Complete Belcore compliant in-band DTMF generation and decoding.
Version 5.12 of the Lanscape VOIP Media Engine™ now supports integrated Belcore compliant DTMF generation and detection.
Brief DTMF Technical Specifications:
Complete in-band DTMF generation and decoding for VOIP applications.
DTMF Tones supported: 1,2,3,4,5,6,7,8,9,0,*,0,#,A,B,C,D
8 kHz PCM and uLaw data interface.
20Ms sample block size.
AGC (Automatic Gain Control) applied to all input source data.
Volume ramping of generated DTMF during ON/OFF and OFF/ON transitions.
Belcore compliant DTMF generation/decoding.
Very fast DTMF detection convergence.
DTMF detection using as little as 20 Ms of input signal.
Employs state of the art Goertzel/LanScape proprietary DTMF detection algorithms.
Two DTMF evaluation modes: Immediate and thread deferred.
Easy of use: Just connect the "plumbing" and go.
Optional: DTMF decoder can be custom tuned to end user's requirements.
4)
Installation image includes a new development server utility - EventLogD.exe.
This release of the VOIP Media Engine™ now includes a new development server utility - EventLogD.exe
EventLogD is a console server application that can be used to view the events the VOIP Media Engine™ sends to applications in real time.
With this handy server tool, you will be able to quickly see what media engine events are being offered to your VOIP application software as they occur. Simple event filtering is also supported.
This server utility can be used in conjunction with the new SetEventLogServer() API capability the VOIP Media Engine now supports.
5)
Added 2 immediate events and API support to allow application software the
ability to inspect and modify RAW SIP messages.
Applications can now intercept all received and ready-to-be transmitted SIP messages. The main purpose of this new capability is as follows:
1) To allow applications the ability to modify SIP messages just prior to protocol transmission.
2) Allow applications to inspect received SIP messages.
3) Allow application software the additional flexibility required to perform application specific protocol tasks.
To support this new functionality the "SipModifySipMessage" immediate event and the ModifySipMessage() API procedure have been added to the media engine.
There are many uses for this generic access to the VOIP Media Engine SIP protocol stream. One important such capability is the application's ability to transparently transmit and receive custom SIP headers between call endpoints.
6)
Sample applications support multiple builds.
Sample applications can now be built with Visual C++ 6, Visual Studio 2003 or Visual Studio 2005.
7)
Sample applications can now be configured via the GUI.
GUI based Sample applications can now be configured for Network settings, SIP Proxy, Registrar and Authentication parameters via the GUI. These changes were implemented to allow users to experiment with the source code examples without having to rebuild them.
8)
No need to rebuild Normal or Trial software examples.
There is no longer a need to rebuild the GUI based software examples. The VOIP Media Engine now ships with pre-built binary images of the software examples.
When the GUI based VOIP software exampled start, they will prompt the user to configure proper network settings and for a valid Microcode/license file image.
This change was based on much customer feedback. Customers not specifically familiar with C/C++ languages wanted to fully test the software examples without having to perform a software build operation.
Note: Non GUI based samples will still have to be rebuilt by the end user.
9)
Trial license now allows up to 5 instances of the VOIP Media Engine to run at
the same time.
The v5.12 trial license now allows up to 5 instances of the VOIP Media Engine to run at the same time. Previously, a single instance was only allowed. Because of this license limitation, multiple host machines were required in order to test and experiment with the sample applications.
Customer feedback has determined that many users want to
be able to quickly test VOIP Media Engine functionality using a single host
machine. As such, we have changed the trial license so that you can now execute
any 5 of the sample applications at the same time.
10)
Support registering individual phone lines using unique names.
This version of the VOIP Media Engine™ now supports registering individual phone lines using different user names (extension numbers).
In this new mode, incoming phone calls are routed to available phone lines that have the same destination user name as specified in the received SIP INVITE message.
Useful for IVR based applications where different IVR tasks must be assigned to different phone lines and registered extensions.
Implementation Notes:
Changed EnableSipRegisterServer() API to add the parameter "RegisterPhoneLines"
Added the return value SipRegisterBadNameList to indicate
that the registration name list does not contain the proper number of names for
all phone lines.
11)
Soft phone examples now support call recording.
The soft phone examples that come with the VOIP Media Engine™ now support call recording on a per phone line basis.
When enabled, call audio can be recorded to a wave file for later playback.
12)
Added support for ignoring incoming calls.
Added support for ignoring incoming phone calls. Applications can now call the new AbortIncomingCall() API procedure when receiving an incoming phone call. When this API procedure is called, the media engine will send a "480 Temporarily Unavailable" status response back to the other user agent or configured SIP proxy.
13)
Added Route header functionality to BYE messages when Record-Route is enabled.
Added Route header functionality to BYE messages when Record-Route is enabled. This capability was missing from previous versions.
14)
Improved event SUBSCRIBE processing.
Improved how event subscriptions using SUBSCRIBE messages are initialized and transmitted to the subscribe destination.
If many event subscriptions were started at the same time, the actual order that the event subscriptions would be transmitted could be interlaced and vary greatly depending on system load. This makes SIP protocol logging more confusing and difficult.
Now when many event subscriptions are started at once, the subscriptions are managed such that the SUBSCRIBE requests will initially be transmitted in the order that they were started.
15)
Log SIP transaction to the SIPLogD server without having SIP log files enabled.
Allowed the media Engine to log SIP transmitted and
received SIP protocol data to a SIP log server (SIPLogD.exe) without forcing
the application to also enable SIP log files. Now logging SIP protocol data to
a SIP log server and to a SIP log file are completely independent.
16)
Improved INVITE loop detection for outgoing calls..
Improved the robustness of INVITE loop detection for outgoing calls. The loop detection logic now also incorporates and validates CSeq SIP header values.
17)
Always use ptime media attribute in SDP.
The VOIP Media Engine now always uses the ptime media
attribute in SDP when initiating calls. This improves default interoperability
with other manufactured SIP devices.
18)
Improved the robustness of registration cycles.
In the previous version of the product, if the initial registration cycle failed, then the application would be notified about the error and further registrations were terminated.
Changes have been made that allow the registration logic to continue to attempt registration cycles in the background until a successful registration is achieved or registrations are turned off.
When registration errors are detected, the registration logic will now retry registrations at the periodic interval as specified by the RegistationErrorRetryTime() API procedure.
This improved behavior will allow VOIP applications to
recover faster and automatically in the event that registrar server loss
occurs.
19)
Maximum SIP message size now configurable.
The media engine can now be configured to use an application specified max SIP message length.
20)
Detection of received SIP messages that are too large.
The media engine now detects and properly reports the reception of SIP messages that are too large to be processed. When this condition occurs, it will send the SipReceiveBufferTooSmall event to application software.
Larger SIP messages can be accommodated by specifying the max SIP message size the media engine should handle.
21)
New API procedure SetEventLogServer().
The New API procedure SetEventLogServer() has been added to the media engine. When application software calls this API procedure, the media engine will send its internal event data to a remote server (EventLogD.exe - Also included with this release)
The primary advantages of activating this feature is the ability to see the VOIP Media Engine's events that are sent to application software in real time. This capability greatly enhances user's understanding of the media engine's event mechanism.
22)
New API procedure GetTelephonyStatusString().
The GetTelephonyStatusString() API procedure can be called by application software to obtain the "man readable" ASCII text string representation of any value specified in the TELEPHONY_RETURN_VALUE enumeration.
This capability can be useful while debugging
applications.
23)
New API procedure ModifySipMessage().
The ModifySipMessage() API procedure will allow
application software the ability to change any received or
ready-to-be-transmitted SIP message as the application dictates.
24)
New API procedure RegistationErrorRetryTime().
Added the new API procedure RegistationErrorRetryTime()
that allows precise control over the registration retry period.
25)
API procedure UseRportInViaHeader().
Added the new API procedure UseRportInViaHeader() that allows finer control over adding rport parameter to transmitted Via headers.
26)
New API procedure UseBranchInViaHeader().
Added the new API procedure UseBranchInViaHeader() that
allows finer control over adding the branch parameter to transmitted Via
headers.
27)
New API procedure SetCallHoldType().
Added the new API procedure SetCallHoldType() that allows
application software to enable different call hold support. Applications can
enable or disable RFC2543 type (c=0.0.0.0) and RFC3261(sendonly/recvonly) hold
support. By default, both types of hold logic are enabled.
Bug Fixes:
1)
SIP receive message timestamp not correct.
If SIP log file functions are disabled and SIP logging to
a SIP log server is enabled, the timestamp value of received SIP messages sent
to the SIP log server will be inaccurate. This problem has been fixed.
2)
Speech recognition callaback not being called.
Due to internal changes in the previous version (v5.11), the speech recognition callback may not be called. This bug has been fixed.
3)
Disabling NIC when not logging to a SIP log causes an exception.
Disabling the NIC used by the VOIP Media Engine when SIP file logging is off and the Media Engine is actively transmitting SIP messages can cause application code to crash.
Further information: If you have not enabled the VOIP Media Engine's ability to log SIP messages to a log file and you then disable the network interface card (NIC) that the VOIP Media Engine is using while it is actively transmitting SIP messages, an internal exception will be generated that may crash application software.
As long as SIP file logging is enabled, this bug will never materialize when actively disabling/enabling the NIC used by the Media Engine. It is only when SIP file logging is off that this problem will occur.
This problem has been fixed.
4)
Transaction Does Not Exists when receiving ACK for canceled INVITE.
A timing issue has been identified that could cause the media engine to transmit a "481 Transaction Does Not Exist" SIP message when in the process of receiving an inbound call and the call is canceled by the far end.
The "481 Transaction Does Not Exist" SIP message could be sent in response to receiving the call's final ACK message.
5)
Handle an unlimited number of media descriptors in SDP.
The media engine will now handle an unlimited number of media descriptors in SDP. This allows the media engine to interoperate with more complex SIP endpoints that offer mixes of audio, video and application media sessions.
Even though the media engine will now accept all other types of media session descriptors in SDP, it will only use the first detected audio media session when terminating a voice call from another SIP device. Video and possibly other media types will be supported in future versions of the product.
6)
GetNumberOfActiveCalls() API now returns proper number of calls for the
SipCallComplete state.
The GetNumberOfActiveCalls() API procedure now returns the proper number of calls when it is called during the SipCallComplete media engine state. This will help to reduce developer confusion. Most developers were calling this API procedure while processing the SipCallComplete event instead of the SipOnHook event. Now once a call hits the SipCallComplete state, the number of active calls will be computed and waiting for the application.
7)
BYE CSeq number may not be incremented in the call dialog.
Under certain conditions and when interoperating with other SIP devices, the CSeq number may not be incremented properly when terminating a received call. This issue has been fixed.
8)
Record-Route and Route set being redefined during call holds.
A bug was fixed that would cause a call's "Route set" during a call dialog to be reinitialized as the result of performing call hold operations.
The route set is now fixed as detected at the start of the call when Record-route is enabled. This also improved interoperability with some other manufactured SIP devices and phones.
9)
Bug fix for SetFromHeaderUserName() API procedure.
Fixed a bug in the SetFromHeaderUserName(). Under some
conditions, the From header user name would not be changed properly.
10)
API procedure GetNumberOfActiveCalls() returns 0 when passing an invalid Media
Engine handle.
The API procedure GetNumberOfActiveCalls() will now return 0 for the "int *pNumberOfActiveCalls" when passing an invalid Media Engine handle to the API procedure. Though not necessarily a software bug, returning a zero value under this condition is more consistent.
11)
INVITE Contact header may not be correct.
Under some situations, an initial INVITE Contact header might contain the SIP domain name and port of the configured SIP proxy instead of the IP address and port of the VOIP Media Engine. Now all INVITE Contact headers will use the IP address and port the VOIP Media Engine is configured to use. An exception to this rule is when enabling WAN IP address detection or manually specifying the WAN IP address. In this case, the IP address of the Contact header will be the WAN IP address instead of the possible "private" IP address.
12)
Fixed BYE request URI user name.
Under some conditions and when being called by other 3rd party SP user agents or IP SIP phones, the user name in the BYE request URI header may not be filled out properly. This can cause problems with some proxy servers.
13)
Fixed a bug in the SetCallInstanceData() API procedure.
Fixed a bug in the SetCallInstanceData() API procedure. Call instance data now gets placed in an outgoing INVITE message using a double quoted string parameter. Some UAs require this for proper SIP message parsing.
14)
Changes to rport and branch parameters and transmitted Via headers.
By default, rport and branch parameters are enabled for all transmitted SIP messages. This differs from the previous revision where user code would have to call the UseRportAndBranchInViaHeader() API procedure to obtain this functionality.
15)
Missing user name when transmitting final ACK for ReINVITE.
When interoperating with multi-lined SIP devices from other manufacturers, under certain conditions, the user name would not be placed in the request URI of the final transmitted ACK for re-invite (call hold) requests. Depending on the multi-lined SIP device, the final ACK may or may not be ignored by the device thus causing unnecessary "200 OK" retransmissions.
16)
Badly formed Via headers in received INVITE may cause illegal provisional
responses.
When receiving INVITE requests from other SIP devices, badly formed Via headers in received INVITEs may cause illegal "100 Trying" and "180 Ringing" SIP messages to be transmitted. This issues has been fixed.
17)
Erroneous "486 Busy Here" sent during call un-hold operations.
While interoperating with another manufacturer's SIP phone, a response of "486 Busy Here" could be sent if the other device used a certain combination of IP addresses in the From, To, Contact and Via headers. The VOIP Media Engine detected the received re-INVITE (for removing a hold state) as invalid.
18)
Call hold-unhold NAT port translation issue.
If two or more VOIP Media Engine applications are running on different machines using the same SIP port (5060) and they are accessing their SIP proxy through the same outermost NAT router, an error can occur that relates to call hold and unhold operations. The NAT router will translate the shared SIP ports for transmitted SIP messages. Depending on the network deployment model used, this can lead to the VOIP Media Engine using the wrong SIP port values in re-INVITE requests regardless of Record-Route or proxy settings. This issue has been fixed.
19)
Updating SIP SDP and values for the "o=" header.
During inter-operational testing using the LanScape VOIP Media Engine and other SIP manufactured devices such as desktop IP phones, it was noticed that Polycom Soundpoint series phones required different handling of SIP SDP "o=" header information in order to achieve proper call hold and call un-hold operation. A change has been implemented such that RFC3261 compliancy is met while at the same time taking into account the characteristics of Polycom devices.
The change specifically addresses how SIP SDP <session id> and <version> values for the "o=" header are manipulated.
20)
Asterisk interoperability issue regarding INVITE authentications.
An issue has been resolved that was associated with how Asterisk open source PBX processes INVITE requests and authentications.
Though not officially a bug, the media engine has been updated to take into consideration Asterisks behavior regarding authenticating INVITE requests and Call-Id headers. Now when calling through Asterisks with authentication enabled, authentication retries will function as expected and calls will not fail due to receiving "SIP/2.0 407 Proxy Authentication Required" SIP responses.
Api Changes:
Note: The API changes mentioned here may have an impact on your source code. We
try to limit making any changes in the VOIP Media Engine API but in cases of
refinement, adherence to namespaces or improvements in the product, we
sometimes have to make changes that modestly impact your project. We regret any
inconvenience this may cause you.
IMPORTANT NOTE:
The VOIP Media Engine's START_SIP_TELEPHONY_PARAMS structure has been updated. Make sure your application software initializes all structure members before instantiating the media engine. Not initializing all start-up structure members properly may lead to undesirable behavior.
1)
Added new startup members to structure START_SIP_TELEPHONY_PARAMS.
The following new structure members have been added to the START_SIP_TELEPHONY_PARAMS structure:
MaxSipMesageLength
Allows application software to specify the maximum SIP message length.
EnableEventLogServer
pEventLogServer
EventLogServerPort:
These 3 values allow application software to enable real time "man readable" event logging to a remote event log server when the VOIP Media Engine™ is started. After the media engine is started, enabling and disabling the man readable event logging can be performed by calling the SetEventLogServer() API procedure. Sending VOIP Media Engine™ events to a log server (EventLogD.exe) is useful for debugging and learning the event behavior of the media engine.
EnablePhoneLineRecording
PhoneLineRecordBuffering
Allows application software to enable call recording and specify the phone line record buffering depth.
The media engine must be instantiated with call recording capability enabled before call recording API procedures can be called.
CallConferenceEnabled
Allows application software to enable call conferencing support. If your application does not require conference calling, this new setting should be disabled in order to speed up boot time and greatly reduce internal memory consumption due to the internal cross line mixer support required for conferencing phone calls.
Important Note: Make sure to update your application source code to initialize these new structure members before starting this new version of the VOIP Media Engine™. Not initializing startup parameters in the START_SIP_TELEPHONY_PARAMS structure may lead to undesirable behavior.
2)
Added parameter RegisterPhoneLines in EnableSipRegisterServer() API procedure.
Added parameter RegisterPhoneLines in EnableSipRegisterServer() API procedure to support the registration of individual phone lines.
3)
Added parameter SIPHANDLE hStateMachine to CreateFormatRateConverter() API
procedure.
Added parameter SIPHANDLE hStateMachine to the CreateFormatRateConverter() API procedure so the API procedure is consistent with other VOIP Media Engine API procedures.
4)
Added new structure members to structure SIP_INCOMING_CALL_INFO.
Added the following two new structure members to structure SIP_INCOMING_CALL_INFO:
pFromHeader: This new structure member allows application software to access the SIP "From:" header that is contained in received INVITE messages.
pToHeader: This new structure member allows application software to access the SIP "To:" header that is contained in received INVITE messages.
5)
Added return parameter DWORD *pNotifyResponseCode to API proc
SendEventNotification().
This allows the application to access the returned SIP response code as the
result of transmitting a NOTIFY message to another device.
6)
UseRportAndBranchInViaHeader removed.
The UseRportAndBranchInViaHeader() API procedure has been removed. It has been replaced by the following 2 new API procedures:
UseRportInViaHeader() and UseBranchInViaHeader()
v5.11.0.0
New Features and
Capabilities:
1)
Low bit rate codec support (iLBC and G729/G729A).
Added support for the following low bit rate codecs:
20Ms iLBC
30Ms iLBC
20Ms G729
20Ms G729A
Low bit rate codec can be used during any initiated an received phone call in addition to using the new codec capability with the transmit and receive IVR interfaces and the audio output interface.
2)
G711a (aLaw) codec support.
Added g711a (aLaw) codec support.
aLaw codec support can be used during any initiated a received phone call in addition to using the new codec with the transmit and receive IVR interfaces and the audio output interface.
3)
Using multiple codecs when initiating and receiving calls.
In support of new codecs and low bit rate codecs: The SetAudioMediaFormats() API has been added to allow applications to specify which multiple codecs will be used when initiating and receiving phone calls.
When initiating phone calls, all codecs that are enabled by this API procedure will be offered to the far end of the call when sending SIP INVITE requests.
When receiving calls, only those codecs that are enabled
will be used to determine the codec of the call. The codec enable order
determines what codec will be used when multiple codecs are offered in a
received INVITE.
4)
New API procedure SendSipKeepAlive().
Transmission of "NULL" SIP packets for the purpose of NAT session keep alive:
Added API proc SendSipKeepAlive() so that NULL UDP packets can be sent to SIP proxies or other servers at the user specified interval. A NULL SIP packet contains a single <cr> <lf> pair.
This is useful for SIP clients behind NAT that have to keep open the NAT router or firewall session. This approach is a "less costly" alternative to sending REGISTER messages to the server every 10 to 30 seconds.
5)
New API procedure SetDefaultReceiveIlbcFrameMode().
Added API proc SetDefaultReceiveIlbcFrameMode() for setting the default iLBC codec mode if the incoming call's SIP does not contain the SDP mode parameter. defaults to 30Ms.
6)
New API procedure SetNumByeRetransmissions().
This new API procedure will allow application software the ability to define the number of BYE SIP messages that will subsequently be sent to a call endpoint after the media engine detects that a "200 OK" response was not received for the fist BYE request transmitted.
Application software should only use this API procedure if you are having problems terminating VOIP calls to other SIP devices, servers or gateways.
7)
New API procedure SetCallTerminateTimeout().
This new API procedure allows applications to program the call terminate timeout value used internally by the media engine.
8)
New API procedure SetReinviteTimeout().
This new API procedure allows applications to program the reINVITE timeout value used internally by the media engine for "call hold" and "call off hold" operations.
9)
New API procedure SetInboundInviteAckTimeout().
This new API procedure allows applications to program the timeout value used internally by the media engine to detect inbound call INVITE final ACK timeouts.
10)
New API procedure ConnectIncomingCallWithoutInviteAck().
This new API procedure allows the VOIP Media Engine to still connect an incoming call even though the far end of the call (the initiating side) did not send a final INVITE ACK. Most helpful when the far end SIP device is not behaving properly (sending the ACK somewhere else) or does not send an ACK at all.
11)
New API procedure AbortIncomingCall().
Added the AbortIncomingCall() API procedure so application software can easily ignore an incoming call.
12)
Real-time SIP message logging to SIP log server.
Added new API proc SetSipLogServer() for real-time SIP message logging to a SIP log server.
As of Version 5.11 of the LanScape VOIP Media Engine™, the development package ships with a SIP log server daemon that you can use to view SIP messages in real time.
13)
LanScape's SipLogD SIP log server.
Included LanScape's SipLogD SIP log server daemon in the product distribution. With the LanScape SipLogd server daemon, you can view transmitted and received SIP messages in real time on the same machine as your VOIP application or elsewhere in your network.
Useful for debugging your VOIP application or deployment.
14)
Simplified the OpenRxIvrChannel() API procedure.
Simplified the OpenRxIvrChannel() API proc to use well known audio formats defined in the AUDIO_BANDWIDTH enumeration.
15)
Simplified the SetTxIvrDataType API procedure.
Simplified the SetTxIvrDataType() API proc to use well known audio formats defined in the AUDIO_BANDWIDTH enumeration.
16)
Simplified the GetTxIvrSampleBlockSize API procedure.
Simplified the GetTxIvrSampleBlockSize() API proc to use well known audio formats defined in the AUDIO_BANDWIDTH enumeration.
17)
Simplified the SetAudioOutDataType API procedure.
Simplified the SetAudioOutDataType() API proc to use well known audio formats defined in the AUDIO_BANDWIDTH enumeration.
18)
Simplified the GetAudioOutSampleBlockSize API procedure.
Added an extra return parameter to the GetAudioOutSampleBlockSize() API proc so the procedure will also return the number of bytes per audio out buffer in addition to the number of samples in the audio out buffer.
19)
Specifying outbound-only phone lines.
The SetOutgoingLineOnly() API procedure was added to allow application to specify that a phone line should only be used for outbound calling.
If a phone line is configured for outbound-only calling, no incoming phone call will be assigned to the phone line.
20)
Spoofing the from header in SIP INVITE messages.
Added the API procedure SetFromHeaderUserName() that can be used to alter the normal user name that is placed in an outgoing INVITE's "From:" header.
This capability is useful if an application wants to call
various voice mail boxes of a voicemail server. In this case, the
"from" SIP header can be temporarily modified a single time for the
outgoing call so that the voicemail server can determine what voicemail box to
access.
21)
SUBSCRIBE_REQUEST structure - 2 new members added.
The SUBSCRIBE_REQUEST structure has a new member added (pContactUserName). This new field is made available so that server applications (such as voicemail servers) can properly identify an incoming call using usernames from the incoming SIP "From:" and "Contact:" headers.
A primary use of this added information is by voicemail servers that receive voice mailbox event subscriptions from multiple UAs for the same voice mail boxes.
The SUBSCRIBE_REQUEST structure has a second new member added (pEventParameter). This new field is made available so that server applications can detect a user definable subscription parameter value string.
22)
SUBSCRIBE_RESULTS structure - 1 new member added.
The SUBSCRIBE_RESULTS structure has a new member added (pEventParameter). This new field is made available so that applications can identify generic event parameter strings when they receive the results of performing SUBSCRIBE/NOTIFY event subscriptions.
New parameter added to the StartEventSubscription() API procedure.
Added a new parameter to the StartEventSubscription() API procedure. The new parameter allows an application to specify an optional parameter field in the SUBSCRIBE message's "Event:" header. Used for subscription requests.
This capability is useful for voicemail servers where you subscribe to voice mail box events and need to specify additional generic parameters like the name of a voicemail account. There are also many other general uses for generic event parameters strings.
23)
SIP_INCOMING_CALL_INFO structure - 1 new member added.
The SIP_INCOMING_CALL_INFO structure has a new member added (pSrcContactUserName). This new member allows an application to detect the far end user name as specified by the received SIP message "Contact:" header.
24)
Improved network error handling and detection of unplugged network cables.
Added the following network error return values and/or events in an effort to detect unplugged network cables and other fatal network errors:
SipRegisterNetworkError (API return value and global Event Notification)
Returned when any network transmission error is detected. Applies to registrations.
SipCallNetworkError (API return value and phone line Event Notification)
Returned when any network transmission error is detected. Applies to outgoing and incoming calls.
SipSubscribeNetworkError (Immediate Event Notification
Returned when any network transmission error is detected. Applies to event subscriptions.
SipNotifyNetworkError (API return value)
Returned when any network transmission error is detected when sending event notifications.
25)
Added new provisional response event notifications.
The following new event notifications will be sent to application software when a far end SIP endpoint starts to respond to the applications out bound call:
SipReceivedProvisionalResponse
SipReceived100Trying
SipReceived180Ringing
SipReceived181CallBeingForwarded
SipReceived182Queued
SipReceived183SessionProgress
SipReceivedUnsupportedProvisionalResponse
26)
New outgoing call event - SipInviteAckSendFailed.
Added the new outgoing call event SipInviteAckSendFailed. This event can be sent to an application when it makes an outbound call and a low memory situation exists or a fatal network error has occurred.
27)
New registration event and return value - SipRegisterErrorBadCredentials.
Added the SipRegisterErrorBadCredentials API return value and event value. Thais value indicates that the Media Engine was challenged by the registrar for authentication information. This is the result of the Media Engine sending bad authentication data for the challenge response. The user should verify that their user name and password are correctly configured for the required domain.
28)
New incoming call event - SipIncomingCallInitialized.
Added the SipIncomingCallInitialized event. If an application handles this immediate event, it will be able to terminate an incoming call before the Media Engine gets a chance to start processing the call. The application also has the ability to specify the SIP return code that will be returned to the far end of the incoming call.
29)
Added structure INCOMING_CALL_INITIALIZED_DATA in support of the SipIncomingCallInitialized event.
Added the INCOMING_CALL_INITIALIZED_DATA that is passed to the application that processes the SipIncomingCallInitialized immediate event. The new structure contains information for the incoming call and allows the application to terminate the call if required.
30)
Added generic Format and rate conversion support to the API.
To ease application software's burden associated with performing format and rate conversion from one audio data type to another, the VOIP Media Engine now supports a "Format and Rate" converter block API.
With these new API procedure, application sift ware can easily convert from one audio data type to another using a single API call.
Once an application initializes one or more instances of an internal "format rate converter block", converting to and from G729/G729A, iLBC, PCM, aLaw and uLaw can be achieved by calling a single API procedure.
The following new format and rate converter API procedures have been added:
CreateFormatRateConverter() - Create a format rate converter block.
DestroyFormatRateConverter() - Destroy a format rate converter block.
FormatRateGetSampleBlockSize() - Obtain sample block sizes.
FormatRateConvert() - Perform format and rate conversion using a single API call.
31)
Increased the performance of SIP protocol parsing and generation.
Internal SIP stack has been modified to reduce the processing time associated with parsing received SIP protocol messages. SIP message generation processing time has also been reduced.
32)
Improved SIP protocol parser error handling and recovery.
Updated and improved SIP protocol parsing error recovery.
33)
Improved internal invalid character detection.
Improved internal invalid character detection in phone names and registration names. Any detected invalid characters will be replaced with underscores.
34)
Improved noise discrimination capabilities.
Improved noise discrimination capabilities. Noise discrimination/gating now incorporates volume ramping to soften audio edge characteristics. The result is better audio quality when enabling noise discrimination.
35)
Quicker call termination.
Shortened the amount of time it takes to terminate a call when the call is in the process of initially connecting. We do his by making the incoming phone ring sound as short as possible. Playing this sound caused undue call setup delays because it had 2.2 seconds of silence at the end of the sample resource data.
36)
Improved how call hold and conferencing operations sequence each other.
Improved how call conferencing and call hold operations
interact with each other when the VOIP Media Engine is used in "phone
line" mode. Also removed transitions to the call hold state when terminating
calls on line that are part of a conference session. This reduces the wait time
to process active call lines and removed unnecessary SIP message transactions
with far end call endpoints.
Bug Fixes:
1)
Possible slow responding call hold operations using reINVITEs.
Under some execution conditions, call hold and unhold operations would appear to take longer than what would be expected if the VOIP Media Engine is busy processing in/out bound calls and call hold and unhold operations are being performed on other phone lines.
The processing of the call hold/unhold via the API is now processed at the same priority as incoming call activity which evens out processing requests. This yields smother call flow operations between the API requests and received phone call processing.
2)
Improved internal error handling for embedded SDP in received SIP messages.
Improved the error handling capability of SDP parsing in received SIP messages.
3)
Updated internal sample rate conversion.
Internal sample rate conversion functionality has been streamlined to a higher degree in order to minimize the processing impact of rate conversion for multi lined media engines.
4)
Improper SIP Route header.
Under certain conditions, a improper SIP Route header would be added to a transmitted ACK messages when using SIP proxy support and when an outgoing call is terminated before the session is completely set up. Note: No Route header is placed in the final ACK when an outbound call is terminated prematurely.
5)
Possible Memory Leak upon multi-line startup
For multi-line VOIP Media Engines consisting of 16 lines or greater, a memory leak could occur if the media engine is started and many other UAs (user agents) are trying to call the media engine during the startup phase.
If the final API call made by the application during startup is the SipTelephonyEnable() API proc, then the memory leak will not occur. However, if other configuration based API procedures are called after the SipTelephonyEnable() procedure is called and multiple inbound calls are being processed, a memory leak may occur.
6)
REGISTER Access violation.
Under certain conditions, an access violation could occur when registering with a SIP registrar server
and the registrar server challenges the registration but does not respond with a valid WWW or Proxy authenticate header.
7)
Port translation detection error.
Sometimes the engine would falsely detect port translation and send the app the SipPortTranslationError event even though no SIP port translation may have been present.
8)
Phone name using spaces causes one way audio.
If the phone name/extension specified in the media
engine's startup parameters contained spaces, it was possible that half duplex
audio would result when calling media engine to media engine. Now if a
phone/extension name contains any space characters, all space characters will
be replaces internally with underscore characters. The spaces in the phone name
caused a far end VOIP Media Engine to improperly parse the SIP session data
under some circumstances.
9)
Missing SIP port making calls fail.
If a port number was not specified in the URI parameter of the TransferLineUri() and MakeCallUri() APIs, the call would sometimes not succeed when calling using a proxy.
10)
Missing SUBSCRIBE SIP headers based on Media Engine configuration.
Depending on how the VOIP media engine is being used and configured, SUBSCRIBE SIP messages may not contain the proper SIP domain name in some of the SIP protocol headers. If you do not use the StartEventSubscription API procedure, this bug fix will not affect you.
11)
Call destinations not correct when interlacing calls to MakeCall() and
MakeCallUri().
A call destination is sometimes incorrect if phone calls are made by interlacing MakeCall() and MakeCallUri() API procedures and if a previous call made by using MakeCallUri() was cancelled before the far end answered.
Explanation: If an application made a phone call using the MakeCallUri() and then made another call using the MakeCall() API procedure, the MakeCall() would call the last URI destination that was specified in the previous call to MakeCallUri() instead of calling the strict destination specified.
12)
Missing URI port value may make call transfers fail.
If transferring an inter-domain call using a sip URI from
one sip device to another, and if the transfer target URI did not contain the
port of the domain proxy, the call transfer would fail. Application software no
longer has to specify the proxy sip port when transferring a call using a URI.
This issue only affected software that used the TransferLineUri API procedure.
13)
Spurious RTP NAT keep alive traffic.
Depending on when an application called the special API function EnableKeepAliveTransmissions(), RTP session keep alive traffic might not be generated or be generated spuriously. Now the API procedure can be called anytime after the VOIP Media Engine has been instantiated and will produce the desired keep alive RTP media traffic. This bug fix will only affect WAN and Internet VOIP deployments.
14)
Access violation when calling GetIncomingCallInfo() during an outgoing call.
Under certain situations, an access violation could occur
if application software calls the GetIncomingCallInfo() API procedure for a
phone line while the phone line is handling an outgoing phone call. Normally
application software should not call the GetIncomingCallInfo() API procedure
when the phone line is processing an incoming call. This situation however has
been resolved.
15)
Small "pops" or noise in telephony audio streams under certain
loading conditions.
Under some host loading conditions, the media engine internal audio mixers could insert a 20Ms block of NULL audio data into an audio data stream. This sometimes could be heard as a single small pop in telephony audio.
16)
Call transfer sometimes failed when inter-domain calling between proxies.
Inter-domain call transfers (call transfers between different domains) would fail if sip proxies are being used for each domain and the sip proxies are assigned different SIP ports.
Description: If a proxy is being used by 2 separate domains and a call is transferred from one domain to another domain and the two proxies use different SIP ports, the call transfer would fail. Note: This anomaly did not affect VOIP deployments where SIP proxies of different domains used the same SIP port.
17)
Call answer/"auto hold" delay issue.
When using the VOIP Media Engine in "phone line mode", a protocol timeout can occur when answering a new incoming phone call on a new phone line while having an active phone call on another phone line. The media engine will place all other phone calls into the hold state when you answer a new call. A condition existed that would cause longer than required phone line answer delays when the other phone lines were automatically placed into the hold state. This issue has been resolved.
Api Changes:
Note: The API changes mentioned here may have an impact on your source code. We
try to limit making any changes in the VOIP Media Engine API but in cases of
refinement, adherence to namespaces or improvements in the product, we
sometimes have to make changes that modestly impact your project. We regret any
inconvenience this may cause you.
1)
AUDIO_BANDWIDTH structure changes.
Changed the structure AUDIO_BANDWIDTH in the following ways:
Changed the name AUDIO_BW_MULAW_8K to AUDIO_BW_ULAW_8K
Added new types:
AUDIO_BW_ALAW_8K,
AUDIO_BW_G729,
AUDIO_BW_G729A,
AUDIO_BW_ILBC_20MS,
AUDIO_BW_ILBC_30MS
Deleted the AUDIO_BW_PCM_44K type.
2)
MEDIA_FORMAT_AUDIO structure changes.
Changed the structure MEDIA_FORMAT_AUDIO in the following ways:
Changed all the names of the structure elements to conform to the "Media_Format_" namespace.
Added new media types for aLaw, G729/A and iLBC codecs.
Changed Media_Format_Pcm11025 to Media_Format_Pcm11050
Delete the Media_Format_Pcm44100 type.
Changed the name of the Media_Format_NoAudioFormat to Media_Format_Undefined.
v5.10.x.x
Initial version 5.xx product
offering. Replaces legacy version 2.xx through version 4.xx LanScape SoftPhone
engines.
V2.x.x.x through v4.x.x.x:
Legacy LanScape soft phone engines. Discontinued.
Notes Regarding
Engineering Releases:
1. If you have received this version of the VOIP Media Engine in the form of an
“Engineering Release”, this information may be of use to you. If you have
received a normal product image, the information describes below does not apply
to you.
The goal of an “Engineering Release” is to test new product functionality or
offer pre-released bug fixes that are added to the product. LanScape offers
engineering releases to customers in an effort to place needed functionality in
the hands of customers as soon as possible. By accepting this engineering
release, customer understands that LanScape will make every attempt to offer
pre-released product functionality into the final officially released product.
Customer also understands that by accepting this engineering release, LanScape
is not bound in any way to offer unpaid free support for this software release
or offer free software upgrades based on this software release.
To use this engineering release, un-archive the product image to your host
machine. The files in this release should be used to directly replace the files
of the same name in your normal product installation. This engineering release
can be used with both trial and normal product install images.
Engineering releases of LanScape software have gone through a modest set of QA
and testing procedures. This software is released to you for evaluation and
testing. If you experience issues or bugs in this engineering product release,
simply report your concerns via the LanScape support forum located at:
http://www.lanscapecorp.com/forum/default.asp.
IMPORTANT:
Before you use this updated product image, you should rebuild your VOIP
applications using the new native code static import library and
SipTelephonyApi.h header file. If you are developing a managed code VOIP
application, re-build your application against the LMEVoipManaged.dll managed
code assembly. You may receive one or more build errors with this updated
image. If so, the changes to your source code will most times be minimal and
self explanatory based on the compiler errors you receive. Changes to the
standard product VOIP Media Engine sample source code may also be necessary
when using this engineering release and when rebuilding source code samples.