Al wrote:
> I would imagine this could be done by naming things a certain 
> way in the GUI to make it clear. It would be good for 
> non-technical folks to know what codec's work with key 
> services like voice mail :) 

Agreed.  This was part of my hope for XX-5492, that all Gateways,
Phones, and Media Servers use consistent codec labels.

The actual GUI control for XX-5492 is done, and looks great.  (See:
http://track.sipfoundry.org/secure/attachment/20664/New_Polycom_Codec_Se
lection.JPG.jpg)

But, it has been implemented only on the Polycom phone plug-in so far.
When will I see it for the CounterPath Bria and Nortel IP 12x0 phones,
AudioCodes gateways, and FreeSWITCH?


Woof wrote:
> One of the major advantages of a pure SIP Proxy architecture 
> is that the endpoints negotiate codecs directly with each 
> other, and thus "sipXecs" is not in the way at all, unlike 
> all(*) the other open source PBX systems out there.  Limiting 
> the codecs to what the media services supports is defeating 
> that advantage. 

We have two different issues.

1. Configuration.  I've proposed that our configuration omit uncommon
codec bit/sample rates that clutter the screen.  Maybe it would be
better to hide these under "Advanced", rather than hide them altogether?
(That would avoid the upgrade issue too.)   

2. Pure SIP Proxy architecture.  Nothing to do with what I've proposed
here, but I don't think we should shut the door on this.  There are some
compelling user stories that would be well served by having sipXproxy
manipulate SDP codec negotiation.  (See
http://list.sipfoundry.org/archive/sipx-users/msg16125.html for
example.)  With exclude lists we could deliver useful functionality,
without hampering media endpoints that use unrecognized codecs.  I do
not see the disadvantage.


-Paul
[email protected]



_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to