pbx support
-
Posts
2,081 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by pbx support
-
-
Probably the DTMF is not being transmitted to the PBX with the new setup. That's why when the customer presses 1, nothing happens.
Meanwhile, you can make use of the"AA->Redirect number & AA->Timeout(s)" fields to forward/redirect the call to either sales or accounting so that you do not miss any calls.
-
-
Not sure if you checked the text in front of the link. It says - (will be released soon!). Probably it is not uploaded yet.
-
Couple of things -
- First check if you can download the http://provisioning.snom.com/download/fw/snom760-8.7.3.10-SIP-r.bin from your phone network.
- On the phone, Advanced->Upgrade page, make sure that "never update.." is not set.
Sometimes, a reset(instead of a reboot) of the phone would help clear everything out and thereby making this process easier.
- First check if you can download the http://provisioning.snom.com/download/fw/snom760-8.7.3.10-SIP-r.bin from your phone network.
-
http://wiki.snomone.com/index.php?title=OEM should provide you with the instructions.
-
We have not worked on this feature so far.
-
You should see "Firmware for snom 720:" field in that page. The 4.5.0.1090 version comes with http://provisioning.snom.com/download/fw/snom720-8.7.2.9-SIP-r.bin. You can modify this field to point to the new 8.7.3.10 version (just copy the firmware download link here).
Same goes for 760 too.
-
It used to get redirected to www.snom.com. Looks like something has changed.
-
In this case we/you really have to look at the RTP streams (In/Out). If the streams are different, then on some devices you will see this issue. The "Lock codec" (at the Admin->Settings->Ports page) supposed to take care of this very issue, i.e., if the phone is doing codec A and if the trunk provider is doing codec B, PBX will transcode codec B to codec A and send it to the phone.
-
Thanks but I think you misunderstood, what the customer would like is
1. during the weekdays monday-friday 9:00am-5:00pm hit a hunt group
2. monday-friday 5:00pm-8:59am hit an AA
Saturday-Sunday 9:00-5:00P New hunt group
Saturday-Sunday 5:00pm-8:59am hit an AA
This needs to happen automatically every week
thanks
You can setup the 2 service flags (one for week days and other for Saturday and Sunday) and then use those under the "AA->Night service" section to forward the calls to respective hunt groups.
-
If this is still an issue, can you capture a registration log between the PBX and the provider?
-
Is the trunk registered properly? The below message is indicates that the trunk is not registered.
[5] 2012/09/14 08:32:28: Registration on trunk 2 (Trunk SIP) failed. Retry in 60 seconds
-
Will be part of the next version too.
-
Ok, we will add the bulk delete option to access list too. (next version)
-
Just FYI..
[0] 2012/09/13 11:00:49: TCP(IPv4):Could not bind socket to port 443 on IP 0.0.0.0 [0] 2012/09/13 11:00:49: FATAL: Could not open TCP port 443 for HTTP/HTTPS [0] 2012/09/13 11:00:49: (IPv6)Could not bind socket to port 443 on IP [::] [0] 2012/09/13 11:00:49: FATAL: Could not open TCP port 443 for HTTP/HTTPS [0] 2012/09/13 11:00:49: TCP(IPv4):Could not bind socket to port 389 on IP 0.0.0.0 [0] 2012/09/13 11:00:49: FATAL: Could not open TCP port 389 for HTTP/HTTPS [0] 2012/09/13 11:00:49: (IPv6)Could not bind socket to port 389 on IP [::] [0] 2012/09/13 11:00:49: FATAL: Could not open TCP port 389 for HTTP/HTTPS [0] 2012/09/13 11:00:59: (IPv6)Could not bind socket to port 80 on IP [::]
This error will occur if the ports are being used by another service. That other service could previous instance of the snomONE PBX too.
Under Linux systems, OS does not release the ports up to a minute after the process has exited.
-
Audio issues are not generally related to the SIP headers. They are generally related to the NAT/Firewall issues. If the IP address in the 2 SDPs can't reach each other, then you will see this issue.
-
Those are learnt by the PBX based on which system it is running on.
For example, {http-url} tag will be replaced with http://192.168.1.10 ,if you run the PBX on 192.168.1.10.
-
You will have to modify the pnp.xml with these 2 sections (search for 720 section and then add these next to that. Position does not really matters, though)
<file name="snom_710.xml" encoding="xml"> <pattern>snom710.htm</pattern> <vendor>snom</vendor> <anonymous>true</anonymous> <protocol>tftp,http,https</protocol> <pnp-vendor>snom</pnp-vendor> <pnp-model>snom710</pnp-model> <pnp-version>^[78]</pnp-version> <pnp-content-type>application/url</pnp-content-type> <pnp-url>{https-url}/snom710.htm</pnp-url> </file><parameter name="snom_fw4_710"> <display>Firmware for snom 710</display> <value>http://provisioning.snom.com/download/fw/snom710-8.7.3.10-SIP-r.bin</value> </parameter>Then place the attached snom_710.xml under the 'html' folder.
-
I am really not sure where you are getting these message syntax from.
Please follow, TCP without SOAP as described in ECMA 323, Annex J
<?xml version="1.0" encoding="UTF-8"?> <GetForwarding xmlns=“http://www.ecma-international.org/standards/ecma-323/csta/ed3"> <device>sip:tom1@domain.com</device> </GetForwarding>
In any case, the next version will have the fix for the "crash". Thanks.
-
I am really not sure where you are getting these message syntax from.
Please follow, TCP without SOAP as described in ECMA 323, Annex J
<?xml version="1.0" encoding="UTF-8"?> <GetForwarding xmlns=“http://www.ecma-international.org/standards/ecma-323/csta/ed3"> <device>sip:tom1@domain.com</device> </GetForwarding>
-
Can you folks send the screen shot of the button profile assigned to that extension (on the PBX) and "Function Keys" page from the phone that is registered to that extension (phone's web interface)?
-
The order in which the snomONE uses the ANI for outbound caller id is -
- Extension ANI
- Domain ANI
- Trunk ANI.
So, if you do not have any ANI set for extension and domain, then you can set the provider supplied DID as trunk ANI. That should take care of your question.
-
No,it is not that ID. It is the actual agent extension number and ACD account number.
-
No, the Admin->Settings: CDR URL: setting
Transfer on Hangup - not disabling
in Call Treatment
Posted
We tested the same scenario here with the same snomONE software and with phone version 8.7.3.10 (that's what was running in the lab). Everything worked without any issues.
On the IP address topic, are you referring to the "Accounts" page? Then these IP addresses are reported by the phones in the REGISTER message using "WWW-Contact" header. So please check the REGISTER messages coming from the phone to see if they are reporting the right info.