locked
SIP Trunking - the ultimate solution? RRS feed

  • General discussion

  • First of all, despite the fact this solution works for me, it is up to you to perform tests for all futures that OCS offers and you intend to use. Take your time, test and when (if) you are sure that would work for you as well, run your test once again.

    Ever since OCS began emerging as possible VoIP solution, there were a lot of "Yey" and "Nay" within the VoIP community. We all have seen comments like:

    "Why SIP over TCP only?" - Well, on my opinion, the decision to use TCP is obvious - we want (at least I do) guaranteed delivery of every packet I sent across the network, Simple as this!

    "Why RT Audio only" - Microsoft is THE software developer and can do whatever they want. For me - another "Case closed, move on"

    "Why OCS SIP messages are so long and complicated?" - Well, if you want short and easy - get Vonage. OCS is a part of Unified Communications Platform meant to serve multiple futures and one should look the global picture...

    All those and other questions are simply complaints from either people that have nothing to do or "partisanship" - sworn Unix fens and/or current VoIP gurus that sees it as "Phew, another thing to research and learn if I want to stay on the top"!

    Where we were? Ah, yes, my pet project:-)

    Connecting OCS directly to ITSP is a pipe dream thus far. I ruled out this possibility immediately and have not spent more than 15 minutes total. However, I made the major mistake to research and try every "solution" ever posted on the Net involving known IP PBXs. Believe me - all of them. Time wasted! I was installing and trying open source software on Linux and despite the partial success somewhere inside my head the "common sense advisor" kept bugging me: "Why are you doing this? Will you accept a solution where another server is added, accounts are "duplicated" and most of all - you have to Google every command for THIS Unix/Linux platform!" The revelation come from my wife. She walked one night (4:30 a.m.) and said - "You either cut this ____ or..." "Or what?" I said. "Or... get the damn OCS manual and read it again" Gog bless her!!!

    Fact is, one must have a clear idea what is the goal. In my case, I wanted to:

    • 1. To be able to connect my fully functional OCS environment to the Public Telephone Network
    • 2. This connection to be a direct connection between my environment and ITSP
    • 3. The ITSP connection to be protocol independent i.e. TCP or UDP
    • 4. To be able to use not only "direct IP trunk" but also "dynamic registration" i.e. Vonage type

    Let's analyze this, shall we?

    1. The answer is use of Mediation Server role. Hmm, big discovery, ah? Well, I not only setup an Mediation and AudioCodes MP114 test environment, but spent some time analyzing what exactly is happening between the two. I was stricken by the fact that Mediation role not only "translates" the media but also is a "middle man" between the OCS (the SIP registrar) and AudioCodes (the media gateway). The sip messages were accepted by the Mediation and sent to OCS. From here to p.2 was a short thinking process:

    2. The SIP messages sent from AudioCodes to Mediation were nothing "extraordinary" ergo ANY standard SIP messages sent to Mediation would be accepted and passed to OCS. Took me a day or two to find several ITSP's that look promising, contacted them and made my pick based on the speed and professionalism of their reply. And the winner was... Broadvox.com. They agreed to set my test trunk TCP and shortly thereafter, I was running test environment with four concurrent calls and four DID's. I was right!

    Let's take a brake here. When we use Mediation server, after the successful negotiation, the RTP flows between the ITSP's front end (SBC/SoftSwitch/PBX.../Whatever!_we_don't_care) and our Mediation Server. So, to achieve p.3, we needed to add something more. This software must:

    1. a. Talk Sip over TCP and UDP
    2. b. Be able to "bridge" SIP over TCP/UDP (from our ITSP) to SIP over TCP (to our Mediation Server).
    3. c. Be able to register dynamically (username/password) and yet perform the "bridging" role
    4. d. Be a Windows based software
    5. e. Be able to co-exist with the Mediation on the SAME physical server.
    6. f. Works after all :-)

    This piece of software does exist, it is Open Source, and it works!

    I will stop here to take a breath and prepaire for the actial deployment example and discussion.

    Drago

    • Edited by Drago Totev Saturday, March 14, 2009 2:36 AM
    Saturday, March 14, 2009 12:31 AM

All replies

  •  

    The answer to our problem is an open source software called FreeSwitch. Please, don't rush to Google...yet :-) Here is a quote from their web site:

     

         "FreeSWITCH is an open source telephony platform designed to facilitate the creation of voice and chat driven products scaling from a soft-phone up to a soft-switch. It can be used as a simple switching engine, a PBX, a media gateway or a media server to host IVR applications using simple scripts or XML to control the call flow.

    We support various communication technologies such as SIP, H.323, IAX2 and GoogleTalk making it easy to interface with other open source PBX systems such as sipX, OpenPBX, Bayonne, YATE or Asterisk.

    FreeSWITCH supports many advanced SIP features such as presence/BLF/SLA as well as TCP TLS and sRTP. It also can be used as a transparent proxy with and without media in the path to act as a SBC (session border controller) and proxy T.38 and other end to end protocols.

    FreeSWITCH supports both wide and narrow band codecs making it an ideal solution to bridge legacy devices to the future. The voice channels and the conference bridge module all can operate at 8, 16, 32 or 48 kilohertz and can bridge channels of different rates.

    FreeSWITCH builds natively and runs standalone on several operating systems including Windows, Max OS X, Linux, BSD and Solaris on both 32 and 64 bit platforms."

     

    Believe - it is exactly what it is stated. I knew this software exist quite some time but never look on it seriously enough or... shall I say never had enough time to research and test it. However, after the success of my Interop certification with Broadvox, I could relax and spend 3 weeks on my "pet project".

    First of all, let's compare it to our "goal list".

    • 1. It DOES talk TCP and UDP
    • 2. It CAN work as a bridge
    • 3. It DOES support dynamic registration with ITSP
    • 4. It DOES have Windows version
    • 5. It CAN co-exist on the same physical server where Mediation Role is installed (this will be proven in the next post)
    • 6. It DOES work (call me at 478.387.4190 this weekend ONLY) to verify

    I know you are now eager to hit Google and you're right. Do some reading to get the concept and tomorrow we'll go back to the actual settings and "real life" working example.

    Cheers!

    Drago

    Saturday, March 14, 2009 1:10 AM
  • First step is to prepare our Mediation server.

    For this example, I'm using Mediation Server R2 role installed on virtual server. My host machine is dual quad core Xeon CPU's with total of 24GB of memory. The guest OS (Windows Server Standard x64) have 4 virtual CPU's and 4GB of memory assigned to it.
    This solution has been tested with four concurrent OCS to PSTN calls with very satisfactory result.

    My Mediation Server have three network adapters. I renamed them to reflect the purpose of each one.

    Here is an example setup: (you should replace the numbers based on you network layout)

    Adapter OCS:

    IP Address: 10.0.30.4
    Mask        : 255.255.0.0
    Gateway   : none (this is very important)


    Adapter GTW:

    IP Address: 10.0.30.14
    Mask        : 255.255.0.0
    Gateway   : none (this is very important)

    Adapter WAN:

    IP Address: your public IP here
    Mask        : your net mask
    Gateway   : your gateway

    Now, let's setup our Mediation Server:

    - Set you "Communication Server Listening IP Address" to Adapter OCS
    - Set your "Gateway Listening IP Address: to your GTW Adapter. Leave the port 5060
    - Select "Default Location Profile" for this server and apply the changes

    - Click the tab "Next Hop Connections"
    - Select your "Next Hop OCS from the list"
    - Type the IP Address of your GTW adapter for "PSTN Gateway Next Hop"
    - Enter port 5040
    - Make sure TCP is set for Transport

    This concludes the Mediation Server setup for our test.

    Drago

    Saturday, March 14, 2009 11:47 AM
  • We will now proceede to real live example. Please, read carefully and understand the steps before recreate them. Looks case censitive, so keep thi in mind as well.

    Next step is to install FreeSWITCH

    Read this first FreeSWITCH for Windows and then download the installer from this link.


    Navigate to the installation directory (C:\Program Files (x86)\FreeSWITCH). All changes will be made from here on and so, you might want to create a shortcut to it on your desktop...


    - Open folder C:\Program Files (x86)\FreeSWITCH\conf\directory\default and delete the entire content.

    - Open the folder C:\Program Files (x86)\FreeSWITCH\conf

    - Open the file vars.xml with text editor, scroll down to the bottom and edit the following block:

      <!-- Internal SIP Profile -->
      <X-PRE-PROCESS cmd="set" data="internal_auth_calls=true"/>
      <X-PRE-PROCESS cmd="set" data="internal_sip_port=5060"/>
      <X-PRE-PROCESS cmd="set" data="internal_tls_port=5061"/>
      <X-PRE-PROCESS cmd="set" data="internal_ssl_enable=false"/>
      <X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>

    to become:

      <!-- Internal SIP Profile -->
      <X-PRE-PROCESS cmd="set" data="internal_auth_calls=false"/>
      <X-PRE-PROCESS cmd="set" data="internal_sip_port=5042"/>
      <X-PRE-PROCESS cmd="set" data="internal_tls_port=5043"/>
      <X-PRE-PROCESS cmd="set" data="internal_ssl_enable=false"/>
      <X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>

    ***Mediation server will not attempt to authenticate before placing the calland so, we set auth_calls parameter to "false" to allow the call to pass trough.

    ***We change the the listenning port to avoid conflict

    ...and the block:

      <!-- External SIP Profile -->
      <X-PRE-PROCESS cmd="set" data="external_auth_calls=false"/>
      <X-PRE-PROCESS cmd="set" data="external_sip_port=5080"/>
      <X-PRE-PROCESS cmd="set" data="external_tls_port=5081"/>
      <X-PRE-PROCESS cmd="set" data="external_ssl_enable=false"/>
      <X-PRE-PROCESS cmd="set" data="external_ssl_dir=$${base_dir}/conf/ssl"/>

    to become:

      <!-- External SIP Profile -->
      <X-PRE-PROCESS cmd="set" data="external_auth_calls=false"/>
      <X-PRE-PROCESS cmd="set" data="external_sip_port=5060"/>
      <X-PRE-PROCESS cmd="set" data="external_tls_port=5081"/>
      <X-PRE-PROCESS cmd="set" data="external_ssl_enable=false"/>
      <X-PRE-PROCESS cmd="set" data="external_ssl_dir=$${base_dir}/conf/ssl"/>

    ***This sets the listenning port for your sip provider to the standard 5060.


    - Around the top, find the line: <X-PRE-PROCESS cmd="set" data="domain_name=$${domain}"/>
    ... and delete it.

    - Locate the lines:

    <X-PRE-PROCESS cmd="set" data="external_rtp_ip=stun:stun.freeswitch.org"/>
    <X-PRE-PROCESS cmd="set" data="external_sip_ip=stun:stun.freeswitch.org"/>

    ... ad change it to:


    <X-PRE-PROCESS cmd="set" data="external_rtp_ip=stun:stun.voxgratia.org"/>
    <X-PRE-PROCESS cmd="set" data="external_sip_ip=stun:stun.voxgratia.org"/>



    - Navigate to folder C:\Program Files (x86)\FreeSWITCH\
    - Open folder named "sip_profiles"

    - Open folder "external"
    - Delete the existing file (example.xml)
    - Create new text file "your_provider_name.xml"

    ***In my case I'm using "broadvox.xml". This is - to keep consistency in the naming convention in case I'll use more than one provider.

    - include the following content:

      <include>
        <gateway name="name_of_your_provider">
          <param name="username" value="none"/>
          <param name="password" value="none"/>
          <param name="caller-id-in-from" value="true"/>
          <param name="proxy" value="ip_address_of_your_provider"/>
          <param name="register" value="false"/>
          <param name="register-transport" value="tcp"/>
        </gateway>
      </include>

    Let's look thi line by line

    *** gateway_name is very important. This how the bridge will be established. Please for your sake use your provider's domain.
    *** Since I'm using IP trunk (no auth.) username and password are set to "none". You cannot use blank - nust be a string and so, just use "none"
    *** caller-id-in-from" means that the your Communicator will present the real Caller ID as it has been send from your provider.
    *** proxy is the IP address given to you from your SIP provider
    *** We set register to "false" becaus this is IP trunk and no auth. is required.
    *** Lastly and most important - the transport. Obviously you will use the type of transport your provider offers.

    - go back to C:\Program Files (x86)\FreeSWITCH\sip_profiles
    - Open folder "internal"
    - Delete the file "example.xml"


    - Navigate to folder C:\Program Files (x86)\FreeSWITCH\dialplan
    - Open folder "default" and delete all files within with exception of 9999_enum.xml
    - Go back to C:\Program Files (x86)\FreeSWITCH\dialplan
    - Open folder "public"
    - Open file "00_inbound_did.xml" and replace the content with the following:

      <extension name="incoming">
        <condition field="destination_number" expression="^(\d*)$">
          <action application="set" data="mediation=your_GTW_ip_address:5060"/>
          <action application="bridge" data="sofia/default/${destination_number}@${mediation};transport=tcp"/>
        </condition>
      </extension>
    </include>

    ***The expression adds "+" to the number which normalizes the number to E.164 format
    *** We set the IP Address of our Mediation server here so our bridge will know where to send inoming call.
    *** Finaly, we set the brigge itsef


    To start the application, locate and double click the icon named "FreeSWITCH.exe" on your desktop. You will see the progress in the command prompt window...
    To exit the application, type shutdown and press Enter or simply ... (three dots) and press Enter
    At this point, our environment should be ready to accept calls.

    Sunday, March 15, 2009 1:29 AM
  • Hi Drago,
    Great article. I am just curious you talk about putting a public IP on your Mediation Server. How do you protect this internet facing adapter that is on a machine that is a member of your domain?
    Thanks
    P
    Celtic
    Saturday, June 6, 2009 10:33 AM
  • Celtic,

    You are correct there could be concerns about exposing domain member to Big Bad Internet (smile). However, let's look the actual situation. A SIP Trunk provider will typically supply two or three IP addresses - one for signaling and one or two for RTP. So, on my Firewall, I have a rule to allow tcp/5060 from the signaling IP toward the Mediation public interface and UDP/media_range_ports from the RTP IP Address(s). This is sufficient for the call flow and yet assures protection.

    Drago

    Saturday, June 6, 2009 3:56 PM
  • Hey Drago,

    I have been following your posts for a while and this weekend I set up an OCS R2 environment with a BroadVox trunk. I have run into some initial problems and so far am unable to receive calls but am able to make calls. I am getting a message saying "This call cannot be completed at this time" I imediately called BroadVox and asked if they could tell me if it was making it through their system so i could determine if my mediation server was simply denying the connection. I am still waiting for an answer from them so in the meantime i thought i would recheck your posts to see if I could find anything that I may have done wrong.

    When I did I found this post I started to wonder if you had to use the method described above to get your BroadVox trunks fully operational?

    From your other post concerning connecting with Broadvox it sounds like it will work without doing the above. If it will work without using FreeSwith then my next question concerning OCS and BroadVox is why bother with the FreeSwitch at all? What benifits do you get from using the FreeSwitch product with your Broadvox trunks?

    Also in the above quote from FreeSwitch it mentions t.38. My next project after getting the OCS BroadVox trunk working is to set up outbound fax using the GFI FaxMaker product and to figure out how to send it over to BroadVox for termination. Is it possible to use freeswitch installed on the mediation server to bridge the t.38 output from faxmaker which runs on my Exchange server to Broadvox? Or do you know of someother ways to accomplish this?

    Thanks so much for the informative posts and I look forward to hearing from you,

    DRandle
    Sunday, June 7, 2009 12:18 PM
  • DRandle,

    Currently I have 7 SIP trunks with Broadvox, all pointed to Mediation servers throughout the state of Georgia in live environment. You must have configuration issues - most probably related to your firewall.

    There are three things to check:
    1. Your firewall must allow connections from their signaling IP on TCP/5060 toward the public interface of your Mediation server.
    2. Your firewall must allow connections from their RTP IP's on UDP toward the public interface of your Mediation server.
    3.  Broadvox does not have experience with OCS. However, you can ask them to make sure your trunk is set exactly as Trunk # 1000898 (one of mine) with exception of your ordination IP. This will assure all Broadvox settings are correct for OCS.

    Are you stripping the "+" on your end or you have asked them to do so? I insisted to be removed in their end so I don't have to worry about it, and so they did... Anyway, since you can make outbound calls, I will take that this is being taken care of.

    The FreeSwitch example above is for cases when one already have Trunk provider that does not offer SIP over TCP or offer dynamic registration only. I tested this scenario with Callcentric and works just fine.

    Finally, if you need assistance, you can federate with us. Our domain is gmc.cc.ga.us and my name is dragomir. You do the math :-) Or, give me a call. You can find my phone number here: http://www.gmc.cc.ga.us

    Finally, I have not worked on T.38 yet. Since we have many fax machines that MUST continue to be used, I will use another Broadvox trunk pointed to 3CX server and ATA devices. This will reduce my cost from $1000/mo to approximately $85/mo.

    Good luck,

    Drago

    Ah, might be worth mention - we are using Snom300 phones with OCS edition firmware in our live environment...
    Sunday, June 7, 2009 6:01 PM
  • Drago,

    Thanks for the reply.

    I got the trunk working, turns out i mistyped the tel URI setting on the test user I was trying to call so when I called the DID OCS was not finding it and inturn denying the connection.

    I will continue to work on this over the course of the next few weeks and will probably be looking into the fax options this weekend I am sure as I get ready to put this into preproduction I will have some questions for you.

    Again thanks so much for your help,

    DRandle

    Monday, June 8, 2009 3:24 PM
  • Hi,

    I'm also setting up OCS 2007R2 SIP Trunking with Broadvox, and am having a problem similar to DRandle.  I'm able to make outbound calls, but not inbound.  I do have the user's tel URI set up properly (tel:+1xxxxxxxxxx).  And rather than getting a "call cannot be completed" message, I'm just getting a busy signal.  If I enable logging on the medation server I don't see any activity.  And if I disable the firewall I get the same behavior, so I don't think that's the problems.  I have a support request into BroadVox, but if anyone has experience with this behavior, I'd appreciate hearing from you.

    Thanks :)

    Dave

    Monday, July 13, 2009 9:26 PM
  • Dave,

    Are you setting up Trunk on the new platform Broadvox is tesing or their current service?

    Drago
    Monday, July 13, 2009 9:56 PM
  • Hey Drago,

    I have been fighting this for a few weeks and I can't seem to get this final piece..
    1st and foremost I want to thank you for your post, I think you might be the ONLY person to get this going out there and actually post about how you did it.. IT's much appreciated.

    My setup here is OCS2007R2 using a SIP trunk that is being provided by an AVAYA pbx.  The PBX is local to our network with a T1 from a local provider providing PSTN access.

    The Mediation server has 1 Nic..

    I've managed to get the incoming calls to work but I'm having trouble getting the outgoing calls to complete.  I believe that I have some sort of issue with my dialplan..
    And one question that I have about your config was that you changed the default ports in the VAR file to 5042 and 5043  Yet you have your destination port for OCS being 5040 on the PSTN??  Whenever I did this, I never saw ANY activity on the bridge when I made outgoing calls.  Was that a typo?  I certainly am WAY new to freeswitch, so I could have missed it, but I didn't see anything listening on 5040....  So as you see in my configs I am pointing my PSTN gateway to the OCSbox insself on 5060 which is the default port setup in the vars for Freeswitch..

    I would appreciate ANY help you could possibly give.. I BELIEVE that I just have a dialplan messed up.. I'm not sure how to reference the trunk on the outgoing call... The only difference I really see is that your using and external provider and I'm not.. I have commented out the stun settings in the VAR file as well..

    Please let me know if you have any suggestions on what I can do here...  Thank you...

    When I make outgoing calls from OCS I get this...

    2009-07-13 22:42:03.335476 [NOTICE] switch_channel.c:602 New Channel sofia/external/+16023662981@OCSMediation.lcslab.root [49c2d8cb
    95ed-cd41-84bc-fba329e15026]
    2009-07-13 22:42:03.351062 [INFO] mod_dialplan_xml.c:252 Processing +16023662981->+16023215107 in context public
    2009-07-13 22:42:03.351062 [NOTICE] switch_core_state_machine.c:179 Hangup sofia/external/+16023662981@OCSMediation.lcslab.root [CS
    EXECUTE] [NORMAL_CLEARING]
    2009-07-13 22:42:03.351062 [NOTICE] switch_core_session.c:1085 Session 2 (sofia/external/+16023662981@OCSMediation.lcslab.root) End
    d
    2009-07-13 22:42:03.351062 [NOTICE] switch_core_session.c:1087 Close Channel sofia/external/+16023662981@OCSMediation.lcslab.root [
    S_DESTROY]
    S_DESTROY]

    This is my configuration.
    OCSMediation Server     10.8.215.90
    AVAYA PBX SIP TRUNK  10.8.215.110 on 5060 TCP       

    Communications Server listening IP address:
    10.8.215.90
    Gateway Listening IP Address
    10.8.215.90  5070
    PSTN Gateway next hop.
    10.8.215.90  5060

    Vars.xml
    <!-- Internal SIP Profile -->
      <X-PRE-PROCESS cmd="set" data="internal_auth_calls=false"/>
      <X-PRE-PROCESS cmd="set" data="internal_sip_port=5042"/>
      <X-PRE-PROCESS cmd="set" data="internal_tls_port=5043"/>
      <X-PRE-PROCESS cmd="set" data="internal_ssl_enable=false"/>
      <X-PRE-PROCESS cmd="set" data="internal_ssl_dir=$${base_dir}/conf/ssl"/>

     <!-- External SIP Profile -->
      <X-PRE-PROCESS cmd="set" data="external_auth_calls=false"/>
      <X-PRE-PROCESS cmd="set" data="external_sip_port=5060"/>
      <X-PRE-PROCESS cmd="set" data="external_tls_port=5081"/>
      <X-PRE-PROCESS cmd="set" data="external_ssl_enable=false"/>
      <X-PRE-PROCESS cmd="set" data="external_ssl_dir=$${base_dir}/conf/ssl"/>

    sip_profiles\external\avaya.xml

    <include>
        <gateway name="avaya">
          <param name="username" value="none"/>
          <param name="password" value="none"/>
       <!-- <param name="realm" value="lcslab.root"/> -->
          <param name="caller-id-in-from" value="true"/>
          <param name="proxy" value="10.8.215.110:5060"/>
     <param name="expire-seconds" value="120"/>
          <param name="register" value="false"/>
          <param name="register-transport" value="tcp"/>
        </gateway>
      </include>

    \conf\dialplan\public\00_inbound_did.xml

    <extension name="incoming">
    <condition field="destination_number" expression="^(\d*)$">
    <action application="set" data="mediation=10.8.215.90:5070"/>
    <action application="bridge" data="sofia/default/${destination_number}@${mediation};transport=tcp"/>
    </condition>
    </extension>
    </include>

    \conf\dialplan\default\99999_enum.xml

    <include>
      <extension name="enum">
        <condition field="${module_exists(mod_enum)}" expression="true"/>
        <condition field="destination_number" expression="^(.*)$">
          <action application="transfer" data="$1 enum"/>
        </condition>
      </extension>
    </include>
    Tuesday, July 14, 2009 5:48 AM
  • Nonek,

    After all, this is OCS community and we shouldnt water down the discussion with non-Microsoft topicks :-)

    Please, get with me here: drago at windstream dot net or federate: dragomir at gmc dot cc dot ga dot us and we'll go from there.

    Drago
    Tuesday, July 14, 2009 12:06 PM
  • Hi Drago,

    I'm not sure - the trunk was built just yesterday, but they didn't say anything about the new platform and I didn't know to ask.  I'll see when I speak to them today...  Thanks!

    Dave

    Tuesday, July 14, 2009 2:00 PM
  • Dave,

    The reason I am asking is - they do not have yet R2 official service. We are running interop as we speak. Anyway, if you have been told that will test R2 trunk, then the setup is a littel complicated. On your firewall, you have to allow a subnet, not single IP address. For example - insted of 208.93.224.224 you must allow 208.93.224.224/28 inbound from Broadvox.

    Drago
    Tuesday, July 14, 2009 2:13 PM
  • Hi Drago,

    I just got off the phone w/ Broadvox - they didn't have our account set up for TCP.  So that fixed the busy signal and our mediation server is now seeing the call.  However, calls are aparantly not getting routed properly (Broadvox is seeing a 404 error returned on their end), so I need to figure out what's going on with that.  Thankfully the mediation server is logging a bunch of information about the call, so hopefully that will help me figure out what's going on.

    I did ask about the "new platform", and he seemed to think I was talking about FreeSwitch, which they are rolling out soon.  So it seems we are on the old service.

    Thanks again!
    Dave
    Tuesday, July 14, 2009 4:07 PM
  • Correct. The FreeSwitch based service is not in Production yet.

    I would not advice you to use Mediation R2 with the current Broadvox service. You will run to the probmem with Early Media / Ringback issue desctibed in an active discussion here. Use R1 instead if you cannot wait.

    If you have Edge, ring me and I could take a look in your settings.

    Drago

    Tuesday, July 14, 2009 4:43 PM
  • Drago,

    I fixed the error - It turned out to be a "404 No matching rule has been found in the dial plan for the called number." (took me a little while to figure out exactly which traces to run in the logging utility).  So I added a normalization rule to translate Broadvox's 10-digit number to E.164 format (+1xxxxxxxxxx).

    So we're now able to make both inbound and outbound calls.  About running the R2 version of the mediation server - I'm not sure the ring back issue will be a problem for us because we're not going to be using DIDs... instead we'll be using the Response Group service to drop calls into a queue.  That's the next thing to work on.  But if for some reason I have to, do you know if I can have both the R1 and R2 mediation servers installed on the same box?

    Thanks again for all your help - it is appreciated :)

    Dave
    Tuesday, July 14, 2009 8:25 PM
  • You cannot, buddy.

    Drago
    Tuesday, July 14, 2009 8:31 PM
  • OK, we'll give it a shot w/ R2 and if it doesn't work out, then uninstall and try R1.

    Thanks again :)

    Dave

    Tuesday, July 14, 2009 8:48 PM
  • Broadvox is making the new service available next week.  The salespeople are not real aware of it at this point.  Ask your salesperson to contact Eliot Gable and he will get them straight on what you need.  The down side is  that their new tech notes are not yet complete but we found the implementation to be simple.  The most involved part was opening up ISA for the army of potential IPs where content can originate.

    If you have any questions let me know. 
    Thursday, August 6, 2009 3:09 PM
  • Hi Drago,

    You should have work for Evangelyze, because they sell a product call SmartSip which use a configuration of freeswitch to enable SIP trunk in UDP for OCS !
    Thanks for publishing a similar config for free !


    You can do the same with other free product like Asterisk by configuring a trunk in TCP to OCS and another to a sip trunk provider in UDP. 

    But The great thing is that Freeswitch is available for Windows platform and seems to be lighter than Asterisk in a config.
    I will do some performance test using your freeswitch config and a asterisk config to see what is better !

    You can have a look at my blog for the configuration :
    http://blog.unifiedcommunications.eu/08/using-asterisk-to-pass-and-receive-sip-calls-from-microsoft-ocs-to-a-sip-trunk-in-udp/

    yann

    Thursday, August 6, 2009 5:23 PM
  • Yann,

    Since you started… SmartSip is a re-compiled version of FreeSwitch. Having said that, I don’t want to underestimate the amount of effort end development  Evangelyze invested in doing so and after all, when you buy their product, you also buy peace of mind in regard of customer and technical support.

    This is very similar compared to Linux world – one can elect to have the community version and relay on community support, while another - paid version. There is enough space under the sun for everybody...

    I have promissed already to have a manual and pre-configured downloads of FreeSwitch <-> OCS by the end of August (hope nothing bug will bump thus project). Once done, I will post the link here on this community.

    Drago
    Thursday, August 6, 2009 6:30 PM
  • Drago,

    I just wanted to say thanks for your help here (and in other posts) - as of yesterday we have our customer service center up and running on OCS w/ Broadvox.  Working well so far!  And the ringback issue turned out to be a non-issue as I suspected, since we're using Response Group and Auto Attendant for all incoming calls.

    Thanks again :)
    Dave

    Friday, August 7, 2009 2:36 PM
  • Drago,
    Its been a while since you last saw SmartSIP - our architecture changed a little since the beta. Actually we now use a relatively plain vanilla install of FreeSWITCH and use the Event socket interface to do our integration. We are also considering supporting other soft siwtches (like Asterisk) for certain use cases such as Skinny and Nortel protocol support.
    SmartSIP is really focussed more on simplifiying the OCS integration and endpoint managment in the large enterprise space. Handling features that you would need to replace a legacy PBX with OCS. For example we have a TFTP provisioning server which dyanmically merges templates with user profile information from AD/OCS. Also we allow dynamic (and multiple) DID mapping to users using AD properties to map back to the OCS line field - eliminating all th eheadaches with an internal extension dial plan vs using the DID in the line field. We also do smart logic on inbound calls such as diverting calls from your cell phone to your office number directly into the exchange voicemail subscriber access. We also set Caller ID outbound for conference invitations and other advanced routing.
    And yes, of course we support the overall solution as commercial application...
    Simon.
    Simon B .::. Unified Communications | Collaboration | Gadgets | www.evangelyze.net. Please mark forum responses as answers if they help you out. Thanks!
    Wednesday, August 12, 2009 1:08 PM
  • Simon,

    I totally agree with you that SmartSip is indeed different and better for its purpose than plain implementation of FreeSwitch. As you have noticed, I did not attack (nor I will) the base of SmartSip.

    I am trying to help colleagues that are eager to test basic functionality of OCS in relatively small environment with little to none support from the management. I had a chance to mention already that due to the lack of support I charged my personal credit card for Tanjay, Snom, Audiocodes, ATA devices, signed up for a trunk service etc just to continue the journey… Although my institution is now 100% EV, I’m still paying for “my sins”.

    Should I have proposed 400 Tanjay devices + SmartSip + SmartSip licenses + all the kinks, this project would never leave ground. Of course, this is specific for my situation. Many others will find you product affordable and as expansion of the current OCS capabilities.

    SmartSip is an excellent product and as a former DB developer I admire your team’s skills and efforts  to create one wonderful add-on to current OCS capabilities.

     

    Drago

    Wednesday, August 12, 2009 1:36 PM
  • Drago,
    We appreciate your support - just to clarify that SmartSIP does not require Tanjay devices, in fact it allows you to register generic SIP devices & softphones in an EV scenario with full precence and direct communicator - communicator calls with non-ev users.
    Simon.


    Simon B .::. Unified Communications | Collaboration | Gadgets | www.evangelyze.net. Please mark forum responses as answers if they help you out. Thanks!
    Wednesday, August 12, 2009 3:41 PM