I brought this up a couple times in the past. Not only is codec support important but also the ability to limit a certain number of concurrent calls across a particular WAN link.
Certainly the addition of the locations concept was a step in the right direction. This enables the administrator to have the dial plan be different for location A vs. location B. With this type of scenario and gateways at each location, voice traffic (except for AA and VM) can be contained within a site minimizing WAN link usage. This of course gets thrown out of the window a bit if you are trying to use centralized trunks. Mike -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of think Sent: Tuesday, August 11, 2009 10:34 AM To: Keith Gearty Cc: [email protected] Subject: Re: [sipx-users] CODEC scenario I have to agree with Keith about the importance of such a feature regardless of how it's implemented. As an integrator I simply need this tool at my disposal. On Aug 10, 2009, at 3:51 AM, Keith Gearty wrote: > Todd Hodgen wrote: > > Dale Worley wrote: > >> A particular problem is that in order to enforce a >> bandwidth restriction, the SDP editing must remove any codecs that >> the >> filter does not understand. This automatically interferes with >> endpoints introducing new codecs. >> >> > Wrong. We're talking about an *ex*clusion list, not an *in*clusion > list. The reality of how such a feature would be used is that the > admin > knows what codecs his phones support. He sets up the high bandwidth > codec as first choice in all the phones, then 'blocks' that codec for > comms going through the low-bandwidth link. > > > Dale Worley wrote: > >> Here is an alternative approach that would be much more robust, >> although >> I don't know if anyone is implementing it: Have the border router >> throttle the bandwidth consumed by each individual IP endpoint. (I'm >> sure that there are routers that can do this.) Then have endpoints >> negotiate a set of codecs with differing bandwidths, and >> automatically >> switch to a codec with a lower bandwidth if it detects RTP packet >> loss. >> As far as I can see, this is within all existing protocol specs and >> since it's negotiated end-to-end, it takes into account all sources >> of >> network constriction. >> >> >> > Now that's an interesting solution, although it probably won't work > across a VPN connection, which is a serious concern. Unfortunately, > the > SIP Foundry cannot expect to dictate the development direction of VoIP > phones. Most phones are designed with Asterisk / Trixbox in mind, and > they're not going to change their design just to accommodate SipXecs. > > My conclusion is that the ability to restrict codecs across a > particular > low-bandwidth link is an essential feature, which several people on > the > list have asked for within the last month. For the implementer who > requires such a feature, it is no doubt important enough to influence > their decision as to which PBX they use, and since Asterisk and > Trixbox > both inherently support such a feature this poses a problem for the > SIP > Foundry. Since it is technically possible to edit the SDP and produce > the desired results, we should seriously consider doing it that > way. It > may not be "conceptually beautiful", but that isn't a good enough > reason > to refuse such an important feature. My view is that we should be > looking to implement this feature in SipXecs ready for 4.2.0. > > Keith. > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/ _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
