Dan, I've been using ClarkConnect since version 4.3, it works really well! I have version 5 installed right now and am utilizing the bandwidth management. So far, so good! It's easy to use, manage and has a great dashboard view!
Alan On Tue, Aug 11, 2009 at 10:39 AM, <[email protected]>wrote: > Send sipx-users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://list.sipfoundry.org/mailman/listinfo/sipx-users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of sipx-users digest..." > > Today's Topics: > > 1. Cisco AS5350 IOS? ([email protected]) > 2. Re: Router for SIPX (Picher, Michael) > 3. Snom no sound for remote users (Frank J Bruzzaniti) > 4. Re: CODEC scenario (think) > 5. Re: Snom no sound for remote users (M. Ranganathan) > 6. Re: CODEC scenario (Picher, Michael) > 7. incoming call transfer dropped (Daniel Yu) > > > ---------- Forwarded message ---------- > From: "[email protected]" <[email protected]> > To: sipx-users <[email protected]> > Date: Mon, 10 Aug 2009 23:38:51 -0500 > Subject: [sipx-users] Cisco AS5350 IOS? > Been reading the wiki and other things and have not been able to confirm > which cisco IOS is the best when using an AS5350 with sipxecs. > > > > > > ---------- Forwarded message ---------- > From: "Picher, Michael" <[email protected]> > To: "Dan White" <[email protected]>, <[email protected]> > Date: Tue, 11 Aug 2009 06:14:21 -0400 > Subject: Re: [sipx-users] Router for SIPX > > On the commercial side, the Cisco ASA series can do this. > > > > For Open Source you can look to pfsense. Vyatta will do it as well but it > is more difficult to manage. > > > > Mike > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Dan White > *Sent:* Monday, August 10, 2009 10:26 AM > *To:* [email protected] > *Subject:* [sipx-users] Router for SIPX > > > > I have a 20 meg available port between my sipx server and the internet, can > I get some suggestions on which would be a good voip router to use, I would > like something that prioritizes voip over internet, and can if necessary > create VPN tunnels, I am looking for something inexpensive. > > > > Please any help would be appreciated. > > > > Thanks > > > > Dan White > > > ---------- Forwarded message ---------- > From: Frank J Bruzzaniti <[email protected]> > To: [email protected] > Date: Tue, 11 Aug 2009 21:06:21 +0930 > Subject: [sipx-users] Snom no sound for remote users > If I configure a snom phone and am using it locally it works fine. > If I move it to another location like home where I am running ADSL. > I can connect and call an external number but there is no sound. > I configured the RTP start and finish range to be 30000-31000 and opend > those UDP ports on the firewall but still no luck. > Is this a NAT traversal problem? > > My gateway is a billion > > Frank. > > P.S. > > I also tried using the alternative manual configuration by using: > > http://"Your_sipX_HOSTNAME":8090/phone/profile/docroot/{mac}.htm > > But when I had a look at my sipx server is was configuring {mac}.xml not > html as the documentation suggested. > > > > > > ---------- Forwarded message ---------- > From: think <[email protected]> > To: Keith Gearty <[email protected]> > Date: Tue, 11 Aug 2009 09:34:07 -0500 > Subject: Re: [sipx-users] CODEC scenario > I have to agree with Keith about the importance of such a feature > regardless of how it's implemented. As an integrator I simply need this > tool at my disposal. > > On Aug 10, 2009, at 3:51 AM, Keith Gearty wrote: > > Todd Hodgen wrote: >> >> Dale Worley wrote: >> >> A particular problem is that in order to enforce a >>> bandwidth restriction, the SDP editing must remove any codecs that the >>> filter does not understand. This automatically interferes with >>> endpoints introducing new codecs. >>> >>> >>> Wrong. We're talking about an *ex*clusion list, not an *in*clusion >> list. The reality of how such a feature would be used is that the admin >> knows what codecs his phones support. He sets up the high bandwidth >> codec as first choice in all the phones, then 'blocks' that codec for >> comms going through the low-bandwidth link. >> >> >> Dale Worley wrote: >> >> Here is an alternative approach that would be much more robust, although >>> I don't know if anyone is implementing it: Have the border router >>> throttle the bandwidth consumed by each individual IP endpoint. (I'm >>> sure that there are routers that can do this.) Then have endpoints >>> negotiate a set of codecs with differing bandwidths, and automatically >>> switch to a codec with a lower bandwidth if it detects RTP packet loss. >>> As far as I can see, this is within all existing protocol specs and >>> since it's negotiated end-to-end, it takes into account all sources of >>> network constriction. >>> >>> >>> >>> Now that's an interesting solution, although it probably won't work >> across a VPN connection, which is a serious concern. Unfortunately, the >> SIP Foundry cannot expect to dictate the development direction of VoIP >> phones. Most phones are designed with Asterisk / Trixbox in mind, and >> they're not going to change their design just to accommodate SipXecs. >> >> My conclusion is that the ability to restrict codecs across a particular >> low-bandwidth link is an essential feature, which several people on the >> list have asked for within the last month. For the implementer who >> requires such a feature, it is no doubt important enough to influence >> their decision as to which PBX they use, and since Asterisk and Trixbox >> both inherently support such a feature this poses a problem for the SIP >> Foundry. Since it is technically possible to edit the SDP and produce >> the desired results, we should seriously consider doing it that way. It >> may not be "conceptually beautiful", but that isn't a good enough reason >> to refuse such an important feature. My view is that we should be >> looking to implement this feature in SipXecs ready for 4.2.0. >> >> Keith. >> >> _______________________________________________ >> sipx-users mailing list [email protected] >> 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/ >> > > > > > ---------- Forwarded message ---------- > From: "M. Ranganathan" <[email protected]> > To: Frank J Bruzzaniti <[email protected]> > Date: Tue, 11 Aug 2009 10:41:33 -0400 > Subject: Re: [sipx-users] Snom no sound for remote users > On Tue, Aug 11, 2009 at 7:36 AM, Frank J > Bruzzaniti<[email protected]> wrote: > > If I configure a snom phone and am using it locally it works fine. > > If I move it to another location like home where I am running ADSL. > > I can connect and call an external number but there is no sound. > > I configured the RTP start and finish range to be 30000-31000 and opend > > those UDP ports on the firewall but still no luck. > > Is this a NAT traversal problem? > > > The SNOM has some issues with SDP that make it not workable as a remote > phone. > > > > > > My gateway is a billion > > Sounds like a big gateway. > > > > > Frank. > > > > P.S. > > > > I also tried using the alternative manual configuration by using: > > > > http://"Your_sipX_HOSTNAME":8090/phone/profile/docroot/{mac}.htm > > > > But when I had a look at my sipx server is was configuring {mac}.xml not > html as the documentation suggested. > > > > > > _______________________________________________ > > sipx-users mailing list [email protected] > > 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/ > > > > > > -- > M. Ranganathan > > > > ---------- Forwarded message ---------- > From: "Picher, Michael" <[email protected]> > To: "think" <[email protected]>, "Keith Gearty" <[email protected]> > Date: Tue, 11 Aug 2009 11:49:21 -0400 > Subject: Re: [sipx-users] CODEC scenario > I brought this up a couple times in the past. Not only is codec support > important but also the ability to limit a certain number of concurrent > calls across a particular WAN link. > > Certainly the addition of the locations concept was a step in the right > direction. This enables the administrator to have the dial plan be > different for location A vs. location B. With this type of scenario and > gateways at each location, voice traffic (except for AA and VM) can be > contained within a site minimizing WAN link usage. This of course gets > thrown out of the window a bit if you are trying to use centralized > trunks. > > Mike > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of think > Sent: Tuesday, August 11, 2009 10:34 AM > To: Keith Gearty > Cc: [email protected] > Subject: Re: [sipx-users] CODEC scenario > > I have to agree with Keith about the importance of such a feature > regardless of how it's implemented. As an integrator I simply need > this tool at my disposal. > > On Aug 10, 2009, at 3:51 AM, Keith Gearty wrote: > > > Todd Hodgen wrote: > > > > Dale Worley wrote: > > > >> A particular problem is that in order to enforce a > >> bandwidth restriction, the SDP editing must remove any codecs that > >> the > >> filter does not understand. This automatically interferes with > >> endpoints introducing new codecs. > >> > >> > > Wrong. We're talking about an *ex*clusion list, not an *in*clusion > > list. The reality of how such a feature would be used is that the > > admin > > knows what codecs his phones support. He sets up the high bandwidth > > codec as first choice in all the phones, then 'blocks' that codec for > > comms going through the low-bandwidth link. > > > > > > Dale Worley wrote: > > > >> Here is an alternative approach that would be much more robust, > >> although > >> I don't know if anyone is implementing it: Have the border router > >> throttle the bandwidth consumed by each individual IP endpoint. (I'm > >> sure that there are routers that can do this.) Then have endpoints > >> negotiate a set of codecs with differing bandwidths, and > >> automatically > >> switch to a codec with a lower bandwidth if it detects RTP packet > >> loss. > >> As far as I can see, this is within all existing protocol specs and > >> since it's negotiated end-to-end, it takes into account all sources > >> of > >> network constriction. > >> > >> > >> > > Now that's an interesting solution, although it probably won't work > > across a VPN connection, which is a serious concern. Unfortunately, > > the > > SIP Foundry cannot expect to dictate the development direction of VoIP > > phones. Most phones are designed with Asterisk / Trixbox in mind, and > > they're not going to change their design just to accommodate SipXecs. > > > > My conclusion is that the ability to restrict codecs across a > > particular > > low-bandwidth link is an essential feature, which several people on > > the > > list have asked for within the last month. For the implementer who > > requires such a feature, it is no doubt important enough to influence > > their decision as to which PBX they use, and since Asterisk and > > Trixbox > > both inherently support such a feature this poses a problem for the > > SIP > > Foundry. Since it is technically possible to edit the SDP and produce > > the desired results, we should seriously consider doing it that > > way. It > > may not be "conceptually beautiful", but that isn't a good enough > > reason > > to refuse such an important feature. My view is that we should be > > looking to implement this feature in SipXecs ready for 4.2.0. > > > > Keith. > > > > _______________________________________________ > > sipx-users mailing list [email protected] > > 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 [email protected] > 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/ > > > > ---------- Forwarded message ---------- > From: Daniel Yu <[email protected]> > To: "sipX Users Mailing List ([email protected])" < > [email protected]> > Date: Tue, 11 Aug 2009 12:39:49 -0400 > Subject: [sipx-users] incoming call transfer dropped > > Outgoing calls are working properly. However, for incoming calls, the call > is answered by AA, when I key in extension, the phone is dropped from the > caller, but extension still rings. Anybody has idea what the problem is? > > > > I’m using sipX 4.0.1 ISO, SIP trunking provider is FreePBX (owned by > bandwidth.com) > > ------------------------------ > The information contained in this email may be privileged, confidential, > and protected from disclosure. If the reader of this email is not the > intended recipient, you are hereby notified that any dissemination, > distribution, or copying of this email is strictly prohibited. If you have > received this email in error, please notify us immediately by replying this > email and deleting it from your system. > > Internet communications cannot be guaranteed to be timely, secure, error or > virus-free. The sender does not accept liability for any errors or > omissions. > > _______________________________________________ > sipx-users mailing list [email protected] > 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 [email protected] 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/
