I had an issue recently when using the VVX Music on Hold
feature in conjunction with a Sonus SBC1000/2000. The problem was that the VVX
phones could not put a trunk call on hold (in this case they were running 5.4.5 software) . The symptom
of this issue was the following message being displayed on the VVX screen (“Hold
Failed. Moving back to call”):
It should be noted here that the VVX in question had the new Music on Hold feature configured and MoH was working to internal Skype for
Business clients and other phones. This was only happening on trunk
calls on the Sonus gateway. This would happen for both Sonus based file hold music (ie. Sonus gateway based hold) or when the Sonus was not being used to supply the hold music (ie. hold passed through from the VVX to the outside party).
Logging on the system showed that the RE-INVITE message being sent by the mediation server to initiate hold was
getting rejected by the Sonus SBC. The INVITE message that was being sent
looked like this:
RE-INVITE message
sent by Mediation Server to Sonus Gateway:
INVITE sip:+61395821300@10.20.1.150:5066;transport=TCP SIP/2.0
FROM:
<sip:+61395824500;ext=4500@myskypelab.com;user=phone>;epid=BB69FBB4BE;tag=45afae0d8
TO:
<sip:+61395821300@SBC1000GW.myskypelab.com;user=phone>;tag=7b66d712-5fc
CSEQ: 83 INVITE
CALL-ID: a9adec59-5f57-4a9c-ac31-78836eb506a3
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 10.20.2.104:49796;branch=z9hG4bKbafabbee
CONTACT:
<sip:2013ENTFE004.myskypelab.com:5068;transport=Tcp;maddr=10.20.2.104;ms-opaque=7b0cff35b7212cae>
CONTENT-LENGTH: 246
SUPPORTED: timer
SUPPORTED: 100rel
USER-AGENT: RTCC/5.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
Session-Expires: 1800
Min-SE: 90
v=0o=- 1477456907 1477456908 IN IP4 10.22.0.23s=sessionc=IN IP4
10.22.0.23t=0 0a=sendonlym=audio 60034 RTP/AVP 0 101c=IN IP4
10.22.0.23a=rtcp:60035a=sendonlya=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=ptime:80
You will notice in the above invite that the Mediation
server is requesting a Payload Size of 80ms (“ptime:80”). The Sonus gateway
doesn’t like this though, and rejects the call with a 488 message:
Call
setup rejected:
SIP/2.0 488 Not Acceptable Here
FROM:
<sip:+61395824500;ext=4500@myskypelab.com;user=phone>;epid=BB69FBB4BE;tag=45afae0d8
TO:
<sip:+61395821300@SBC1000GW.myskypelab.com;user=phone>;tag=7b66d712-5fc
CSEQ: 83 INVITE
CALL-ID: a9adec59-5f57-4a9c-ac31-78836eb506a3
VIA: SIP/2.0/TCP 10.20.2.104:49796;branch=z9hG4bKbafabbee
CONTENT-LENGTH: 0
WARNING: 304 "Media
type not available"
SERVER: SONUS SBC1000 5.0.4v415 Sonus SBC
When the 488 message gets fed back to the VVX, it displays
the “Hold Failed. Moving back to call” message and everyone is very sad :(
Why is this happening?
The Sonus gateway supports a maximum payload sizes of 60ms.
This can be seen in INVITE messages sent out of the Sonus like the one below:
v=0
o=SBC 79 1001 IN IP4 10.20.1.150
s=VoipCall
c=IN IP4 10.20.1.150
t=0 0
m=audio 20112 RTP/AVP 0 8 101 13
c=IN IP4 10.20.1.150
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:13 CN/8000
a=ptime:20
a=maxptime:60
a=sendrecv
As you can see in the SDP message above, the Sonus says that
it will only handle a maximum payload size of 60ms. There is also a reference
to this in the SBC1k/2k manuals, which state that “If the SBC receives a larger
than configured payload size from the peer offer in the re-invite, the SBC
rejects with a 488 'Not Acceptable Here' response. The call rolls back to the
previous negotiated offer answer.” – Reference: https://support.sonus.net/display/UXDOC60/Creating+and+Modifying+Voice+Codec+Profiles
The Fix!
So the fix turns out to be a VVX phone setting. When initiating hold the VVX the phone doesn’t follow the regular payload
size settings for the codec being used (which by default for PCMA/U is 20ms).
Instead it has a setting called feature.moh.payload which defaults to 80ms.
Fortunately for us, this setting can be changed within the configuration file (it’s
not available in the web interface!). The setting for Music on Hold are shown
below:
Setting
|
Default Value
|
Required Value
|
feature.moh.enabled
|
0
|
1
|
feature.moh.filename
|
Set this to the hold music file name. The file will be served off the config server. The default file is “Polycom-hold.wav”
|
|
feature.moh.payload
|
80
|
20 or
40 or 60
|
res.quotas.tone
|
600
|
600 – 1024
|
Note: The default moh file size is 600KB which works fine for the default hold music provided by Polycom. However, if you want to change this to your own file then you can expand the size up to 1024KB.
Polycom has made the payload setting 80ms by default to reduce the processor usage on the phone when it plays the hold file. So selecting 60ms may be the best option from a processor load perspective (which will work with the Sonus max payload size of 60). This way the
hold music will work correctly, without putting too much load on the VVX's CPU.
Here is an example of how this might look in a config file:
<feature feature.moh.enabled="1" feature.moh.filename="Polycom-hold.wav" feature.moh.payload="60" />
<res res.quotas.tone="1000" />
<res res.quotas.tone="1000" />
The Wrap Up
Well there you go, another weird integration issue to add to
the list… Hopefully it didn’t wreak too much havoc in your deployments before
finding this article. Until next time, happy hacking.
Extremely useful. Thanks for sharing!
ReplyDeletethank - you for sharing this information!!! we just updated our SBC2000 firmware to 6.1 and encountered the above problem with hold and also transfers from our VVX phones. If I hadn't quickly found this article with a google search I think we would have had weeks worth of effort rolling back and sending logs off to Sonus! thanks again!
ReplyDeleteI've just experienced the same issue after upgrading to version 6.1.1 of the sonus gateway firmware. I'd also like to add my thanks of saving me weeks of support call effort!
ReplyDeleteHi, for your information the issue and the solution are the same on Trio 8800 devices.
ReplyDeleteThank you for sharing.