I just finished an application that records calls using DMCC api, it just registers a dependent recording device and receives the RTP stream (client media mode). The application works fine using codec g711U, I wanted to use g723 instead, but i can not find the string for g723 to put in the codecs list (using 'g723' didn't work). g723 is included in the ip codec set. Can I use g723 to receive media streams? am i missing something? Any other suggestion for a smaller recording file size? g729 seems to work, but i can not find an application to play g729 recordings.
Thanks.

Carlos,

You don't say what version of AE Services you are using. However, any version of R4.2 or later should work with G.723. The string to use for the codec is "g723". but note that G.723 codec can only be used for "client-media-mode". Since you are using "client-media-mode", I'm not sure what the problem is. Have you checked that the "ip-codec-set" on Communication Manager, that is being used for this extension, supports the G.723 codec?

AES version is: r4-2-3-33-0. There's only 1 codec set defined and it includes g723, however, there are 2 choices for g723 : G.723-5.3K and G.723-6.3K, the first one is used. When specifing g723 in the application, everything seems to work ok, except that the app does not receive a single RTP packet. Just changing the codec from g723 to g711U (or even g729) and the RTP packets are sent to the app. That makes me think that the code is fine, I'm not sure if additional configuration is required in CM.

The fact that everything seems to work except that you don't get any RTP suggests that maybe there is a codec mismatch between you recorder app.and the other entities in the call. Check that all call participants can use G.723

Communication Manager should provide the transcoding from whatever the other parties are using to G.723 for the recorder assuming there are medpro resources available and g.723 is properly configured in Communication Manager. Given you 'see it' in the provisioning UI, I would think that it is 'allowed' (licensed if there is one).

As you setup the call and add the recorder at the SAT run a 'list trace station xxx' and look for denial codes, where xxx is the recorder's extension. If you get a denial code please provide it, or act on what it is telling you is not as it should be. If there is no denial code, let us know that and I will try to think of another cause for what you are experiencing.

Well, after a long while working with G711, I decided to revisit this subject in an effort to reduce the size of the recording. The application works fine with G711 but I'm still not able to get g723 RTP. This is the trace when G711 is requested:

11:25:20 G729A ss:off ps:20
rgn:1 [192.168.210.200]:3814
rgn:1 [172.23.111.203]:46048
11:25:20 G711MU ss:off ps:20
rgn:5 [192.168.210.31]:600
rgn:1 [172.23.111.203]:46060
11:25:20 xoip options: fax:Relay modem:PT tty:US uid:0x3400dd
xoip ip: [172.23.111.203]:46060

192.168.210.31 is the monitoring application.
192.168.210.200 is the ip phone extension I'm recording


this is the trace when requesting g723 audio:

11:23:23 denial event 2300: Ept capabilities mismatch D1=0x5 D2=0x5
11:23:23 denial event 2300: Ept capabilities mismatch D1=0x5 D2=0x5
11:23:23 G729A ss:off ps:20
rgn:1 [192.168.210.200]:3814
rgn:1 [172.23.111.204]:56160
11:23:28 idle station 19511 cid 0x1c19

the description of the event 2300 is:

2300 Ept capabilities mismatch Endpoint connects to TDM bus or is hairpinned capabilities
mismatch.

Which, is not much help. I'm not sure that I'm licensed to use G723, how can I check that?

Any other suggestions will be appreciated.

Thanks

Here are some things to check, but I cannot make it work myself, so I have asked for development what is going on.

1) the DMCC application must signal the codec(s) it supports during the device registration phase of initialization (registerTerminal) From the programmer's guide it indicates this is signaled by sending G723. I am assuming you have made this change.. but mention it because it is important.

2) In Communication Manager what codecs are allowed are controlled on a per IP network region basis for bandwidth management, and other resource consumption reasons. Thus the ip-network-region that the recorder registers into must support G.723. To check that, access the Communication Manager SAT and when your recorder is registered run these commands:
command: list registered-ip-stations ext XXXX
where XXXX is your recorder device's extension. In the second column bottom number is the network region that extension registered into (it is a function of what CLAN/procr was used, or what the ip-network-map specified). Next run
command: disp ip-network-region X
where X is the network region you located before.
Find the Codec Set value, it is on page 1 in the upper right.
Next run
command: change ip-codec-set X
where X is the Codec Set value from the ip-network-region form.
Verify that g.723-5.3K or G.723-6.3K is provisioned. re-test. If it still fails switch go g.723-6.3K

I've followed your indications, but I'm not getting G723 stream yet. I'm using DMCC dashboard for these tests, I just select G723 codec and DMCC dashboard will do the proper request, I can see that in the outgoing XML. Then in the client media tab I can see whether I'm getting RTP stream or not. When choosing G711U or G729, I get to see RTP packets coming, but not for G723. This is how my IP codec set looks for network region 1 (the one where the ext registers)


IP Codec Set

Codec Set: 1

Audio Silence Frames Packet
Codec Suppression Per Pkt Size(ms)
1: G.729A n 2 20
2: G.711A n 2 20
3: G.711MU n 2 20
4: G.723-6.3K n 1 30

I have also tried with G.723-5.3K with the same results. I one thing I forgot to mention is that when I first ran the trace on the extension,I got 4 denial events, then I changed the parameter "IP-IP Audio Connections?" to "y" (it was set to "n") and when I ran the trace again, I got 2 denials.

G.729 works as well, but I haven't been able to find a media player (free, paid, sw, commercial...) for G729, does it exist?

Thanks

I believe G.729 is licensed. There are companies that claim to have a free G.729 codec, but I have never pursued it. You results and mine are the same. I am waiting on development to clarify what the mechanism is to make it work.

G.723 is not supported on all media processor circuit packs. In particular my problem getting it to work is because I was using a TN2602AP circuit pack.

I searched the Communication Manager product documentation for G.723 and ran a cross a statement in the Capacities Table for the TN2602AP that indicated "It does not support G.723". From the rest of that table, it appears the other media processor platforms do support G.723. Please check and verify this is/is not the issue in your case.

I did a 'list registered-ip-station ext 32004'
I found the network region used by the station I am testing with.
I did a 'list ip-interface medpro'
I looked at the media processors assigned to that network region.

Geez, there are 7 medpro boards in our PBX and they all happen to be TN2602AP. Any workaround for this? If I get a newer Medpro or DSP, can I manage to get the audio sent from that board?

You would need a TN2302 (lower capacity) circuit pack or a gateway (e.g. G430, G450, G700, etc) that has embedded media processing capability.

From the way I read the table, there is no firmware change that would enable support for G.723 on the TN2602AP.

We already had plans on getting a G450 with 2 additional DSP resources, but until that this subject will remain in stand by.
Thanks a lot for your valuable help

A G450 woudl be a good choice for support of G.723; From the Communication Manager Capacities Table document:

G450 can host up to 4 MP [media processing] circuit packs; two types are supported; the MP80 and the
MP20
o MP80 supports 80 VoIP channels G.711,G.723,G.729A/AB and G.726A with and without encryption.
o MP20 supports 20 VoIP channels G.711,G.723,G.729A/AB and G.726A with and without encryption

test to check time stamping delta.. please ignore.