See http://track.sipfoundry.org/browse/XX-6688 Enhanced Codec Pref for FreeSWITCH (Media Services) service
-Paul [email protected] ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Fowler, Peter (Peter) Sent: May 6, 2010 1:31 PM To: Tony Graziano; GERTSVOLF, MARK (MARK) Cc: [email protected] Subject: Re: [sipX-dev] Auto-attendant mystery In 4.2 Freeswitch will use its codec list to find a match instead of the clients. Ie. FS will use the first codec in the FS codec list that the client also supports. Prior to 4.0.4 FS would use the first codec in the client's list that FS also supports. This helps a bit but still doesn't address the issue that the FS codec list is a free form field (administrator could put G.729 as the beginning of the list). Peter ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Tony Graziano Sent: Thursday, May 06, 2010 1:25 PM To: GERTSVOLF, MARK (MARK) Cc: [email protected] Subject: Re: [sipX-dev] Auto-attendant mystery but shouldn't FS fail and try the next codec since it doesn't actively negotiate it? Since FS offered it, is there any "mechanism" in FS to say "that didn't work well, so ..next codec... before failing over"? I think it's awesome the failover did exactly what is was supposed to do. On Thu, May 6, 2010 at 1:20 PM, GERTSVOLF, MARK (MARK) <[email protected]<mailto:[email protected]>> wrote: Here is an interesting problem, which took me quite some time to explain. Customer complaining that calls to auto-attendant from a subset of phones are being forwarded to live operator without being presented with AA prompts. First I discover that live operator is specified as an AA failover destination. I then discover that all sets exhibiting this behavior have one thing in common - G.729 is ahead of G.711 in the codec list. Looking at the call trace it seems that Freeswitch receiving the call with G.729 followed by G.711 answers the call with G.729 and immediately transfers the call to the live operator. This is odd since Freeswitch in sipX does not have support for G.729. Now, "media services" service has configuration parameter called "Codecs", which is a free form text string set by default to: "p...@20i,p...@20i,speex,G722,L16". This parameter is accessible via Servers->Services screen. It turns out the customer, in his infinite wisdom, changed this parameter and added "G729" to the list... Presence of G.729 codec on the codecs list is causing FS to answer the call with G.729 for all calls that have G.729 as a preferred codec in the SDP offer. After answering the call FS determines that there is no valid input and transfer the call to failover destination. Even though technically this is a case of invalid configuration, it may save us time in the future if the media services "codecs" parameter is converted into a multi-selection list. Alternatively, we could use a new sipX 4.0 codec widget, which is used for codec selection for phones. Thanks, Mark. _______________________________________________ sipx-dev mailing list [email protected]<mailto:[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/ -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected]<mailto:[email protected]> Fax: 434.984.8431 Email: [email protected]<mailto:[email protected]> LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected]<mailto:[email protected]> Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ 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/
