locked
Re-routing SIP messages from OCS --> Proxy ---> Mediation Server RRS feed

  • Question

  • Hi there,

    I did post this on another sub-thread but got no reply, so this may be the correct place.

    I am attempting the following:

       OC Client makes a call (VOICE)
       OCS Sever Routing (Next Hop) is pointing to the Proxy Server.
       Proxy Server uses Microsoft.rtc.sip Namespace SDK to manipulate these SIP
       Messages to do the following:
                      VOICE is redirected via URI manipulation (adding MAddr, Transport type 
                      (TLS)) to the Mediation Server.
                 OC Client --->OCS Front End --> Proxy ---> Mediation Server ---> SIP End PT

      The message is sent out from the Proxy ok, but then is swallowed for want of a better word
      once it gets to the Mediation Server (which it is to pass it onto our SIP end point).
       (No relevant logs on the Mediation Server, no real response from it back to the Proxy either) - Need Proxy for load balancing

    I have analyzed the SIP messages coming from the OCS to the Mediation server (normal operation) and the ones that I have sent from the Proxy .. only difference is the URI, So I cannot understand what is wrong here. I assumed on a SIP message (which originated from the OCS) would be passed on as normal, but it seems the Mediation Server does not like it coming from the Proxy ..... Analysis of the Mediation Server is difficult due to MTLS/TLS being required and so looking on the wire has no benfit to see what is happening.

    Any ideas, clues , help , guidance ... anything Smile) ...

    What I do:
              (Orig INVITE  uri)
              Request: INVITE sip:xxxx@sipccocs.com
              (Manipulated to re-direct to Mediation)
              sip:xxxx@sipccocs.com:5061;maddr=XX.XXX.XXX.XX;transport=TLS

    and that is all.... I am no expert in TLS/MTLS so any info would be grateful if you know what is wrong here



    Wednesday, June 6, 2007 12:52 PM

Answers

  • Sorted it out ..... FQDN instead of using IP address for MAddr
    Thursday, June 21, 2007 2:52 PM

All replies

  • Hi Eoin,

     

    Using OCSLogger on the Mediation Server helps a lot.

     

    Regards,

    Dieter

    Thursday, June 7, 2007 10:20 AM
  • Thanks for the reply Dieter,

    I have tried OCSLogger, but on the Mediation Server it does not report on the SIP Messages being presented to it. I believe "SIPStack" is the tracking element/trace used when OCSLogger is on the OCS server itself but the Mediation server has no SIP stack to report on. So I cannot see what is happening the SIP message when it enters the Mediation server.

    I have attempted to use WireShark to look at the messages being passed but again Certificates (pem) files on WireShark does not work when translating from TLS using the Public key for some reason.

    Unless there is something else in OCSLogger I can use that you know of ?

    Eoib
    Friday, June 8, 2007 7:41 AM
  •  

    Hi Eoin,

     

    You can use the mediation server component.

    There you can see the SIP messages.

     

    Dieter

    Monday, June 11, 2007 9:28 AM
  • Use the OCSlogger tool to get SIPStack logs on the Frontend and Proxy server and on the Mediation server get the Mediation Server log and on the client get the communicatoruccp.log file.  This way we can track the packet from the client to the Mediation server.  You can then post logs for review.

     

    Louis H

    Wednesday, June 13, 2007 11:41 PM
  • Thanks for that.

    I have changed the goal posts since my last post.

    I am now running on the OCS FE and removed the Proxy server from the set-up. But I am getting the same results.

    As before my code detects the SIP messages (INVITES) , but now all I do is pass the SIP INVITE through my code, in other words I have not modified it in any way.  I still get the same results - No logs on the Mediation server.

    So I am assuming (mainly because I have no real indication of what is happening) that the unmodified SIP INVITE is either:
                 1. Not being handled by the OCS routing rules after pass thru my code (which I    
                    hoped it would be) 
                 2. TLS connection cannot be established for whatever reason.

    So I then decided to put back in place the code to modify the URI (as before - orig post) but now it is being run on the OCS FE. I get the same  results as if it was run on the Proxy. So it seems to point to the code / modified invite not being able to handle TLS.


    Any advice ?







    Monday, June 18, 2007 9:26 AM
  • Sorted it out ..... FQDN instead of using IP address for MAddr
    Thursday, June 21, 2007 2:52 PM
  • Hi Eoin,

       We are trying to setup an application proxy in our test lab.

    I have a few questions about the same.

    I setup the proxy using the command line server.msi SERVER=PROXY.

    The problems I faced were

    1. Unless I add the fqdn of the OCS home server as a trusted server in the routing Host authorization tab in the Application proxy, the proxy does not communicate.

    2. Unless I add the fqdn of the Application proxy as a trusted server in the routing Host authorization tab in the OCS home server the TLS communications were not successful.

     

    Now after adding the fqdn of the Application proxy as a trusted server in the routing Host authorization tab in the OCS home server , I get an event saying the fqdn is configured in two roles a) Proxy server b) Trusted Host. I also complains about two GUIDs.

     

    Am I doing something wrong here.

    It would be of great help if you could jot down the process to setup a proxy.

     

    Regards,

    Vik

    Monday, June 25, 2007 8:58 AM
  • Hi Vik,

    If you are talking about the MS Proxy server (and not writing your own as I am attempting) then I only followed the normal installation as you have done
                    
    server.msi SERVER=proxy  or
                  
    SetupSE.exe /ONELINESETUP /INSTALLStick out tongueROXY


    and then activated it via

    Activate FP on domain:       lcscmd /server /password:<password> /action:activate /roleStick out tongueroxy

    Activate FP on workgroup    lcscmd /server /password:<password> /action:activate /role:workgroupproxy


    Deactivate FP on domain:    lcscmd /server /actionBig Smileeactivate /roleStick out tongueroxy

    Deactivate FP on workgroup:  lcscmd /server /actionBig Smileeactivate /role:workgroupproxy


    and then configured it via Comp Management MMC. But it sounds like you have this in place aready.  I just checked my system, I have the OCS FE as a trusted server on my Proxy server and then I have the Proxy in the OCS trusted node (both IP and FQDN).


    But I was not using the proxy routing as I had written an app that did that for me, so I have now removed the proxy from the configuration as my routing app works on the OCS FE itself. Maybe one of the MS guys would know what is wrong here, sorry


    Eoin







     


    Monday, June 25, 2007 12:22 PM
  • Apologies for the smilies faces .... don't know what happened there - must be some symbol conversion when I pasted in the lines
    Monday, June 25, 2007 12:55 PM
  • Hello

     

    1. What type of PSTN gateway are you using? Goes it have the IP address of the external interface for the Mediation server listed as its internal proxy address?

     

    2. The internal NIC on your OCS 2003 server should have a next hop address of the FQDN of the OCS 2007 pool or Proxy (OCS 2007 Director)

     

    3. The external IP address of the Mediation server will have a next hop address of the PSTN Gateway's IP address. You can also specify anf Default Location Profile you are using for the pool here.

     

    4. Have you tested the Mediation server by using the Pool FQDN as the next hop address for the internal NIC (just as a test)

     

    5. From the OCS Access server you can set up OCSLogger logging for OutboundRouting and InboundRouting and then try to place the outbounf VOIP call. This will provide you with some literal information in regard to the failure.

     

    6. If you would like please attatch the logs to this post or provide me with an email addess that I can reply to so you can email the logs to me for review.

     

    Thanks,

    Monday, June 25, 2007 7:18 PM