hp.telephony.media
Interface Player

All Superinterfaces:

CoderConstants, FaxConstants, PlayerConstants, Resource, ResourceConstants, SMSPlayerConstants, TTSConstants

All Known Implementing Classes:

AsyncMediaGroup

public interface Player

extends Resource, PlayerConstants, TTSConstants, SMSPlayerConstants, FaxConstants

Defines methods for playing a media stream into a Terminal. A Player extracts data from a media stream container (MSC), transcodes the data as necessary for the telephony network, and streams the resultant data out to that network.

The play() method accepts one or an array of Strings which identify the media streams to be played. Each media stream may be encoded by any coder type supported by this player resource.

The Player interface is also used to send synthesize requests to a TTS server (see below). In that case it does not support an array of Strings but only a String defining the URI to the TTS server.

The Player interface is also used to send SMS-TL messages. In that case it does not support an array of Strings but only a String defining the SMS-TL mode.

This resource will be able to send faxes (see below).

In addition to the play method, a number of RTC actions affect the operation of the player. These can be invoked through a Run Time Control RTC,

A Player may optionally support additional processing features. These features define parameters and runtime controls that affect operation of an ongoing play operation. The presence of these features is indicated by a true value for the following attributes:

Attribute:	indicates the ability to:
a_Pause	pause and resume in place
a_Speed	change the playback speed
a_Volume	increase and decrease the volume
a_Jump	jump forward and backward while playing

Each of these is explained in the Attributes section.

Coding types for data objects are defined in CoderConstants.

The MSC to be played is identified by its String name. The String name is an identifier that may be interpreted as a path or URL (URI) for the MSC.

Note: The format of the String that identifies an MSC is not defined by this release of specification. The vendor-specific implementation of the MediaService (for example, the vendor of the server or resource) shall define the supported String formats.

For example, an implementation may support URLs or File pathnames; in which case an application could use Strings of the form: "file://node/dir/name" or "dir/dir/name"

If the MSC identifier is a file pathname, it is interpreted in the logical filename-space of the server. Applications and their prompts need to be installed with correct pathnames.

Operation:

Player States:

The following is the state diagram for a player.

The Player has three states: Idle, Active, and Paused.

In the Idle state, the Player is performing no coding or transmit operations. The state transitions to the Active or Paused state when the play() method starts. The state of the Player after play() starts is determined by the Boolean value of the parameter p_StartPaused. The state transitions to Active if p_StartPaused is false. The state transitions to Paused if p_StartPaused is true.

In the Paused state, the player is not transmitting the media stream. It retains its place in the MSC being played, and resumes from the same place when the RTC action, rtca_Resume is received.

In the Active state, the Player is busy, actively transmitting the media stream from a MSC to its output media stream (the Terminal). The Player continues in this state until it reaches the end of the MSC list or until RTC actions tell it to pause or stop. In the Active state, the Player may receive RTC commands to change the speed or volume of the play operation. It may also receive commands to jump forward or backward in the MSC.

If a new play() is attempted while the Player is Active, the result is determined by the value of the p_IfBusy parameter. The alternative values for p_IfBusy are:

• v_Queue: This play is queued (default). It is played when the previous plays have completed.
• v_Stop: The current play and any queued plays are stopped, (with event qualifier q_Stop). This play begins immediately.
• v_Fail: This play fails, with (getError()==Error.e_Busy)

Player Attributes

Attribute a_Pause

If the attribute Player.a_Pause is true, then the Player supports the pause and resume operations.

• rtca_Pause sets the player state to Paused and onPlayerEvent() is invoked if ev_Pause is enabled in p_EnabledEvents.
• rtca_Resume sets the player state to Active, continues to play the stream from its current offset, and onPlayerEvent() is invoked if ev_Resume is enabled in p_EnabledEvents.

If the value of attribute a_Pause is false, then then the effects of the RTC actions, parameters, and methods discussed in this section are not defined.

Attribute a_Speed

A MSC has a "normal" speed at which its data is to be played. The RTC actions discussed in this section may change the speed up or down. The playback speed achieved by these actions is called the adjusted speed.

The units by which speed may be adjusted are percentage change from the normal speed. If the attribute Player.a_Speed is true, then the player supports the following features:

• The rtca_SpeedUp and rtca_SpeedDown RTC actions cause the playback speed to be adjusted one quantum up or down respectively.
• If the current playback speed is not at the default normal value, the rtca_ToggleSpeed RTC action changes the speed to the normal value. If the current playback speed is at the default normal value, the rtca_ToggleSpeed RTC action changes the speed to the last adjusted value.
• If a RTC action would result in setting the speed beyond the maximum or minimum allowed values, the command/action is ignored. If a RTC action would result in no change to the playback speed (e.g., changing speed to normal when the speed is already normal, toggling the speed when no adjustment had been made to the speed), the action is ignored.
• The event ev_Speed is delivered to PlayerListener.onSpeedChange. This event may be enabled or disabled by the p_EnabledEvents parameter.

If the value of attribute a_Speed is false, then then the effects of the RTC actions, parameters, and methods discussed in this section are not defined.

Attribute a_Volume

A MSC has a "normal" default volume at which its data is to be played. The RTC actions discussed in this section may change the volume up or down. The playback volume achieved by these actions is called the adjusted volume. Local regulatory restrictions may limit the levels to which volume may be adjusted. It is the responsibility for the client application to ensure that it does not adjust the volume so as to exceed those levels. The units by which volume may be adjusted are measured in dB from the normal volume.

If the value of attribute a_Volume is true then the Player supports the following features:

• The rtca_VolumeUp and rtca_VolumeDown RTC actions cause the playback volume to be adjusted one quantum up or down respectively. The size of the quantum is governed by the parameter p_VolumeChange, measured in dB from the normal volume.
• If the current playback volume is not at the default normal value, the rtca_ToggleVolume RTC action changes the volume to the normal value. If the current playback volume is at the default normal value, the rtca_ToggleVolume RTC action changes the volume to the last adjusted value.
• The event ev_Volume is delivered to PlayerListener.onVolumeChange. This event may be enabled or disabled by the p_EnabledEvents parameter.

If an RTC action would result in no change to the playback volume (e.g., changing volume to normal when the volume is already normal, toggling the volume when no adjustment had been made to the volume), then the command/action is ignored. Likewise, when the volume is already at its maximum or minimum value, RTC actions that attempt to set it beyond the limit are ignored.

If the value of attribute a_Volume is false, then the effects of the RTC actions, parameters, and methods discussed in this section are not defined.

Attribute a_Jump

A Player has a "current location" within a MSC when in the Active or Paused state. The location and the granularity of changing that location depends on the coder type; being determined by the sample rate and whether the coder is "stateful". For simple Pulse Code Modulation (PCM) coders the location is reported and changed in millisecond units (rounded to the sample rate).

If a player resource supports a_Jump attribute, then the following features are supported:

• The rtca_JumpForward and rtca_JumpBackward RTC actions change the current location one quantum forward or backward respectively. The quantum is set by the parameter p_JumpTime.
• The rtca_JumpStartMSC and rtca_JumpEndMSC RTC actions change the current location to the start or the end of the current MSC.
• The rtca_JumpForwardMSCs and rtca_JumpBackwardMSCs RTC actions change the current location to the beginning of the MSC that is n MSCs ahead or behind the current MSC in the play list respectively. The value n is set by the parameter p_JumpMSCIncrement.
• The rtca_JumpStartMSCList and rtca_JumpEndMSCList RTC actions change the current location to the beginning or end respectively of the list of MSCs being played.

A Jump method or RTC action that goes past the end of the current MSC continues into the next MSC in the MSC list if the coders for the MSCs support the same time increment. If the next MSC in sequence has a different coder type, the current location is set to the beginning of that MSC.

If the value of attribute a_Jump is false, then the effects of the RTC actions, parameters, and methods discussed in this section are not defined.

TTS Operations

Player interface for sending TTS synthesize requests

For TTS server access, the interface remains the same, except that:

• The streamID parameter is the Audio Service in form rtsp://audioservice
• The text to be synthesized is passed in the optArgs hashtable, referenced by the parameter TTSConstants.p_TTSData
• offset parameter is ignored
• As mentioned above, the multi-MSC play method (with an array of streamID) is not supported.

Other MRCP specific optional parameters can be passed in the optArgs table. The list of parameters is given by TTSConstants. The onPlayerEvent() callback is used to deliver the same PlayerEvents as for a normal play, but the events are extended to implement TTSPlayerEvent.

Code snippet about how using a TTS Audio Service

 // AudioService URL
 String ttsAudioService="rtsp://ttsAudioService";
 // the parameter dictionary
 Hashtable optArgs = new Hashtable();
 
 // The message to be translated into audio
 String message="Hello World";
 // the message is set into an optArg dictionary
 optArgs.put(p_TTSData, message);
 // start playing
 try {
 // send the play request to the audio service
 mediagroup.play(ttsAudioService,myRtcs,optArgs);
 } catch (Exception e) {
 // exception processing etc.
 }
 

Other considerations

The default type of text is "text/plain". MRCP servers must also process text corresponding to the W3C Speech Synthesis Markup Language. To identify text as being in this form, the parameter TTSConstants.p_TextType should be set in the optArgs to "application/synthesis+ssml".

SSML tagged text can contain tags to change the voice type, prosody etc. These can also be set by using various parameters passed in optArgs such as p_Speaker, p_SpeakerGender, p_SpeakerCatagory etc. Refer to TTSConstants for full details.

It is also possible to set arbitary MRCP SPEAK message parameters using the optArgs. Any entry that has a String type key, and a String type value, is placed "as-is" into the MRCP header in the form key : value. This should only be used by advanced users after referring to the MRCP RFC.

SMS-TL Operations

Player interface for sending a p_DLL_MessageType and a p_TL_Data in case of v_DLL_INFO_REQ DLL message type value

For SMS-TL message sending, the interface remains the same, except that:

• The streamID parameter is the SMS mode in form sms-tl://
• The DLL message type to be send is passed in the optArgs hashtable, referenced by the parameter SMSPlayerConstants.p_DLL_MessageType The SMS-TL message to be send is passed in the optArgs hashtable, referenced by the parameter SMSPlayerConstants.p_TL_Data in case of v_DLL_INFO_REQ DLL message type value
• offset parameter is ignored
• As mentioned above, the multi-MSC play method (with an array of streamID) is not supported.

Other SMS specific optional parameters can be passed in the optArgs table SMSPlayerConstants.p_DLL_T10Timeout, SMSPlayerConstants.p_DLL_T11Timeout, SMSPlayerConstants.p_DLL_T12Timeout, SMSPlayerConstants.p_DLL_RequiredTestErrorCause . The p_DLL_TxTimeout allows to set the Tx Timeout used by the DLL protocol The p_DLL_RequiredTestErrorCause allows to generate a DLL error for test purpose The list of parameters is given by SMSPlayerConstants. The result of the SMS play() operation is delivered in an SMSPlayerEvent to the onPlayerEvent callback of the ResourceEventListener.

If the SMS play was successful, then an eventId equal to SMSRecorderConstants.ev_SMS is received.

Refer to SMSPlayerConstants for full details on these symbols and their meaning.

Code snippet about how using a SMS

 // SMS Service 
 String smsService="sms-tl://";
 // the parameter dictionary
 Hashtable optArgs = new Hashtable();
 
 // The message to be send
 byte[] message= { 'E', 'n', 'c', 'o', 'd', 'e', 'd', ' ',  'T', 'L', ' ', 'M', 'S', 'G' };
 // the message is set into an optArg dictionary
 optArgs.put(SMSPlayerConstants.p_DLL_MessageType, SMSPlayerConstants.v_DLL_INFO_REQ);
 optArgs.put(SMSPlayerConstants.p_TL_Data, message);
 // start playing
 try {
 // send the play request to the SMS service
 mediagroup.play(smsService,myRtcs,optArgs);
 } catch (Exception e) {
 // exception processing etc.
 }
 

Fax Operations

The target AsyncMediaGroup should be brought by loopCP with ConfigSpec.basicFaxConfig.

Player interface for initiating the V25 fax protocol

The interface remains the same, except that:

• The streamID parameter is the 20 printable characters fax ID, prefixed by fax://.
• the offset parameter is ignored
• The multi-MSC play method (with an array of streamID) is NOT supported.
• Mandatory parameters are passed in the params hashtable to setup the local fax characteritics.

Code snippet for an outgoing call sending fax pages as one TIFF file

 params.put(FaxConstants.p_PagesEncoding         ,FaxConstants.v_TIFF);
 params.put(FaxConstants.p_TiffPath              ,"/tmp/test/fax/coarse_a4_2.tif");
 params.put(FaxConstants.p_DeTiffPrefix          ,"/tmp/test/fax/"+uniqueSessionId+"_");
 params.put(FaxConstants.p_DeTiffSuffix          ,".fax");
 
 params.put(FaxConstants.p_VerticalResolution    ,FaxConstants.v_Fine_196lpi);
 params.put(FaxConstants.p_PageWidth             ,FaxConstants.v_2048pixelsIn255mm);
 params.put(FaxConstants.p_PageLength            ,FaxConstants.v_B4_364mm);
 params.put(FaxConstants.p_FaxTimeOut            ,new Integer(900000));//15 minutes
 params.put(FaxConstants.p_MaxPageToReceive      ,new Integer(5));
 
 params.put(FaxConstants.p_EnablePolling         ,Boolean.FALSE);
 params.put(FaxConstants.p_CapabilityToReceive   ,Boolean.FALSE);
 
 //   we have made an outgoing call, willing to send fax :
 params.put(FaxConstants.p_Role                  ,FaxConstants.v_Caller);
 
 //   start sending whatever pages in the Tiff-F container :
 String servicePrefixPlusFaxID = FaxConstants.v_Prefix+"hp OC MP 2.4C2 fax";
 mediagroup.play(servicePrefixPlusFaxID, -1, myRtcs, params);
 

The result of the Fax play() operation is delivered in a FaxEvent to the onPlayerEvent() or onRecorderEvent() callback of the ResourceEventListener.

Note : the regular direct send is delivered with 2.4C2 EA.

Code snippet for an incoming call being polled

 params.put(FaxConstants.p_PagesEncoding         ,FaxConstants.v_TIFF);
 params.put(FaxConstants.p_TiffPath              ,"/tmp/test/fax/coarse_a4_2.tif");
 params.put(FaxConstants.p_DeTiffPrefix          ,"/tmp/test/fax/"+uniqueSessionId+"_");
 params.put(FaxConstants.p_DeTiffSuffix          ,".fax");
 params.put(FaxConstants.p_VerticalResolution    ,FaxConstants.v_Normal_98lpi);
 params.put(FaxConstants.p_PageWidth             ,FaxConstants.v_1728pixelsIn215mm);
 params.put(FaxConstants.p_PageLength            ,FaxConstants.v_A4_297mm);
 params.put(FaxConstants.p_PageResolution        ,FaxConstants.v_Page_Resolution_0200_0100);
 params.put(FaxConstants.p_FileType              ,FaxConstants.v_T4_1D_ModifiedHuffman);
 params.put(FaxConstants.p_FaxTimeOut            ,new Integer(900000));//15 minutes
 params.put(FaxConstants.p_MaxPageToReceive      ,new Integer(5));
 //   parameters above are like for the regular direct send.

 //   we receive an incoming call, and are sending :
 params.put(FaxConstants.p_Role                  ,FaxConstants.v_Answerer);// as for the regular direct receive
 params.put(FaxConstants.p_CapabilityToReceive   ,Boolean.FALSE);// as for the regular direct send

 //   we do not have any page to receive, we just send :
 params.put(FaxConstants.p_EnablePolling         ,Boolean.TRUE);// unlike the regular direct send
 

The play() method will be called the same way.

Note : the reversed polling mode is delivered within late 2.4C2.

Since:

OCMP 2.0

Field Summary

Fields inherited from interface hp.telephony.media.ResourceConstants

e_Disconnected, e_OK, FOREVER, q_Duration, q_RTC, q_Standard, q_Stop, rtcc_Disconnected, rtcc_TriggerRTC, v_Forever

Fields inherited from interface hp.telephony.media.PlayerConstants

a_AutomaticGainControl, a_Coder, a_Jump, a_Pause, a_Speed, a_Volume, ev_Pause, ev_Play, ev_Resume, ev_Speed, ev_Volume, p_CoderTypes, p_DisplayName, p_EnabledEvents, p_FileFormat, p_IfBusy, p_JumpMSCIncrement, p_JumpTime, p_MaxDuration, p_SpeedChange, p_StartPaused, p_VolumeChange, q_Duration, q_EndOfData, rtca_JumpBackward, rtca_JumpBackwardMSCs, rtca_JumpEndMSC, rtca_JumpEndMSCList, rtca_JumpForward, rtca_JumpForwardMSCs, rtca_JumpStartMSC, rtca_JumpStartMSCList, rtca_NormalSpeed, rtca_NormalVolume, rtca_Pause, rtca_Resume, rtca_SpeedDown, rtca_SpeedUp, rtca_Stop, rtca_StopAll, rtca_ToggleSpeed, rtca_ToggleVolume, rtca_VolumeDown, rtca_VolumeUp, rtcc_PlayComplete, rtcc_PlayStarted, v_Fail, v_GSMFormat, v_Queue, v_RawFormat, v_Stop, v_WavFormat

Fields inherited from interface hp.telephony.media.CoderConstants

p_AMR_SDPelement, p_channels, p_crc, p_G723_annexa, p_G723_bitrate, p_G729_annexb, p_interleaving, p_maxptime, p_modechangeneighbor, p_modechangeperiod, p_modeset, p_octetalign, p_ptime, p_robustsorting, v_ADPCM_16kG726, v_ADPCM_24k, v_ADPCM_32k, v_ADPCM_32kG726, v_ADPCM_32kOKI, v_ADPCM_44k, v_ALawPCM_48k, v_ALawPCM_64k, v_ALawPCM_88k, v_AMR, v_AMR_WB, v_G723_1b, v_G723_53, v_G723_63, v_G723_no_vad, v_G723_yes, v_G729_no_vad, v_G729_yes, v_G729a, v_GSM, v_Linear16Bit_64k, v_Linear8Bit_48k, v_Linear8Bit_64k, v_Linear8Bit_88k, v_MuLawPCM_48k, v_MuLawPCM_64k, v_MuLawPCM_88k

Fields inherited from interface hp.telephony.media.TTSConstants

a_ASSessionAllocation, a_ASSessionCreation, a_AudioService, e_ResourceUnavailable, e_ServerError, e_ServerFailed, ev_Tag, p_AudioData, p_Language, p_ServerURL, p_Speaker, p_SpeakerCategory, p_SpeakerGender, p_SpeakerPitch, p_SpeakerRate, p_SpeakerVolume, p_StartMarkerMS, p_StartMarkerToken, p_StopMarkerMS, p_StopMarkerToken, p_TextType, p_TTSData, q_StartMarkerNotFound, q_StopMarkerReached, rtca_ReleaseCurrentASSession, v_ASStartTime, v_Call, v_FromFirstOperation, v_OnDemand, v_Operation

Fields inherited from interface hp.telephony.media.SMSPlayerConstants

e_TL_InternalError, ev_SMS, p_DLL_MessageType, p_DLL_RequiredTestErrorCause, p_DLL_RequiredTestMessageType, p_DLL_T10Timeout, p_DLL_T11Timeout, p_DLL_T12Timeout, p_TL_Data, p_TL_RequiredTestData, v_DLL_DATA_ACK, v_DLL_DATA_NACK, v_DLL_DATA_REQ, v_DLL_EST_IND, v_DLL_EST_REQ, v_DLL_ExtensionMechanismNotSupported, v_DLL_INFO_CFM, v_DLL_INFO_REJ, v_DLL_INFO_REQ, v_DLL_REL_REQ, v_DLL_UnknownMessageType, v_DLL_UnspecifiedCause, v_DLL_WrongChecksum, v_DLL_WrongMessageLength, v_NO_DLL_MANAGER, v_NO_MEMORY, v_TL_NOT_DLL_EST_REQ, v_TL_NOT_DLL_INFO_CFM, v_TL_NOT_DLL_INFO_REQ

Fields inherited from interface hp.telephony.media.FaxConstants

ev_Fax, p_AnswerCED, p_BitRate, p_ByteAlignedEol, p_CapabilityToReceive, p_DataCompressionFormat, p_DeTiffPrefix, p_DeTiffSuffix, p_EnablePolling, p_ErrorCorrection, p_FaxTimeOut, p_FileType, p_InternetRoutingSupport, p_InternetSelectivePollingSupport, p_KeepDataOrder, p_LegalSupport, p_LetterSupport, p_MaxLineToReceive, p_MaxPageToReceive, p_MaxSpeed, p_MinSpeed, p_PageLength, p_PageResolution, p_PagesEncoding, p_PagesPaths, p_PageWidth, p_PasswordSupport, p_PixelArrays, p_Role, p_ScanTimePerLine, p_SelectivePollingSupport, p_SelectivePollingWithSubaddressingSupport, p_StorePath, p_SubaddressingSupport, p_Suffix, p_T37Support, p_T38Support, p_TiffPath, p_VerticalResolution, q_Count, q_Document, q_Page, rtca_AssumeCNG, rtca_Cancel, v_12000bps, v_1216pixelsIn151mm, v_14400bps, v_1728pixelsIn215mm, v_2048pixelsIn255mm, v_2400bps, v_2432pixelsIn303mm, v_33600bps, v_4800bps, v_7200bps, v_864pixelsIn107mm, v_9600bps, v_A4_297mm, v_AfterCNG, v_Answerer, v_B4_364mm, v_BandWarrays, v_BMP, v_Caller, v_DisableECM, v_EnableECM_256bytes, v_EnableECM_64bytes, v_Encoding_MS_BMP, v_Error_Conversion_To_G3, v_Error_Decomp_Init, v_Error_Disconnect, v_Error_File_Open, v_Error_Illegal_Width, v_Error_Page_Format, v_FilesList, v_Fine_196lpi, v_GIF, v_JPEG, v_Normal_98lpi, v_NotSet, v_Page_File_Name_Size, v_PageResolution_0100_0100, v_PageResolution_0200_0100, v_PageResolution_0200_0200, v_PageResolution_0200_0400, v_PageResolution_0300_0300, v_PageResolution_0300_0600, v_PageResolution_0400_0400, v_PageResolution_0400_0800, v_PageResolution_0600_0600, v_PageResolution_0600_1200, v_PageResolution_1200_1200, v_PNG, v_Prefix, v_Rcv_Qual_Bad, v_Rcv_Qual_Medium, v_Rcv_Qual_OK, v_RightNow, v_ST0000, v_ST0505, v_ST1005, v_ST1010, v_ST2010, v_ST2020, v_ST4020, v_ST4040, v_T4_1D_ModifiedHuffman, v_T4_2D_ModifiedRead, v_T4_Buff_Size, v_T6_ModifiedModifiedRead, v_TIFF, v_UnlimitedLength, v_UponRTC

Method Summary

void	play(String[] streamIDs, int offset, RTC[] rtc, Dictionary optargs) Play a sequence of MSCs (Media Stream Containers) identified by the streamIDs.
void	play(String streamIDs, int offset, RTC[] rtc, Dictionary optargs) Play a single MSC (Media Stream Container) named by streamID.

Method Detail

play

public void play(String[] streamIDs,
                 int offset,
                 RTC[] rtc,
                 Dictionary optargs)
          throws MediaResourceException,
                 AccessControlException

Play a sequence of MSCs (Media Stream Containers) identified by the streamIDs. This sequence of MSCs is called the "MSC list".

This method cannot be used for sending TTS synthesize requests. Sequences of MSCs are not supported for this type of requests.

This method cannot either be used for SMS, nor for fax.

This method returns when the MSC list is started. This method is non-blocking. The result is passed in a PlayerEvent event through the ResourceEventListener Interface. The condition that caused the play to stop is included in the completion event. RTC actions can alter the course of the play without the intervention of the application. Optional arguments can alter the characteristics of the play.

Exceptions are thrown if pre- or post- conditions are not satisfied

Pre-conditions:

1. a Player resource is configured
2. all MSCs are playable

Post-conditions:

1. As indicated by getQualifier():
   • q_EndOfData: All MSCs named in this MSC list have been played.
   • q_Stop: play was stopped by the stop() method or because (p_IfBusy=v_Stop)
   • q_RTC: play was stopped by Player.rtca_Stop

Parameters:

streamIDs - a String[] naming the MSC list to be played.

offset - number of milliseconds into the MSC list at which play is to start, offset may span several items in streamIDs.

rtc - Array of RTC that effect this play.

optargs - a Dictionary of optional arguments.

Returns:

a PlayerEvent when the operation is complete (or queued).

Throws:

MediaResourceException - if requested operation fails.

AccessControlException - if access to resource is refused

See Also:

ResourceEventListener.onPlayerEvent(PlayerEvent)

play

public void play(String streamIDs,
                 int offset,
                 RTC[] rtc,
                 Dictionary optargs)
          throws MediaResourceException,
                 AccessControlException

Play a single MSC (Media Stream Container) named by streamID. Equivalent to play() with a String[] of length one, containing the given streamID.

This method should be used for sending TTS synthesize, Fax and SMS requests. This method is non-blocking. The result is passed in a PlayerEvent event through the ResourceEventListener Interface

Parameters:

streamIDs - a String naming the MSC to be played or the TTS Audio Service URI in form "rtsp://audioservice"
or the SMS mode in form "sms-tl://"
or the Fax ID prefixed by "fax://".

offset - int number milliseconds into the MSC (ignored for TTS synthesize, fax or SMS requests) at which play is to start. Not supported for file with encoding format: v_ADPCM_32k, v_ADPCM_32kOKI, v_ADPCM_16kG726 and v_ADPCM_32kG726.

rtc - Array of RTC that effect this play.

optargs - a Dictionary of optional arguments.

Throws:

MediaResourceException - if requested operation fails

AccessControlException - if access to resource is refused

See Also:

ResourceEventListener.onPlayerEvent(PlayerEvent)