SPA 509G Multicast paging

[Daniel Andres]

Hello, 

We recently connected a new client with 30 509G phones and two multicast page groups, configured as follows. 

pggrp=224.168.168.168:34560;name=All;num=800;listen=yes;pggrp=224.168.168.168:34561;name=Service;num=801;listen=yes;

While this worked great in testing and during deployment we have run into an intermittent bug where some phone stop receiving the pages. While most phones will respond to the page a 509G that is set to listen to the page group will just not respond when a page is sent. If the phone is rebooted it starts responding as soon as its back. 

Has anyone experienced this before or have any tips on where I should start looking. We are running 7.5.7 firmware. 

Thanks in advanced. 

[Dan Lukes]

You may turn on syslog&debug messages. They may help you to analyze the issue, but I suspect you will be unable to solve it even if you disclose the cause. You may try to use most recent firmware.

Sorry, not so much experience with it - we tried to use this kind of paging few years ago, but we considered it so unreliable. We decided to use classic soft-switch driven group call instead of it.

[Daniel Andres]

I have turned on syslog&debug messages for these phones but have not found anything indicating why the page did not go through on select phone. 

When you say you found it unreliable what did you experience? 

[Dan Lukes]

As you didn't disclosed the log you catched, I can just accept there's nothing helpful inside.

According reliability - not only the phone doesn't accept the paging. There's no easy to way to identify which phone has accepted the paging. Also, the paging is not authenticated, thus the feature can be misused by rogue user - we consider it so insecure and dangerous.

[Daniel Andres · Accepted solution]

So after much investigation, I was able to reproduce the issue. 

Long story short, When a phone is actively receiving a page if the receiving phone presses a function key (in this cause a speed dial to a parking spot) the page ends but does not seem to end correctly and the phone stops listening to pages.  

Capture 1 is a normal page from .143 to .214. The receiving phone ends the page by pressing end call. 

• .134 tries to start to page: LOCAL3.DEBUG: [PGGRP]Try to page group <0>[All|800]e0a8a8a8:34560\n
• .134 then starts paging: LOCAL3.DEBUG: [PGGRP]Paging to group <0>[800] starts\n
• .134 sets audio path: LOCAL3.DEBUG: PHN_setAudioPath(3)  \n
• .134 starts sending traffic: 224.168.168.168 UDP 214 34560→34560 Len=172
• .214 starts receiving the page: LOCAL3.DEBUG: [PGGRP]Receiving group page call [800] start\n
• .214 sets audio path: LOCAL3.DEBUG: PHN_setAudioPath(3)  \n
• .214 dissconnects with the following
  • LOCAL3.DEBUG: [CCTRL]Free Call Obj 94a075c0(0) \n
  • LOCAL2.DEBUG: sa disconn 0\n
  • LOCAL2.DEBUG: [0:0]AUD Rel Call\n
  • LOCAL3.DEBUG: [PGGRP]Receiving group page call [800] end. ssrc 2546986307\n
  • LOCAL3.DEBUG: PHN_setAudioPath(0)  \n
  • LOCAL3.DEBUG: [GPGRP] Socket 13 on e0a8a8a8:34560.\n
• .134 contiues to page until it ends the page
  • LOCAL3.DEBUG: [CCTRL]Free Call Obj 94a0c390(0) \n
  • LOCAL2.DEBUG: ucId: 0, bRtpTxEnable: 1, ucNumRtpTxEnable--: 0\n
  • LOCAL2.DEBUG: sa disconn 0\n
  • LOCAL2.DEBUG: [0:0]AUD Rel Call\n
  • LOCAL3.DEBUG: [PGGRP]Paging to group <0>[800] end\n
  • LOCAL3.DEBUG: PHN_setAudioPath(0)  \n
  • LOCAL3.DEBUG: [GPGRP] Socket 12 on e0a8a8a8:34560.\n

Capture 2 is a page that is inturpted by .214 by pressing a fuction key (in this case a speed dial for a parking spot *34)

• .134 sets up the page as normal: LOCAL3.DEBUG: [PGGRP]Paging to group <0>[800] starts\n
• .214 starts receiving the page as normal: LOCAL3.DEBUG: [PGGRP]Receiving group page call [800] start\n
• .214 then hits the function key for speed dial *34 and ends the page
  • LOCAL0.INFO: Terminate current page call\n
  • LOCAL3.DEBUG: [CCTRL]Free Call Obj 94a09f40(0) \n
  • LOCAL2.DEBUG: sa disconn 0\n
  • LOCAL2.DEBUG: [0:0]AUD Rel Call\n
  • LOCAL3.DEBUG: PHN_setAudioPath(0)  \n
  • LOCAL3.DEBUG: [CCTRL]Obtain Call Obj 94a0a470(0:0)<0:0>\n
  • LOCAL3.DEBUG: {sc} cid=0, speed dial: *34\n
  • LOCAL0.INFO: [CMXHTTP] force stop wav\n
• .214 then sets up a call to *34 and ends that call. 
• .134 ends its page as normal and then starts paging again but .214 does not respond. 
• .134 then ends a page

So few things stand out to me. 

• When the page was stopped by .214 pressing a function key it sends a "Terminate current page", this was not done during a normal end call page. 
• .214 does not send out a "[GPGRP] Socket 12 on e0a8a8a8:34560.\n" after the terminate. This is sent on the normal end call page. This could be the phone starting to listen for pages again. Since this is not sent on the second capture the phone stops listening until it sends a page then starts listening again. 

This seems like a firmware issue to me but I am not sure. 

Thoughts?

[Dan Lukes]

Well, I consider it firmware bug.

Unfortunately, 7.5.7. version you are running is not the most recent one. Although you may contact SMB support center even now, I suspect they will just ask you to upgrade first, then try again.

[Daniel Andres]

I upgraded a phone to 7.6.2a and have the same result. 

[Dan Lukes]

It's not possible to report firmware bugs here. In the fact, customer support for SMB Voice product is almost nonexistent.

Your only chance is to call official SMB support center and report issue to them. But according my experience, you can't expect patched firmware in any reasonable time.

You should think about a workaround ...

[Daniel Andres]

Thanks Dan, its good to know that support may not help. 

I am looking at a workaround as so far telling the client to end the page before hitting the park key has not been met with enthusiasm. 

[Dan Lukes]

Of course. Moreover, it's not reliable method as end users are not reliable devices.