This question was asked a few times lately but I don't have a real AES and we did not worked out a connection to the Avaya Remote Lab yet. So is it correct that for CM 5.0 we don't need to do a single step conference in order to accuire RTP. I can register a DMCC extension in Depended mode with client media mode and CM will send the RTP to my application as well as to the original device(which also can be a softphone or IP hardphone or digital station on the CM)
Can someone confirm this
Thanks a lot
Ilana

Yes, that's exactly right. Additionally, in our 4.2 AES release (soon to be released) if your application is administered in the AES Security Database (SDB) as having unrestricted access, you can register your DMCC extension without a PIN. This makes it much easier for your application to register in dependent mode with a real user extension.

Joel

Is the CM5.0 AES 4.1 the only combination that allows this kind of feaure will it work for cm4.0 with AES 4.1 ?
Thanks
Ilana

CM 5.0 is required for this feature.

On other update, the registration without PIN feature requires CM 5.1. Just to summarize:

Media forking via registration using Dependent mode:
AES 4.1 or later; CM 5.0 or later

Registration without PIN:
AES 4.2 or later; CM 5.1 or later

Is there already a scheduled release date for CM 5.1?

Ragards,
Claus

Hi Claus, the scheduled release date for 5.1 is the end of June, 2008.

Joel

This RTP forking feature is very promising, but what is the situation with the server media mode recording. We have a pretty complete prototype, which works fine with this approach. We utilize the VoiceUnit class to record the desired calls by DMCC on AES 4.1.
Do you have any comment or consern with the server media mode approach for call recording?
What are the capacity limitations on the AES?
THX,
Gabor

Hi Gabor,

There are several reasons that most call recording partners choose client media mode over server media mode:

Capacity: If you look at page 24 of the following document you'll find our AES 4.1 capacities. You'll note that a single AES server can support a maximum of 1000 registrations / simultaneous recordings in client media mode, but only 120 simultaneous recordings in server media mode.
http://support.avaya.com/elmodocs2/AES/4.1/02_300360_i4.pdf

Access to recording files: If recordings are stored on the AES, you're faced with the issue of how to retrieve / manage those recordings. Most partners find it much easier to capture the RTP on their own hardware.

Joel

Hello Joel,
Many THX for the quick reply.
I agree, that client media mode offers greater flexibility, but below CM 5.0 you have to use single-step conference or service observing to achieve this. Regarding the mentioned disadvantages:
- capacity: for more than 120 calls, we can add more AES servers as a workaround
- file access: we simple download the files right after the end of the recording from the AES to our server, where all the file and access management are done
Overall, I think that client mode with CM 5.x is the ultimate approach.
What do you think?
THX,
Gabor

I think that you may have some misunderstanding of how server media mode works. The exact same mechanisms must be used to involve a server media mode station in a call as would be used for a client media mode station. The only difference is the RTP IP address given to CM at the point that DMCC registers the station.

Joel

I do not know whether it is a missunderstanding or not (can be :-)), but it works for us without involving a 3rd station to a call, by simply registering the recorded phoneset by DMCC. As far as we understood, for service observing or single-step conference approach you have to use application controlled softphones.
Are we missing something?
Gabor

The only way to get the functionality you describe is to use the aforementioned RTP forking feature, which can be used in both server meida mode and client media mode. You must be using this feature in server media mode.

Joel

We are using the VoiceUnit/RecordMessage method on the monitored device, but we do not know how this method is implemented, what is behind the scenes.
Gabor

We're still somehow talking past each other here.

The fact of whether Voice Unit Services is used has absolutely no bearing on which media mode is used. VUS is essentially the control interface that an application can use to control an established RTP stream to AES when working in server media mode.

It's the RegisterTerminal message that tells AES which media mode to use. My guess is that you're sending a Register Terminal message to AES 4.1 that asks for a Dependency Mode of "Dependent" with server media mode. This is how you're requesting the RTP forking. If instead you asked for Dependency Mode of "Dependent" and client media mode, you'd be taking advantage of the RTP forking feature in client media mode.

Just to compare and contrast, if an application instead wanted to use a standalone DMCC station that would be conferenced in to a call using SSC or SO, it would ask for a Dependency mode of "Main" with client or server media mode.

Does that make sense?

Joel