Multicast paging issue on "newer" Poly firmware

40 views
Skip to first unread message

Nathaniel Watkins

unread,
Jul 9, 2024, 10:32:23 AM7/9/24
to sipxcom-users
This likely needs to be reviewed by the Devs. I've had an ongoing issue with multicast paging on Poly phones on "newer" firmware. Historically, I have to use dated (7+ years old) firmware for this to work.

I was recently able to work around this by abandoning the built-in multicast paging functionality and manually managing via the custom configuration section.

I've not yet taken the time to update firmware and use this new methodology. I figured I would see if a patch would be forthcoming or if I should simply change to this more nuanced method.

I'm running what was the commercial version (if that matters):
Uniteme (21.04.20210908050259 2021-09-08EDT05:09:11 localhost.localdomain) update 0

Here is the custom config file that does work (I've not compared this to what sipxcom is generating):

<WEB
ptt.pageMode.enable="1"
ptt.address="224.0.1.116"
ptt.port="5001"
ptt.pageMode.defaultGroup="3"
ptt.pageMode.group.3.label="Center Street"
ptt.pageMode.group.3.allowReceive="1"
ptt.pageMode.group.3.allowTransmit="1"
ptt.pageMode.group.3.subscribed="1"

ptt.pageMode.group.24.label="Priority"
ptt.pageMode.group.24.allowReceive="0"
ptt.pageMode.group.24.allowTransmit="0"
ptt.pageMode.group.24.subscribed="0"

ptt.pageMode.group.25.label="Emergency"
ptt.pageMode.group.25.allowReceive="0"
ptt.pageMode.group.25.allowTransmit="0"
ptt.pageMode.group.25.subscribed="0"


feature.nonVolatileRingerVolume.enabled="1"
np.normal.ringing.toneVolume.chassis="1000"
np.normal.alert.messageWaiting.tonePattern="silent"

feature.enhancedFeatureKeys.enabled="1"

softkey.1.action="$FPage$"
softkey.1.enable="1"
softkey.1.label="Paging"
softkey.1.use.active="1"
softkey.1.precede="1"

softkey.2.action="$FForward$"
softkey.2.enable="1"
softkey.2.label="Forward"
softkey.2.use.active="1"
softkey.2.precede="2"
/>

OnRelay Support

unread,
Jul 16, 2024, 5:54:06 AM7/16/24
to sipxcom-users
Hello Nathaniel,

Not sure if it is relevant for your case, anyhow we did a fix for- and a test of the sipXcom paging feature in 24.01 update 2 that has been tested with Polycom UC 5.9.8.

Roy Reynolds

unread,
Jul 17, 2024, 11:09:30 PM7/17/24
to sipxcom-users
Hello,

We have installed sipXcom(24.01.20240705081048).  We have polycom 331 phones running UC Software Version 4.0.2.11307.  When we try to page to them, we get the paging tone but the page itself cannot be heard.  A packet capture revealed that the paging audio is extremely low (Playstream).  If we do an intercom call to the 331 the phone auto-answers and audio is nice and loud.  I have struggled with this for a bit and wonder if I am missing something.  I compared the setup with a system running release sipxcom 18.x and polycom 331 phones at the same release (UC Software Version 4.0.2.11307) and that works fine.  Any help would be greatly appreciated.

Thanks.

OnRelay Support

unread,
Jul 18, 2024, 3:48:06 AM7/18/24
to sipxcom-users
Hello Roy,

We had to do an SDP change to get TLS and SRTP to work with paging.

Previously the sipXpage module always generated a new SDP for the outbound legs, which broke the flow for secure audio.

Now we forward the inbound SDP onwards if it exists.

So check the audio parameters of your inbound legs.

The updated logic from LegSipListener.java below, with the legacy code that previously generated a new SDP found under the 'else' statement.

if( originatorSdp != null ) {
sdp.setMediaDescriptions( originatorSdp.getMediaDescriptions(true));
}
else {
Vector <MediaDescription>mediaList = new Vector<MediaDescription>() ;
Vector <Attribute>attrs = new Vector<Attribute>();
attrs.add(sdpFactory.createAttribute("rtpmap", "0 PCMU/8000"));
attrs.add(sdpFactory.createAttribute("ptime", "20"));
if (sendOnly)
{
attrs.add(sdpFactory.createAttribute("sendonly", null)) ;
}
else
{
attrs.add(sdpFactory.createAttribute("sendrecv", null)) ;
}
String[] codecs = {PCMU};
MediaDescription md = sdpFactory.createMediaDescription("audio", localPort, 2, "RTP/AVP", codecs);
md.setAttributes(attrs);
mediaList.add(md);
sdp.setMediaDescriptions(mediaList) ;
}

Also beware JAIN SIP has been upgraded, and those Polycom phones are now quite old.

So if you have some VVXs there with updated FW it is worth checking if you experience the same issue.

Roy Reynolds

unread,
Jul 18, 2024, 5:35:56 PM7/18/24
to sipxcom-users
Thanks for the response. 

Unfortunately I don't have VVX phones to try.  

I assume you want me to check in the packet capture for the inbound legs? 

Are the updates not backward compatible?  I would hate to tell so many people to throw out their working poly 331 phones if they ever have to upgrade.  Are there no options to make it work? 

Thanks in advance for your response.

OnRelay Support

unread,
Jul 18, 2024, 5:44:32 PM7/18/24
to sipxcom-users
Note the legacy implementation is quite ugly as it hardcodes the outbound paging leg to PCMU over RTP.

Irrespectively it is certainly feasible and quite simple to add a non-default compatibility switch or similar in settings. We just couldn't think of a case it would be needed since the inbound SDP should always be valid and possible to route onwards.

Anyhow, the culprit is likely at the phone calling the paging server, not all the phones receiving, so a good start would be to look at its or their outbound call media settings first.

What type device are you calling the paging service from?  Poly 331s as well?

OnRelay Support

unread,
Jul 18, 2024, 6:23:43 PM7/18/24
to sipxcom-users
There is e.g. an 'Emergency paging volume' setting for Polycoms under Push-To-Talk and Paging Groups, which defaults to -10.

Could this be the problem?

Carlos E Olivencia Vazquez

unread,
Oct 30, 2024, 10:24:54 AM10/30/24
to sipxcom-users
I saw that too: volume at -10
Reply all
Reply to author
Forward
0 new messages