-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Dale Worley Sent: Friday, August 07, 2009 12:07 PM To: Keith Gearty Cc: Bogdan Brezoi; [email protected] Subject: Re: [sipx-users] CODEC scenario
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 Something in Dales discussion here got my attention. IF the endpoints are a telephone and a sipXecs system, does that mean there won't be a negotiation of the speed then? Can someone explain how that works technically. One example that I'm curious about is if you have two sipXecs located at two different locations. When a call is placed from the far end system to the near end system auto attendant as an example, what Codec is use - I'm assuming G711. It could be a great feature for sipXecs systems to have a special configuration for when they are communicating to another sipXecs system, allowing them to have some features not available to other systems, and giving some enhancements to the network itself - for example - additional codecs like g729, etc. Knowing the two endpoints systems are the same could allow for some transferring of alarms, errors, etc. between the devices with some specialty tunnels, etc. for a common user interface, centralized management, etc. Having not worked with the HA versions, this might be in there already and I'm not aware. Regards, Todd Hodgen _______________________________________________ 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/
