Niek, You might get some info from some of these posts in the wiki: http://wiki.sipfoundry.org/display/sipXecs/Custom+FreeSWITCH+programming
If you do get something working this would be the appropriate place to document unless it's code that can be integrated. Thanks, Mike On Sun, Sep 18, 2011 at 5:41 AM, Niek Vlessert <niekvless...@gmail.com>wrote: > Hello Todd, > > Thank you for this very informative and interesting answer. > > It's a very good thing that SipXecs is trying hard to remain in the > boundaries of open standards. Doing this will make sure a huge amount > of other problems will never happen. > > But I'm not sure that I'm not following open standards when doing > things like this. I agree, a phone should just follow a few RFC's > concerning call pickups, and then all will work. Brands should just do > that! > > But what if a phone does not support Call Pickup? Then there's 2 > options; wait for the phone to support it, or create a helper thing > around it. In Asterisk of FreeSwitch land I can easily create a helper > without having any RTP through the proxy. So I'm not breaking the > thought of letting the proxy be a proxy and I'm also not breaking any > RFC. I'm simply watching channels coming in and then bridging them > based on a user dialing some number. One can look at it as an add-on > instead of breaking a philosophy. The only ugly-ness in it is that I'm > taking system resources to fix a problem a phone should fix. Advantage > of this is that ALL phones will have call pickup support on SipX. > Something like this: *78 means RFC based pickup, *79 means channel > bridge based pickup. > > I guess it's a matter of opinion about strictness. I might oversee > things like HA & Fail Over (what if a Call Pickup comes in on server B > for phones on server A?), don't know enough yet about it. > > One major difference between Asterisk & SipX is that in SipX land the > phone should take care of a lot of stuff, in Asterisk it's the other > way around. When doing things like this, it's true that I'm breaking > this philosophy. But what is the difference between this fix and the > MOH on Polycom? Polycom will redirect the audio to the media server, > so MOH is on the server. Same issue with the philosophy. > > Come to think of it, there's a software called Voice Operator Panel > which bridges calls all the time on SipX, so I will have a look at > that, maybe that will provide an answer on how to get in the call in a > similar way as AMI. > > I will also look into your suggestion about other people trying to fix > SIP incompatibilities. > > If we succeed I will still supply the patch. ;) > > Regards, > > Niek > > On Sat, Sep 17, 2011 at 9:48 PM, Todd Hodgen <thod...@frontier.com> wrote: > > I'm not the owner of Sipfoundry, or a member of the developers team, so I > > can't speak with authority to the subject. But from what I have seen in > the > > history of this mailing list for the past few years, the fixes need to be > > within the confines of the appropriate RFC. This project uses open > > standards, and as such, fixes to make Aastra work with sipXecs should be > > based on using only those open standards. > > > > Possibly, you need to look at development of your own gateway to sit > between > > sipXecs and the Aastra phones to provide sip truing, if that is even > > possible. If the opportunity for your firm is great, you may want to > > investigate the business case for development of some custom software to > > work between the applications. > > > > Citel is an example of a company that builds devices that work between a > sip > > server and proprietary phones - like Nortel, Avaya, Panasonic, NEC, > Toshiba, > > etc. They also make gateways that allow the old legacy PBX products to > be > > extended over IP networks. Many of the SBC's on the market do truing > > between disparate SIP implementations, so there is no lack of > demonstration > > of products that merge incompatible SIP implementations, or similar. > > > > A couple days legwork looking at what options might exist may be time > well > > spent for your business opportunity. Some of the developers might have > some > > suggested avenues to try. > > > > > > -----Original Message----- > > From: sipx-dev-boun...@list.sipfoundry.org > > [mailto:sipx-dev-boun...@list.sipfoundry.org] On Behalf Of Niek Vlessert > > Sent: Saturday, September 17, 2011 12:21 PM > > To: sipXecs developer discussions > > Subject: Re: [sipx-dev] Aastra Call Pickup > > > > Hello Todd, > > > > The problem is obvious in the Aastra firmware. We tried to get Aastra to > fix > > the problems, but they don't seem to care; it works on Aastra PBX's, > > Ericsson PBX's and Asterisk. We are still pushing Aastra, but it's a > > difficult process, and other tried and have not succeeded. > > > > A fix to the firmware would definitely benefit the community. But won't a > > completely functional work around as well? > > > > Regards, > > > > Niek > > > > On Sat, Sep 17, 2011 at 8:50 PM, Todd Hodgen <thod...@frontier.com> > wrote: > >> It seems for you, that it would be prudent to document the issues with > >> the Aastra phone, determine if they are SIP standards issues, or > >> issues in the template of sipXecs, and develop a corrected template > >> for them, and work with Aastra to fix their deficiences. You can find > >> cost effective firms out there to develop software for this open > >> source project. Fixing the issues that are keeping you from > >> deploying to your customer, will not only fix that for you and create > >> sales for your firm, but benefit the community as a whole > >> > >> -----Original Message----- > >> From: sipx-dev-boun...@list.sipfoundry.org > >> [mailto:sipx-dev-boun...@list.sipfoundry.org] On Behalf Of Niek > >> Vlessert > >> Sent: Friday, September 16, 2011 11:38 PM > >> To: sipXecs developer discussions > >> Subject: Re: [sipx-dev] Aastra Call Pickup > >> > >> Because one of our big partners has a lot of Ericsson setups, and you > >> might know that Ericsson == Aastra these days, so the Aastra phones > >> are compatible with Ericsson. If these phones work fine we can get SipX > in > > those companies. > >> > >> And because the hardware itself is pretty good and good looking, and > >> not too expensive. > >> > >> And because it works just fine on Asterisk... ;) > >> > >> Regards, > >> > >> Niek > >> > >> On Sat, Sep 17, 2011 at 1:42 AM, Michael Picher <mpic...@ezuce.com> > wrote: > >>> Why the desire to use these phones so much from an unhelpful vendor? > >>> > >>> On Sep 16, 2011 3:30 PM, "Niek Vlessert" <niekvless...@gmail.com> > wrote: > >>>> Hello Tony, > >>>> > >>>> I couldn't agree more with your statement, but that doesn't get Call > >>>> Pickup fixed on Aastra phones. And because Aastra is not doing > >>>> anything, and we need this feature badly I'm asking for trickery. 2 > >>>> options: remain stubborn and require full SIP compliancy or use > >>>> tricks. I guess Aastra won't listen and not supporting this feature > >>>> will not increase acceptance for SipX. > >>>> > >>>> We are fixing the BLF in a bad way for Aastra, but in the most > >>>> elegant way this bad hack can be done. :) It's like problems with > >>>> the Linux kernel in the past; you can fix hardware problems through > >>>> drivers or tell the company to fix their hardware. Sometimes it's > >>>> good to choose the first option. This BLF ticket is from 2008, and > >> nothing happened. > >>>> > >>>> I agree with the Freeswitch thing. Most of the time we try to not > >>>> involve Freeswitch, but it has more flexability because of all the > >>>> applications and no recompiling when changes are made. If we can get > >>>> grip on the call in SIP without using Freeswitch it's less ugly, but > >>>> we > >> have no idea how. > >>>> > >>>> When using Asterisk we could just listen on the AMI and then bridge > >>>> the call to the phone doing call pickup without doing any RTP. Where > >>>> do we inject like this in SipX? > >>>> > >>>> If you have some trick up you sleeve PLEASE tell me. :) > >>>> > >>>> Regards, > >>>> > >>>> Niek Vlessert > >>>> Telecats > >>>> > >>>> > >>>> Op 16 sep. 2011, om 21:13 heeft Tony Graziano het volgende geschreven: > >>>> > >>>>> Internal calls (where call pickup comes into play) is handled by > >>>>> the proxy. It's always beena goal of the project to intentionally > >>>>> not use a b2bua for every phone connection in order to achieve peer > >>>>> to peer media and scalability. > >>>>> > >>>>> I would really not put FS in that role, it's intention is a media > >> server. > >>>>> On Fri, Sep 16, 2011 at 3:09 PM, Niek Vlessert > >>>>> <niekvless...@gmail.com> > >>>>> wrote: > >>>>>> Hello all, > >>>>>> Some of you might know that Call Pickup and BLF with Aastra phones > >>>>>> don't work on SipX because the Aastra firmware is not compatible. > >>>>>> We already fixed the BLF issue > >>>>>> > >>>>>> (http://track.sipfoundry.org/browse/XTRN-113?focusedCommentId=5587 > >>>>>> 5 > >>>>>> #action_55875) > >>>>>> but now we need Call Pickup. > >>>>>> The problem is that the phone won't respond well to the call > >>>>>> pickup SIP stuff. Is there a way to get control over the call in > > another way? > >>>>>> Something like this; instead of dialing *78<extension> (which is > >>>>>> call > >>>>>> pickup) we dial *79<extension>. In Sipx, add a gateway to local > >>>>>> port 15060, which is freeswitch, and a route to get the > >>>>>> *79<extension> in Freeswitch. > >>>>>> Freeswitch can execute any script. Is there a way to get to the > >>>>>> SIP header and bridge the call to the phone which did the *79? I > >>>>>> know, not beautiful at all, but it's a way. Some other direction > >>>>>> we are thinking is that Freeswitch registers itself as a phone on > >>>>>> the same extension as the Aastra phone, the dual forking feature > >>>>>> in SipX. So if the number is dialed, the Freeswitch phone will also > > 'ring'. > >>>>>> Maybe we can then bridge that call to the user who did the > >>>>>> *79<extension>? > >>>>>> But it we do that, then every Aastra phone needs a seperate SIP > >>>>>> account in Freeswitch. Freeswitch can handle that, but that's even > >>>>>> less beautiful, I'd say very ugly. ;) Anyone got a trick? > >>>>>> Regards, > >>>>>> Niek Vlessert > >>>>>> Telecats > >>>>>> _______________________________________________ > >>>>>> sipx-dev mailing list > >>>>>> sipx-dev@list.sipfoundry.org > >>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> ====================== > >>>>> Tony Graziano, Manager > >>>>> Telephone: 434.984.8430 > >>>>> sip: tgrazi...@voice.myitdepartment.net > >>>>> Fax: 434.465.6833 > >>>>> > >>>>> Email: tgrazi...@myitdepartment.net > >>>>> > >>>>> LAN/Telephony/Security and Control Systems Helpdesk: > >>>>> Telephone: 434.984.8426 > >>>>> sip: helpd...@voice.myitdepartment.net > >>>>> > >>>>> Helpdesk Contract Customers: > >>>>> http://support.myitdepartment.net > >>>>> Blog: > >>>>> http://blog.myitdepartment.net > >>>>> > >>>>> Linked-In Profile: > >>>>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > >>>>> Ask about our Internet faxservices! > >>>>> _______________________________________________ > >>>>> sipx-dev mailing list > >>>>> sipx-dev@list.sipfoundry.org > >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > >>>> > >>>> _______________________________________________ > >>>> sipx-dev mailing list > >>>> sipx-dev@list.sipfoundry.org > >>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > >>> > >>> _______________________________________________ > >>> sipx-dev mailing list > >>> sipx-dev@list.sipfoundry.org > >>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > >>> > >> _______________________________________________ > >> sipx-dev mailing list > >> sipx-dev@list.sipfoundry.org > >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > >> > >> _______________________________________________ > >> sipx-dev mailing list > >> sipx-dev@list.sipfoundry.org > >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > >> > > _______________________________________________ > > sipx-dev mailing list > > sipx-dev@list.sipfoundry.org > > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > > _______________________________________________ > > sipx-dev mailing list > > sipx-dev@list.sipfoundry.org > > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > _______________________________________________ > sipx-dev mailing list > sipx-dev@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- Michael Picher eZuce Director of Technical Services O.978-296-1005 X2015 M.207-956-0262 @mpicher <http://twitter.com/mpicher> www.ezuce.com
_______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev/
