SIP Trunking 101 with Lync Server 2013

I will start this blog post with a caveat: it is huge and more of a beginners encyclopedia of Lync SIP trunking configuration and troubleshooting tips than a blog post! It also adds some new specific Lync Server 2013 configuration information to the existing information available on configuring a SIP trunk with previous releases of Lync Server.

It includes some great tips on getting up and running with a SIP Trunk and I am hoping it is one of the best troubleshooting reference for Lync Server and SIP trunk connectivity available. If you are familiar with SIP trunking and Lync and are having some issues, you might want to skip ahead to the sections “Noteworthy Configuration Tips” and “Troubleshooting Tools and Tips”. Here are some particularly useful tips you might want to check-out below:

    • Problems with older Firewalls or Gateways Mangling SIP Packets
    • The "Enable outbound routing failover timer” Setting on the Lync
    • NAT IP addresses at the Session Description Protocol (SDP) level
    • Allowing Lync clients to transfer inbound calls from the SIP Trunk

Configuration Used in this Article

This post focuses on the practical steps required to get a simple SIP Trunk to work with Lync 2013 with the most basic scenario:

  1. One Lync Server 2013 Enterprise Pool and One Lync Server 2013 Mediation Pool – each with one server.
    • It is possible to also configure a SIP trunk with a Lync 2013 Mediation server collocated with the front-end, but this is not recommended for production scenarios, and depending on your scenario it could pose a security risk.
  2. Unencrypted Traffic. For this basic setup the SIP signaling and media is not encrypted. When you move into production, it is recommended to encrypt the traffic.
  3. A SIP Trunk over a Public Internet Connection. In this configuration, the Mediation Server connects to the SIP trunk by using a direct Internet connection. Unlike the private and VPN options, this topology does not leverage an isolated link to the SIP trunk.
  4. A Lync 2013 Mediation Server with 2 NICs.  One NIC is connected to the external Internet through a Firewall (which has network connectivity to the SIP trunk), and the other NIC is connected to the internal LAN.
  5. A SIP Trunk from IntelePeer.  This configuration uses a Lync SIP trunk from IntelePeer (you can read more about their SIP trunk offering for Lync 2013 here: http://www.intelepeer.com/SIPTrunking-microsoft-lync).  You can purchase a Lync SIP trunk from other vendors and here are some tips:
    • Pick a vendor that is on Microsoft’s list of Services qualified for Microsoft Lync. This helps ensure there will be no interoperability issues.
    • Some SIP trunking providers require a piece of hardware called a Session Border Controller (SBC) whereas other vendors can connect their SIP trunk directly to a Lync Mediation server (usually through an external firewall).

Here is a simplified diagram of the call flow:

image

What’s Changed in Lync Server 2013 for SIP Trunking?

Rather than focus on the steps to get up-and-running with Lync Server and a SIP trunk, I will focus on what has changed with Lync Server 2013 which supplements the excellent article that fellow MVP Brian Ricks wrote for NextHop: Configuring an IntelePeer SIP Trunk Solution in Lync Server 2010. Not a lot has changed in Lync 2013, so I recommend following the steps outlined in Brian’s NextHop article if you are not familiar with Lync server voice routing, and then read this article for tips and troubleshooting information.

To provide the new capability in Lync Server 2013 of “M: N trunk routing” (that is, the ability for any number of Lync Trunks to be paired with any number of Lync Mediation servers), Lync Server 2013 introduced “Trunks” as a component that can be defined in the topology as shown here:

image

Your first step in the Lync configuration side will be to define a Lync SIP trunk and associated PSTN Gateway that will be used to route the call to the SIP trunk.  Here are some important tips:

  1. Trunks are Logical entities. The topology definition of a Lync trunk (and the associated Lync trunk configuration) are logical entities. The physical connectivity is established through the the Associated PSTN Gateway that you specify when defining the trunk. It follows then, that you need to define an associated PSTN gateway before you can define the trunk in the Topology.
  2. The PSTN Gateway is the External SIP Trunk. Don’t let the terminology confuse you. In the Lync Topology Builder, the PSTN Gateway that you associate with the trunk is the external SIP trunk. When you define a new PSTN Gateway, just enter the external IP of the SIP trunk (given to you by your provider) as the gateway FQDN.  Note: the trunk can be defined in the same wizard that you used to create the PSTN Gateway.
  3. Configure the Trunk through the Lync Control Panel. Many people get confused because there is now a trunk definition in the Topology Builder and a Trunk Configuration in the Lync Control Panel. The trunk definition in the topology just contains basic connectivity information (e.g. physical gateway, what mediation pool to associate with, etc…).  An associated trunk configuration in the Control Panel allows you to configure how the trunk is used and configured at protocol level. See the step “Defining the SIP Trunk Configuration in the Lync Control Panel” for more information.

Adding the SIP Trunk to the Lync Topology

As mentioned above, to add the SIP Trunk to the Topology as a new PSTN Gateway, add a new PSTN Gateway as follows in Topology Builder:

  1. Define the PSTN Gateway FQDN = IP Address of the external SIP Trunk
  2. Define the Root Trunk (the associated trunk can be defined at the same time you create the PSTN gateway)
    • Trunk Name: <IP address of the SIP trunk>
    • Listening port for IP/PSTN Gateway: 5060   (in this case unencrypted TCP is being used; use 5061 for TLS encrypted)
    • Transport: TCP
    • Associated Mediation Server:  <Lync Front End Pool + Lync Site>
    • Associated Mediation Server port:  5060

* Don’t forget the publish the topology and make sure the Mediation server has picked up the changes (see “If I Make a Routing Change in the Lync Control Panel, How do I Know if my Mediation Server Picked Up the Change?” below for more information on this).

Defining the Associated SIP Trunk Configuration in the Lync Control Panel

Under the Voice Routing panel, click on the “Trunk Configuration” heading, and define a new Pool trunk.  With a Pool trunk, you will be able to associate the trunk with the PSTN Gateway defined in your Topology that represents the SIP trunk.

The the New Trunk configuration dialog is show here:

image

In my experience, four settings that you want to pay particular attention to are:

  1. Encryption support level: this identifies what encryption (if any) will be made on the media traffic. They key is, you need to match whatever your peer SIP trunk is configured for. Note that encryption will use TLS which requires certificates.
  2. Refer support: in my experience, setting this option to “Enable sending refer to the gateway” will allow the caller-ID to be passed through to the SIP trunk and on to the called party.
  3. Centralized media processing:  this indicates to Lync that the SIP trunk peer uses the same IP address for media as it does the SIP signaling. If you are having trouble getting Lync audio working, but the call is established, try enabling this if it is not already enabled.
  4. Enable outbound routing failover timer: when enabled, the SIP trunk has 10 seconds to tell Lync that the call has been processed or else the call get’s dropped.  Lync Server 2010 did not have this setting.
  5. Associated PSTN Usages:  this instructs Lync to only allow calls through this trunk the match the PSTN usages listed here.

Note: all the Lync Trunk configuration settings are defined here: Microsoft TechNet – Configuring Trunks.

Finishing your Topology Changes and add the Lync Voice Routing Changes

For the rest of the required Topology changes and Lync voice routing additions, the steps outlined in Brian Rick’s article still apply for Lync Server 2013: http://blogs.technet.com/b/nexthop/archive/2011/04/21/configuring-an-intelepeer-sip-trunk-solution-in-lync-server-2010.aspx.

Noteworthy Configuration Tips

This section outlines some important configuration and troubleshooting tips.

Do you need to define a Lync Server 2013 SIP Trunk in the Lync Control Panel?

A common question is: once I have the SIP trunk defined in my Topology, do I need to define an associated Lync Trunk Configuration in the Lync Control panel?

In theory “no” because there will always be a Global Lync trunk that will be used. In practice though the answer is “yes” – you should because it enables you to control the Lync configuration for calls intended specially for the SIP trunk.

This Microsoft Technet article has all of the information you need to know to Configure a SIP trunk in Lync 2013: Configuring Trunks.

Problems with older Firewalls or Gateways Mangling SIP Packets

You can save yourself many potential headaches by using hardware (e.g. SIP-PSTN Gateways) that have been certified by Microsoft for PSTN integration by visiting the Microsoft Infrastructure qualified for Microsoft Lync web site.

Unfortunately that interop program does not cover firewalls, and some firewalls like to mess with SIP packets!

For example, several model’s of the older Cisco PXE firewalls will be configured to do a “inspect sip” or a “fixup protocol sip” on the SIP packets. In my experience this will cause the inbound packets to be mangled. You will first noticed this problems with ‘NO RESPONSE’ errors to SIP OPTIONS messages in the event log on Lync 2013 Mediation server. The Mediation server is sending the OPTIONS requests but not receiving the replies because the SIP packets are getting mangled.

I have read this can also be a problem with interoperability between Lync and Asterisk PBX’s.

The fix is to remove the command “inspect sip”, “fixup protocol sip”, or any other packet manipulation on the firewall.

I have read about older SIP-PSTN Gateways with packet manipulation capabilities, so you might want to check that if your are using a Gateway between Lync and the SIP Trunk.

A Lync Edge Sever is only needed to Support SIP Trunk Calls for External Lync Users

If you start searching the Internet and forums for problems with Lync SIP trunk configurations, you will run into several errors and references to the Lync Edge server.  To save yourself some time, the Lync Edge is only used to support external Lync users. The Edge Server allows the Mediation Server to interact with users who are located behind a NAT or firewall – external to the organization.

An Edge is not required to provide call connectivity over a SIP Trunk for Lync users inside your network as long as an Internet Telephony Server Provider’s Session Border Controller (SBC) is configured to receive traffic from any Mediation Server in the pool, and can route traffic uniformly to all Mediation Servers in the pool

A good overview of a SIP trunk implementation can be found in the Microsoft TechNet article: How Do I Implement SIP Trunking?

Note: if you are trying to configure the Edge to allow external Lync users to make calls over the SIP trunk, be sure to use the Set-CsMediationServer cmdlet.  This tells the Mediation server what Lync Edge server is used for external users.

Fellow Lync MVP Ståle Hansen recently blogged about this. See his post “No media connectivity with Lync Server 2010 collocated mediation server and external users” for more information.

Check the "Enable outbound routing failover timer” Setting on the Lync Server 2013 Trunk if the Call is Dropping After a Successful Connection

This Lync trunk setting requires that the SIP Trunk notifies Lync within 10 seconds that it is processing an outbound call from Lync. Some SIP trunks will either not provide this notification, or are not able to get it back to the Lync server within 10 seconds.

In this case the call will drop in about 10 seconds and a “SIP/2.0 487 Request Terminated” will appear in the Lync server SIP transaction logs (more information on this error is in the troubleshooting section).

Here is the explanation of the failover timer setting in the Lync 2013 trunk:

Enable outbound routing failover timer should be selected to enable fast failover. The gateway associated with this trunk can give notification within 10 seconds that it is processing an outbound call. Rerouting to another trunk will occur if this notification is not received by the Mediation Server. On networks where latency may delay the response time or the gateway takes longer than 10 seconds to respond, the fast failover should be disabled..

This setting is enabled by default.  Disabling it will solve your issue.

Explicitly Setting the Audio Port Range on the Mediation Server is not Always Required

The audio port range used by the Lync Mediation server can be configured with the Set-CsMediationServer

cmdlet. For example, IntelePeer requires ports 5000 thru 65535 to be used for the RTP Audio.

The Lync 2013 Mediation server defaults for the port range are 49152 to 57500. I have not needed to change the default Mediation audio port range to successfully do SIP trunking however. As such, I am not clear when the port range need to be explicitly configured on the mediation server, but I have not had problems, even when the port range used by the SIP trunking audio is much larger than what the default port range.

If you do need to set a custom port range on the Lync Mediation server, the cmdlet to do it would look like this:

Set-CsMediationServer -Identity "MediationServer:<Lync Pool FQDN" -AudioPortStart 5000 -AudioPortCount 60535

If you do explicitly set the audio range to a custom port range, remember to allow for CMS replication restart the mediation server service so that the Lync mediation server picks up the change.

You can see the existing settings used for the Mediation Server with the cmdlet “Get-CsService –MediationServer”.  Here is an example:

Identity             : MediationServer:<Lync Pool FQDN>
Registrar            : Registrar:<Lync Pool FQDN>
EdgeServer           : EdgeServer:<Lync Edge Server FQDN> 
SipServerPort        : 5070
SipClientTcpPort     : 5060
SipClientTlsPort     : 5067
AudioPortStart       : 49152
AudioPortCount       : 8348
DependentServiceList : {PstnGateway:<IP G/W 1>, PstnGateway:<IP G/W 2>}
ServiceId            : 1-MediationServer-4
SiteId               : Site:<Lync Site> 
PoolFqdn             : <Lync Pool FQDN> 
Version              : 6
Role                 : MediationServer

If you detect a port conflict (either on the SIP signaling or Media Port), you can use this command to see what IP address have are using specific ports:

netstat -ant

netstat –ant | finder 5060  (to find references to port 5060)

Allowing Lync clients to transfer inbound calls from the SIP Trunk

In most SIP trunking scenarios the associated Lync SIP trunk needs to have the “refer” value set to False to allow a Lync client to transfer an incoming call to another number. For example, when the Lync user wants to transfer an incoming call to their cell phone.

You can do this through Lync PowerShell by setting the ‘EnableReferSupport’ parameter to $false on the Set-CsTrunkConfiguration cmdlet:

Set-CsTrunkConfiguration –Identity Service:PstnGateway:IP_Address  -EnableReferSupport $false

This is particularly important to remember in scenarios when moving to a SIP trunk from an existing PRI such as a T1. The ability to “refer” (aka transfer) a call could be set on the existing trunk and users will expect the same functionality after the transition to a SIP trunk is complete.

 

Troubleshooting Tools and Tips

This section details the best tools to use to troubleshoot SIP trunk issues, and how to resolve some common problems.

Tools of the Trade

  1. Microsoft PortQryUI
    • http://www.microsoft.com/en-ca/download/details.aspx?id=24009
    • PortQryUI is the GUI version of the free Microsoft utility for PortQry command line port scanner utility which shows the port status of TCP and UDP ports on the remote computer specified.
    • This tool is most useful to test the ports that should be open on your firewall.  It is best to run it on a computer outside of your network with access to the firewall and you can use it to ensure TCP port 5060 (or 5061) and the UDP ports used for the media or available.
  2. Free Online Port Scanners
    • If you need to do some quick port checking and do not have access to a Windows machine outside your network to run PortQry, a good alternative are online port scanners which run on a web server on the Internet.
    • You can enter the IP address of your firewall and the port(s) that you want to query and run the query from the remote web site. Do a Bing search for “online port scanner” and pick one that seems reputable.
  3. OCSLogger & Snooper
    • OCSLogger can be used to set server-side logging to debug SIP trunking activity.
    • The Lync 2013 Centralized Logging service will also give you debugging information, but to show details of the SIP protocol, I find OCSLogger and it’s log analysis counterpart tool, Snooper, the best.
    • These two tools now ship in the Microsoft Lync Server 2013 Debugging Tools; in Lync Server 2010 they were part of the resource kit.
  4. WireShark
    • http://www.wireshark.org/
    • If you experience network connectivity issues that cannot be figured-out at the SIP or Lync server logging levels, you may need to capture network activity on the wire. Hopefully it won’t come to that, but if it does, WireShark is one of the best network troubleshooting tools available.
    • You will want to run WireShark on the Lync Mediation Server.
  5. The Test-CsPstnOutboundCall Lync Test Cmdlet
    • This test cmdlet is available in the Lync Management Shell and is good for quick outbound test calls to identify any high level problems.
    • Caveat: I have had some cases where the error messages returned by this cmdlet masked the real problem.
    • Here is a quick sample of how to use this cmdlet:

      $cred1 = Get-Credential "domain\LyncUser1"

      Test-CsPstnOutboundCall –TargetFqdn LyncPool.domain.com -TargetPstnPhoneNumber "123 456 7890" -UserSipAddress "sip:LyncUser1@domain.com" -UserCredential $cred1

Specific Troubleshooting Tips

This section details some hard learned lessons which will hopefully save you time.

OCSLogger Categories to Select to Debug SIP Trunk Issues

Here are the categories I found most useful to debug connectivity and configuration issues with a SIP Trunk.

On a Lync 2013 Standalone Mediation Server

image

On a Lync 2013 Front-End Server

image

No SIP Protocol Messages Show up in the Lync Server 2013 Version of Snooper

There have been several reports of Snooper not showing any SIP traffic despite the appropriate categories being selected.

As of April 30, 2013 Microsoft is aware of this issue and is investigating. It is not known whether this issue is environmental or a bug

If I Make a Routing Change in the Lync Control Panel, How do I Know if my Mediation Server Picked Up the Change?

You may be wondering this especially if you are running a standalone Mediation pool. The key is to look for Event ID 3013 “LS Replica Replicator Agent Service” in the event log on the Mediation server.  It looks like this.

image

Outbound SIP Error: SIP/2.0 487 Request Terminated

While making an outbound call, if you experience the scenario where the call rings through but then terminates shortly afterwards and the following SIP error appears in Snooper:

ms-diagnostics-public: 5025;reason="Cancel sent by application for INVITE client transaction.";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FOutboundRouting"

ms-diagnostics-public: 5011;reason="ACK is being generated on receipt of a 487 canceled response for an INVITE forked by application";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FOutboundRouting"

One likely possibility is that the “Enable outbound routing failover timer setting” is set in the Lync trunk configuration and it should not be. See the ‘Check the Enable outbound routing failover timer” Setting on the Lync Server 2013 Trunk if the Call is Dropping After a Successful Connection’ previously in this article for more information.

Event Log Error: “14613, LS Protocol Stack”

Sometimes debugging is to know what not to pay attention to.  I’ve yet to get to the bottom of this error, but the SIP Trunk will work while this error is present on the Lync Enterprise Front-End server. I believe this is not specific to a SIP trunk configuration. The event log error is shown here:

image

Outbound Error: 403

This is a very common error that will appear in both the Lync client and in the SIP logs (e.g. using Snooper).

Generally a 403 means “forbidden” and in the context of an outbound call it usually means that the Lync user making the call (the caller) is not authorized to call the destination number. The reason is usually that the caller has not been configured to have the required PSTN Usage for the called number.

To resolve this error, ensure that the Lync user making the call is configured with a Lync server Voice Policy that contains a PSTN Usage record that the chosen Lync Voice Route maps to based on the called number.

A great way to test what PSTN usage will be used if a specific Lync user dials a specific number is the "voice routing test case” functionality in the Lync Control Panel.  This feature is somewhat hidden, so I have highlighted where in the Voice Routing panel you can find this functionality, and where the specific user information is populated:

image

Event ID 25051 – There was no response from a Trunk to an OPTIONS request sent by the Mediation Server.

This is a very common problem reported in the event log of the Lync 2013 Mediation Server.  The details of Event ID 25051 look like this:

The Trunk, {IP Address};trunk={IP Address}, is not responding to an OPTIONS request sent by the Mediation Server service.
Cause: The Mediation Server service cannot communicate with the Trunk Service over SIP due to network connectivity issues.
Resolution: Please ensure network connectivity and availability of the Trunk for the Mediation Server service to be able to function correctly.

The most likely cause is network connectivity – specifically the port configured for inbound SIP signaling is not open on the firewall (i.e. TCP Port 5060 or TCP Port 5061).

As part of normal operations the Lync 2013 Mediation server periodically sends a SIP OPTIONS message to the SIP trunk to ensure the SIP Trunk is able to service requests – similar to a heartbeat.  Event ID 25051 appears if the Mediation server has sent the request but did not receive a response.

To resolve this error, use the Microsoft PortQry tool, or an online port scanner and make sure that the SIP signaling port (TCP 5060 or 5061) is open on the firewall and the Mediation server is able to issue a response. Any port scanner utility should report a “LISTENING” status.

If the ports are open, another problem could be that the firewall or externally connected Gateway is mangling the inbound SIP packets. This problem is described earlier in this blog entry – see: “Problems with older Firewalls or Gateways Mangling SIP Packets”.

Outbound Error 503:  Gateway Not Available

This manifests itself as Event ID 46046 in the event log or a 503 response to the a call attempt in the Lync client or the Test-CsPstnOutboundCall cmdlet, and the details look like this:

A call to a PSTN number failed due to non availability of gateways.

Called Number: +1xxxxxxxxxx
Phone Usage: International All
Route: International All
CallId: 524d2e6d-b938-466e-b8b7-8f31d170d58a

Cause: All gateways available for this call are marked as down.
Resolution:
Verify that these gateways are up and can respond to calls.

This error can be deceiving.  The Lync Mediation role has the ability to * remember * when their was a prior failure to a particular trunk or gateway and if a call to that same trunk or gateway is attempted in a certain time frame, the Mediation server will immediately return this error without actually trying the call because it has flagged the gateway as down.

If you restart the “Lync Server Mediation” service, it will reset the “bad gateway” flag and you can try your call again. It is also supposed to reset after a specific amount of time, but in my experience with Lync Server 2013, it doesn’t.

Outbound: Event Log Error 10001

This is another common outbound error. The Lync client will show an error like this:

image

The details of the event log error will show:

ms-diagnostics-public: 10001;reason="Gateway did not respond in a timely manner (timeout)";component="MediationServer"

In a nutshell, the PSTN gateway associated with the SIP trunk which is responsible for handling the call is not reachable (i.e. unavailable).

Make sure you have restarted the Lync Mediation Service after adding the new SIP trunk to the topology and configured the ports on the Mediation Server.

This error will also be generated if Lync has marked the PSTN Gateway as down from previous failures. Restarting the Lync Mediation Service will solve this.

Outbound Error – “Busy Network”

This error can occur for several reasons. The experience is that the call initially rings through to the called party, but then it will drop and the Lync client will display an error like this:

image

This might manifest itself as a “Service Unavailable” in the snooper logs:

TL_INFO(TF_PROTOCOL) [0]1238.0C84::03/28/2013-21:48:26.505.00000082 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[3323817907] $$begin_record
Trace-Correlation-Id: 3323817907
Instance-Id: 17BB
Direction: outgoing;source="local"
Peer: <Peer IP>:62802
Message-Type: response
Start-Line: SIP/2.0 503 Service Unavailable
From: "Lync User 1"<sip:LyncUser1@domain.com>;tag=f75e2a3e27;epid=fd52f25f59
To: <sip:+16132701611@qms-l13.dev.kan.ca.qsft;user=phone>;tag=F5D5957753477DCEBB3D60994713111A
Call-ID: 649bee354cb24e8d86891483086008ce
CSeq: 1 INVITE
Via: SIP/2.0/TLS ….. :62802;ms-received-port=62802;ms-received-cid=3D300
Content-Length: 0
ms-diagnostics: 12000;reason="Routes available for this request but no available gateway at this point";source="<LyncServer FQDN>";appName="OutboundRouting"

If the call drops after a few seconds, you will want to check the “Enable outbound routing failover timer” setting in the Lync Server 2013 Trunk that you defined for the SIP Trunk.

Specifically, this setting will cause Lync to drop the call if it doesn’t complete it in 10 seconds. Some SIP trunks can take longer to setup the call, so you might need to disable this settings. This is described further previously in this blog entry under “Key Tips”.

Inbound Issue: No Inbound Audio and a SIP/2.0 400 BAD Request

If an inbound call rings through to the Lync user, but no audio can be hear from the caller, in my experience there are three potential problems.

  1. The Inbound Media Ports are not Opened on the Firewall.  The most obvious cause is that the media ports are not open on the firewall. A network port scanning tool should be used to verify that the port range that the SIP trunk uses to send the audio through is opened.
  2. Centralized Media Processing needs to be Enabled on the Associated Lync SIP Trunk.
    • This setting in on the Lync trunk tells Lync that the IP address for the SIP trunk used for the media is the same as the IP address on the SIP trunk that is used for the SIP signaling.  If the IP addresses are the same, and this is not set, you will experience audio issues – specifically no inbound audio in my experience.
    • You can see all the Lync Server 2013 Trunk configuration settings on Microsoft Technet here: Modify SIP Trunk Configuration Settings.
  3. The external Firewall is not configured (or does not support) the ability to NAT IP addresses at the Session Description Protocol (SDP) level.
    • This problem can easily be configured by doing a packet capture on the SIP trunk side. If the IP address used in the out-going Lync SDP requests are the internal NIC of the Lync Mediation server there is no NAT being done. Most SIP trunks require require the public IP (of the firewall or externally connected gateway) in the SDP layer.
    • Many older firewalls from certain manufactures (such as the Cisco PXE 515e) do not NAT at this level.  Some SIP Trunk providers such as IntelePeer are able to NAT it on their end, and this will resolve the issue.
    • As mentioned above, the hallmark flag for this issue is a SIP/2.0 400 BAD Request in the Snooper logs:

SIP/2.0 400 BAD Request

TL_INFO(TF_PROTOCOL) [0]1388.2388::04/24/2013-19:09:55.121.0001ca88 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2420.idx(196))[1487080697] $$begin_record
Trace-Correlation-Id: 1487080697
Instance-Id: 101E
Direction: incoming
Peer: <Lync mediation server>:5070
Message-Type: response
Start-Line: SIP/2.0 400 Bad Request
FROM: <sip:LyncPoolFQDN>;tag=78487B30899D015765DB0B0D60A1A729;ms-fe=LyncFrontEnd_FQDN
TO: <sip:LyncMediationServerFQDN>
CALL-ID: 9F3C3F68F0322050961C
CSEQ: 1 NEGOTIATE
VIA: SIP/2.0/TLS 10.4.49.177:53575;branch=z9hG4bKC5687AD3.FB2A5CCBDD249253;branched=FALSE
CONTENT-LENGTH: 0
REQUIRE: ms-compression
ms-negotiate-data: LZ77-64K

 

References

These are the best references I found to get up-and-running with Lync Server 2013 and a SIP Trunk:

Source What It Gives You
Microsoft NextHop – Configuring an IntelePeer SIP Trunk Solution in Lync Server 2010 A very useful article similar to this one for getting a SIP Trunk working with OCS 2007 R2.
JaapWesselius.com – Installing Lync Server 2013 Mediation Server A good article on installing the Lync 2013 Mediation server and establishing call connection with a SIP Trunk.
Microsoft TechNet – Modify SIP Trunk Configuration Explains the specific settings for a Lync 2013 SIP Trunk in the Lync Control Panel.
Microsoft TechNet – Mediation Server Component Covers the main functions of the Lync Mediation server used SIP Trunking.
Lync Server Forums: Disable Lync SIP OPTIONS Requests A good thread which describes the Lync Mediations server’s behavior or issuing an OPTIONS request to determine if a Gateway is available.
Microsoft TechNet – Deploying Mediation Servers and Defining Peers A good starting point reference.
Microsoft TechNet – How Do I Implement SIP Trunking? The basics of SIP trunking including the various possible SIP Trunk connection types and bandwidth requirements available to Lync Server.
Services qualified for Microsoft Lync Microsoft’s official list of vendors that a certified to provider SIP trunk services.
Be Sociable, Share!

13 comments to SIP Trunking 101 with Lync Server 2013

  • Kim

    Thanks for a great article for Lync 2013

  • Lars Weimar

    Hi Curtis

    Thank´s for reply!

    > Does outbound calls from Lync to CUCM work? That will tell a lot.
    –> No, this should be a one way trunk. CUCM to Lync. We will provide to call in a meeting from CUCM.

    >1] The associated Lync 2013 Trunk configuration has a setting called “Enable forward P-Asserted-Identity data”. If it is not set, I would try enabling it (and restarting the mediation service, etc…). I see in the log file that the proxy side terminates the session with this message: “Send back P-Asserted-Identity header to Proxy with displayname: “[none]”.
    –> I can not find the “Enable forward P-Asserted-Identity data” setting. This is the get-csTrunkConfiguraion:
    Identity : Global
    OutboundTranslationRulesList : {}
    SipResponseCodeTranslationRulesList : {}
    OutboundCallingNumberTranslationRulesList : {}
    PstnUsages : {CUCM PSTN Test}
    Description : Global Trunk Settings
    ConcentratedTopology : True
    EnableBypass : True
    EnableMobileTrunkSupport : False
    EnableReferSupport : False
    EnableSessionTimer : True
    EnableSignalBoost : False
    MaxEarlyDialogs : 20
    RemovePlusFromUri : False
    RTCPActiveCalls : False
    RTCPCallsOnHold : False
    SRTPMode : Optional
    EnablePIDFLOSupport : False
    EnableRTPLatching : False
    EnableOnlineVoice : False
    ForwardCallHistory : False
    Enable3pccRefer : False
    ForwardPAI : False
    EnableFastFailoverTimer : True
    EnableLocationRestriction : False
    NetworkSiteID :

    And the Get-CsTrunk:

    Identity : PstnGateway:callmanager.adcrestron.eu
    MediationServer : MediationServer:Mediation.demo.crestron.eu
    AlternateBypassId : 0532ecb6-270b-4997-833b-185f6d603298
    Routable : False
    Default : True
    RepresentativeMediaIP :
    GatewaySipClientTcpPort : 5065
    GatewaySipClientTlsPort :
    DependentServiceList : {}
    ServiceId : 1-PstnGateway-11
    SiteId : Site:DemoSite1
    PoolFqdn : callmanager.adcrestron.eu
    Version : 6
    Role : PstnGateway

    > 2] Is your transport configured to use TCP or TLS? TLS is obviously more secure but to figure out whether it is a TLS settings (e.g. certificates) you can configure the Lync and Cisco side to use TCP.
    –> It is TCP (the cucm version doesn´t support TLS)

    > 3] Ensure that Lync and Cisco are configured to use a common Codec. G.711 is a commonly supported audio codec on both sides. Check your Cisco and Lync configuration to make sure they are using a common codec. I do not think this is the issue because I believe the error message would point that out.
    –> we configured ulaw and alaw g.711

    I will look for the “Enable forward…” setting. Do we need able to do call´s from Lync to CUCM to get a working inbound dial?

    Greetings Lars

  • Lars Weimar

    Hi

    I connect a Cisco CUCM with trunk configured to a Lync2013 enviroment. If I do a call from CUCM to Lync, the call signalling at endpoint (Lync Client) and after pickup, I get a busy tone at CUCM. The log at Lync seems always the same error. empty SDP answer:
    ——————-
    TL_INFO(TF_COMPONENT) [1]0954.0D4C::10/25/2013-14:18:24.998.00004566 (MediationServer,ProxyCall.MediaSessionAgentSyncCallback:871.idx(5004))[28109074]28109074MediaSessionAgentSyncCallback called with Notification (MediaReceivedFromPeer), Reason (ReceiveStreamActive).NULL
    () [1]0954.0CD4::10/25/2013-14:18:25.073.000046d7 ((Shared),RtcPalSocket::Initialize:1494.idx(124))[0x000000001E5A8B10]AddressFamily=2 Protocol=17
    () [1]0954.0CD4::10/25/2013-14:18:25.073.000046da ((Shared),RtcPalSocket::Initialize:1494.idx(124))[0x000000001E5A8BD0]AddressFamily=2 Protocol=17
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.178.00004ae8 (MediationServer,MediationMedia.CreateMediaSender:990.idx(192))[47624634]47624634Creating MediaSender. NULL
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.179.00004b00 (MediationServer,MediaAsyncResultT.MakeCallback:123.idx(696))(00000000031CAA77) Owner: External callback=
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.179.00004b19 (MediationServer,GatewaySDP.SetAvailableLocalCodecs:2281.idx(331))[47624634]47624634Stack returned 2 enabled codecs (8 0 ) on the gateway side.NULL
    TL_INFO(TF_PROTOCOL) [1]0954.0AD4::10/25/2013-14:18:25.179.00004b1b (MediationServer,GatewaySDP.GetOffer:2281.idx(222))[47624634]47624634Send INVITE / reINVITE to Gateway with SDP: v=0
    o=- 12 1 IN IP4 10.32.1.131
    s=session
    c=IN IP4 10.32.1.131
    b=CT:1000
    t=0 0
    m=audio 50154 RTP/AVP 97 101 13 0 8
    c=IN IP4 10.32.1.131
    a=rtcp:50155
    a=label:Audio
    a=sendrecv
    a=rtpmap:97 RED/8000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=rtpmap:13 CN/8000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=ptime:20
    NULL
    TL_ERROR(TF_COMPONENT) [1]0954.068C::10/25/2013-14:18:25.189.00004bba (MediationServer,GatewaySDP.SetAnswer:2281.idx(965))[47624634]47624634Empty SDP answerNULL
    TL_ERROR(TF_PROTOCOL) [1]0954.068C::10/25/2013-14:18:25.189.00004bbb (MediationServer,GatewayCall.GatewayParticipateComplete:1879.idx(2307))[47624634]47624634SDP Exchange Exception: Microsoft.RTC.MediationServerCore.MCSignalingException: Gateway SDP Neogiation Error: Empty SDP answer
    at Microsoft.RTC.MediationServerCore.GatewayCall.GatewayParticipateComplete(IAsyncResult ar)NULL
    TL_INFO(TF_COMPONENT) [1]0954.068C::10/25/2013-14:18:25.290.00004ee4 (MediationServer,ProxyCall.TerminateSession:871.idx(3807))[28109074]28109074Send back P-Asserted-Identity header to Proxy with displayname: “[none]” value: NULL
    TL_INFO(TF_PROTOCOL) [1]0954.068C::10/25/2013-14:18:25.290.00004ee5 (MediationServer,ProxyCall.TerminateSession:871.idx(3822))[28109074]28109074Terminating Proxy side call with session state: Connected, sip-response: 488, ms-diag: 10010, ms-diag reason: Gateway side Media negotiation failed.NULL
    TL_INFO(TF_COMPONENT) [1]0954.068C::10/25/2013-14:18:25.290.00004ee6 (MediationServer,MediaAsyncResultT.MediaAsyncResult:123.idx(368))(00000000032B0F40) Owner: , Microsoft.Rtc.Collaboration.AudioVideo.MediaSessionAgent+TerminateMediaSessionWorkitemAsyncResult created. External callback:, OperationId: NULL
    TL_INFO(TF_COMPONENT) [1]0954.068C::10/25/2013-14:18:25.290.00004ee8 (MediationServer,MediationCall.Terminate:1017.idx(299))[47624634]47624634Mediation Call Terminate successfully.NULL
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.290.00004ee9 (MediationServer,MediaSessionAgent.TerminateMediaSession:738.idx(5501))(000000000089245D)28109074 Terminating media session, reason: MediaSessionTerminated
    $$END-MEDIATIONSERVER
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.290.00004eea (MediationServer,MediaSessionAgent.SetNextState:738.idx(5691))(000000000089245D)28109074 MediaSessionAgent state transition: Confirmed -> Terminated
    $$END-MEDIATIONSERVER
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.290.00004eeb (MediationServer,MediaAsyncResultT.MediaAsyncResult:123.idx(368))(000000000315AB28) Owner: , Microsoft.RTC.MediationServerCore.ProxyCall+BeforeDisposeMediaWorkitemAsyncResult created. External callback:, OperationId: NULL
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.290.00004eed (MediationServer,MediaAsyncResultT.MakeCallback:123.idx(696))(000000000315AB28) Owner: External callback=
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.343.00005015 (MediationServer,ProxyCall.MediaSessionAgentSyncCallback:871.idx(5004))[28109074]28109074MediaSessionAgentSyncCallback called with Notification (DisposeMedia), Reason (MediaSessionTerminated).NULL
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.358.00005065 (MediationServer,ProxyCall.MediaSessionAgentSyncCallback:871.idx(5004))[28109074]28109074MediaSessionAgentSyncCallback called with Notification (TerminateSession), Reason (MediaSessionTerminated).NULL
    TL_INFO(TF_COMPONENT) [1]0954.0AD4::10/25/2013-14:18:25.374.00005067 (MediationServer,MediaAsyncResultT.MakeCallback:123.idx(696))(00000000032B0F40) Owner: External callback=
    TL_INFO(TF_COMPONENT) [1]0954.0FB8::10/25/2013-14:18:25.374.0000509a (MediationServer,MediationMedia.DisposeConference:990.idx(111))[47624634]47624634Conference Disposed. NULL
    —————————–
    CUCM version 7.0.2.20000-5 and Lync2013.

    Do you have anny suggestions?
    Greeting Lars

    • I believe you are saying that the call rings through, but when the Lync client pickups up, the Cisco caller endpoint gets a busy dial tone.

      From the log you provided (which is really helpful) it looks like the SIP signaling is setup and it is the media negotiation (audio) that is failing – specifically Lync cannot establish audio back to the CUCM endpoint.

      Does outbound calls from Lync to CUCM work? That will tell a lot.

      I would check 3 things off the top of my head.

      1] The associated Lync 2013 Trunk configuration has a setting called “Enable forward P-Asserted-Identity data”. If it is not set, I would try enabling it (and restarting the mediation service, etc…). I see in the log file that the proxy side terminates the session with this message: “Send back P-Asserted-Identity header to Proxy with displayname: “[none]”.

      2] Is your transport configured to use TCP or TLS? TLS is obviously more secure but to figure out whether it is a TLS settings (e.g. certificates) you can configure the Lync and Cisco side to use TCP.

      3] Ensure that Lync and Cisco are configured to use a common Codec. G.711 is a commonly supported audio codec on both sides. Check your Cisco and Lync configuration to make sure they are using a common codec. I do not think this is the issue because I believe the error message would point that out.

      Hope that helps,
      Curtis

  • Tarakesh

    We had a 2010 setup, where a FE and the mediation server were collocated. We thought, the design would work for 2013 as well. Since it’s not and considering your setup, which is explained above, I would like to know, how to collocate the mediation and front end on a single server with 2 interfaces. How should I go about configuring the PSTN and trunk, as we are getting port sharing conflict error for mediation and PSTN gateway.

    Thanks in advance.

  • Well done. Nice to see someone update this subject for 2013. Now we need to see one for three node EE pool without using a hardware gateway/sbc local.
    John

  • Kenneth Polaski

    This last step helped me fix the dreaded “Gateway not responding” or “Peer state: Down”. It was the middle of the day and I could not restart the Lync FE but your tip did the trick. Thanks a bunch!

    “Make sure you have restarted the Lync Mediation Service after adding the new SIP trunk to the topology and configured the ports on the Mediation Server.”

  • Grant

    Thanks for this post. I was able to use to use your techniques to guide me to the answer to a tricky SIP trunk issue. Not that hard when you understand the concepts, but brutal when you don’t. thanks again.

  • [...] Vad ska man tänka på och vad har förändrats sen Lync 2010? [...]

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>