Vodia PBX

Maybe just take the below file and modify the time section (call it snom_m3.cfg). That should fix your problem for the moment (create and put it into the html directory). //-----------Network Settings------------ %SIP_RPORT_ENABLE%:1 // A way around NAT %SIP_STUN_ENABLE%:0 // 0-disable, 1-enable stun services %NETWORK_STUN_SERVER%: "stun.com" // insert name of STUN Server here %SIP_STUN_BINDTIME_GUARD%:80 %SIP_STUN_BINDTIME_DETERMINE%:0 %SIP_STUN_KEEP_ALIVE_TIME%:90 %SIP_RTP_PRIORITY%:{global tos_rtp} %NETWORK_VLAN_ID%:{parameter NETWORK_VLAN_ID} %NETWORK_VLAN_USER_PRIORITY%:{parameter NETWORK_VLAN_USER_PRIORITY} %VOIP_SETTINGS_PIN_CODE%:{parameter VOIP_SETTINGS_PIN_CODE} //------------Network Time--------------- %NETWORK_SNTP_SERVER%:"{tz ntp-adr}" // insert a local NTP Server here %NETWORK_SNTP_SERVER_UPDATE_TIME%:0xFF //SNTP Update in seconds %GMT_TIME_ZONE%:{tz gmt-hour 13} %DST_ENABLE%:{tz dst-enable} %DST_FIXED_DAY_ENABLE%:{tz dst-fixed} %DST_START_MONTH%:{tz dst-start-month} %DST_START_DATE%:{tz dst-start-day0} %DST_START_TIME%:{tz dst-start-hour} %DST_START_DAY_OF_WEEK%:{tz dst-start-wday} %DST_START_WDAY_LAST_IN_MONTH%:{tz dst-start-last} %DST_STOP_MONTH%:{tz dst-stop-month} %DST_STOP_DATE%:{tz dst-stop-day0} %DST_STOP_TIME%:{tz dst-stop-hour} %DST_STOP_DAY_OF_WEEK%:{tz dst-stop-wday} %DST_STOP_WDAY_LAST_IN_MONTH%:{tz dst-stop-last} //--------Provisioning Server------------ %NETWORK_FWU_SERVER%: "provisioning.snom.com" // Firmware update server IP or FQDN %FWU_TFTP_SERVER_PATH%:"/m3/firmware/" //subdir to find Firmware updates %VOIP_LOG_AUTO_UPLOAD%:0 //0-no uploading, 1-upload bootlog only,2-upload everything {loop-start 0 8} // ------------ SIP Server --------------- %SRV_{lc}_SIP_UA_DATA_DOMAIN%:"{domain}" %SRV_{lc}_SIP_URI_DOMAIN_CONFIG%:0 %SRV_{lc}_SIP_UA_DATA_SERVER_PORT%:{sip-udp-port} %SRV_{lc}_SIP_UA_DATA_PROXY_PORT%:{sip-udp-port} %SRV_{lc}_SIP_UA_DATA_SERVER_TYPE%:0 %SRV_{lc}_SIP_UA_DATA_SERVER_IS_LOCAL%:1 %SRV_{lc}_SIP_UA_DATA_REREG_TIME%:600 %SRV_{lc}_SIP_UA_DATA_PROXY_ADDR%:"{ip-adr}" %SRV_{lc}_DTMF_SIGNALLING%:2 %SRV_{lc}_SIP_UA_CODEC_PRIORITY%:0, 1, 2, 4, 255 // ------------- Registration ------------------- %SUBSCR_{lc}_SIP_UA_DATA_SIP_NAME%:"{account}" %SUBSCR_{lc}_UA_DATA_DISP_NAME%:"{display-name}" %SUBSCR_{lc}_SIP_UA_DATA_SIP_NAME_ALIAS%:"{account}" %SUBSCR_{lc}_SIP_UA_DATA_VOICE_MAILBOX_NAME%:"{account}" %SUBSCR_{lc}_SIP_UA_DATA_VOICE_MAILBOX_NUMBER%:"{account}" %SUBSCR_{lc}_UA_DATA_AUTH_NAME%:"{account}" %SUBSCR_{lc}_UA_DATA_AUTH_PASS%:"{password}" {loop-end} // ----------Emergency Primary Line---------------- END_OF_FILE

Well, we need to get the initial seed for the random number generator sorted out. Depending on your operating system the answer will differ. For example in Linux, usually the OS will inject some randomness (e.g. by measuring the interrupt time). Maybe we also need to do something like taking some configuration-based data to add more randomness to the system; but first lets try to find out what exactly is causing this surprising non-randomness.

Make sure that all user agents subscribe for the MWI event. The PBX tries to do a favor and send MWI also out if there is no subscription. But as soon as one registered device has a MWI subscription it sticks to the subscriptions. I guess this is a topic that we need to clean up (no more favors).

1) Yea, that is a common problem in this kind of setup. As long as you have less than 10 destinations you can use the direct destinations feature to work around this. 2) Hot desking is like changing the registration. The call redirection is sending out new calls. That is why hot desking cannot work across different PBX.

Seems we had a similar finding, see http://wiki.pbxnsip.com/index.php/Performa...perating_System.

Hmm. That looks like the PBX must have picked something up from the trunk... You are sure that this was not the domain name??? Anyway, there is no deeper meaning.

It is strange that they share the same call-ID. That looks like there is a problem with the initialization of the random number generator.

Try (915[0-4][0-9]*)@.* - the match must also include the domain name...

There is a SOAP request for this (especially for hospitality purposes). Not sure if that is "simple"...

Whow the Call-ID are the same! Is that Windows or Linux?

Well, in the night mode checking area, you can list more than one service flag. E.g. you have one manual first, and if that is not set then take the automatic. That could help solving the problem. Service flags are mit second-precise but reasonable (I would say minute-precise).

Maybe you can combine one automatic flag with another manual flag. The ACD checks the manual flag first; if it is set, the call gets redirected somewhere else (maybe the "overtime" ACD). Otherwise the standard rules apply for 9-5 automatic flag.

That sounds like a license problem. Anything in the LOG?

No. The value is what the PBX passed down to the OS. It is just an integer in the range between 0 and 255, I believe in steps of 4. A value of "184" is the default, corresponding to the value "B8" (hexadecimal), corresponding to B8 >> 2 = DSCP 2E. Not sure what value CS5 has... If you look in Wireshark on a IPv4 packet, you see the bits right there. A lot of talk about 8 bits in the IP header.

Well the question is what should the PBX then do with the presence information?

There is a global setting called "tos_rtp". This gets propagated to the phones as well (if the PnP file supports it).

If you are a pragmatic guy, just overwrite one of the prompts with what you need. Adding it "in style" would be a lot of work.

Changing the port number is as bad as changing the IP address. You have a lot of "black spots" in the availability of the device, don't be surprised if you have "random" unavailability of the device. Anyway, if you don't want to receive those email messages, set "email_address_change" to "false" (see http://wiki.pbxnsip.com/index.php/Global_Configuration_File).

http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems and http://wiki.pbxnsip.com/index.php/One-way_Audio would be locations that I would check.

Those messages are serious and a indication something is not right with that extension. If the address keeps changing probably the router is not suitable for stable VoIP. You can turn the notification of with a special setting, check out your pbx.xml file for "email_address_change".

For per-call basis the user needs to start the recording from the phone. You can either use a special code for that (see the feature codes in the domain) or use a special key on the phone. Then the recording does not land in the file system, it lands in the mailbox as if someone left a voicemail.

If there is no need to upgrade don't do it... We keep the release notes on the Wiki. If there is nothing that interests you, "never change a running system".

The SMTP settings are either in the "Logging" settings on admin (really difficult to find, but we already moved it into a own email section) or in the domain settings.

It is strange. Maybe we can "catch" the situation also here in our test system.

The PBX is just obeying oders regarding the TTL. If the service providers thinks that it is enough to check once per day if a record changes it is a "feature" that the user has to wait one day until the DNS record changes. Though I have some doubts that that was the problem. I know from other users that they did not have such a problem with callcentric. And you can always override the DNS by manually looking it up and putting the IP there temporarily.