<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello all,<br>
<br>
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.<br>
<br>
<br>
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):<br>
<br>
<br>
Scenario 1:<br>
<br>
With my FS codec-prefs set to "ISAC,G722,...", the remote end offers
up "a=rtpmap:96 ISAC/16000" in the INVITE.<br>
<br>
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.<br>
<br>
Though FS thinks it has answered the call, the remote end stays
ringing (playing ringback), and no connection ever actually seems to
happen.<br>
<br>
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.<br>
<br>
<br>
Scenario 2:<br>
<br>
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:<br>
<br>
<tt>2012-04-27 01:27:39.490028 [NOTICE] mod_conference.c:6228
Channel [<a class="moz-txt-link-abbreviated" href="mailto:sofia/external-4/Steve@comrex2.onsip.com">sofia/external-4/Steve@comrex2.onsip.com</a>] has been
answered<br>
2012-04-27 01:27:39.490028 [DEBUG] sofia.c:5602 Channel
<a class="moz-txt-link-abbreviated" href="mailto:sofia/external-4/Steve@comrex2.onsip.com">sofia/external-4/Steve@comrex2.onsip.com</a> entering state
[completed][200]<br>
2012-04-27 01:27:39.490028 [DEBUG] mod_conference.c:6111 Raw Codec
Activation Success L16@16000hz 1 channel 60ms<br>
2012-04-27 01:27:39.490028 [WARNING] switch_core_codec.c:691 Codec
L16 Exists but not at the desired implementation. 48000hz 60ms<br>
2012-04-27 01:27:39.490028 [DEBUG] mod_conference.c:6159 Raw Codec
Activation Failed L16@48000hz 1 channel 60ms<br>
2012-04-27 01:27:39.490028 [WARNING] switch_core_codec.c:789 Codec
is not initialized!<br>
</tt><br>
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.<br>
<br>
<br>
Scenario 3:<br>
<br>
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.<br>
<br>
Scenario 4:<br>
<br>
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.<br>
<br>
<br>
<br>
<br>
<br>
So, a few questions:<br>
<br>
- 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?<br>
<br>
- 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.<br>
<br>
- Any other advice for things to test or try out?<br>
<br>
<br>
thanks,<br>
Steve<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font size="2">
<b>Stephen Richardson<br>
Senior Software Engineer</b><br>
Comrex Corporation<br>
19 Pine Rd<br>
Devens MA 01434 USA<br>
v 978.784.1764<br>
f 978.784.1717<br>
<a href="mailto:steve@comrex.com">steve@comrex.com</a><br>
<a href="http://www.comrex.com/">http://www.comrex.com/</a><br>
</font></div>
</body>
</html>