locked
Looking for some advice - OCS to [some IP PBX] to PSTN RRS feed

  • Question

  •  

    Hi,

     

    I'm hoping someone knows 'the answer' & can share...

     

     

    Our existing PBX is ready to die - we are looking at a full replacement.  We use a full T1 PRI (23 channels) - 50 DID's.

     

    We already have Exchange 2007 & OCS 2007 - both working together.  We have some Polycom CX200 phones to experiment with - and we have been impressed with everything so far.

     

    OCS does not offer everything a full IP PBX does - so we still need an IP PBX to fill the gaps.  We need to support about 130 people/UM accounts max - but we only use 50 to 60 phones at any one time (different shifts)

     

     

    Here's the question...

     

    Is there an IP PBX that can do the following:

    1) Terminate a full T1 PRI

    2) Provide all the functions from a tradiaitonal PBX (voicemail is NOT needed, but call queueing, basic IVR, etc)

    3) Offer SIP over UDP to support traditional VoIP desk phones, (these will be our non-communicator phones - maybe 10).

     

    AND - can do one of the following :

    - Offer CSTA over TCP and seamlessly intergrate with OCS without a mediation server

    - Offer SIP over TCP and can go via a mediaition server to get to OCS

     

     

    I've been looking at several solutions, but I'm struggling to find sucess stories...

    - Asterisk & OpenSER on the same box to a Mediaition server

    - TrixBox 2.4 to a mediaition server

    - PBXNSIP to ? to a mediation server

    - Some Cisco solution?

     

     

    Anyone got any success stories they would like to tell?

     

     

    Thanks in advance

     

    Paul

    Friday, February 1, 2008 9:25 PM

Answers

  • That's a very workable budget, though it likely eliminates Cisco from the mix.

     

    Right now Nortel is the only PBX vendor that has announced official OCS support that would meet all your goals, but Mitel is on the verge of releasing it (some people already have it working).  Take a look at the 3300 system.  Their upcoming release (expected to release very soon) should provide the same integration as the Nortel.

     

    You could realistically satisfy all your requirements with the exception of call queuing using a pure MS solution attached to a media gateway.  The cost of this solution would be about $2000 for the gateway plus the cost of the Communicator phones for employees who need a hard phone.

     

    You could also get a low budget PBX or a software-based PBX to which you could attach low priced SIP phones.  The T1 would land on a media gateway which would provide Enterprise Voice for your Communicator phone users.

     

    These are a few examples.  Hopefully this all makes sense...you are likely to solicit a wide variety of solutions to your problem, but hopefully this at least gives you a starting point for research.

    Tuesday, February 12, 2008 5:29 PM
    Moderator

All replies

  • Have you looked at a sipX solution or any of the hybrid gateways?

     

    Thursday, February 7, 2008 10:44 PM
  • Thanks for the feedback.

     

    I believe SipX has problems - which is why I've been looking at OpenSER.

     

    What's a Hybrid Gateway?  If it's a gateway that provides no PBX functions - just routes converts voice from the PSTN to SIP - then unfortunetly - it doesn't do what I require.  I shall search for Hybrid Gateways to see what it involves...

     

    So far - the best solution for my problems seems to be either:

     

    1) Asterisk / OpenSER (cheap / flexible / I can customise to do what I want)

    2) a Cisco solution (expensive / reliable / somewhat inflexible)

     

     

    Paul

    Friday, February 8, 2008 12:37 AM
  • Can you please advise me that why we need OpenSER?. I thought OpenSER is purely a SIP server, which is similar to OCS server. Is it possible to use only Asterisk  as an IP PBX, integrated with OCS server?

     

    Thanks

    Noppong 

    Sunday, February 10, 2008 5:53 PM
  •  

    In a ideal setup - Asterisk would connect directly to OCS - as few gateways or devices inbetween as possiple.

     

    Asterisk uses SIP over UDP. (There is a TCP module for Asterisk - but my understanding is it's not 100% reliable yet)

     

    OCS uses CSTA over SIP, (and is TCP based)

     

    An OCS Mediation server will communicate in SIP over TCP.

     

    OpenSER (and SipX) can use both SIP/UDP & SIP/TCP.

     

    So - it all ends up looking like this.

     

     

    Asterisk <==[SIP/UDP]==>OpenSER<==[SIP/TCP]==>OCS Mediation Server<==[TLS?]==>OCS Server

     

     

    It's messy - but that's how it is for right now...(unless anyone knows a better solution?)

     

     

    Regards

     

    Paul

    Monday, February 11, 2008 7:02 PM
  • You've mentioned a number of FOSS-based solutions.  What is your budget?  That's a key factor to the solution you would implement.  You can find something to cobble together for low cost or you can spend some money and get something a little more reliable.

    Monday, February 11, 2008 9:25 PM
    Moderator
  •  

    Thanks Mike - I am extremly interested in hearing about more reliable solutions.

     

    Reliability is first.  Flexibility / adaptability is second.  Cost is third.

     

    I mention the FOSS-based solutions because I have an interest in Asterisk & dabble in Linux.  We run some FOSS solutions here and they have proven to be extremly good.

     

    I do not have a set budget as such, but if the product met all the criteria - up to $20K would be relatively easy.

     

     

    Regards

     

    Paul

     

    Monday, February 11, 2008 9:59 PM
  • That's a very workable budget, though it likely eliminates Cisco from the mix.

     

    Right now Nortel is the only PBX vendor that has announced official OCS support that would meet all your goals, but Mitel is on the verge of releasing it (some people already have it working).  Take a look at the 3300 system.  Their upcoming release (expected to release very soon) should provide the same integration as the Nortel.

     

    You could realistically satisfy all your requirements with the exception of call queuing using a pure MS solution attached to a media gateway.  The cost of this solution would be about $2000 for the gateway plus the cost of the Communicator phones for employees who need a hard phone.

     

    You could also get a low budget PBX or a software-based PBX to which you could attach low priced SIP phones.  The T1 would land on a media gateway which would provide Enterprise Voice for your Communicator phone users.

     

    These are a few examples.  Hopefully this all makes sense...you are likely to solicit a wide variety of solutions to your problem, but hopefully this at least gives you a starting point for research.

    Tuesday, February 12, 2008 5:29 PM
    Moderator
  • HI Paul,  Check out Mitel  http://www.mitel.com/DocController?documentId=25323

     

    At its core - the Mitel 3300ICP supports T1/PRI/Analog and SIP trunking (sip trunking to the PSTN as well as to the Exch 2007 server for support of Exch as VM/UM/Speech AA). Also 'in the voip pbx' would be ACD, basic IVR.  Mitel has been around for 35+ years in the business of providing telephony solutions to large and small customers - so pretty much anything you want a pbx to do, we do.

     

    As for your shifts - you can use "hot desking" - so you would only need 50-60 phones, but as users come in on their shift, they sit at any phone and 'log in' so the phone would take on their entire personality, including ext/did, personal buttons/features, and integration to the OCS for calling/presence etc... and access to the VM hg for Exchange 2007.

     

    As I said above, we do supply direct SIP trunking integration for the Exchange 2007 integration. However to integrate and extend the Microsoft OSC product, we do require the Mitel Live Business Gateway which esentially converts the Microsoft protocols to Mitel - this allows us to do a lot more then enable click to call from OCS - it allows us to provide out customers with 8 party conferencing from OCS, extend presence to your cell phone (with Mobile Extension), and also integrate MS provided presence information into our own Mitel applications.

     

    Let me know if you have any questions or need to be pointed toward a Mitel rep for further assistance.

     

    Kati

    Tuesday, February 19, 2008 10:45 PM
  • Kati,

     

    Who can I speak to about Software Updates and LBG here in the UK? We've tried contacting a rep (James Madgwick) but he won't call us back!

     

    Cheers,

    Steve Jenkinson

     

    Thursday, February 28, 2008 1:31 PM
  • Hi,

     

    Try Brekeke PBX.  It comes with a built-in SIP Server that supports TCP (currently in alpha release).  If you already have a favorite IP PBX, you can try their Brekeke SIP Server which is a SIP proxy and registrar.  It is also in alpha.

     

    cheers,

    Big Willis

    Tuesday, March 11, 2008 10:01 PM
  • Hi Paul,

    the OCS uses the uaCSTA protocol as defined by ECMA TR/87 to communicate with the PSTN as shown below

    OCS---/uaCSTA/---Gateway---/other-protocol/----PBX---PSTN

    where /other-protocol/ is vendor specifc.

    So what you need is a so called uaCSTA gateway.

    I am working as a developer for a company which has developed an uaCSTA gateway for various types of PBXes from different vendors, e.g.
    • ShoreTel
    • Siemens
    • Avaya
    • Nortel
    • Alcatel
    • Cisco
    • and a lot more, e.g. customizable generic PBX types
    even if did not purchase your type of PBX from one of the vendors mentioned above there is a very good chance that it will work with one of the customizable generic PBX types.

    The uaCSTA gateway you need is called Teamcall Server. For more information please look at  http://ww.ilink.de/en/index.html.
    Wednesday, April 23, 2008 9:09 AM
  • high.there!
    i'm just wondering if you also have a uaCSTA gateway to connect the OCS with asterisk?
    thx & cheers
    -hugo
    Wednesday, May 7, 2008 6:12 AM
  • high.again!
    just forgot to state to the original post.
    currently i've suceeded in integrating asterisk with OCS (including the OCS mediation server) using openser. but this is simply fine for a pure softphone functionality.
    like the following setup:

    OCS <--|uaCSTA|--> OCS mediationserver <--|SIP:TCP|--> openSER <--|SIP:UDP|--> asterisk

    so this is working fine, but as for the CTI integration i need somehow a gateway which translates uaCSTA to SIP, as the mediation server is not in the line, to meet the needs of the following setup:

    OCS <--|uaCSTA:TLS/TCP|--> ??? <--|SIP:UDP|--> asterisk

    i didn't found any kind of module or plugin for asterisk or openSER which, provides this functionality. addtionally i didn't found any open source based SIP gateway supporting this protocol translation.

    any thoughts which could solve this problem?

    thx for any suggestion...
    cheers
    -hugo

    Wednesday, May 7, 2008 6:39 AM
  •  

    Thanks to everyone for the info...

     

    Hugo - I've been following (shamelessly copying!) your OpenSER work - nice fix on the RTP problem btw.

     

    I'm interested by the CTI intergration.  What can you do if you get this working?

     

    Could you route a call from Asterisk to an OC client - and if they do not answer within a certain time - enable Asterisk to route the call somewhere else?

     

    I'd like to use the call queues in Asterisk for a call room here at work - but if I use OC phones with it - they will cut to voice mail if unanswered.  Someone suggesed using secondary OCS accounts without vm - and that would work - but it kind of defeats the object of intergrated comms with less hassle.

     

     

    Paul

     

    PS - you may already know this - but Asterisk 1.6 (still beta) has SIP TCP built in - and other have set it up & it works directly with OCS Mediation server.

    Wednesday, May 7, 2008 4:34 PM
  • high.paul!

    well, nice if it works for you as well. don't know if you need also "call hold" to be working. for this had to do another protocol patch with openSER, something like modify the re-invites reply ("200 OK") has the correct SDP headers. so if you need this fix too just give me a note. Wink

    thx, for the info. i've heard about * supporting TCP. unfortulately i have the requirement to stick to * v1.2, so it's currently no option. anyways i need to access the SIP protocol header for the mods to get the thing interacting in the correct manner, which honestly i kinda like doing it via openSER. Smile
    (actually i do not know how to directly modify SIP protocol in *, without touching *'s source code. is there any possibility?)

    well concerning the CTI integration i'll still on the search for an apporpriate (if possible open soure) implementation, which translates normal SIP traffic to the uaCSTA protocol. until now i'd been unlucky on that challange.
    the other suggestion is the implement a home-grown gateway (most probably in perl), which is listening to the uaCSTA SIP traffic and interacting with * via the AMI.
    it's not my favourite but just a way to start with...

    if someone has any hints for such a SIP/uaCSTA gateway for connecting * with OCS, it be pleased to get into the loop.

    thx & cheers
    -hugo



    Thursday, May 8, 2008 3:06 AM
  •  

    Hi Hugo - I couldn't find your e-mail address anywhere - so I'm posting here hoping you receive this...

     

    Please can you send me the "call hold" fix you mentioned.

     

    In-fact - can I ask you for a copy of your entire working openser.cfg file?  I'm not much of an OpenSER guy & I think I'm making some errors in the file somewhere. Something's just not working right..

     

    Any help is appreciated...

     

    Regards

     

    Paul Adams

    padams [at] freightliner [dot] bc [dot] ca

    Friday, May 16, 2008 7:09 PM
  • high.paul!

    i couldn't find your email address too. Wink

    anyways, maybe there are more out there interested in that patch (now for openSER v1.3):

    Code Snippet


    ############################ Global Parameters ###############################

    debug=3
    fork=yes
    log_stderror=yes
    log_facility=LOG_LOCAL5

    children=4

    port=5060


    ############################## Modules Section ################################
    #set module path
    mpath="/usr/local/lib/openser/modules/"

    loadmodule "sl.so"
    loadmodule "tm.so"
    loadmodule "rr.so"
    loadmodule "maxfwd.so"
    loadmodule "textops.so"
    loadmodule "mi_fifo.so"
    loadmodule "uri.so"
    loadmodule "xlog.so"
    loadmodule "gflags.so"

    # ===================== setting module-specific parameters ====================

    # ----- mi_fifo params -----
    modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")

    # ----- rr params -----
    modparam("rr", "enable_full_lr", 1)
    modparam("rr", "enable_double_rr", 0)

    # ----- gflags params -----
    modparam("gflags", "initial", 1)    # 1..enable extended debug


    ################################# Routing #####################################

    # =========================== request routes ==================================
    route {
        if (msg:len >= 2048 )  {
            sl_send_reply("513", "Message too big");
            exit;
        }

        if (loose_route()) {
            append_hf("P-hint: rr-enforced\r\n");
            xlog("L_INFO", "Loose Route\n");
        }

        if (!uri==myself) {
            append_hf("P-hint: outbound\r\n");
    #        xlog("L_INFO", "URI is not myself\n");
        }

        route(1);
    }

    route[1] {
    #   various debug outputs
        xlog("L_INFO","$C(yb)$cs $rm: mF=$mF, bF=$bF, sF=$sF$C(xx)\n");
        if (is_gflag("0")) {
            if(!t_check_trans()) {
                $var(trans)=$var(trans)+1;
                xlog("L_INFO","$C(gx)[ New Transaction ($var(trans))]$C(xx)\n");
            }
            xlog("L_INFO","\n\n$C(py)[  Method $rm from $si:$sp ($var(trans))  ]$C(px)\n$mb$C(py)[  End of Request ($var(trans))  ]$C(xx)\n\n\n");
        }

    #   use a non-generic reply route to be able to use transaction flags
        t_on_reply("1");

    ####################
    #   request to *   #
    ####################
        if (src_ip == <IPaddr_of_OCS_mediation_server>) {
            xlog("L_INFO", "~~~ OCS -> * ~~~\n");

    #       remove misleading CONTACT header line
            remove_hf("CONTACT");
    #        subst("/(CONTACT:).*/\1 <sip:$fu>/ig");     # use from address in contact header

    #       remove UTF-8 information, as * is not able to process it properly (causes RTP problem)
            subst("/^(CONTENT-TYPE:.*);[ ]*charset=utf-8(.*)/\1\2/ig");

    #       identify re-INVITEs
            if ((method == INVITE) && (search("^TO.*tag=.*"))) {
    #           mark INVITE (hold) for latter modification of the reply "200 OK"
                if (search("a=inactive")) {
                    xlog("L_INFO", "$C(rx)'a=inactive' found in INVITE!$C(xx)\n");
                    setflag(5);
                }
            }

    #       relay request to *
            if (!t_relay("udp:<IPaddr_of_*>:5060")) {
                xlog("L_ERR", "~~~ relay to udp:<IPaddr_of_*>:5060 failed!\n");
                sl_reply_error();
            }
        }

    ######################
    #   request to OCS   #
    ######################
        else {
            xlog("L_INFO", "~~~ * -> OCS ~~~\n");

    #       relay request to OCS
            if (!t_relay("tcp:<IPaddr_of_OCS_mediation_server>:5060")) {
                xlog("L_ERR", "~~~ relay to tcp:<IPaddr_of_OCS_mediation_server>:5060 failed!\n");
                sl_reply_error();
            }
        }
        exit;
    }

    # ============================= reply routes ==================================
    onreply_route[1] {
    #   various debug outputs
        xlog("L_INFO","$C(yr)$rs $rr ($cs $rm): mF=$mF, bF=$bF, sF=$sF$C(xx)\n");
        if (is_gflag("0")) {
            xlog("L_INFO","\n\n$C(bc)[  Reply $rs ($rr) from $si:$sp concerning $rm  ]$C(bx)\n$mb$C(bc)[  End of Reply  ]$C(xx)\n\n\n");
        }

    #######################
    #   reply back to *   #
    #######################
        if (src_ip == <IPaddr_of_OCS_mediation_server>) {
            xlog("L_INFO", "$C(cx)reply OCS -> *$C(xx)\n");

    #       remove misleading CONTACT header line
            remove_hf("CONTACT");

    #       remove UTF-8 information, as * is not able to process it properly (causes RTP problem)
            subst("/^(CONTENT-TYPE:.*);[ ]*charset=utf-8(.*)/\1\2/ig");
        }

    #########################
    #   reply back to OCS   #
    #########################
        else {
            xlog("L_INFO", "### * -> OCS ###\n");

    #       identify reply to call hold
            if (isflagset(5) && (status == "200") && (has_body("application/sdp"))) {
    #           add missing "a=inactive", as OCS expects it
                if (subst_body("/(m=.*\r\n)/\1a=inactive\r\n/")) {
                    xlog("L_INFO", "$C(rx)'a=inactive' inserted in 200 OK!$C(xx)\n");
                }
            }
        }
    }



    The fix for the call hold is done in two stages. First identify the RE-INVITE based on the tag value in the TO header of the INVITE request message and second to add the SDP media attribute "a=inactive" in the reply, which is needed by the OCS to correctly react on the confirmed hold action.

    Hope this helps for your setup...

    If you are also starting to do OCS CTI integration for the *, I'll be pleased to get information on that... Wink

    cheers & have fun
    -hugo
    Monday, May 19, 2008 12:33 PM
  • I work at a company that's developed a SIP/CSTA gateway for Asterisk and MS OCS.  It's a standards compliant TR/87 gateway that uses the Manager API in Asterisk and SIP to MS OCS.  It can be used for remote call control (CTI integration), location based forwarding and device monitoring.  Feel free to email me at amit.kulkarni@litescape.com if you have any questions.

     

    Amit

    Saturday, May 24, 2008 12:38 AM
  • pbxnsip is mentioned as one of the companies that support OCS in the thread and there are many companies running it successfully.   http://wiki.pbxnsip.com/index.php/Office_Communications_Server is a wiki page on how to set it up and http://forum.pbxnsip.com/index.php?showforum=37 is the forum page with feedback on customers using it. For an internal T1 card you can use an audiocodes TP260 gateway card  or sangoma T1 card with echo cancellation on windows only or any standalone SIP gateway.  You can get a trial of the software at www.pbxnsip.com/trial
    Monday, May 26, 2008 2:10 PM
  •  

    Thanks to all...

     

    This excellent article from Tom Keating pretty much sums everything up with regards to Asterisk <> OCS so far...

    http://news.tmcnet.com/news/-asterisk-with-office-communications-server-2007-/2008/05/27/3467535.htm

     

    In that article - Tom says

    "Lastly, I'm told that pbxnsip will have uaCSTA support very shortly. Although pbxnsip isn't Asterisk, it is another open source IP-PBX solution and a very feature-rich one at that"

     

     

    Is PBXNSIP open source?  There's a trial version on the website - but it looks like a commercial product with full licensing?

     

     

    Paul

    Tuesday, May 27, 2008 10:29 PM
  • if you have a PBX with T1 connection why not to use Basic Hybrid Gateway

     

    like a GW from AudioCodes

     

    Wednesday, May 28, 2008 12:52 PM
  • The existing PBX is very old - requires a full replacement.  Spares are getting rare & support is lacking...

     

    OCS / OC would be enough for about 50% of my users - they others need more, including call queuing...

     

    Paul

     

    Thursday, May 29, 2008 4:10 PM
  • Hi Paul,

     

    as you assumed, pbxnsip is not open source. The article lacks on some informations, that might be useful for some:

     

    • it also runs on Windows, not only Linux - you can run it on win2000, XP, 2k3, Vista, Server2008 (supports IP V6), (also on the Server-WebEditions)
    • beside the normal trial key, you can get a special trial key - permanent licence - with all features, but a 3 minute Call-Limit. Useful for showcases, demos, workshops!
    • it is open in terms of customization, customer wishes and offers endless features, interoperability
    • if you need help, the support is offered instantly and is very open for feature request
    • the learning curve with pbxnsip ascends steeply, you can get a running system within minutes - especially with OCS2007 and Exchange2007
    • ok, I will stop here , the list might become endless.

    From my own experience it is the ip-pbx that enables "windows"-admin-guys like me to run a pbx, without to much

    headaches Smile

     

    Best regards,

     

    Jan

    Thursday, May 29, 2008 7:44 PM
  •  

    Thanks Jan,

     

    Yes - PBXNSIP does look impressive & I've been reading the forums.  I like that it runs on XP which saves a lot over Windows server & it's easier to admin.

     

    I shall have to download it and test...

     

     

    I also see you are a 'guru' when it comes to intergrating PBXNSIP & OCS...

     

    You're a handy guy to know...  :-)

     

     

    Paul

     

     

     

    Thursday, May 29, 2008 8:17 PM
  • Paul,
    Glad you enjoyed the article. I incorrectly stated pbxnsip was open source. I went on vacation or I would have posted a correction earlier. In any event, I posted a correction to the original source article, which I'll also include here:

    "I mentioned pbxnsip was open source. This was due to a conversation I had with pbxnsip about them 'potentially' making their solution open source. They are currently not open source, however, I should point out that it is developed in C++ and is therefore easily compiled to run on multiple operating systems, including Windows, Linux, etc."

    It would be great if they did make it open source. I think they'd get a lot more media attention and attract developers.

    Cheers,
    Tom Keating

    Tuesday, June 3, 2008 4:57 PM
  • Hello Tom,

     

    I am pleased to see you posting here. Thank you  a lot for the correction. If I could ask you to enhance the link to your "full review of pbxnsip".

     

    At the moment the link directs to the small appliance CS 410. But your excellent review of pbxnsip is here:

     

    http://blog.tmcnet.com/blog/tom-keating/voip/pbxnsip-ippbx-review.asp

     

    In this review you mentioned a pbxnsip test done at Miercom. Do you know if the results, or parts of it are public available?


    Best regards,

     

    Jan

    Tuesday, June 3, 2008 6:21 PM
  • I linked to my pbxnsip appliance review over my standalone pbxnsip review because it was a newer article. But you're right, I should mention the standalone pbxnsip software, since not everyone wants or needs the turnkey appliance. So per your suggestion, I added this text to the top of the pbxnsip appliance review: "And be sure to check out my full review of the pbxnsip standalone software, which runs on Windows and Linux." So now they can read both reviews and decide which is best for them.
     
    >>In this review you mentioned a pbxnsip test done at Miercom. Do you know if the results, or parts of it are public available?
     
    Unfortunately, the results aren't public. But I have contacts at both pbxnsip and Miercom, so I'll see what results they're willing to divulge.
     
    The one "piece" of results they were willing to share with me, which I included in my article is as follows:
     
    Miercom, a partner labs for TMC's publications, tested pbxnsip and ran overnight benchmark/performance tests using a 3.4 Ghz Pentium D machine running Windows 2003 server. They were able to blast 60 simultaneous calls using WinSIP and encountered no errors. Considering the average 4 to 1 (busy-to-idle) call ratio, that would equate to a 250 seat IP-PBX system, which is pretty impressive.
    Wednesday, June 4, 2008 5:27 PM