Fixing PSTN Music On Hold In Lync When AudioCodes M800 In Use


I was recently informed by one of the clients that i deployed Lync Server 2013, is having issues when calls put on hold. There were 2 issue. The first and major is that, when a call put on hold and retrieved, there’s no audio from caller end. It’s basically one-way audio. And the other issue is that Lync MoH no longer works. Meaning that the caller hears nothing but dead silence.

Given that the PSTN integration was done using a SIP Trunk, i suspected that the provider must have done a change on the trunk which cause the feature to break and cause one-way audio when calls put on hold.

Digging in to the M800 Sys Logs, it seems that when a call put on hold by Lync client, the hold method that Lync use is “Inactive”. Below is the Re-INVITE sent from Lync to M800.

INVITE sip:SD4tl71-vv9pmjn1vl07h0t6in0808cjov84opsv-7@10.0.0.154:5067;transport=tls SIP/2.0
FROM: <sip:+61732680000@uctect.com.au;user=phone>;epid=D273FA8C4C;tag=575613f4b
TO: <sip:0451984283@lyngw01.ac-onebox.com;user=phone>;tag=1c1714098312
CSEQ: 433019 INVITE
CALL-ID: b01bc354-481a-4faa-aa5f-e4d14b46c1a7
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 10.0.0.151:60001;branch=z9hG4bKb6b1af81
CONTACT: <sip:UC-FE.ac-onebox.com:5067;transport=Tls;ms-opaque=9928a17d8863ebef>
CONTENT-LENGTH: 469
SUPPORTED: 100rel
USER-AGENT: RTCC/5.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
v=0
o=- 34278 2 IN IP4 10.0.0.151
s=session
c=IN IP4 10.0.0.151
b=CT:1000
t=0 0
m=audio 51466 RTP/AVP 8 101
c=IN IP4 10.0.0.151
a=tcap:1 RTP/SAVP
a=pcfg:1 t=1
a=rtcp:51467
a=label:Audio
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:Y8xM2t1C3q2zKVguMXQW3TPExRfQX8Dy6YPV+xVK|2^31|2:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:35UmPksBksSuS3iCs+kjjTw2uruKKYS4ZRufvTYY|2^31
a=inactive
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16

The “Remote Hold Format” parameter in IP Profile configuration for both Lync and PSTN profiles are set to “Transparent”. Which means that the SBC will not do any modification and it will send the SIP traffic as-is to the PSTN.

Capture1

As suspected, The M800 uses “inactive” method when call put on hold which pretty much grantee that there won’t be MoH.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.0.0.158:5060;branch=z9hG4bKac1164951996
From: “Support” <sip:0892000000@ipsystems.com.au;user=phone>;tag=1c1718935812;epid=D273FA8C4C
To: <sip:0451980000@ipsystems.com.au;user=phone>;tag=SDu8t2799-1701991312-1456809140654
Call-ID: 1718912646132016131218@172.0.0.158
CSeq: 4 INVITE
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported: timer
Accept: application/media_control+xml,application/sdp
Contact: <sip:SD4tl71-vv9pmjn1vl07h0t6in0808cjov84opsv-7@202.0.0.5:5060;transport=udp>
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 240
v=0
o=BroadWorks 34676300 2 IN IP4 202.0.0.5
s=-
c=IN IP4 0.0.0.0
t=0 0
m=audio 16496 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=inactive
a=maxptime:20
a=bsoft: 1 image udptl t38

To fix this, set of message manipulation rules can be configured and assigned against both Lync and SIP Trunk IP Groups. These manipulation rules will change the hold method from “inactive” to “sendrecv” before sending it to PSTN. And it will change the hold method to “inactive” instead of “sendrecv”, before sending it to Lync Mediation Server. There should be both inbound and outbound manipulation sets. Manipulation rules should looks like below;

Capture

The Manipulation Set ID 2 should be configured in to SIP Trunk IP Group Table “Outbound Message Manipulation Set” and Manipulation Set ID 1 should be configured in to both Lync and SIP Trunk  IP Group Tables “Inbound Message Manipulation Set”.

Capture4

Lync IP Group

Capture5

SIP Trunk IP Group

Upon configuring, run a test call and put it on hold. The caller was able to hear the MoH and audio was there when the call was retrieved. When looking at the Sys log of the call, the message manipulation was clearly doing what was expected.

SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.0.0.158:5060;branch=z9hG4bKac25768176
From: “Support” <sip:0732684306@ipsystems.com.au;user=phone>;tag=1c1900081337;epid=D273FA8C4C
To: <sip:0451984283@ipsystems.com.au;user=phone>;tag=SDi988799-1512955841-1456808868261
Call-ID: 190005820313201613745@172.0.0.158
CSeq: 4 INVITE
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Supported: timer
Accept: application/media_control+xml,application/sdp
Contact: <sip:SD4tl71-vv9pmjn1vl07h0t6in0808cjov84opsv-7@202.0.0.5:5060;transport=udp>
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 244
v=0
o=BroadWorks 34627140 1 IN IP4 202.0.0.5
s=-
c=IN IP4 202.0.0.5
t=0 0
m=audio 16670 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=bsoft: 1 image udptl t38

If you have a similar  issue with a SIP Trunk with MoH, this could most probably be the solution.