locked
Last Live Meeting version not compatible with OCS public beta RRS feed

  • Question

  • The last bits posted on the connect site (16th of July) are not compatible anymore with the public beta of OCS. We are not able to log on to the conferencing server anymore with this version of LM. So we have decided to use the previous version again as long as we're using the public beta. It is advisable to test the new version with the final OCS release.

    The last Communicator release still works fine.

    /Thomas



    PS. If anyone knows a work around to get it running with the public beta, I would be glad to know of course ;-)

    Friday, August 10, 2007 11:23 AM

Answers

  • 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

     

    Wednesday, September 19, 2007 2:57 PM

All replies

  • Hi,

     

    I found a way on Friday, seems to be a lock in the software. If you start it with "Meet now" or the Outlook Add-In it does not work, but if you start a Communicator conversation with somebody and click "Share content using LiveMeeting", then it works.

     

    Interesting, because some features changed in Live Meeting, like Document Sharing, the Edit Mode is not available any more you have to open the Office Application and share the application manually.

     

    bg

    Alex

    Monday, August 13, 2007 7:07 AM
  • Correction: it is the outlook add-in of newer life meeting versions that do not work with the public beta. The newer LMconsol versions work correctly with the public beta.

     

    I do have some problems with sound and video configuration. It tries to make an AV connection by looking at my internal OCS server name if I connect cia Edge. Is this issue releated to the public beta server?

     

    I'm using life meeting build 8.0.6362 and it is working with communicator if you schedule meetings using webschedular and/or start it via communicator.

     

    /Thomas

     

    PS. The RTM is now available via MSDN...so I can start planning replacing the public beta install ;-)

    Saturday, August 18, 2007 6:24 AM
  • I got some more information on the Live Meeting error in the previous post:

     

    ---------------------------
    Voice and Video Error Information
    ---------------------------
    Your audio and/or video session was unexpectedly disconnected.

     

    Action required: Please rejoin audio and/or video.

     

    ---------------------------------------------------------------------------

    More details for technical support:

    ---------------------------------------------------------------------------

    Message Category: 2 (kNetworkError)

    Message Code: 8 (kMediaConnectivityFailure)

    Root Cause Error: 0x00000000

    Root Cause Component: kNetwork

    Audio Input Device: SoundMAX Digital Audio

    Audio Output Device: SoundMAX Digital Audio

    Video Input Device:

    Audio Muted: Yes

    Media State: (43,2,2,10,0,0,Reinviting)

    AvMcu Uri: sip:INTERNAL_FQDN_OF_OCS_MACHINE:5063;transport=tls

    Avmcu Reachable: Yes

    Acp Reachable: No

    Diagnostics Information:

    ---------------------------------------------------------------------------

    To copy this message, press CTRL+C or press ALT+PRINT SCREEN.
    ---------------------------
    OK  
    ---------------------------

     

    Why is it trying to connect to the FQDN of the internal machine when I'm connecting via the Edge server?

     

    Did anyone else experience the same error?

     

    /Thomas

    Saturday, August 18, 2007 9:41 AM
  •  

    Hi Thomas,

     

    I experience the same error in live meeting as you described, this happened in my case in both versions of live meeting, I am working with an firewall between our OCS environment and the live meeting session all the necessarily ports are open in fact all the ports are open so that should not be the problem. But it’s very strange it can’t reach the ACP module of OCS which is responsible for conferencing.

     

    Best regards, 

     

    Michiel Timmermans

    Tuesday, August 28, 2007 7:39 AM
  • Hi Michel,

     

    I was on leave for a while. We will be installing the RTC version a the short term and find out if this problem still exists. What version of OCS have you installed?

     

    /Thomas

    Friday, August 31, 2007 3:54 PM
  • Hi Thomas,

     

    At this time we have installed the beta version of OCS, we are going to upgrade to the msdn version this week. If this error is fixed in this version I will let you know.

     

    Regards Michiel

    Monday, September 3, 2007 8:43 AM
  • Michel,

     

    I got some details from the debugging log. You can enable it by setting the following registry value:

     

    HKEY_CURRENT_USER\Software\Microsoft\Tracing\uccp\LiveMeeting\EnableFileTracing

     

    set Dword value of "EnableFileTracing" on 1.

     

    Audio and video will connect for a short while and after a few seconds it will be disconnected. So this only happens when I connect via Edge. Connecting via the internal frontend everything works absolutely fine.

     

    09/06/2007|22:32:04.718 370:4B4 INFO  :: End of Sending Packet - 82.94.6.253:5061 (From Local Address: 192.168.1.110:4795) 837 bytes
    09/06/2007|22:32:04.718 370:4B4 TRACE :: - encrypted buffer length: 858 bytes.  First 8 bytes:
    09/06/2007|22:32:04.718 370:4B4 TRACE ::  17 03 01 03 55 7A F1 C2  :....UzñÂ
    09/06/2007|22:32:04.718 370:4B4 TRACE :: ASYNC_SOCKET:Tongue TiedendOrQueueIfSendIsBlocking sending sendBuffer 02C5B090, this 00153288
    09/06/2007|22:32:04.718 370:4B4 TRACE :: ASYNC_SOCKET:Tongue TiedendHelperFn sendBuffer 02C5B090 sent, this 00153288
    09/06/2007|22:32:04.718 370:4B4 TRACE :: call.SetState[00168398]  SIP_CALL_STATE_CONNECTED-->SIP_CALL_STATE_DISCONNECTED for sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:audio-video:id:20040C025FF2794884513DC99E220366, stack=0010EB70
    09/06/2007|22:32:04.718 370:4B4 TRACE :: SIP_CALL::NotifyCallStateChange[00168398] : CallState : 2 StatusCode: 0, s=2
    09/06/2007|22:32:04.718 370:4B4 TRACE :: MULTIPARTY_SESSION::NotifyCallChange[00126820]- call-leg:00168398, Callstate:2 StatusCode:0 SessionState:2
    09/06/2007|22:32:04.718 370:4B4 INFO  :: CUccMultipartySession::NotifyPartyChange[00140E4C] - for participant [sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:audio-video:id:20040C025FF2794884513DC99E220366]
    09/06/2007|22:32:04.718 370:4B4 ERROR :: CRTCMediaParticipant::RemoveStream[02B86D50] HasStream failed (1). 80ee0002
    09/06/2007|22:32:04.718 370:4B4 INFO  :: Function: CRTCChannel::CreateUCCPMediaAddress
    09/06/2007|22:32:04.718 370:4B4 ERROR :: HRESULT API failed: 80ee0058 = hr. failed to get the subnet mask
    09/06/2007|22:32:04.718 370:4B4 INFO  :: CRTCStream::CreateUCCPCallSetupMetricCollection[02B4E410] isequencenumber is < 0.
    09/06/2007|22:32:04.808 370:4B4 ERROR :: CRTCMediaParticipant::RemoveStream[02B86D50] HasStream failed (1). 80ee0002
    09/06/2007|22:32:04.808 370:4B4 INFO  :: Function: CRTCStream::CollectMidCallMetrics
    09/06/2007|22:32:04.808 370:4B4 ERROR :: HRESULT API failed: c0042003 = hr. failed to get metrics
    09/06/2007|22:32:04.808 370:4B4 INFO  :: Function: CRTCStream::CollectPostCallMetrics
    09/06/2007|22:32:04.808 370:4B4 ERROR :: HRESULT API failed: c0042003 = hr. failed to get metrics
    09/06/2007|22:32:04.808 370:4B4 INFO  :: Function: CRTCStream::CollectPostCallMetrics
    09/06/2007|22:32:04.808 370:4B4 ERROR :: HRESULT API failed: c0042003 = hr. failed to get metrics
    09/06/2007|22:32:04.808 370:4B4 INFO  :: Function: CRTCChannel::CreateUCCPMediaAddress
    09/06/2007|22:32:04.808 370:4B4 ERROR :: HRESULT API failed: 80ee0058 = hr. failed to get the subnet mask
    09/06/2007|22:32:04.808 370:4B4 INFO  :: CRTCStream::CreateUCCPCallSetupMetricCollection[02B4E918] isequencenumber is < 0.
    09/06/2007|22:32:04.808 370:4B4 ERROR :: CRTCStream::GetResolutionString[02B4E918] height or width is 0.
    09/06/2007|22:32:04.858 370:4B4 ERROR :: SIP_URL::Initialize UnicodeToUTF8((null)) failed 80004003
    09/06/2007|22:32:04.858 370:4B4 ERROR :: SIP_URL::Initialize UnicodeToUTF8((null)) failed 80004003
    09/06/2007|22:32:04.858 370:4B4 INFO  :: Function: CUccMediaChannel:Tongue TiedetNegotiatedEnable
    09/06/2007|22:32:04.858 370:4B4 ERROR :: HRESULT API failed: 80ee0082 = hr. failed to set mute to false
    09/06/2007|22:32:04.858 370:4B4 INFO  :: Function: CUccMediaChannel:Tongue TiedetNegotiatedEnable
    09/06/2007|22:32:04.858 370:4B4 ERROR :: HRESULT API failed: 80ee0082 = hr. failed to set mute to false
    09/06/2007|22:32:04.858 370:4B4 INFO  :: CUccMediaChannel:SurprisenStreamStateChanged - XXX Raising Event for media stream state change from STATE: 1 to 4, MEDIATYPE: 2, DIRECTION(S): 2
    09/06/2007|22:32:04.858 370:4B4 INFO  :: CUccSessionParticipant::InternalSetState [020C7104] - state: 0x3->0x5
    09/06/2007|22:32:04.858 370:4B4 TRACE :: CUccSession::InternalRemoveParticipant - Removing participant sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:audio-video:id:20040C025FF2794884513DC99E220366
    09/06/2007|22:32:04.858 370:4B4 TRACE :: MULTIPARTY_SESSION::HandleCallLegNotifyDisconnect number of participants remaining 0, this 00126820
    09/06/2007|22:32:04.858 370:4B4 INFO  :: MSP.SetState[00126820] SIP_CALL_STATE_DISCONNECTED->SIP_CALL_STATE_DISCONNECTED, local=sip:wesselth@sgtiocs.nl
    09/06/2007|22:32:04.858 370:4B4 INFO  :: CUccSessionParticipant::InternalSetState [020C6F7C] - state: 0x3->0x5
    09/06/2007|22:32:04.858 370:4B4 TRACE :: CUccSession::InternalRemoveParticipant - Removing participant sip:wesselth@sgtiocs.nl
    09/06/2007|22:32:04.858 370:4B4 INFO  :: MSP.SetState[00126820] SIP_CALL_STATE_DISCONNECTED->SIP_CALL_STATE_DISCONNECTED, local=sip:wesselth@sgtiocs.nl
    09/06/2007|22:32:04.858 370:4B4 INFO  :: Function: CUccMultipartySession::NotifyCallChange
    09/06/2007|22:32:04.858 370:4B4 ERROR :: Condition failed with 80ee002a: 'spLocalParticipant.IsValid()'
    09/06/2007|22:32:05.029 370:4B4 INFO  :: CUccSession::Terminate - Terminate called by the app Session ptr - 00140E4C
    09/06/2007|22:32:05.029 370:4B4 INFO  :: Function: CUccSession::Terminate
    09/06/2007|22:32:05.029 370:4B4 ERROR :: Condition failed with 00000001: 'GetLocalParticipant() != 0'
    09/06/2007|22:32:05.139 370:4B4 INFO  :: CUccConfSession::InternalAddEndpoint - scheduled join for sip:wesselth@sgtiocs.nl, hr = 00000000
    09/06/2007|22:32:05.139 370:4B4 INFO  :: CUccConfSession:Tongue TiederializeOperation - Operation - 
    09/06/2007|22:32:05.139 370:4B4 INFO  :: Dumping the conference operation:
    09/06/2007|22:32:05.139 370:4B4 INFO  :: <?xml version="1.0"?>

    <request xmlns="urn:ietfStick out tonguearams:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:focus:id:20040C025FF2794884513DC99E220366" from="sip:wesselth@sgtiocs.nl" requestId="5"><addUser mscp:mcuUri="sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:audio-video:id:20040C025FF2794884513DC99E220366" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"><conferenceKeys confEntity="sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:focus:id:20040C025FF2794884513DC99E220366"/><ci:user xmlns:ci="urn:ietfStick out tonguearams:xml:ns:conference-info" entity="sip:wesselth@sgtiocs.nl"><ciBig Smileisplay-text>Thomas Wesseling</ciBig Smileisplay-text><ci:roles><ci:entry>presenter</ci:entry></ci:roles><ci:endpoint entity="{E6AD0A8C-293E-4552-B282-51C9E672B8AF}" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions" sip-instance="&quot;&lt;urn:uuid:0E19ECA7-89A3-5730-B853-711C250F8AB4&gt;&quot;"><ci:joining-method>dialed-in</ci:joining-method><ci:media id="audio"><ci:type>audio</ci:type><ciTongue Tiedtatus>sendrecv</ciTongue Tiedtatus></ci:media><ci:media id="video"><ci:type>video</ci:type><ciTongue Tiedtatus>sendrecv</ciTongue Tiedtatus></ci:media></ci:endpoint></ci:user></addUser></request>


    09/06/2007|22:32:05.139 370:4B4 TRACE :: SIP_STACK::FindProviderSAContext SA_CONTEXT foundTongue TiedOCS0001SEL.sgtiocs.nl- 00135318, SA list entry 020C6AB8, this 0010EB70
    09/06/2007|22:32:05.139 370:4B4 TRACE :: signed buffer: <NTLM><b8674b7c><15><SIP Communications Service><SOCS0001SEL.sgtiocs.nl><4b2c7ec0724f461cbbd1d8df370143da><6><INFO><sip:wesselth@sgtiocs.nl><e024c2e492><sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:focus:id:20040C025FF2794884513DC99E220366><23480080><><><> - length- 256. SSPI context:1277648-15266168.
    09/06/2007|22:32:05.139 370:4B4 INFO  :: Sending Packet - 82.94.6.253:5061 (From Local Address: 192.168.1.110:4795) 2051 bytes:
    09/06/2007|22:32:05.139 370:4B4 INFO  :: INFO sip:<accessedgeservername>:5061;transport=tls;lr;ms-route-sig=fakBE4uZfDLN2n2VZYepX3evi08RWT79HGTK2ZjAAA SIP/2.0

    Via: SIP/2.0/TLS 192.168.1.110:4795

    Max-Forwards: 70

    From: <sip:wesselth@sgtiocs.nl>;tag=e024c2e492;epid=fda62b04e5

    To: <sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:focus:id:20040C025FF2794884513DC99E220366>;tag=23480080

    Call-ID: 4b2c7ec0724f461cbbd1d8df370143da

    CSeq: 6 INFO

    Route: <sipTongue TiedOCS0001SEL.sgtiocs.nl:5061;transport=tls>

    User-Agent: UCCP/2.0.6362.0 LMC/8.0.6362.0

    Supported: timer

    Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="72C2E7C7", crand="b8674b7c", cnum="15", targetname="SOCS0001SEL.sgtiocs.nl", response="01000000b1e1ffffa19859b7a917c693"

    Content-Type: application/cccp+xml

    Content-Length: 1268

     

    <?xml version="1.0"?>

    <request xmlns="urn:ietfStick out tonguearams:xml:ns:cccp" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions" C3PVersion="1" to="sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:focus:id:20040C025FF2794884513DC99E220366" from="sip:wesselth@sgtiocs.nl" requestId="5"><addUser mscp:mcuUri="sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:audio-video:id:20040C025FF2794884513DC99E220366" xmlns:mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"><conferenceKeys confEntity="sip:wesselth@sgtiocs.nl;gruu;opaque=app:conf:focus:id:20040C025FF2794884513DC99E220366"/><ci:user xmlns:ci="urn:ietfStick out tonguearams:xml:ns:conference-info" entity="sip:wesselth@sgtiocs.nl"><ciBig Smileisplay-text>Thomas Wesseling</ciBig Smileisplay-text><ci:roles><ci:entry>presenter</ci:entry></ci:roles><ci:endpoint entity="{E6AD0A8C-293E-4552-B282-51C9E672B8AF}" xmlns:msci="http://schemas.microsoft.com/rtc/2005/08/confinfoextensions" sip-instance="&quot;&lt;urn:uuid:0E19ECA7-89A3-5730-B853-711C250F8AB4&gt;&quot;"><ci:joining-method>dialed-in</ci:joining-method><ci:media id="audio"><ci:type>audio</ci:type><ciTongue Tiedtatus>sendrecv</ciTongue Tiedtatus></ci:media><ci:media id="video"><ci:type>video</ci:type><ciTongue Tiedtatus>sendrecv</ciTongue Tiedtatus></ci:media></ci:endpoint></ci:user></addUser></request>

    Thursday, September 6, 2007 8:52 PM
  • Hi all,

    I too am having this issue. I did a network trace on the client machine and it definitely shows the client trying to talk to the internal (10.x.x.x) IP address of the A/V conferencing server.

     

    What is even more strange is that I can do successful A/V conferences through the A/V edge server when I do them without LiveMeeting. For example, if I start an IM with voice, then invite several people to the conference, they all join just fine. So I know that my A/V settings are mostly correct. It just seems like the LiveMeeting service is handing out the wrong FQDN for voice and video.

     

    I tried exporting the config with the lcscmd.exe tool to see if there were any LiveMeeting + A/V settings in there, but I couldn't find anything.

     

    This behavior seems similar to when you don't have the A/V edge service reachable by external users - the client will try to contact the internal IP's if it can't talk to the edge. Very odd...

     

    Matt

    Wednesday, September 12, 2007 1:41 PM
  • Hi,

    We have migrated to the RTM last week. I will test Live Meeting again tomorrow to see if the error still occurs.

    /Thomas
    Sunday, September 16, 2007 2:19 PM
  • After installing the RTM the problem is still there. Why is Live Meeting trying to connect to an interal server?

     

    ---------------------------
    Voice and Video Error Information
    ---------------------------
    Your request to add/remove a media failed.

     

    Action required: Please try your action again. If that doesn't work, set up audio and video from the Options menu.

     

    ---------------------------------------------------------------------------

    More details for technical support:

    ---------------------------------------------------------------------------

    Message Category: 5 (kOperationFailure)

    Message Code: 2 (kReinviteFailed)

    Root Cause Error: 0x80EF01F4

    Root Cause Component: kAVMCU

    Audio Input Device: Microphone (2- Microsoft® LifeCam NX-6000)

    Audio Output Device: Speakers (SoundMAX Integrated Digital HD Audio)

    Video Input Device: Microsoft® LifeCam NX-6000

    Audio Muted: Yes

    Media State: (47,10,10,10,12,0,Reinviting)

    AvMcu Uri: sipTongue TiedOCS0001SEL.sgtiocs.nl:5063;transport=tls

    Avmcu Reachable: Yes

    Acp Reachable: No

    Diagnostics Information:

    ---------------------------------------------------------------------------

    To copy this message, press CTRL+C or press ALT+PRINT SCREEN.
    ---------------------------
    OK  
    ---------------------------

    Monday, September 17, 2007 7:59 PM
  • Hi Thomas,

    I finally opened a PSS case on this. The answer I got was : "You need to have a publicly routable IP address on the A/V edge server"

     

    I was not / am not too happy about the answer because I pointed out that I can actually do audio and video conferencing fine through IP communicator (even with multiple clients on multiple remote subnets) but it just doesn't work for livemeeting.

     

    I am going to reconfigure my AV Edge to use the public IP and my firewall to transparently pass traffic to that NIC. I'll let you know how it goes and if it definitely fixes the problem.

     

    Regards,

    Matt

     

    Monday, September 17, 2007 8:32 PM
  • Hi Matt,

    Thanks for sharing this with us. Looking forward to hear more about this altenative configuration.

    /Thomas
    Tuesday, September 18, 2007 7:52 AM
  • 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

     

    Wednesday, September 19, 2007 2:57 PM
  •  mmcgille wrote:

     

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

     

     

    Interesting and worth trying. At the moment we have one public IP configured and an Edge Server behind it listening on its own external IP and of course different ports. So changing the IP configuration on the Edge works fine? I only have to change the AV Edge server interface, right?

     

    I'll try it.

     

    Thanks,

     

    Thomas

     

    Wednesday, September 19, 2007 3:36 PM
  •  

    Hi Thomas,

    If you only have 1 external IP configured on your edge server, then that is the only IP that you have to pass through in transparent mode. I just changed the IP on the external NIC to be the external one, then re-ran the edge config. It prompted me to change the edge interfaces (because the old IP was no longer there). I picked the external IP, stopped and started all the services (FE and Edge) and it came right up.

     

    I have a different IP for each service, so I ended up having to change them all, but you should be fine if your just on 1 IP.

     

    Regards,

    Matt

     

    Wednesday, September 19, 2007 4:46 PM
  • Hi Matt,

     

    Since Communicator and Federation are already working fine I'm going to create one extra interface on the Edge for a/v conferencing. Will let you know if it works.

     

    /Thomas

    Thursday, September 20, 2007 4:40 AM
  • Today I was testing out live meeting with some federated users and found out that the a/v conferencing server is working perfectly fine. I haven't added an interface yet. The quality of video and audio was very good and the connections were stable.

    This was the scenario:

    Edge server configured to trust the other domain for federated contacts
    One interface (one public address) on both Edge servers
    Root certificated installed of the other domain on each participants computer
    Initiating a live meeting, having 2 users joined from the other domain and 3 users from our domain

    However video conferencing /calling with federated users using communicator was not working yet but this could be due to the fact that we do not have a public certificate on the Edge interface yet.

    Will do some more tests after the weekend to find out more about the behaviour of connections via Edge in other scenarios.

    /Thomas
    Friday, September 21, 2007 7:54 PM
  • I'm having the same issue with external Live Meeting clients trying to connect to the internal FQDN of the front end server for A/V conferencing.

     

    Communicator voice/video works fine for me too externally. And yes, you need a public cert for federated partners.

     

    It looks like having a publicly routable IP assigned to the A/V edge itself and traffic flowing without using NAT is a required configuration for this to work properly.

    Wednesday, September 26, 2007 4:36 PM
  • Today I found out that the following ports are not open om the firewall:

    ports 50000 - 59999 (tcp, but also udp) from the internet to A/V edge and the other way around.

    I think this could be the reason that we can not send A/V from LM over the line.

    I 'll let you know the results once the ports has been opened.

    /Thomas
    Wednesday, September 26, 2007 6:49 PM
  • I was doing some tracing and found out some interesting things... please read more on this in the following post...

     

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

    Thursday, October 25, 2007 7:13 PM