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/
