On Mon, Mar 15, 2010 at 10:31 AM, JOLY, ROBERT (ROBERT) <[email protected]> wrote: >> On Sun, Mar 14, 2010 at 3:18 PM, Andy Spitzer <[email protected]> wrote: >> > Woof! >> > >> > On Sun, 14 Mar 2010 10:54:26 -0500, M. Ranganathan >> <[email protected]> wrote: >> > >> >> 1. Why is G729 not enabled by default for freeSWITCH ? >> > >> > One word: >> > Patents >> > >> > >> http://en.swpat.org/wiki/Free_software_projects_harmed_by_software_pat >> > ents >> > >> > --Woof! >> > >> >> Woof!!! >> >> Thanks for the link. >> >> Simple solution ( requiring no sipxconfig work) : >> >> If MOH is enabled on the bridge ( a checkbox exists ), limit >> the call setup invite for dialog forming INVITE (to or from >> ITSP) to only those codecs supported by FreeSWITCH. This >> will exclude G729 from the list. >> >> Better solution : http://track.sipfoundry.org/browse/XX-6235 >> >> >> Opinions solicited. > > Locations with low bandwidth wouldn't be too happy with this arrangement. > This problem comes from the fact that you are re-inviting bandwidth.com with > no SDP but I'm wondering if you have to do that. What if you used a > different call flow instead? > > 1- INVITE MOH server without SDP > 2- Get 200 OK from MOH server with MOH SDP > 3- Re-INVITE bandwidth.com with with MOH's SDP > 4- Get 200 OK from bandwidth.com with b/w.com SDP > 5- Pass b/w.com's SDP in Ack you send to MOH server. > > Unless, I'm missing something, it seems to be that this call flow would give > you the best of both worlds. > >
Following up on the list with what I posted on our chat: Unfortunately it does not work because the phone does not do this.Here is a case where it will fail to produce consistent results: Consider the case when MOH is enabled on both phone and bridge. We support this configuration in 4.2. Keep in mind that with such a configuration, for a blind transfer, the MOH is coordination is handle by BOTH phone and SipXBridge. When the transferee ( itsp caller) is on hold when the transfer agent is dialing the transfer target, the phone will play MOH and when the transferree is being transferred sipxbridge will play MOH. What the phone does when it puts the ITSP caller on hold is to send the INVITE(no SDP) to the ITSP first (in the same manner as sipxbridge currently does). Hence this will result in inconsistent behavior during blind transfer ( even if the ITSP did cooperate with the scheme you propose ). For the portion of the transfer that is handled by the phone, you will have silence and for the portion that is handled by sipxbridge, you will hear music. Further, it will depend upon what codec was negotiated during call setup. I think it better to have a consistent user experience. I am going ahead with codec filtering. See XX-7951. If MOH is enabled on the bridge, you are restricted to negotiate only those codecs that freeSWITCH supports. At least for 4.2 that is a safe solution. Regards, Ranga -- M. Ranganathan _______________________________________________ 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/
