Hello all, I've been trying to work with the reasonably new mod_isac over the last couple of days, with no luck. We are launching a smartphone app as a companion to our hardware product (which is based on FreeSWITCH). The app is basically a really simplified SIP client that supports G.722 and iSAC for wideband audio calls. I can make G.722 calls into FreeSWITCH and they work fine. Unfortunately, I haven't been as lucky with iSAC. I have a few different failure scenarios, all of which tested with the latest git this morning -- FreeSWITCH Version 1.1.beta1 (git-7a147e4 2012-04-25 17-14-55 -0500): Scenario 1: With my FS codec-prefs set to "ISAC,G722,...", the remote end offers up "a=rtpmap:96 ISAC/16000" in the INVITE. When I answer the call by bridging it to a conference, FS unilaterally decides that "a=rtpmap:96 ISAC/32000" is more to its liking in the SDP. Though FS thinks it has answered the call, the remote end stays ringing (playing ringback), and no connection ever actually seems to happen. I have to individually hang up each end of the call; if I just hang up one end, the call remains in some half-active state. Scenario 2: If I change the codec-prefs to "ISAC@16000h", things go a little bit better in terms of the codec negotiation, but the call immediately drops after this happens: 2012-04-27 01:27:39.490028 [NOTICE] mod_conference.c:6228 Channel [sofia/external-4/Steve@comrex2.onsip.com] has been answered 2012-04-27 01:27:39.490028 [DEBUG] sofia.c:5602 Channel sofia/external-4/Steve@comrex2.onsip.com entering state [completed][200] 2012-04-27 01:27:39.490028 [DEBUG] mod_conference.c:6111 Raw Codec Activation Success L16@16000hz 1 channel 60ms 2012-04-27 01:27:39.490028 [WARNING] switch_core_codec.c:691 Codec L16 Exists but not at the desired implementation. 48000hz 60ms 2012-04-27 01:27:39.490028 [DEBUG] mod_conference.c:6159 Raw Codec Activation Failed L16@48000hz 1 channel 60ms 2012-04-27 01:27:39.490028 [WARNING] switch_core_codec.c:789 Codec is not initialized! The conference is set up at 48kHz/20ms, if that matters any. It has a mod_portaudio participant in it, also running at 48kHz/20ms. Scenario 3: If I change the codec-prefs to "ISAC@16000h@60i", things behave exactly as scenario #2, leading me to think that's what the default value is when the "@##i" suffix is left off. Scenario 4: If I change the codec-prefs to "ISAC@16000h@30i", things work marginally 'better,' but still aren't working properly. In that case, the call is established, but I can get no audio in the FS->remote direction, and the audio in the other direction is badly mangled. It sounds like periodic short frames of working audio, interleaved with silence frames, and the delay seems to spool out more and more over a very short period of time. "Choppy" is the layman description I would use. So, a few questions: - Given that iSAC is an adaptive codec that can place one or two frames (30ms or 60ms) of audio data into an RTP payload, how does this play with FS seeming to assume a fixed frame size? - What was used to test mod_isac when it was written? There are not a lot of soft phones out there that I've found that support the iSAC codec, so it's hard to come up with a known-good reference for testing. - Any other advice for things to test or try out? thanks, Steve -- *Stephen Richardson Senior Software Engineer* Comrex Corporation 19 Pine Rd Devens MA 01434 USA v 978.784.1764 f 978.784.1717 steve@comrex.com <mailto:steve@comrex.com> http://www.comrex.com/