asterisk users - Mar 2008 - Local music on hold -- mohinterpret=passthrough assymetrical ?

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

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
>