Deloying CCE in one site with HA

Microsoft

Working the other day with a customer to deploy two CCE connector in HA using the Sonus appliance Sonus Cloud Link for Microsoft CCE (https://www.sonus.net/solutions/microsoft-solutions/sonus-cloud-link-for-microsoft-cce) we have the following issue after we configured the two appliance to reach both SBC (USER-AGENT: SONUS SBC1000 6.1.1v460 Sonus SBC), so each Mediation is connected to both SBS to get on the site HA when one of the mediation or SBC fails.

Med/CCE1 <-> SBC1

Med/CCE1 <-> SBC2

Med/CCE2 <-> SBC1

Med/CCE2 <-> SBC2

When testing we get the following result, when SBC1 send the call to the Med/CCE1 the call is accepted. When the SBC1 send the call to the Med/CCE2 the call is refuse after the 100 Trying with a 400 Bad Request.

 

TL_INFO(TF_PROTOCOL) [mspool\Med-041515]0940.23E4::03/01/2017-14:10:32.898.000025E5 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(801)) [1608821117]

>>>>>>>>>>>>Outgoing SipMessage c=[<SipTcpConnection_3B11652>],xxxxxxxxx:5068->xxxxxxxxx27361

SIP/2.0 400 Bad Request

FROM: <sip:xxxxxxxxx:5068>;tag=a026541-a499;sgid=2

TO: <sip:+33xxxxxxxxxx@Med-041515.sfb-ccedomain.local:5068;user=phone>;epid=3141A5FF2F;tag=324ab7d333

CSEQ: 2 INVITE

CALL-ID: call-F8ED6E14-0000-0010-0219-978@10.2.101.65

VIA: SIP/2.0/TCP xxxxxxxx:5068;branch=z9hG4bK-UX-0a02-6541-16bdd

CONTENT-LENGTH: 0

SERVER: RTCC/6.0.0.0 MediationServer

------------EndOfOutgoing SipMessage

 

Looking more in detail we can found:

TL_INFO(TF_PROTOCOL) [edgepool\Edge-041515]0AD4.0DA4::03/01/2017-14:10:33.036.000021E9 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [10766034]

Trace-Correlation-Id: 10766034

Instance-Id: 2ED2

Direction: incoming;source="internal edge";destination="external edge"

Peer: mspool.sfb-ccedomain.local:58014;ms-fe=Med-041515.sfb-ccedomain.local

Message-Type: request

CALL-ID: 0f39d9372ab046ada4670afafbcce005

CSEQ: 800 SERVICE

CONTACT: <sip:Med-041515.sfb-ccedomain.local@xxxxxxxxxxxx;gruu;opaque=srvr:MediationServer:50RnLW4MzlmbVL628u7...>

VIA:  SIP/2.0/TLS xxxxxxxxx:58014;branch=z9hG4bKd2118e37

MAX-FORWARDS: 70

CONTENT-LENGTH: 578

CONTENT-TYPE:  application/msrtc-reporterror+xml

Message-Body: <?xml version="1.0" encoding="us-ascii"?><reportError xmlns="http://schemas.microsoft.com/2006/09/sip/error-reporting"><error callId="call-F8ED6E14-0000-0010-0219-978@10.2.101.65" fromUri="sip:anonymous@xxxxxxxxx;user=phone" toUri="sip:+33xxxxxxxxxxxxx;user=phone" fromTag="a026541-a499" toTag="" requestType="INVITE" contentType="application/sdp;call-type=audio" responseCode="400"><diagHeader>10013;reason="Gateway peer in inbound call is not found in topology document or does not depend on this Mediation Server"</diagHeader><progressReports /></error></reportError>

 

With this two information we look at the configuration files, from both CCE we run Get-CsTopology -AsXML | Out-File C:\Topology.xml

 

So for each of these appliances we would expect to see a Mediation Server Cluster including both Mediation Servers which we see in the topology.xml

<Cluster Fqdn="mspool.sfb-ccedomain.local">

      <ClusterId SiteId="co1" Number="3" />

      <Machine OrdinalInCluster="1" Fqdn="Med-034501.sfb-ccedomain.local">

        <NetInterface InterfaceSide="Primary" InterfaceNumber="1" IPAddress="0.0.0.0" />

        <NetInterface InterfaceSide="Pstn" InterfaceNumber="1" IPAddress="0.0.0.0" />

      </Machine>

      <Machine OrdinalInCluster="2" Fqdn="Med-041515.sfb-ccedomain.local">

        <NetInterface InterfaceSide="Primary" InterfaceNumber="1" IPAddress="0.0.0.0" />

        <NetInterface InterfaceSide="Pstn" InterfaceNumber="1" IPAddress="0.0.0.0" />

      </Machine>

    </Cluster>

 

We found a discrepancy in the topology, There was a wrong IP address for one of SBC that caused this 400 Bad request answer from this CCE Mediation. Share this experience because the main solution comes from Cloud Connector Deep Dive: https://aka.ms/sa-cce where everything is on one page: Under HA and Multi Site Considerations

So look at this presentation.

Thanks

Leo

1 Reply

Thank you for sharing your experience through your customer work, @Leonardo Wormull!