locked
Mediation Server with 2 NIC's RRS feed

  • Question

  •  

    Hi Thom,  Mike,

    Forum members,

     

    I've changed my configuration for the Mediation Server with 2 NIC's like documented in the Public Beta and suggested (http://forums.microsoft.com/Ocs2007publicbeta/ShowPost.aspx?PostID=1573167&SiteID=57).

    But now I have a routing problem, when making outbound calls. The gateway cannot disconnect the call.

     

    Topology:

    * MOC : 192.168.2.A

     

    OCS :

    * IP: 192.168.2.B

    * FQDN: artademoocs.artiliumdemo.local

     

    OCMediation: 192.168.2.C ( port) and 192.168.2.D (Gateway Listening port)

    * Communications Server listening IP: 192.168.2.C

    * Gateway listening IP: 192.168.2.D

    * FQDN: ArtaDemoOCMed.artiliumdemo.local

     

    Gateway:

    * IP: 192.168.2.E

     

    Outbound call (MOC->Gateway)

     

    The INVITE is forwarded by the Mediation Server to the Gateway on NIC with IP 192.168.2.C

    and with CONTACT: <sip:ArtaDemoOCMed.artiliumdemo.local:5060;transport=Tcp;maddr=192.168.2.C;ms-opaque=2f0346ae89399a07>

    instead of CONTACT: <sip:ArtaDemoOCMed.artiliumdemo.local:5060;transport=Tcp;maddr=192.168.2.D;ms-opaque=2f0346ae89399a07>

     

    -> For disconnecting the call. The gateway must send the BYE message to 192.168.2.C; But the mediationserver isn't listening on port 5060 at 192.168.2.C . Only at 192.168.2.D

    -> Gateway cannot open tcp->connection for sending BYE message.

     

    Regards,

    Dieter

    Tuesday, June 19, 2007 2:48 PM

Answers

  • Dieter,

     

    I have run into this issue once before with a customer that has updated a Mediation sever with one NIC to OCS 2007 RC and then added a second NIC. They reoported the same symptoms as you, the Media Gateway could not route back to the listening NIC for the Media Gateway. I will work on trying to reproduce your issue to see if this is a issue with the product. The workaround that I have used with the other customer was to simply switch the IP addresses on the OCS Mediation server. We replaced the IP address on the listening for OCS 5061 gateway with the IP address from the NIC that listens for the Media Gateway on port 5060 and Vice Versa. After we made the switch me made sure that the Internal NIC was registering the correct IP address in DNS for port 5061 connectivity. I know this sounds hazardous and you may not care to test in this manner.

     

    When you use c:\>netstat -ano you will be able to see what processes are listening on what ports using specific IP addresses. Let's see if port 5060 is listening on the wrong NIC with this test. Record the process ID and use c:\>tasklist /svc to match the process ID to a process. Let me know what the results are

     

    Thanks

     

     

     

     

    Wednesday, June 27, 2007 6:49 PM

All replies

  • Dieter,

     

    A common mistake that can be made when adding an additional NIC to the mediation server is not unchecking the the Advanced DNS property of "register this connection in DNS". If this attribute is left checked the Mediation server's external NIC it will have 2 IP addresses in DNS registered to the same FQDN. The FQDN should be mapped to the IP addreess of the internal NIC and that FQDN should be the subject name for the Server certificate on the Mediation server for internal port 5061 traffic. Please check on this and re-post to the issue for more assistance

     

    Thanks,

    Monday, June 25, 2007 7:41 PM
  •  

    Hi Mike,

     

    I've unchecked the DNS property on the Gateway listening NIC. Restarted the MediationServer.

    But with no effect:

     

    The MediationServer still forwards the message (from OCS) to the gateway using "the Listening NIC for OCS", and with the Contact-header:

    CONTACT: <sip:ArtaDemoOCMed.artiliumdemo.local:5060;transport=Tcp;maddr=192.168.2.C;ms-opaque=51ed190d08d6f2a4>

     

    192.168.2.C = the Listening NIC for OCS

    ==> Disconnecting the call from the gateway side fails.

     

    I have no problem with the MTLS between OCS and the MediationServer.

    Disconnecting the call from the OC-side succeeds.

     

    But thanks for the tip; it resolves another problem I had.

     

    Regards,

    Dieter

    Tuesday, June 26, 2007 9:29 AM
  • Dieter,

     

    I have run into this issue once before with a customer that has updated a Mediation sever with one NIC to OCS 2007 RC and then added a second NIC. They reoported the same symptoms as you, the Media Gateway could not route back to the listening NIC for the Media Gateway. I will work on trying to reproduce your issue to see if this is a issue with the product. The workaround that I have used with the other customer was to simply switch the IP addresses on the OCS Mediation server. We replaced the IP address on the listening for OCS 5061 gateway with the IP address from the NIC that listens for the Media Gateway on port 5060 and Vice Versa. After we made the switch me made sure that the Internal NIC was registering the correct IP address in DNS for port 5061 connectivity. I know this sounds hazardous and you may not care to test in this manner.

     

    When you use c:\>netstat -ano you will be able to see what processes are listening on what ports using specific IP addresses. Let's see if port 5060 is listening on the wrong NIC with this test. Record the process ID and use c:\>tasklist /svc to match the process ID to a process. Let me know what the results are

     

    Thanks

     

     

     

     

    Wednesday, June 27, 2007 6:49 PM
  • Dieter,

     

    If you need to continue troubleshooting this issue please leave me an email address that I can reply to so we can transfer logs. I would like to get a sipstack.etl from the Mediation server, a inboundrouting.etl and a outboundrouting.etl from the OCS access server.

     

    Thanks,

     

    Mike Adkins

    Tuesday, July 3, 2007 2:36 PM
  •  

    Hi Mike,

     

    I've send you an email.

     

    Rgds,

    Dieter

     

    Wednesday, July 4, 2007 1:43 PM
  • Hi Mike and Dieter,

    Can you let us know the status of your troubleshooting? If you have found a solution can you share it with the forums?

    Friday, July 13, 2007 9:18 PM
  • Hi Thom and Mike,

    My issue has been solved with the installation of the trial version build 2.0.6362.0

    Regs,
    Dieter
    Tuesday, August 28, 2007 11:28 AM
  • Hi Dieter,

    I am trying to add one more nic card in my mediation server, but i get this error that, i cannot have same default gateway for two nic card. could you please let me know what should i give as default gateway ?

    thanks in advance.
    Tuesday, November 6, 2007 2:46 PM
  •  

    Hi,

     

    Just leave the gateway blank on the second nic.

    Regards,

    Dieter

    Tuesday, November 6, 2007 3:08 PM
  •  

    I have version build 2.0.6362.24 installed and having same problem as you, Dieter. Do you have any other solution ?

     

    CONTACT: <sip:mediationv2.escaux-ocs.com:5060;transport=Tcp;maddr=172.16.35.147;ms-opaque=51cfe5eace987117>
    instead of

    CONTACT: <sip:mediationv2.escaux-ocs.com:5060;transport=Tcp;maddr=172.16.35.148;ms-opaque=51cfe5eace987117>

    when i call a nummber (for example 528), the telephone is ringing but i don't hear anything.

     

    SoJo

    Wednesday, November 14, 2007 2:25 PM
  •  

    Hi,

     

    Work around:

    the first ip-address must be used as gateway listening ip. (use ipconfig /all for determination)

    the second ip-address for the ocs listening ip.

    Point the fqdn to the second ip-address.

     

    After changing this, you have to restart the medation service and the ocs home service.

    Clear the dns cache before restarting the serv (ipconfig /flushdns).

    Regards,

    Dieter 

    Wednesday, November 28, 2007 9:33 AM
  • This is my topology:

     

    * OCS : 172.16.35.145

    * Mediation Server A : 172.16.35.147 is OCS listinging IP and FQDN is point to this IP

    * Mediation Server B : 172.16.35.148 is Gateway listing IP

    * Gateway : 172.16.35.64 is an openser which forwards the packet to

    * PBX : 172.16.35.230 an Asterisk server

     

    when i try nslookup then i recceive  Address: 172.16.35.147

     

    Its the same as your last "work-around" suggestion. do you have any other idea where i could make mistake or the way i could find out what i am not doing correctly ?

     

    My Problem :

    I can call the phone connected with PBX, the phone rings but i don't hear anything.

     

    Any help is greatly appreciated

     

    Regards,

    SoJo

    Wednesday, November 28, 2007 3:23 PM
  • Hi Sojo,

     

    My workaround is a solution for the problem that the disconnect from the PSTN side (when calling OC->PSTN) not succeeds (see previous posts of me).

     

    Mind: the GW-listening IP-address must be the first IP-address (if you do ipconfig /all the first ip address shown)

     

    In your setup, I guess that you have to change the GW listening ip to the 147 and the OCS listening ip 148, also the fqdn has to changed to the 148.

    after changes: do ipconfig /flushdns on the OCS server, and restart the mediation and OCS service.

     

    Regards,

    Dieter

     

     

    PS: I don't know if your rtp-problem should be solved with my workaround.

    Wednesday, November 28, 2007 3:34 PM
  • We ran into a similiar issue with our internal mediation server as it was also running a couple web sites on it and had additional IP addresses bound to one of the NICs.  Even though OCS was not configured to use any of those IP addresses we started seeing numerous problems.

     

    My collegeue has a blog entry discussing the recommendation to not assign multiple IPs to any NICs on a Mediation server.

     

    Wednesday, November 28, 2007 3:43 PM
    Moderator
  •  

     

    Hi Jeff,

     

    My problem was not only 1 NIC-related, but also 2 NICs related.

    See previous messages of me. My post that my issue was solved, was par hazard. Today I had a similar problem on another installation. And I've looked to my working deployment. And so that I've configured as described above.

     

    So I've configured the same situation again with the same good results.

     

     

    Dieter

    Wednesday, November 28, 2007 3:49 PM