Hello!

I have following problem:

My current session is connected to a third-party Application by using an own Freeswitch application "DoingReadAndWriteFrames". The communication between Freeswitch Session and third-party application is done by reading and writing frames in a while loop.

At start of Freeswitch session the codec is PCMA, which I need for voice recognition.

Customer reports, that the codec of the Freeswitch session changes from PCMA to PCMU.

If an external call comes in, I’m playing an audio ringing tone into the Freeswitch session.

I have realize, that the codec is changed back from u-law to a-law.

I have recorded the voice stream and I have heard the codec change.

I have never reproduced the codec change of an active Freeswitch session on my test system.

Some customer reports, that the system is running fine (no codec change) for half a year.

My own bug fix is to manually translate PCMU data to PCMA, if session codec is switched to PCMU.

But I cannot test my bug fix, because I can't force the changing of codec within a running session.

Maybe the "codec change" was a bug from Freeswitch version at October 2010.

Maybe the hardware SPA3102 sends a sip re-invite message on special cases.

I have no idea.

I have some questions about codec negotiation and sip re-invite:

A) On what reasons can a re-invite message triggered and why is the session codec changed?

B) What must be happen, that a codec is changing, after a codec negotiation was done, on a running Freeswitch session?

C) Why is there a codec change back to a-law, when I’m playing an own ringing tone?

D) Is there a solution for forcing Freeswitch always use PCMA?

My configuration of Freeswitch in “vars.xml” to force codec PCMA:

<X-PRE-PROCESS cmd="set" data="global_codec_prefs=PCMA"/>

<X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=PCMA"/>

Greetings

Achim Stamm