Wednesday, October 26, 2016

Polycom VVX Hold Issue with Sonus SBC1000/2000 Calls

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
NULL
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" />


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.



4 comments:

  1. Extremely useful. Thanks for sharing!

    ReplyDelete
  2. thank - 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!

    ReplyDelete
  3. I'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!

    ReplyDelete
  4. Hi, for your information the issue and the solution are the same on Trio 8800 devices.
    Thank you for sharing.

    ReplyDelete