if you look at how the call pickup works its because the device supports a sip standard like alert-info and things like that. not all devices support that. some do and have a poor or broken behavior.
sipx was designed for the enterprise environment. aastra phones imo have a lot of growing up to do. im not sure I agree with forcing round pegs into square bowls, but I understand. good luck. On Sep 18, 2011 5:41 AM, "Niek Vlessert" <[email protected]> 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 <[email protected]> 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: [email protected] >> [mailto:[email protected]] 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 <[email protected]> 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: [email protected] >>> [mailto:[email protected]] 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 <[email protected]> wrote: >>>> Why the desire to use these phones so much from an unhelpful vendor? >>>> >>>> On Sep 16, 2011 3:30 PM, "Niek Vlessert" <[email protected]> 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 >>>>>> <[email protected]> >>>>>> 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 >>>>>>> [email protected] >>>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ====================== >>>>>> Tony Graziano, Manager >>>>>> Telephone: 434.984.8430 >>>>>> sip: [email protected] >>>>>> Fax: 434.465.6833 >>>>>> >>>>>> Email: [email protected] >>>>>> >>>>>> LAN/Telephony/Security and Control Systems Helpdesk: >>>>>> Telephone: 434.984.8426 >>>>>> sip: [email protected] >>>>>> >>>>>> 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 >>>>>> [email protected] >>>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>>> >>>>> _______________________________________________ >>>>> sipx-dev mailing list >>>>> [email protected] >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>> >>>> _______________________________________________ >>>> sipx-dev mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>>> >>> _______________________________________________ >>> sipx-dev mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>> >>> _______________________________________________ >>> sipx-dev mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >>> >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> >> _______________________________________________ >> sipx-dev mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-dev/ >> > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
