Today a colleague of mine was having an issue with ring back on calls originating from the PSTN to Lync. You would basically here dead air or if you listened close enough you could hear the “Comfort Noise”.
The PSTN connectivity is being provided by Comcast via a SIP trunk that terminates to an Adtran. From the Adtran there is a T1/ESF/B8ZS trunk to a Sonus UX 1000. The Sonus is configured to pass calls to the mediation server in Lync Server 2013.
When a call was placed to a Lync Enterprise Voice user from the PSTN you would not hear ring back and you could hear comfort noise if you listened hard. In the UX log traces we saw the SIP 180 and 183 messages being sent and received. The issue was related to a SIP 180 being sent back to the T1 and the T1 not understanding it. T1’s view ringing as an “Alerting” message as defined in RFC 4497 Interworking between the Session Initiation Protocol (SIP) and QSIG and based on the RFC a SIP 180 should be sent as a QSIG Alerting message to support ring back:
8.3.4. Receipt of QSIG ALERTING Message
The gateway SHALL map a QSIG ALERTING message to a SIP 180 (Ringing) response to the INVITE request. If the SIP INVITE request contained either a Require header or a Supported header with option tag 100rel, the gateway SHALL include in the SIP 180 response a Require header with option tag 100rel.
The resolution to this is to implement a “Message Translation” table and add the following rule:
This is basically stating that when a SIP 180 is received to send out a corresponding QSIG Alerting message.
Just creating this table does not address the problem. Once the table has been created you need to assign it to the Call Routing Table
Once we completed this ring back worked as it should. This seems to be related to the unique setup of the Comcast SIP trunk being terminated to the Adtran then converted to T1 back to the Sonus. If this was common we would see this a lot more in typicall configurations since it is very common to have a T1 terminate to a UX.