Link to home
Start Free TrialLog in
Avatar of MikeKane
MikeKaneFlag for United States of America

asked on

Lync 2010 Mediation Server - Not accepting inbound calls

Lync 2010, front end pool is also doing Mediation services.    I have setup a SIP trunk to the Cisco Call manager on site.    

From Lync clients, I can call outbound to CM phones and beyond in to the pstn.   No issues there.  

The problem comes when a cisco phone tries to call the Lync client #.    After working with TAC, we see the SIP trace from CM sending out the invite to the mediation server on port 5068 (default TCP listening port for Lync).   But an immediate RST.  

After looking at the server, I see that there is nothing listening on 5068 or 5067 (Tcp and Tls respectively).     Nmap shows no open ports waiting for inbound sip invites.  

Firewall is off.  

So my question, if someone with a mediation server would confirm, does the mediation server show a listening/open port on 5068 and 5067?  

If you answer a yes, then my mediation service is Fubar'd somehow and not listening.   (I'm assuming its this answer actually, but need someone to verify).

If you answer a no, then I'll look somewhere else.  

ASKER CERTIFIED SOLUTION
Avatar of Cliff Galiher
Cliff Galiher
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of MikeKane

ASKER

I did and it all looks correct.   Mediation service is started.  It's just not listing ports listening on 5068 and 5067.   It does list 5061, so its just the mediation stuff that's not cooperating.  

I'll try a re-install in the morning unless anyone can offer any suggestions.  
Don't overlook the event logs. Lync actually is very detailed if you open the various application-specific event logs in event viewer. It may tell you why the mediation prices failed to load or bind to a NIC or ports.

Honestly, this is a VERY strange way for lync to break. I suspect something bigger at work, and reinstalling without determining that cause may not net the results you want.

-Cliff
That's whats very confusing.   The event viewer is clean.   Nothing there.    It seems that everything 'should' be running well, but it isn't.  

There's not much to the config of the mediation server itself in topology builder.       I tried changing the ports to 5167 and 5168 and reran the setup, but still there's no listening ports.    Again, EV is clean.  

I have a feeling this will turn into a $300 MS call.  

Would you verify the versions here.   I pulled this from the Event Viewer Info items for the 'LS Mediation Server' 25002 for the start of the service.  

Mediation Server Service has started.
C:\Program Files\Microsoft Lync Server 2010\Mediation Server\Microsoft.RTC.MediationServerCore.dll v4.0.7577.0
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll v2.0.50727.5420
C:\Windows\assembly\GAC_MSIL\Microsoft.Rtc.Collaboration\4.0.0.0__31bf3856ad364e35\Microsoft.Rtc.Collaboration.dll v4.0.7577.0
C:\Windows\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll v2.0.50727.5420
C:\Windows\assembly\GAC_MSIL\Microsoft.Rtc.Management.Core\4.0.0.0__31bf3856ad364e35\Microsoft.Rtc.Management.Core.dll v4.0.7577.0
C:\Windows\assembly\GAC_64\Microsoft.Rtc.Internal.Media\4.0.0.0__31bf3856ad364e35\Microsoft.Rtc.Internal.Media.dll v4.0.7577.0
C:\Windows\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll v2.0.50727.5420
C:\Windows\assembly\GAC_64\SIPEPS\4.0.0.0__31bf3856ad364e35\SIPEPS.dll v4.0.7577.0
C:\Windows\assembly\GAC_MSIL\System.Management\2.0.0.0__b03f5f7f11d50a3a\System.Management.dll v2.0.50727.5420
Strange things are afoot at the circle K.  

So, to test my sanity, I built another server and gave it mediation roles.  I moved the gateways to it in topo builder and restarted all servers and the sip trunk at CM.    It worked fine, first try, no issues.    

I moved the gateways back to the Front end server (in mediation), re-ran setup, restarted mediation, and lo and behold, there are the ports, and the SIP calls are working as they should.  

Very very very weird issue, but its fixed now.

From one expert to another, thanks for the assist.
No worries. Sorry for not seeing your replies before now. My *first* guess is that some corrupt data was in the topology which, as you already know, is now stored separately in its own database. Even though *viewing* the topology looked write, it wasn't revealing the corrupt data. By actually moving things around, you caused the topology builder to rewrite those settings, overwriting the corrupt data, and fixing things up.

Of course that is purely speculation. I'd loved to have gotten a chance to peak at the database itself, but in understanding how things work, it is the most reasonable explanation I can think of on how that whole thing came together.

Glad things are working now, and thanks for the points.

-Cliff