en-US.concept-chapter-MS_Best_Practices.xml Maven / Gradle / Ivy

Go to download
<?xml version='1.0'?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
<!ENTITY % BOOK_ENTITIES SYSTEM "Media_Server_User_Guide.ent">
%BOOK_ENTITIES;
]><!-- chapter id nickname: msbp -->
<chapter id="msbp-MS-Best_Practices">
	<title>MMS: Best Practices</title>
	<section>
		<title>&MMS_LONG_NAME; Best Practices</title>
		<para>Note: these best practices apply to &MMS_LONG_NAME; version &MS_VERSION; and later</para>
		<section>
			<title>DTMF Detection Mode: RFC2833 versus Inband versus Auto</title>
			<para>The &MMS_LONG_NAME; will block the resource depending on the DTMF detection mode configured in <emphasis>jboss-service.xml</emphasis> at start-up time. Inband is highly resource-intensive and must perform many more calculations in order to detect DTMF when compared to RFC2833. So if your application already knows that User Agents (UAs) support RFC2833, it is always better to configure DTMF mode as <emphasis>RFC2833</emphasis> rather than as <emphasis>Inband</emphasis> or <emphasis>Auto</emphasis>. Also, please note that <emphasis>Auto</emphasis> is even more resource-intensive because it does not know beforehand whether DTMF would be Inband or <emphasis>RFC2833</emphasis>, and hence both detection methods must be started. The default detection mode is <emphasis>RFC2833</emphasis>. </para>
			<para>All of the Conference, Packet Relay and IVR endpoints have DTMF detection enabled; the mode can be configured using <emphasis>jboss-service.xml</emphasis>. We advise retaining the same mode for all three, but this is not a necessity.</para>
		</section>
		<section>
			<title>Transcoding Is CPU-Intensive</title>
			<para>Digital Signal Processing (DSP) is very costly and should be avoided as much as possible. By default, Announcement endpoints and IVR endpoints do not have DSP enabled. What this means is that your application needs to know beforehand which codecs are supported by your UA; you can then ask Announcement or IVR to play an audio file which has been pre-encoded in one of these formats. The onus of deciding which pre-encoded file to play lies with the application.  For example, if I am writing a simple announcement application that would only play announcements to the end user, and I know that my end users have one of either the <emphasis>PCMU</emphasis> or <emphasis>GSM</emphasis> codecs, then I would make sure to have pre-encoded audio files such as <emphasis>helloworld-pcmu.wav</emphasis> and <emphasis>helloworld-gsm.gsm</emphasis>. Then, when the UA attempts to connect to the Media Server, my application knows which codecs the UA supports and can ask the &MMS_SHORT_NAME; to play the respective file.</para>
			<para>This strategy will work fine because, most of the time in the telecommunications world, applications have a known set of supported codecs, .However if this is not true, or if you are writing a simple demo application and need or want all codecs to be supported, you can put a Packet Relay endpoint in front of Announcement or IVR endpoint. This way, the Packet Relay will do all necessary digital signal processing, and your application need not bother about which audio file to play. The audio file in this case will be encoded in <emphasis>Linear</emphasis> format, and all UAs, irrespective of whether they support <emphasis>PCMU</emphasis>, <emphasis>PCMA</emphasis>, <emphasis>Speex</emphasis>, <emphasis>G729</emphasis> or <emphasis>GSM</emphasis> codecs, would be able to hear the announcement.</para>
		</section>
		
		 
		
	</section>
</chapter>