I've been using the current (pre release) code, the Polycom plugin changed to using 127 as part of the 3.2.2 firmware transition. My 550's and 335's all had to be set back to 101 for it to work right with voip.ms (and my SPA3102's).
At least that's not your problem them :) -Eric On Mar 8, 2010, at 2:57 PM, Burden, Mike wrote: > We are set for 101. > > > > Ø SipXecs defaults polycom phones to use 127 instead of 101 (because polycom > uses 127 as the default). > > That does not appear to be correct, at least for IP550 phones and sipXecs > 4.0.4: > > > <image001.jpg> > > > > > <image002.jpg> > Mike Burden > <image003.gif> > Lynk Systems, Inc > e-mail: m...@lynk.com > Phone: 616-532-4985 > > > > > > > From: Eric Varsanyi [mailto:sip...@eljv.com] > Sent: Sunday, March 07, 2010 2:03 PM > To: Burden, Mike > Cc: sipx-users@list.sipfoundry.org > Subject: Re: [sipx-users] DTMF Issues Revisited > > I recently had a problem with voip.ms exactly like this, the problem was that > something in their infrastructure or downstream just assumes that the > 'dynamic' RTP code for telephony events (DTMF) is 101. It isn't consistent > and DTMF on calls to the same destinations work or don't work apparently > randomly. I tried calling a local pots number and typing DTMF and sure enough > sometimes I would hear the tones and sometimes there was total silence on the > receiving end. > > SipXecs defaults polycom phones to use 127 instead of 101 (because polycom > uses 127 as the default). > > Linksys/Cisco SPAxxx devices suffer from the same problem, they let you > negotiate 127 (as an FXO from a Polycom) but then just work as if 101 was > selected. > > What solved it for me and made voip.ms 100% reliable wrt DTMF was to switch > the polycoms to use 101. I put in a jira/patch for this but since Polycom > thinks 127 is a good default its unlikely the default will be changed in the > sipXecs polycom plugin. > > -Eric > > On Mar 5, 2010, at 2:27 PM, Burden, Mike wrote: > > > Good afternoon, > > Most of the time (about 75%) we can call a Customer/Vendor/etc that has an > automated attendant, and we are able to make selections or choose extensions > using DTMF on the keypad. > > Once in a while, though, we make a call and are not able to make a selection > unless we wait until the auto-attendant on the receiving end finishes its > spiel. > > > Since our configuration isn’t changing between calls, and I assume that our > ITSP isn’t changing configurations, I believe that DTMF is configured > correctly in sipXecs (or else it wouldn’t work right 75% of the time.) > > > My theory is that the ITSP must have a number of FXO/FXS devices to connect > VOIP calls into the POTS system. I’m guessing that they may vary somewhat > in the quality of the DTMF tones they generate, and that different calls > being routed to different FXO/FXS devices explains why sometimes DTMF works > fine and sometimes it doesn’t. > > > Could I be onto something here, or is there a flaw in my reasoning? > > > > Mike Burden > Lynk Systems, Inc > e-mail: m...@lynk.com > Phone: 616-532-4985 > > _______________________________________________ > sipx-users mailing list sipx-users@list.sipfoundry.org > 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 sipx-users@list.sipfoundry.org 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/
