pbxuser911

is it possible to be able to also add that it should include the Domain name in the results when using the following script #!/bin/bash # Show the passwords of all users: function get_xml() { gawk -v tag=$1 'BEGIN{regex="<" tag ">([^<]*)</" tag ">";}{ match($0, regex, m); for(i = 1;; i++) { if(!(i in m)) break; printf("%s\n",m[i]);}}' $2 } for user in users/*.xml do name=${user:6} # only the name idx=${name%.xml} # only the number type=$(get_xml type $user) if [ "$type" == extensions ]; then id=$(get_xml id $user) primary=$(get_xml alias $user) dialplan=$(get_xml dial_plan $user) if [ -z "$dialplan" ]; then plan="Default" else plan=$(get_xml name dial_plan/$dialplan.xml) fi password=$(get_xml password extensions/$id.xml) pin=$(get_xml mb_pin extensions/$id.xml) username=$(get_xml name user_alias/$primary.xml) if [ -z "$pin" ]; then echo $username $password \($plan\) else echo $username $password \($plan\) [$pin] fi fi done

I have a script that will show me all DID's and to which domain its on #!/bin/bash # Show all account names that are a telephone number: function get_xml() { gawk -v tag=$1 'BEGIN{regex="<" tag ">([^<]*)</" tag ">";}{ match($0, regex, m); for(i = 1;; i++) { if(!(i in m))\ break; printf("%s\n",m[i]);}}' $2 } for alias in user_alias/*.xml do name=${alias:11} # only the name idx=${name%.xml} # only the number name=$(get_xml name $alias) if [ -z "$name" -o "${#name}" -lt 8 ]; then continue; fi user=$(get_xml user $alias) domain=$(get_xml domain $alias) domainname=$(get_xml name domains/$domain.xml) echo $name $domainname done any Linux Gurus on here can tell me how to modify it and have it send me the results in a email?

when the call comes in, why would it matter which trunk it comes in from? You can A) use a global trunk and it will find which domain has the DID thats coming in if you put in the DID on a account, and on that domain that trunk exists, it will route it to the proper account why would you need the call to come in on 2 trunks?

I never knew it worked at one point? we always had this problem that if you dial in a wrong "account" number then it will tell you this extension number does not exist and after the timeout it will only announce you the info you have selected in the "Entering the destination" under the IVR tab on a Auto Attendant for example. would be nice to have a setting where to send the call if a wrong extension was dialed from the auto attendant (not if I pick up the phone on the domain and dial a wrong extension)

dont forget about getting it to work with "hosted" edition would require new 3.4 release so we can have a "upload" button on the PBX to upload those images? thanks!

copy from polycom http://knowledgebase.polycom.com/kb/search...0%200%201475374 Updated: March 2009 Part Number: 3725-17493-001_RevB Page 1 SoundPoint® IP Family Technical Bulletin – TB 35311 Supporting SoundPoint IP 300/301/500/501/600/601 and SoundStation IP 4000 phones with SIP 2.2.0 or SIP 3.2.0 and later releases This information applies to: • SoundPoint IP 300 and 500 phones used in SIP installations running SIP software release 2.2.0 or later • SoundPoint IP 301, 501, 600, and 601 and SoundStation IP 4000 phones used in SIP installations running SIP software release 3.2.0 or later. BACKGROUND The SIP2.2.0 Release did not include support for the SoundPoint IP 300, 500, and 600 products. These products were discontinued in May 2006 (Refer to Product Bulletin Number 532.PB available from the Polycom Resource Centre). The upcoming SIP3.2.0 Release will not include support for the SoundPoint IP 301, 501, and 601 desktop phones and the SoundStation IP 4000 conference phone. The IP 301 and 601 products were discontinued in March 2008 (Refer to Product Bulletin Number 803.PB). The IP 501 and 4000 products were discontinued in February and March 2009 (Refer to Product Bulletin Numbers 970.PB and 993.PB respectively). BootROM Release 4.2.0 and future releases will not include support for the SoundPoint IP 300, 301, 500, 501, 600, and 601 and SoundStation IP 4000 products. These products will be supported on the BootROM 4.1.y stream as needed for critical issue fixes. The replacement models are shown below: Model Last SIP Release Supported Replaced By IP 300 SIP 2.1.3 IP 320/330 IP 301 SIP 3.1.3 IP 320/330 IP 500 SIP 2.1.2 IP 450 IP 501 SIP 3.1.3 IP 450 IP 600, 601 SIP 3.1.3 IP 650/670 IP 4000 SIP 3.1.3 IP 6000/7000 Installations that have a mixture of IP 300/301/500/501/600/601/4000 phones deployed along with other newer models will require changes to the phone Updated: March 2009 Part Number: 3725-17493-001_RevB Page 2 configuration files to continue to support these phones when newer software releases are deployed. Any Critical issues that affect IP 300 and IP 500 phones will be addressed by a maintenance patch on the SIP 2.1.x stream until the End of Life date for the products. Any Critical issues that affect IP 301, 501, 600, 601, and 4000 phones will be addressed by a maintenance patch on the SIP 3.1.x stream until the End of Life date for the products. Note: All IP 300 and 500 phones should be upgraded to BootROM 4.0.0 for these changes to be effective. All IP 301, 501, 600, 601, and 4000 phones should be upgraded to BootROM 4.0.0 or later for these changes to be effective. CONFIGURATION SYSTEM CHANGES TO SUPPORT SOUNDPOINT IP 300/301/500/501/600/601/4000 PHONES WITH SIP 3.2.0 AND NEWER Enhancements have been added in the BootROM 4.0.0 and SIP 2.2.0 releases to allow the deployment of phones using different software versions using a common provisioning server and configuration file set.. The following procedure must be used for upgrading to SIP 3.2.0 for installations that have SoundPoint IP 300/301/500/501/600/601/4000 phones deployed. It is also recommended that this same approach is followed even if SoundPoint IP 300/301/500/501/600/601/4000 phones are not part of the deployment as it will simplify management of phone systems with future software releases. Note: The instructions here are representative of how Polycom plans to support SoundPoint IP 300/301/500/501/600/601/4000 phones in SIP 3.2.0 . Polycom reserves the right to make changes to the final design in SIP 3.2.0 .This technical bulletin will be updated to reflect any such changes. 1. Ensure that all phones are running BootROM 4.0.0 or later. 2. Copy sip.ld, sip.cfg, and phone1.cfg from the SIP3.2.0 release distribution onto the boot server. These are the relevant files for all phones except the SoundPoint IP 300/301/500/501/600/601/4000 phones. 3. Download the SIP 2.1.x ‘legacy’ phone release file from the Polycom Customer Support site, or rename the sip.ld or <MODEL_NUMBER>-sip.ld files from the preferred ‘legacy’ release for the SoundPoint IP 300 and 500 phones. 4. Copy or rename the sip.cfg and phone1.cfg files as sip_21x.cfg and phone1_21x.cfg on the provisioning server (if necessary). These will be used by the SoundPoint IP 300 and 500 phones. Updated: March 2009 Part Number: 3725-17493-001_RevB Page 3 Note: “x” refers to the particular patch level for the SIP 2.1.x release that is being used. 5. Download the SIP 2.1.y ‘legacy’ phone release file from the Polycom Customer Support site, or rename the sip.ld or <MODEL_NUMBER>-sip.ld files from the preferred ‘legacy’ release for the SoundPoint IP 301, 501, 600, 601 and SoundStation IP 4000 phones. 6. Copy or rename the sip.cfg and phone1.cfg files as sip_31y.cfg and phone1_31y.cfg on the provisioning server (if necessary). These will be used by the SoundPoint IP 301, 501, 600, 601 and SoundStation IP 4000 phones. Notes: “y” refers to the particular patch level for the SIP 3.1.y release that is being used. 7. Modify the 000000000000.cfg file, if required, to match your configuration file structure – the template is detailed below 8. Remove any <Ethernet address>.cfg files that may have been used with earlier releases from the boot server. Notes: 1. The above approach takes advantage of an enhancement that was added in SIP2.1.2 and BootROM 4.0.0 that allows for the substitution of certain parameters in the configuration files (refer to Technical Bulletin TB35361 for more information).This avoids the need to create unique <Ethernet Updated: March 2009 Part Number: 3725-17493-001_RevB Page 4 address>.cfg files for each phone such that the default 000000000.cfg file can be used for all phones in a deployment. 2. If this approach is not used, then changes will need to be made to all the <Ethernet address>.cfg files for SoundPoint IP 300/301/500/501/600/601/4000 phones; or all of the <Ethernet address>.cfg files if it is not explicitly known which phones are SoundPoint IP 300/301/500/501/600/601/4000. UPGRADING BOOTROM WHEN A MIXTURE OF PHONES ARE DEPLOYED Since the BootROM 4.2.0 and future releases will not include an image for the SoundPoint IP 300, 301, 500, 501, 600, and 601, and the SoundStation IP 4000 phones, it is recommended that the 'split images' be used for maintanance and upgrade of BootROM releases. The BootROM does not allow for renaming of the release files as documented for SIP releases in the previous section. Thus the relevant <PHONE-PART-NUMBER>-bootrom.ld files will need to be placed on the provisioning server for each phone model, for example, the download and unzip the BootROM 4.1.2 release. Then download and unzip the BootROM 4.2.0 release. The images for each of the phones included in the BootROM 4.2.0 release will over-write the BootROM 4.1.2 versions, and the BootROM 4.1.2 images will remain for phones not included in the BootROM 4.2.0 release. HOW TO DETERMINE IF SOUNDPOINT IP 300/301/500/501/600/601 AND SOUNSTATION IP 4000 PRODUCTS ARE DEPLOYED Note: If the steps in this technical bulletin are followed it is not necessary to know whether the phones in question are deployed. The following methods may be used to determine the phone models deployed. If it is possible to physically access the phones: 1. Read the model number from the label on the back of the phone. 2. Read the part number from the product label on the back of the phone. Refer to Technical Bulletin TB35361 for a mapping of product model to part number. If it is not possible or desirable to physically access the phones, then the phone log files may be examined and the phone model number extracted. This may be used to generate an inventory of the phones that have been deployed. The phone will log the model number following a phone reboot. The log files can be ‘parsed’ to look for a ‘Platform’ string: 0406003403|so |3|00|Platform: Model=SoundPoint IP 501, Assembly=2345-11500-030 Rev=C Updated: March 2009 Part Number: 3725-17493-001_RevB Page 5 TROUBLESHOOTING What are the consequences if the changes shown in this technical bulletin are not made and SIP 3.2.0 is deployed using the ‘old model’? The IP 300/301/ 500/501/600/601/4000 phones will not ‘understand’ the new configuration parameters, and will attempt to load the new application. This attempt will fail since there is no 300/301/500/501/600/601/4000 image contained within the sip.ld file, so the phone will continue on and run the current version of application that it has in memory. It will, however, use the new configuration files, which could cause incorrect behavior. What are the consequences if the configuration file changes are made but the IP 300/301/500/501/600/601/4000 phones are not running SIP 2.1.2 or later? The IP 300/301/500/501/600/601/4000 phones will not ‘understand’ the new configuration parameters, and will attempt to load the new application. This attempt will fail since there is no 300/301/500/501/600/601/4000 image contained within the sip.ld file, so the phone will continue on and run the current version of application that it has in memory. It will, however, use the new configuration files, which could cause incorrect behavior.

here is copy from Polycom http://knowledgebase.polycom.com/kb/search...1%200%207876946 Technical Bulletin 42250 Using Enhanced Feature Keys and Configurable Soft Keys on SoundPoint® IP Phones This technical bulletin provides detailed information on how to set up enhanced feature keys and configurable soft keys with any call server. This information applies to SoundPoint IP phones running SIP application version 3.1 or later. This technical bulletin contains information on: • Enhanced Feature Key Overview • Configurable Soft Keys • Testing and Troubleshooting Tips Note: Polycom recommends that you use Adobe Reader 8 or 9 to view this technical bulletin and the attachments. Click on the paperclip icon on the left-hand side to view attachments. Enhanced Feature Key Overview Enhanced Feature Keys provide a method of creating interactive call sequences that will be executed by the phone. The ‘interactivity’ consists of the following elements: 1 . Gather input from the phone’s user 2 . Send SIP signaling requests to a call server (INVITE or REFER) 3 . Cause the phone to perform certain operations (for example, hang-up a call, place a call on hold) 4. Emulate a key press on the phone 5. Invoke the phone’s Microbrowser to access an XHTML URI (for example, set action.string to "http://leo/test/menu.xhtml") A macro language is used to define these actions. Details of this macro language are documented in the “Enhance Feature Key” section of the SIP 3.1 Administrator’s Guide, which is available at http://www.polycom.com/support/voip/ . These macros may be utilized in a number of methods: • B y defining an Enhanced Feature Key macro using the efklist parameters • D irectly as part of a speed-dial entry • D irectly as part of a ‘soft key’ configuration January, Use of the efklist to define the macros is optional. Using this method is useful when a macro may be used for more than one ‘soft key’ or speed-dial definition. The efkprompt parameter must be used if interactivity with the user is implemented as part of any macros. Note: The feature flag, feature.18.enabled, must be set to 1 to use the Enhanced Feature Key and Configurable Soft Key features. Configurable Soft Keys Soft key configuration may be used by the phone’s system administrator to customize the usage of the soft keys on the phone to best suit the needs of their users. This soft key configuration has two parts: • Adding new soft keys that use the Enhanced Feature Key capability to simplify the operation of common telephony tasks that might take more than one button press with the ‘default’ configuration. • Removing certain ‘default’ soft keys defined by Polycom for functions that may be redundant or never used To assist system administrators in configuring common features, some example configuration files for soft key configuration are attached to this technical bulletin.) Example 1 – Simplifying Commonly Used Telephony Features Note: For this example, refer to EFK-SoftKey1.cfg . To use these files, change the example star codes to the star codes used by your call server for the appropriate feature. This example might apply when the phone user has the following use characteristics: • Uses the handset predominantly for making phone calls (and does not need New Call and End Call soft keys) • Uses Call Park, Pick-Up, Retrieve features using ‘* code’ sequences • Frequently sends call directly to another person’s Voice Mail • Makes frequent Conference Calls to a specific bridge number • Uses Push To Talk (PTT)/Intercom communication with close business associates • Needs easy access to call lists in many call states • Desires single-button Blind Transfer capability The attached configuration file contains the necessary configuration to implement nine Enhanced Feature Key functions as soft keys and one (Intercom) as a speed-dial. The following ‘standard Polycom’ features were disabled for this example: • Redundant Call management keys (softkey.feature.basicCallManagement.redndant=”0”) 2 • Buddies (softkey.feature.buddies=”0”) • Callers (softkey.feature.callers=”0”) • Directories (softkey.feature.directories=”0”) • EndCall (softkey.feature.endcall=”0”) • Forward (softkey.feature.forward=”0”) • MyStatus (softkey.feature.mystatus=”0”) • NewCall (softkey.feature.newcall=”0”) The following screen shots show the phone UI in different states (idle, active, alerting, dial tone, setup, hold, and proceeding) when configured with the sample Enhanced Feature Key configuration file: Idle State If you press the More soft key, the following screen appears: Active State One active call 3 One active call and one call on hold Alerting State Dial Tone State Setup State 4 Hold State Proceeding State Example 2: Configuring Common Administrator Functions Through Soft Keys Note: For this example, refer to EFK-SoftKey2.cfg . This example might apply to people that are involved in implementing solutions with Polycom SoundPoint IP phones and frequently need to perform Menu-driven functions that require multiple key presses. By defining macros to emulate these key presses, it is possible to configure the phone for single button access to common functions. In this example, the following Enhanced Feature Key features are defined and assigned to phone soft keys and speed-dial keys: • Admin – single button access of Advanced Settings • Restart – single button phone restart (to apply configuration changes) 5 • Ln1Setup – speed-dial key assigned to take the administrator to the SIP Line1 setup menu to view the SIP settings for that line (Note the use of an embedded macro ($MAdminMenu$) within the Line1Setup EFK) • Browser – a soft key available in the Active call state to take the user to a specific browser location Note: For this example the following ‘standard Polycom’ soft key functions were disabled: Mystat, Buddies, Forward, Callers, and Directories. Idle Screen If you press the Admin key on the idle screen, the following screen appears: If you press the Ln1Setup speed dial key on the idle screen, the following screen appears: 6 The second page of soft keys in the Active State has the Browser soft key as shown in the following screen: Pressing the Browser soft key will take the user to a configured XHTML page. Testing and Troubleshooting Tips Make note of the following when working with Enhanced Feature Keys: • Phones do not give a user visible error message if something is not correct. If a function is executed that contains incorrect macros, the function may implement partially or not at all. The phone log files will log a message if an invalid Enhanced Feature Key operation is attempted. Common causes of errors: o EFK macros/actions are case sensitive (Note: see Internal Functions). o If implementing key press emulation macros, it may be necessary to enter a pause between operations. • It is recommended that configuration files created and edited with an XML editor are used for prototyping features. o Use of speed-dials to prototype the macros can be useful to avoid having to re-boot the phone to test out changes. In this case, the macro can be entered directly into the speed-dial ‘Contact’ field and edited from the phone keypad. o The web interface cannot be used to configure Enhanced Feature Keys. • The Administrator needs to take into account soft key and menu differences between certain models of phones when designing any custom soft key features. In particular, the SoundPoint IP 301, 320, and 330 phones have only three soft keys. The other family members are very similar in soft key designation and usage. • The Phone Administrator must be cautious not to implement soft key features that might hide commonly used functions from users. Given the level of configurability of the keys, it may be possible to define a soft key configuration or operation that results in a ‘dead end’ or improper behavior of the phone user interface. Careful prototyping and testing is strongly encouraged before a new soft key design is implemented in a phone system. 7 8 Trademark Information Polycom®, SoundPoint®, and the Polycom logo design are registered trademarks of Polycom, Inc. in the U.S. and various countries. All other trademarks are the property of their respective companies.

maybe we can get this working soon! check this out copy from polycom: http://knowledgebase.polycom.com/kb/search...1%200%204730251 Description This white paper provides instructions on how to add a background logo to allSoundPoint IP and SoundStation IP phones in your organization. This information applies to SoundPoint IP and SoundStation IP phones running bootROM versions 2.x or later and SIP application version 1.x or later. Introduction You can add your company’s logo as the background logo of all SoundPoint IP and SoundStation IP phones in your organization. One bitmap file is required for each model; however, SoundPoint IP 301 phones do not support bitmap logos. Model Width Height Color Depth IP 300/301 n/a n/a n/a IP 430 94 23 monochrome IP 500/501 114 51 4-bit grayscale or monochrome IP 600/601 209 109 4-bit grayscale or monochrome IP 4000 150 33 4-bit grayscale or monochrome Logos smaller than described in the table above are acceptable, but larger logos may be truncated or interfere with other areas of the user interface. The SoundPoint IP 500/501/600/601 phones only support the four colors listed below. Any other colors will be approximated. The SoundStation IP 4000 phone only supports black and white. Any other colors will be rendered as either black or white. Color RGB Values (Decimal) RGB Values (Hexadecimal) Black 0,0,0 00,00,00 Dark Gray 96,96,96 60,60,60 Light Gray 160,160,160 A0,A0,A0 White 255,255,255 FF,FF,FF Configuration File Changes Warning: Polycom recommends that you create another file with your organization’s modifications. If you must change any Polycom templates, back them up first. For more information, refer to the “Configuration File Management on SoundPoint® IP Phones” whitepaper at www.polycom.com/support/voip/. Note: Use an XML editor to edit the configuration file. In the <bitmaps> section of sip.cfg, find the end of each model's bitmap list and add your bitmap to the end; do not include the .bmp extension: <bitmaps> <IP_300 … /> <IP_500 … bitmap.IP_500.66.name="logo-500" /> <IP_600 … bitmap.IP_600.70.name="logo-600" /> <IP_4000 … bitmap.IP_4000.70.name="logo-4000" /> </bitmaps> Next, enable the idle display feature and modify the idle display "animation" for each model to point to your bitmap (again without the .bmp extension): <indicators ind.idleDisplay.enabled="1"> <Animations> <IP_300> … </IP_300> <IP_500> … <IDLE_DISPLAY ind.anim.IP_500.38.frame.1.bitmap="logo-500" ind.anim.IP_500.38.frame.1.duration="0"/> … </IP_500> <IP_600> … <IDLE_DISPLAY ind.anim.IP_600.38.frame.1.bitmap="logo-600" ind.anim.IP_600.38.frame.1.duration="0"/> … </IP_600> <IP_4000> … <IDLE_DISPLAY ind.anim.IP_4000.38.frame.1.bitmap="logo-4000" ind.anim.IP_4000.38.frame.1.duration="0"/> … </IP_4000> </Animations> … </indicators> Finally, edit the {MAC}.cfg file to instruct the phone to download the bitmap files at boot time: MISC_FILES="logo-500.bmp" [for SPIP 500/501 phones] MISC_FILES="logo-600.bmp" [for SPIP 600/601 phones] MISC_FILES="logo-4000.bmp" [for SSIP 4000 phones] Many configuration-generation systems do not make it easy to customize the contents of this file based on the model; if you are using one of these systems, you can have all phones download all the bitmaps: MISC_FILES="logo-500.bmp, logo-600.bmp, logo-4000.bmp" [for all phones]

I also adjusted the max loop and that helped some of our issues we had what I was wondering if it’s possible to allow anything that was done on the PBX end that will cause loops, except if it was done on the UA (like forwarding a call to your own number, will cause a great number of loops, which is a user error, that should be considered a loop detection)

with the DECT phone your using with the ATA, can you transfer calls from one handset to another? how many calls can you take on one device? how many callers can you put on hold? i am looking for a good dect phone for a client, they have used the aastra and are very unhappy

i leave the outbound proxy blank and still able to receive calls

for incoming only why would you need an outbound proxy?

can you post some exact instructions on how to set this up? im sure it is much better to keep the traffic within the server rather then terminating with another carrier

the way it will work is that it wont block the CID on any number thats entered into the Emergency Number field on the Domain Level? and can there also be a Emergency Field in the System level? this way we dont have to go into 150 domains and add the Emergency Number? thanks!

PBX directory / generated / then you will find the domain name / then the extension number / there is the files the phone gets when doing PnP

because as an employee if he wants to use disa, he is unable to if the only DID the company has is on a Hunt Group also eventually to go fancy, maybe be able to restrict which user can and which user can’t use DISA on certain DID's maybe having a page that has allot of controls for DID's is also good (for example to which account it belongs, have a setting to reject blocked CID calls, set who can use disa on that DID, have service flags to which account it should ring based on service flag etc)

again, why do you need the CO lines? what do you want done? have unlimited calls coming in from any of the 2 trunks you use for incoming?

add the DID on the Confrence Room 71 account in the same field that has the account number "71" here is a picture of how i have it set up if you need further help, let me know!

how about at least have it on every account except on an extension? this way a hunt group / agent group / auto attendant / ivr node etc has it? but still have the option to uncheck a radio button on that said account to disable it?

would be much better by per extension also is it possible to have DISA even the DID is not on a Auto Attendant?

didnt we also see that there might be another web server running and thats why its unable to start the PBX? check what else is running in the background that could cause this issue

exactly thats why were requesting to have this option that if a end user blocks his outbound calls. it should not be blocked for "emergency" calls

Is it possible to set that *67 should NOT take effect on Emergency calls? I’m having a problem with if customers block their outbound caller ID, it will also block it on 911 calls this is NO good

what info do I give the other person to use as credentials to register?

even better if its possible to set to which accounts (if i edit an extension) it should apply to changes so lets say this way i can set a domain that has 150 extensions to only apply to the new ANI on 25 extensions at once, without having to go over all those 25 extensions