>>> "[email protected]" <[email protected]> 01/17/11 2:05 PM >>>
>I thought the device itself or the switch in the middle would require the 
>licensing to compress calls to g729.
>
>Meaning, even if a device is set to use g729 but doesn't itself have a license 
>or if the switch it is connecting to doesn't then >the call would end up being 
>what ever the devices could agree on after that, typically g711.


If your device has a setting for g729 then it is licensed for it.  So polycoms 
(and really all hard phones) and bria softphones will do g729.  Some of the 
free softphones do not.

So, in sipx, we really only need to be concerned with what the endpoints 
support.  Unlike Asterisk or some other system there really is no other 
"switch" in the media path.  

So there are 3 cases we need to decide.

1. Endpoint to Endpoint = If both support G729 and the codec is preferred, it 
will be used.

2. Endpoint to Media Services (VM, AA, Conferencing) = Right now it only 
supports G711.  So if the phone is set to first use G.729 and then fallback to 
G.711 then your endpoint will use G711 only when it has too.
            
                 - In 4.4 Freeswitch will be able to use G729 and transcode it 
should an endpoint not support it.

3. Endpoint to trunk = This is the same as case number 2 except we have more 
option with Sipxbridge that can strip out unwanted codecs.  It does not 
transcode but it can hide what codecs the sip trunk offers your endpoint.

So if what your trying to accomplish is to get remote phones to use the smaller 
G.729 as much as possible just pick a phone or softclient that has the G.729 
codec listed.  Set it to prefer that codec first but allow it fall back to 
G.711.

This does not *force* G729 because it would use G.711 for media services or for 
calling an endpoint not configured with G.729 but it will catch the majority of 
all your calls.  If you lock the phone at only G729 then calls to VM and other 
non-g729 media services would fail.

-M


_______________________________________________
sipx-users mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-users/

Reply via email to