Exvito Did you ever make any progress on this?
Richard On Mon, Mar 10, 2008 at 2:38 AM, Ex Vito <[email protected]> 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 > _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
