Hello,

We have 96xx phones configured for G.722 as primary codec and G.711MU as secondary codec.

When trying to conference a DMCC softphone into a call that is established between two of these 96xx phones, the codec always switches to G.711MU..

Is there any chance to get a G.722 encoded audio stream via DMCC?

Regards,
Claus Suffel

when you register you DMCC station that you conference in, what codecs are you announcing support for in the media parameters? Note that if you announce support for G722 Communication Manager will send you a G722 stream and expect that you can decode it.


<localMediaInfo>
<rtpAddress>
<address>135.9.62.75</address>
<port>4727</port>
</rtpAddress>
<rtcpAddress>
<address>135.9.62.75</address>
<port>4728</port>
</rtcpAddress>
<codecs>g711U</codecs>
<codecs>g722</codecs>
<packetSize>20</packetSize>
<encryptionList>none</encryptionList>
</localMediaInfo>

How can I set codec to G722 with DMCC Java API?

Only the following options are available:
G711A
G711U
G729
G729A
G723

I am checking with development on the gap between AE Services codec set and that supported by Communication Manager... It seems reasonable to expect the full set of G. codecs to be supported by AE Services but there are a few omissions as I compare that to the documentation & XSDs.


G.711A G.711MU G.722-64K G.722.1-24K G.722.1-32K
G.723-5.3K G.723-6.3K G.726A-32K G.729 G.729A
G.729B G.729AB

And after reading this perhaps some of of the SIREN codecs should be included as well.

http://en.wikipedia.org/wiki/Siren_(codec)

The response is that the list needs updated. I entered a clear case MR to track the request. It is targeted for 7.0 wi01015946

In the mean time specifying codecs other than the ones the SDK supports is only possible with the XML version of the interface.

Hi John,

Are you really sure that the current XML API already supports G722 codec?

I've checked the XML API for rel. 6.1. There is also no G722 option mentioned within documentation and XSDs. The programmer's guide contains just a list of available codecs similar to Java API.

Same thing with 'AES Admin and Maintenance Guide'. This manual also demands to set codec to G711A/MU or G729 for DMCC devices (see p. 36).

If G722 will be supported by Java API in the near future, please can you give us an estimation when this feature will be available.

Regards,
Claus

Indeed, when testing with the DMCC Dashboard I get invalidParameterValue responses, G.722 will not work even with an XML implementation.

Assuming it is accepted as a MR for the 7.0 release, at best that puts a change late fall 2012 or perhaps late spring 2013, but since the MR has not even been seen by the MR review board, that is pure speculation on my part based on normal release timing.

OK, thanks for your investigations.

Please keep us informed in the case you'll get more information about the scheduling of your change request.

Regards,
Claus

Just one more question:

For a plain softphone instance which is only registered via the application, it is clear that this softphone does not support G722.

But what happens in the case of a softphone that is registered against a (softphone enabled) hardware 96xx station.

The 96xx itself is able to run in G722 mode, but the softphone instance is not.
Does the hardware phone automatically fall back to another codec as soon the softphone is registered against the same extension?

The codec choice for a call is basically a union of sets, along with some prioritization. However for what you are driving at, there is a twist (see below).

In the simplest case
A supports codecs 1, 2, 3, 4
B supports codes 2, 4, 6

When A and B are in a call the only codec in common is 2 so that is what is used (it is higher priority than 4)

Communication Manager adds its own codec list to the mix through the ip-network-region -> ip-codec-set mapping.. so A and B may register into different network regions and thus have different ip-codec sets for inter region calls, and another ip-codec set for intra region calls. View this codec-set as another member to the union who has to be satisfied. Thus to extend the example

A supports codecs 1, 2, 3, 4 registers in region 90
B supports codes 2, 4, 6 registers in region 91

inter-region-ip-codec-set for 90-91 supports codecs 2, 3, 5

Again the codec supported by A, B and the inter-region-ip-codec-set is 2.

So now lets add what I suspect is your case
A is a 96xx hardphone,
A' is a DMCC softphone instance that does not support G.722
B does support G.722
codec 1 is a G.722 codec.
codec 2 is G.711Mu


A supports codecs 1, 2, 3, 4 registers in region 90
A' supports codecs 2, 3, 4 registers in region 90 (for simplicity, I could have A' register in a third network region but for simplicity I won't).
B supports codes 1, 2, 4, 6 registers in region 91

inter-region-ip-codec-set supports codecs 1, 2, 3, 5

If ONLY A and B are involved in the call then we would use codec 1.
If A, A' and B are involved in the call then we would use codec 2.

now the twist... a 3 party call requires media "summing" i.e. a conferencing resource. Communication manager hardware does not support conferencing of G.722 audio. Thus even if A' supported codec 1, the call would still revert to codec 2 whenever there were three parties involved.

Hi John,

Thanks for this great explanation.

But now I have to come back to my initial question:

I've asked, if it is possible to add a DMCC softphone to a call between two 96xx phones and to get a G722 audio stream out of it.
This scenario would definitely be a 3 party call.

Considering your statement, that CM hardware cannot conference G722 audio at all, it would not be really helpful, if DMCC API will support G722 in the future.

Regards,
Claus

I believe would be helpful if you were building a IP softphone (agent console) and handling point to point calls, or some form of IVR like behavior, or a dial out announcement behavior. Until there is Communication Manager hardware built that can handle the conference case, any three party scenario will revert to a codec that Communication Manager supports conferencing for (e.g. G.711, G.729, G.723).

Hi John

Do you have any news regarding the schedule of implementing G722 support into the next version of Java DMCC API?

Are there plans for building CM hardware that will support G722 conferencing?

Regards
Claus

I am told that with the 96x1 SIP phones there is a mechanism to configure things such that they dynamically switch to the Avaya Aura Conferencing 7 system when a three or greater party call is created, and this allows for wideband audio conferencing.

For native conferencing on Communication Manager limitations in the gateway currently preclude native wideband conferencing on those platforms.

Relative to G.722 support in AE Services I had entered clearcase MR wi01015946 back in May 2012.. it is currently targeted to AE Services 7.0