[Freeswitch-dev] mod_isac questions

[Steve Richardson]

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 at 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 at comrex2.onsip.com] has been answered
2012-04-27 01:27:39.490028 [DEBUG] sofia.c:5602 Channel 
sofia/external-4/Steve at comrex2.onsip.com entering state [completed][200]
2012-04-27 01:27:39.490028 [DEBUG] mod_conference.c:6111 Raw Codec 
Activation Success L16 at 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 at 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 at 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 at 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 at comrex.com <mailto:steve at comrex.com>
http://www.comrex.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20120426/9e14061c/attachment-0001.html