locked
Audio - Video P2P RRS feed

  • Question

  • Hello All,

     

    Thanks in advance to anyone responding to this thread.

     

    We are in the process of rolling out Office Communicator 2007 to our colleagues.  Before we advertise that the system is globally available we are trying to work out issues with audio and video calls. (Audio being the most important).

     

    The situation is this, we have our OCS 2007 servers on our servernet routable IP addresses.  These servers sit behind a FW are are not public.  Users that are inside our office, and offices where we have tunnels connected, do not have a problem using the AV features of the system.  Our remote users that connect to the office via CheckPoint's secure remote/secure client will have intermittent issues with AV.

     

    It appears that this issue is tied into the fact that they are behind a NATing device such as a small home cable/dsl router.  We have tested this issue using verizon/sprint air cards and the solution works.  We are on publicly routable IPs at that point.

     

    The question I have is this, is there a way for our company to force pinning through the server for user to user communication, or does communicator have any functionality that will work with uPNP?

     

    Any thoughts/comments would be appreciated.

     

    Again thanks,

     

    Mike C.

    Tuesday, October 23, 2007 3:38 PM

All replies

  • Double post:

     

    Here is a log from a Communicator to Communicator call, notice that SIP is sending out the local IP of a client.

     

    10/23/2007|13:13:23.843 7028:7628 INFO  :: Data Received - 64.90.227.238:5061 (To Local Address: 192.168.27.97:60061) 2412 bytes:

    10/23/2007|13:13:23.843 7028:7628 INFO  :: BENOTIFY sip:192.168.27.97:60061;transport=tls;ms-opaque=8a2518363c;ms-received-cid=D0300 SIP/2.0

     

    Via: SIP/2.0/TLS 64.90.227.238:5061;branch=z9hG4bK5F734EE0.AE055E5E;branched=FALSE

     

    Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFFFEC6B5316C7076DBD032541BF1F93AAC", srand="4065B443", snum="2764", opaque="08B49CFF", qop="auth", targetname="sip/extprdlc12.bentley.com", realm="SIP Communications Service"

     

    Tuesday, October 23, 2007 5:26 PM
  •  

    Bump
    Wednesday, October 24, 2007 2:06 PM
  •  

    Anyone from Microsoft want to chime in here?

     

    I can't be the only guy who has brought this up.

    Monday, October 29, 2007 7:30 PM
  • Hi Michael,

    I have two posts open with familiar issues ....

    http://forums.microsoft.com/OCS2007/ShowPost.aspx?PostID=2148971&SiteID=57

    http://forums.microsoft.com/OCS2007/ShowPost.aspx?PostID=2322791&SiteID=57

    The solution MMCGILLE is refering to can be found in the following post

    http://forums.microsoft.com/OCS2007/ShowPost.aspx?PostID=1989357&SiteID=57


    Hi,

    Ok - so the putting a public IP address on the Edge server definitely did fix this. BUT - there were some odd complications that are worth noting. Here's what I had to do to make it all work:

     

    1) Configure the Edge server with 1 "internal" IP address for the inside edge (10.x.x.x)

    2) Configure the Edge's second NIC with 3 "external" non-NAT IP addresses (38.x.x.x)

    3) Configure an interface on my sonicwall firewall for "transparent" mode, which passess traffic through from the WAN interface without NAT.

    4) Plug the second NIC of the Edge server into this new interface on the firewall

    5) rebind all the edge services to their new external IP addresses

     

    Step 2 is the craziest. I had to configure every external interface on the edge with a publicly routable IP. I tried to just configure the AV edge server with the public IP (leaving auth and webconf with NAT IPs), but that did _VERY_ strange things to the routing table on the Edge server.

     

    The edge started getting confused as to how to route outbound traffic because external traffic was coming to it from two sources: the SIP traffic was coming from one of the internals (bound to the auth service) and the AV traffic was coming in on the external (bound to AV edge). There can be (should be) just 1 default gateway on a windows box, so all the traffic on the way back out was exiting the external interface (my default gateway). Well, that broke all the SIP traffic cause it was coming in to the internal IP and exiting the external. I couldn't make it work.

     

    So I bit the bullet and configured all the edge IPs as their public addresses.

     

    This defintitely solved the problem.

     

    I can only see 2 other ways to do this:

     

    1) Have a separate edge A/V server. Configure 1 internal IP (10.X.x.x) and one external (38.x.x.x) - that way you can have a separate server for webconferencing and A/V authentication with their NAT IPs (10.x.x.x) on the external interfaces.

     

    or

     

    2) Have 3 different networks on your Edge server:

    - 1 External (38.x.x.x) for A/V Edge service

    - 1 Internal (10.x.x.x) for the edge internal interface

    - 1 DMZ (172.16.x.x) for the web conf and A/V auth

    - add persistent static routes for 172.16.x.x and 10.x.x.x on your edge server

     

    The problem with this is that you use two interfaces on your firewall: 1 for the external transparent A/V edge, 1 for the DMZ.

     

    For now, I am sticking with my solution; it works well. I just am still slightly unsettled by needing to put convert all the IPs to publicly routeable ones. There's no harm in doing it, because the firewall is still only allowing certain ports through, but it still seems strange to me.

     

    Matt

    Thursday, November 1, 2007 5:27 AM