locked
Help with voice scenario - not sure of options RRS feed

  • Question

  • Hi  all,
              I have an OCS 2007 R2/Exchange 2010 integrated environment and an audiocodes MP114

    Previously, i had it all setup so i could make external calls from my OCS client - but never quite ghot incoming calls routing properly.

    Now i have ditched all my PSTN lines and have one VOIP number directly with my ISP. I've been testing this number via my DSL model (which has an ATA built in) and via softphones and it works fine. So the next step is, to try and integrate this with OCS.

    I've been looking around for doco on how to setup a SIP trunk on the mediation server... but all i can find is lots of "ra ra" ____ on how great sip trunks are (and dont get me wrong, the concept is good) - but nothing on whewre you actually configure it.... on the mediation server i cant see anything to do with sip trunk config... I'm guessing that i wont be able to register a single endpoint - but i thought i could at least check.... can anyone offer advice here?

    Nest step - assuming i cant register a single end-point as a trunk... does anyone know if it possible to use this scenario with my audiocodes MP114 ? Have my ISP SIP proxy registered, and the mediation server registered and route between the two ?
    Monday, February 22, 2010 9:14 PM

Answers

  • You can use Broadvox SIP truncks with OCS, They have Documenntation and support available.

    They support SIP over TCP.

    You can use a device like an Ingate Siparator and connect this to you trunk and route call to OCS Mediation as well.

    Audio Codes also supports IP to IP  routing, I am not sure if the MP114 Is supported for this feature You would need to check the Audio Codes site for this. This is an Add-On feature to the gateway you must pay for. This would allow you to use a provider that dosent support TCP the Audio Codes would convert UDP to TCP and route it to the mediation server.

    I have deployed all three of these scenerios and prefer the Ingate Device or Audio Codes Upgrade to support IP to IP routing.

    If you want contact info and Documenation for Broadvox you can reach me at keith @ gotuc.net or contact them directly http://www.broadvox.com

    Like chris said for Direct SIP you put the Next Hop IP as your ITSP gateway, They might require a VPN or have an access list allowing only the IP of your Mediation server through. Broadvox will forward all SIP traffic to an a Public IP you provide them, this would be the IP of your mediation server.
    • Marked as answer by Ben_22 Wednesday, February 24, 2010 5:05 AM
    Monday, February 22, 2010 10:43 PM

All replies

  • The only configuration you have is the the same as you had with your MP114. You define the next hop gateway this will be your ITSP details. It is unlikely it will work unless your ITSP has tested and verified OCS connectivity. You should ask them for the configuration details. The alternative is to put another gateway (the MP114 won't do this) inbetween to modify the SIP trunk to the format that the mediation server is expecting.
    Chris Clark - | MCTS:OCS | MCSE | MCSA | CCNA
    Monday, February 22, 2010 9:35 PM
  • You can use Broadvox SIP truncks with OCS, They have Documenntation and support available.

    They support SIP over TCP.

    You can use a device like an Ingate Siparator and connect this to you trunk and route call to OCS Mediation as well.

    Audio Codes also supports IP to IP  routing, I am not sure if the MP114 Is supported for this feature You would need to check the Audio Codes site for this. This is an Add-On feature to the gateway you must pay for. This would allow you to use a provider that dosent support TCP the Audio Codes would convert UDP to TCP and route it to the mediation server.

    I have deployed all three of these scenerios and prefer the Ingate Device or Audio Codes Upgrade to support IP to IP routing.

    If you want contact info and Documenation for Broadvox you can reach me at keith @ gotuc.net or contact them directly http://www.broadvox.com

    Like chris said for Direct SIP you put the Next Hop IP as your ITSP gateway, They might require a VPN or have an access list allowing only the IP of your Mediation server through. Broadvox will forward all SIP traffic to an a Public IP you provide them, this would be the IP of your mediation server.
    • Marked as answer by Ben_22 Wednesday, February 24, 2010 5:05 AM
    Monday, February 22, 2010 10:43 PM
  • thanks for the responses guys.
    So basically in order to use SIP trunking the remote provider needs to specifically support sip trunking from OCS. Support (from a mediation server) for connecting up to standard VOIP accounts would be a real nice feature for smaller places, that only want to have a couple of incoming numbers... but alas - i realise this is unlikely to happen. I cant imagine this would be too difficult, a sip proxy, logon details etc to register - then just the routing.

    Thanks for the info on the audiocodes keith... im not overly keen to fork out for another box.... as this is for a test/demo environment - not a  corporate production gig - so ill look into the audio codes add-on.
    Monday, February 22, 2010 11:21 PM
  • Ben,

    We at Georgia Military College have 7 SIP trunks with Broadvox (GMC is 100% OCS EV since April, 2009). I can assist you with contact information and/or setup. Drop me a note if you need help.

    Drago
    http://ocsdude.blogspot.com | MVP Snom OCS Edition
    Tuesday, February 23, 2010 12:29 AM
  • Ben
    If this is a test demo environment then the cheapest option is to stick with the MP114 if it has some FXS ports and just plug a phone in. Otherwise look at a freeware pbx like Asterisk or even Cisco do a free limited version of CUCM. There are a number of smaller companies which provide a cheap SIP trunk which although not approved will work. The scenario you describe using a proxy and logging on is not really SIP trunking this is more commonly used for logging on an IP phone to an "IP PBX".
    Chris Clark - | MCTS:OCS | MCSE | MCSA | CCNA
    Tuesday, February 23, 2010 11:00 AM
  • Hey Chris,
                 i know what your saying about the PSTN, but really, fixed lines are going the way of the dodo, fax machines and cheques... (or if your a yank, checks) - and im not a fan of encouraging this ancient rubbish to stay around needlessly. In additional, in Aus we only have one telco infrastructure provider (even if you go with another company, Telstra still is involved) - and dealing with them is a nightmare - and something any sane individual would get out of as quickly as possible. So yer, i just got rid of my last PSTN lines so i wouldn't have to deal with those peanuts. 

    I was aware of asterisk, but not that there was a free version of CUCM.... thats interesting - i might go have a look for that.
    I hear what your saying about the differences between a SIP trunk and just logging an extension onto a IP PBX. If MS is trying to move people away from using analog interfaces anywhere (which i would think is the case - it can only benefit them) - perhaps allowing people to register a small number of endpoints without a trunk would help speed adoption - especially for smaller customers. In a world where we all use our mobiles anyway, i, for example, only want 1 line coming into my business, and then have the call routed based on IVR. The volume will be low - as all our regulars just call our mobiles direct. Am i missing some type of technical issue that would make that not feasible? I mean, trunk or endpoint, as long as the routing is correct - its still going to work.

    Anyhoo - going off track.... thanks for the replies all - i will look into the various solutions suggested.
    Wednesday, February 24, 2010 5:19 AM
  • Cheques are what I understand;)

    I think you are being uneccessarily harsh about fixed lines being rubbish. SIP is still not "always" a high quality product and in most cases a fixed line will be a far superior product. However for cost saving ease of provisioning (possibly not configuration) then SIP sometimes fits the bill. You need the right tool for the job at the right price and that means keeping an open mind.

    Microsoft are not moving people away from tradition TDM interfaces they have chosen to keep their architecture as simple as possible by using 3rd parties to provide the interfaces. Microsoft is not a hardware company so the manufacture of Microsoft badged analog, T1/E1, phones and other interfaces would never (dangerous word I know) happen. If you can manage with 1 line then that is fine but it will need to be a trunk not an endpoint.

    Your plans are fine you just need the right SIP trunk.

    Good luck with the project but remember if you go down the approved providers route then you will have a lot of support but trying to find a cheap SIP trunk provider may work out more expensive in the long run if you don't have the ongoing support. Fine for a lab or proof of concept but if your business relies on it you need a supportable solution.
    Chris Clark - | MCTS:OCS | MCSE | MCSA | CCNA
    Wednesday, February 24, 2010 10:23 AM
  • hey chris,
                  i get what your saying - and understand - but doesn't mean that i dont think other options are viable.... whether or not they actually happen is another matter. I spose i like to put them out there and ask the question as to why they not around.... ofcourse the primary driver for MS and other places is the business, not technical...

    MS ventured far enough into hardware with round-tables.... and with the snom endpoints, we now have a reasonably priced alternative to polycom ocs endpoints... but yes, i dont expect MS to provide the hardware... but more options could be provided via the software.... we'll wait on the details of OCS 2010 to see which of them have made it.... the survivability stuff is cool.... but we'll see what else actually makes it.

    In regards to the fixed lines - can we at least agree that telco's are dragging their heels so as not to errode their traditional revenue base ? (at least until they work out their charging models for current technologies... especially when telstra would charge $20k+ for a single dial in bridge that OCS now offers out of the box). I have now, and will continue to have un-realistic expectations of companies based on technology rather than the real world :-)

    Anyhoo - i do like your points chris - they are interesting - its definately a different point of view/angle to my own - but presented well.



    Wednesday, February 24, 2010 11:59 AM
  • Different points of view drive innovation. What I normally recommend on here is the safe route because if people are asking a question about streatching the technology they probably aren't ready to do it. If I'm face to face with the customer I go through all the options to guage the level of risk they are willing to take in a project and make sure they are willing to accept any risks.

    As vendors modify their products to integrate more with OCS we will see a lot more choice. The important thing to remember is voice is a mission critical application in most businesses and if the if the CEO of a major organisation picks up his Communicator phone and doesn't get dial tone or has a poor quality call with a large customer he is not going to be happy. I've seen that happen on day one of a traditional PBX vendor VoIP rollout and there are a lot of scared frantic people running round.

    There are a number of possible points of failure in an OCS telephone call and the quality and availability is only as good as its weakest link. A narrow band phone, a SIP trunk on a congested internet link, a underspec'd virtualised mediation server, no resiliance etc can all lead to poor quality calls and outages. As a company you need to decide if they are acceptable risks you are willing to take to save on the project cost. For a smaller organisation like yourself who would never pay the price for a Cisco Call Manager you are trying to implement a product that will perform as well as CUCM but only if you invest in the hardware, planning and infrastructure. OCS is a much more network resilient product than CUCM but you still need to evaluate your deployment to minimise the risks.

    On the telephony side I would expect Microsoft to be looking at what big corporates want and build functionality to support their requirements going forward. Although more confgurability and options will come for the smaller deployment size end of the market the aim will be competitive with the major PBX vendors. 

    Sorry for rattling on here but just want to make sure you get the best deployment you can.


    Chris Clark - | MCTS:OCS | MCSE | MCSA | CCNA
    Wednesday, February 24, 2010 1:05 PM
  • Did you get this to work?

    Can you provide details?


    CarolChi
    Friday, March 18, 2011 4:20 PM