On Fri, 2009-08-07 at 17:49 +0100, Keith Gearty wrote: > But that would be true if you followed my suggestion as well. No > codec manipulation is required, just filtering of the codec names > (treated as text strings) in the SIP messaging, according to an > exclude list. That to me seems like the cleanest way to prevent > high-bandwidth codec being used across a particular SIP trunk or > site-to-site (gateway) interface. If you can suggest a better way of > achieving this, then please do.
Scott includes "editing SDP" in the category "codec manipulation". Clearly, the cleanest way to restricting the codecs used with an ITSP is to have the ITSP offer/accept only the codecs that the customer wants. Since the ITSP is almost certainly encoding/decoding RTP, it is already doing SDP negotiation. That doesn't work if the two ends of the link in question are sipXecs's. If one must edit SDP, problems will likely ensue. It does seem that the structure of SDP allows us to find all mentions of codecs that can be used in the RTP, even if the endpoints are using SDP extensions that we do not know. 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. This approach generates endless ramifications that must be dealt with. 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. Dale _______________________________________________ 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/
