Please login or register to access secure site features.

Note: By continuing to use DevConnect Program Services you agree to our latest Registered Member Terms.

Sign in using DevConnect ID

Forgot password?

Trouble logging in?

Submit a ticket for Registration Support.

I have an SSO ID

sign in

Don't have a DevConnect or SSO ID ?

Create a DevConnect account or join the program.

register now
Forum Index » DMCC APIs » RegisterTerminal packet size ignored   XML
Author Message

Joined: 26/03/2013 12:28:40
Messages: 8

If I use a packet size greater than 20 in a RegisterTerminal request for Client Mode it gets ignored. When I get a MediaStartEvent I always get a packet size of 20, even though I asked for 40 or more.

Is there a way to get a larger packet size? I'm using G711U as the codec, but I'm not sure if that has anything to do with it. Using Avaya 7, maybe this is supported on newer versions?

Joined: 20/06/2005 14:06:52
Messages: 815
Location: Thornton, CO

you are not 'asking for' you are stating 'you support,' and by implication you are saying you support smaller packet sizes. DTMF, codecs and packet sizes are a negotiation between two media devices involved in the call. In most two party calls you are ultimately negotiating with the far end device.

On the Communication Manager System Access Terminal (SAT) through the 'change ip-codec-set X' form you can configure what CM supports - in the case of G.711 by changing the frames per packet setting. Note you are making this change for all users of this ip-codec-set.
One can control which devices are impacted through the use of ip-network-region form and what network-region devices are registered into via the ip-network-map form thus providing a means to limit this change to just devices registering through a specific AE Services server.

This may only partially solve your problem.. it depends on if you are building a call recorder -in which calls are > 3 party and thus anchored on CM, or something that does point to point calls, and thus you are probably ultimately communicating directly with the far end device and constrained with its capacities and how it was implemented relative to far end capabilities (back to you are negotiating - and only stating what you can accept).

I hope that helps.
Go to: