VoIP Mailing List Archives

[ex.vitorino at gmail.com]

Hi list,

I'm planning and testing a distributed asterisk deployment
throughout several sites; each will be connected to the PSTN
and all of them among themselves via IAX trunks. Phones
will be SIP.

I guess I already "solved" (worked-around, actually) asterisk's
codec negotiation limitations regarding local G.711 utilization vs.
remote G.729 while minimizing transcoding -- a bit of dial plan
tweaking via the setting of SIP_CODEC variable seems to do
the trick. But I digress... (with patch in issue 4825 things would
be much nicer!)

Now I'm still trying to improve bandwith usage with "local music
on hold"; that is, when sip user A1, registered to server A puts
sip caller B1, registered to server B, caller B1 gets server B's
music on hold -- this removes the need of streaming audio from
server A to server B while B1 is on hold, which in my scenario
is a good thing.

I post to the list trying to get peer feedback to my initial tests.
The configurations I mention are always applied to both
servers A and B.

1. If I set mohinterpret=passthrough + mohsuggest=default
in the [general] section of iax.conf the "local music on hold"
never works. Results:

bad - A1 calls B1, B1 puts A1 on hold, A1 gets B's music
bad - A1 calls B1, A1 puts B1 on hold, B1 gets A's music
bad - B1 calls A1, A1 puts B1 on hold, B1 gets A's music
bad - B1 calls A1, B1 puts A1 on hold, A1 gets B's music

2. If I set mohinterpret=passthrough + mohsuggest=default
in the specific peer/user (friend, actually) section I get improved
results but not perfect (or, at least, as I'd like them to be).
Results:

good - A1 calls B1, B1 puts A1 on hold, A1 gets A's music
bad - A1 calls B1, A1 puts B1 on hold, B1 gets A's music
good - B1 calls A1, A1 puts B1 on hold, B1 gets B's music
bad - B1 calls A1, B1 puts A1 on hold, A1 gets B's music

Fortunatelly, the good cases seem to be the most plausible ones.

So, in my observation, the mohinterpret=passthrough behaviour
is not symmetrical; that is, the hold signalling only seems to
travel one way along the IAX trunk... From the side receiving the
call to the side initiating it, and not the other way around.

Can anyone verify this behaviour ? Am I doing something wrong
or is this expected / "by design" behaviour ?

Should I file a bug against 1. ? Against 2. ?
"Extra points" question:

Since the calls in this case are remote, from site A to site B, the
codec in use is G.729 which, as you might well know, is really
awfull at supporting music since it's been designed for voice only.

How would one have the RTP stream renegotiated during call
to G.711 when entering music on hold (local, of course, after fixing
my issues above!) and back to G.729 when back to conversation ?

(ok, this probably needs patching the source !... but maybe someone
has an idea or has taken a different approach at this...)




Thanks a lot for any feedback,
--
exvito