[asterisk-users] Local music on hold -- mohinterpret=passthrough assymetrical ?

[Richard Brady]

Exvito

Did you ever make any progress on this?

Richard



On Mon, Mar 10, 2008 at 2:38 AM, Ex Vito <ex.vitorino at gmail.com> wrote:
>  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
>