View Full Version : How to prevent a Polycom user from receiving Call Waiting Tones for there own Page

10-12-10, 05:10 PM
I have an update with regards to Polycom phones receiving call waiting tones for their own Page (Polycom). This occurs when the Paging user is also a member of the same group they are attempting to Page.

What you can do to combat this is create a ‘Distinctive Call Waiting ‘ tone pattern for when any user is paged. This tone pattern will only repeat once, it is 500 ms in length and the frequency matches that of the page tone provided by Warp Pager. So from a user stand point you hear only one uniform tone.

A copy of a Polycom default sip.cfg is available as an example on our FTP site here:


I used a default 3.1 version sip.cfg file and made the following modifications.

I added a new ‘Call Progress’ tone chord:

<CALL_WAITING_PAGE tone.chord.callProg.11.freq.1="700" tone.chord.callProg.11.level.1="-10" tone.chord.callProg.11.onDur="500" tone.chord.callProg.11.offDur="0" tone.chord.callProg.11.repeat="1"/>

I monopolized the pre-existing “Call Waiting Long” call progress tone pattern entry that was there originally and changed it to:

<CALLWAITINGPAGE se.pat.callProg.7.name="call waiting page" se.pat.callProg.7.inst.1.type="chord" se.pat.callProg.7.inst.1.value="11"/>

Last of all I changed the Ring Answer ring type to use the Call Waiting Page call Progress tone pattern instead of the default call waiting pattern:

<RING_ANSWER se.rt.4.name="Ring Answer" se.rt.4.type="ring-answer" se.rt.4.timeout="2000" se.rt.4.ringer="2" se.rt.4.callWait="7" se.rt.4.mod="1"/>

Not only does this mask the dual tone issue but it also provides the means for a paged user to audibly distinguish between a waiting Page and a normal waiting call.


06-17-11, 03:20 PM
To further combat this issue 2 changes have been made to prevent the Paging party from paging themselves.

The first is that the WARP will extract the 'From' header from the SIP Invite received in the page request:

INVITE sip:warppager@ SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK5dbdd235;rport
From: "Polycom" <sip:2413338181@>;tag=as4eb29a54
To: <sip:warppager@>
Contact: <sip:2413338181@>
Call-ID: 37048d79724852660ead885c3fae3bb9@
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Fri, 17 Jun 2011 18:52:49 GMT
Supported: replaces
Content-Type: application/sdp
Content-Length: 266

In this case the from header is as follows:

From: "Polycom" <sip:2413338181@>;tag=as4eb29a5

If the page group dialed contains a target with a number matching 2413338181 it will remove it from the list of phones to Page.

For example, if 2413338181 made a page to group 0 and the same number was assigned as a member of group 0 in the <MAC>.phones file:


Well the WARP will know not to send the pgae to this device since it is the paging party.

Now there are also situation where a phone may be registered as 2413338181 but the Hosted PBX system with deliver the call withwith the from header in extension format.

ie. From: "Polycom" <sip:8181@>;tag=as4eb29a5

In this case the number would not match the 2413338181 number programmed in the <MAC>.phones file and the page would still be sent to the paging device. To prevent this scenario we added a parameter to the <MAC>.cfg file called extension_length. What you do is set this parameter to the extension length being used in your environment. WARP will then use this value to check if the number received matches extension number format. So in this case you would set the parameter as follows:


This parameter tells the WARP to look for the following numbers when a page is receive 2413338181 or (match the last 4 digits) 8181. If the from header received matches either of these digit strings then the page will not be sent to that target.