Skype for Business - SIP/PSTN Trunk Configuration

According to best practices, you need to deploy an SBC between
- the service provider SBC and
- your mediation server.

Your SBC will have one SIP trunk to the service provider, and another SIP trunk to your mediation server. I suggest you to contact your service provider to find out
- which SBCs they have tested in their lab for compatibility
- sample configurations for that SBC in an SfB 2015 environment

I hope this helps.

You need to test the port that your mediation server is listening on. check what's the port your SIP provider have assigned on their end and whether they are using UDP or TCP protocol. normally SIP providers provide UDP protocols since they don't now Skype/Lync work with TCP traffic.

It's always a good suggestion that you try to use wireshark or any of those log tracking apps to see where does your call drops .. attach it here if you can to let us see as well.

good luck

As long as your provider is competent, you should not need an SBC.

I would start with a packet trace on the SfB server when you are trying to make or receive a call.

Also make sure that the appropriate ports (TCP/UDP) are not blocked by the firewall on your SfB server.

More information about SBC from Microsoft:

https://blogs.technet.microsoft.com/nexthop/2013/07/08/what-is-a-session-border-controller-sbc-and-do-i-need-it/

I strongly suggest working together with your SP to avoid issues in the future. You're not their first SfB customer. They should guide you for a smooth SIP trunking experience on your end and on their end.

Can an SBC make configuration simpler ? Yes.
Is an SBC needed if the service provider knows how to provision for SfB ? No.
Can an SBC add additional complexity to an installation ? Yes.

The original reason to have SBC was back when vendors were touting SIP to SIP direct traffic, and SIP devices were not very good at traversing NAT ,but when you are only in effect replacing an ISDN PRI with an IP equivalent (with suitable firewall rules to only allow access to/from the service provider using only the required ports etc) the primary reason of not opening up your SIP server to the Internet goes away.

The secondary reason to use an SBC is to effectively act as a protocol converter, speaking the SIP tuned for your SIP server (in this case SfB) on the "LAN" side, and SIP for the service provider on the "WAN" side. If the service provider is unable to configure their side for your SIP server, I would suggest that a different service provider was used.... I would put media conversion in with this, your provider should be able of using the CODECs that suit you, to me it makes no sense to have to convert media to suit the provider...

A single hardware SBC also adds an additional single point of failure.

I'm actually quite a big "fan" of SIP, but there are issues with it, primarily that it was designed without any thought for NAT, and secondarily that the standard is very "loose" which allows for a lot more "interpretation" between different vendors, which can create interopability issues when two vendors can point out how their interpretation fits within the standard, but neither will connect directly to the other, but when one of teh vendors is a service provider, I would always put the interopability issue firmly in their court, unless they want to provide, support and maintain a device to resolve the issue, in which case, they might as well host it as well...

/rant

I'd love to work with the provider on this, but we actually are their first SfB client. They're local and have never done it. The info I gave above (about being set up like a Cisco Call Manager and having a Broadsoft switch) came from them.

I'll try to do a Wireshark trace tomorrow and will report back.

I hope I've done the WireShark capture properly. When I opened it it had not port 3389 in there already so that's what I tried to use. If I need to do something different, please let me know what steps I should take to get what you need.

Essentially I started the trace and attempted to place a call and then stopped. Attached is the output from WireShark.

I also had to rename the file as it would not take the pcapng extension that WireShark saved.

Thanks.
testcall.txt

I'm guessing that 10.0.91 is one side, and 10.0.1.249 is the other, but as it is using TLS, it is impossible to look at the SIP traffic.

I would suggesting not using TLS while you configure it to make sure that the basic things work, and then when they are working properly, make the change toTLS

I would also suggest that you used a capture filter to match the traffic rather then exclude RDP

https://wiki.wireshark.org/CaptureFilters

Presuming that you are capturing on your SfB server, the capture filter could just be the IP address of the provider .

Hi,
You cannot resolve this issue by yourself. Apparently there is an incompatibility between your SIP trunk setup and the SP.

I am sure the SP has an SBC. They cannot operate without it. They can see the SIP trace for your calls very easily on their side. They should be able to tell you to enable/disable options or change the format of your SIP URI, codec etc. These can be easily done on their SBC as well. SBC can fix literally any incompatibility issue between 2 domains.

If they setup your SIP trunk just like Cisco call manager, then you should start disabling encryption for your SIP trunk and RTP. Disable SRTP and SIP-TLS or any other encryption method. Cisco by default doesn't do encryption.

Codec is another typical issue. Cisco uses industry standard codecs such as G711 by default. SfB uses its own proprietary codecs by default. You need to have a mediation server to convert proprietary Microsoft codec to standard codecs *accepted* by your service provider. G711 and G722 are the most popular and widely supported codec in the world. The whole PSTN runs on G711/PCM. You can deploy the mediation server role on your front end server as well. Mediation server will convert the SFB codec to standard G711 on the SIP trunk to your service provider. Make sure you enable G711 and G722 codec on that outside SIP trunk that points from your mediation server to the SP. That's the safest option to start with.

Good luck.

I agree with Arne, you're apparently using TLS and in order to setup your system you should first use TCP and if everything works properly then setup TLS. now from the Wireshark we can't see anything because the traffic is encrypted ..

Unless you import the certificate+Key to the Wireshark and decrypt the traffic and send us the decrypted version we can't help :)

How do I change SfB to use TCP instead of TLS?

From SFB front end server, Open topology builder and under the mediation server change the config there. but before changing those and publishing the topology you'll need to ask your ISP or VoIP provider whether they are using TLS or TCP on their side too ..

So this is weird - under mediation server, it shows three trunk servers. All three of those are configured to use TCP.

So the problem is not from your side I would say.. it's from the other end which is your trunk service provider. they will need to use TCP for the time being to know the cause of the issue.

Anyways you can still use Skype for Business centralized logging services
https://technet.microsoft.com/en-us/library/jj688145.aspx

You could do this from powershell:
start-csclslogging -scenario incomingandoutgoingcall -pool yourpoolname
wait for it to start (will say scenario started for each server)

recreate the problem
stop-csclslogging -scenario incomingandoutgoingcall

wait for it to stop
search-csclslogging -outfile c:\mylog.txt

then look at that log in snooper.  You can also see all the built in scenarios with:
get-csclsscenario | select-object name


You can send the mylog.txt log to us after you have reproduced a problematic call which will be logged on Skype Server.

Service providers *never* use TLS for SIP trunks in a setup like yours. If in doubt, ask your SP. The issue seems to be on your side Mediation server SIP trunk.

Service providers *never* use TLS for SIP trunks in a setup like yours. If in doubt, ask your SP. The issue seems to be on your side Mediation server SIP trunk.

@Alex not sure where you're getting your information from but what you stated is not true. There are many trunk providers that provide TLS connectivity over sip trunk.
Plus I think TLS nowadays is growing to be a requirements more than it is an accessory.

https://technet.microsoft.com/en-us/office/dn788947.aspx?f=255&MSPPError=-2147217396

Attached is the output "mylog.txt" that was requested.
mylog.txt

@Mohammad  I am firm with my comment "Service providers *never* use TLS for SIP trunks in a setup like yours. If in doubt, ask your SP."  

He is getting the SIP trunk over a private network. Only a CLEC SP that provides SIP over public internet may offer encryption. In your list, check all real telcos. Do didn't even bother "qualifying *testing *"  SIP TLS/srtp. Enterprise and service provider world are different. Most people have no or little clue about the SP... No wonder it is called "the cloud", people cannot see what's inside.

Can anyone confirm if the log was helpful or not on this?

Sorry forgot to answer this, could you please send the IP of your Skype Server, Gateway IP, the tel URI/Nubmber you called from and to .. and which time if you can still remember? I can see this message which is a good indication that we have a problem that needs to be fixed
"Non-trusted source sent an FQDN/IP that doesn't match a routing table rule"

I think you probably didn't correctly added the gateway IP to the topology or it's added but not published and your dial plan/trunk is not properly configured too.

No worries. Here's the info you requested:

IP of Skype Server: 10.0.0.91
Gateway IP: 10.0.0.1
Telephone # Called: 8004377950
Time of Call: 1/27 4:13PM (EST)

The from phone # I'm honestly not sure of.

I guess there is a port and protocol misconfiguration going on.. I can see the call failed with a failed to connect to Lync Server using TLS ..

Could you please attach an image of your Skype for Business topology .. along with their configuration.

- Mediation Pools
-PSTN Gateways
- Trunks

Also could you please ask your VoIP service provider of how they configured the sip trunk ? İs it using TCP/UDP and on which port the trunk is bind?

On Lync server/Skype server run CMD as administrator and type the following too
netstat -anbo >c:\netstat.txt
Open Netstat.txt on C drive and attach it here.

Via: SIP/2.0/TLS 10.0.2.40:55383;ms-received-port=55383;ms-received-cid=A00
Content-Length: 0
ms-diagnostics: 1038;reason="Failed to connect to a peer server";ip-address="10.0.0.91";peer-type="InternalServer";winsock-code="10061";winsock-info="The peer actively refused the connection attempt";source="MEMC-LYNC.memco1.moores.memc"
Authentication-Info: TLS-DSK qop="auth", opaque="75946AFB", srand="9A302E95", snum="284", rspauth="74418e80c3d0c23755106c78135fdd2cbcf3fbda", targetname="MEMC-LYNC.memco1.moores.memc", realm="SIP Communications Service", version=4
Server: OutboundRouting/6.0.0.0

Select allOpen in new window

Hello,

I've finally gotten all of the info you asked for. It is as follows:

• Mediaton Pools, PSTN Gateways, and Trunks screenshots are attached.
• According to our SIP provider, the Call Manager uses UDP protocol on port 5060.
• I've also attached the netstat.txt file that was requested.

Let me know what other information you need. I greatly appreciate the help in getting this running.
Mediaton-Pools.png
PSTN-Gateways.png
Trunks.png
netstat.txt

Hi, 5060 is the default port anyway. Can you please share the service provider's SIP trunk product guide? It will list all supported options.

Your mediation service is using both TCP and TLS, TCP is bind on 5060 but no service is listening on it so there's a problem with your Skype Services. it might not be started .. You need to check if Mediation service is actually started or stopped..

Neither your TLS port 5059 have any listening service .. did you run Setup or Remove Skype For business components?
Your MediationServerSvc.exe service is not in the list of processes ... that's why your having issues apparently.

Here's what mine looks like
mediationservice.jpg

You're right, for some reason the "Skype for Business Server Mediation" service wasn't running. I was able to start it and test a phone call, but still no joy. I've re-attached the netstat.txt file so you can see that it's listening now and perhaps see what else is wrong.
netstat.txt

You have an issue with your mediationservice apparently. the service is not listening on any port as if there's something not letting it listening on port 5060..

Could you change your mediation service's TCP port from port 5060 to 5068, restart the service , publish topology and inform your service provider of this change? let them change the destination port on their end so they can send you calls on the right port..

If they can't do this then just change the port, publish the topology, change it back to 5060 , publish the topology again and each time your publish the topology restart the Mediation service ..

After last change please share your netstat again

It's a little bit different of a look, but is that not it listening on 5060 on line 709?

That's your sip trunk's IP from the provider. mediation service should be using Lync server's local IP not public IP.

Could that be the issue? Where is that checked/changed?

Your topology looks right, but what I am assuming is that another topology XML file might be published to Lync server.. If you re-publish the current topology which you have sent screenshots from I think it should be ok .. restart mediation service after t hat.

Could this be the problem? I was trying to tell SfB to use the LAN port that's connected directly to our SIP Provider, but I may have done that improperly.
PSTN-Gateway-Properties.png

I just re-published that topology and restarted the mediation service. Attached is a fresh netstat.txt.
netstat.txt

No nothing changed, you have an issue with the server.. I guess the best thing to do is change the port on the TCP port to 5068 in this screenshot that you sent, publish the topology .. restart mediation service and see if mediationservice is listening on 5068 or not.

You might need to restart the server
https://filedb.experts-exchange.com/incoming/2017/02_w07/1145677/Mediaton-Pools.png

Okay, I changed the port in the screenshot you referenced, and I changed it again at the trunk level. Should I have changed both fields on this screen or just the one it forced me to change?

I only changed the one for now and restarted the mediation server. Attached is a new netstat.txt.
Trunk-Properties.png
netstat.txt

Since we'll have no more activity here, I'm going to close the question.