Vodia PBX

If you use two gateway trunks, the PBX somehow needs to figure out to which trunk incoming calls belong. If they are coming from the IP address, this will not help. What helps is setting the account name of the trunk to what the provider sends when using the trunk. If there is a match, the PBX will find the right trunk even if there are several trunks that receive traffic from the same IP.

Okay, now it is getting interesting... What ciphers does Bria offer? Wireshark will show it.

We are also re-visiting the password issue

Bria actually checks the certificate, this is perfectly okay. What you need is to add the snom ONE certificate to the trust chain, then Bria can also work with TLS. You can check and do this by using your web browser and navigate to the snom ONE HTTP web interface and then use the browsers tools to add the certificate. Then Bria will also take it.

There were complains stating that it would be a waste to use an extension license to have someone login as domain administrator and there was a point. So we changed the concept and explicitly create the concept of system administrators and domain administrators. Now when you click on the edit button in the domain list you can set one or more domain administrators for the domain.

Had recently been re-addressed ;-) 5.0.10k already has it.

For example if the other phones are in a remote location and the one local stays registered it would be possible... It is not always easy to find the root cause immediately. For example, what if the caller-ID is "<script>alert('hello');</script>", then e.g. the phones that use webkit might act different than the others... Also we recommend to use a little bit more outdated firmware for the snom phones as the newer firmware have various strange behaviors, also in the area of dealing with incoming calls. Bottom line: Any clue that makes the problem more reproducible is welcome...

Okay the screen is not completely blank... The time server seems to be working in principle. The Polycom has a attendant mode where people can see incoming calls (hopefully silent) for the purpose of checking pickup. Could it be something in this area that screwed up? The phone also has a web server, this could be a way of peeking at the configuration and finding a clue if something strange has been provisioned.

Well we had some issues with the forum... Upgrading it obviously helps :-) Did you check the flag "Remember login information"? If yes, clear the cookie for the web page and try to login without it.

Something like that can definitively happen if for whatever reason the PBX looses the connection to the phones while they are ringing. They simply don't get the cancel message. You can track such things down by having the PBX send out an email when the phones lose registrations; just to get an idea on how many times that happens. There were some older versions on the PBX where this situation also could happen when everything was okay in the network. But if you are on a recent version it should be not a problem any more.

Sounds to me like your IP address was blacklisted by the PBX. This can happen easily, especially if the Xlite hammers out lots of requests before having the chance to answer the first challenge from the PBX.

Sorry wir können die Posts nicht zwischen verschiedenen Servern verschieben. Bitte einfach ein neues Thema auf forum.snom.com aufmachen.

Well well, here we go again. Firefox 22 has a different way to secure the packets than Chrome. This will keep us busy for some time.

Nope. The problem is that the PBX usually sends a 183 back with a SDP attachment, while on the other side of the B2BUA you would have the video negotiations still going on. This would result in the SDP in the 200 Ok being an *offer*, not an answer--which it okay according to the standards, but practically no device supports that today. The alternative would be to give up on SDP in 18x; but we need that when calling (and potentially forking calls to) PSTN. Forking does not work well with early media.

Does the PBX get all sockets that it needs? We also had problems when the PBX was constantly trying to get port 80 on IPv4 and IPv6. We have changed the algorithm for allocating the ports that makes it a lot more probably that the PBX actually gets the ports and keeps them. Apart from that, your session duration might be too short.

Falsches Forum? forum.snom.com? Abgesehen davon, nach dem Ändern der Settings muss man wohl nochmal auf "Save" drücken.

Well video is not video... You can still start a regular call and then turn video on. The video and the audio will flow through the SBC. Surveillance video is a different nature. It is "one-way video" and usually not so critical regarding frame rate. And it sometimes runs around the clock It is better to keep the PBX out of the loop there.

Maybe you should also check the "Hangup Timeout" of the AA.

My guess is that the service provider has problems with early media. Sometimes that even depends on the number where the call comes from (2nd tier service provider). There is a settings in the trunk called "send 180 message" or so; try to turn that on to see if that helps. Obviously you loose the possibility to send the ringback tone from the PBX, but that is better than dead air.

In principle that is a good idea. Changing templates is a good idea instead of changing code. However, the PBX will (hopefully) block this request--users are not allowed to see other users CDR. Also, the scope of available XML commands is pretty much narrowed to what is already available.

Did you set the system maximum recording destination?! 20 seconds seems really very short. Can you leave voice-mail messages which are longer than 20 seconds?

We had reports that changing from TLS to TCP dramatically increased the stability of installations. We are also scratching our heads why. It is easy to blame US NSA and the British Intelligence for this, but no serious explanation. We need to keep watching this topic.

What OS do you use?

Sounds weird! Can go get us a screen shot (cell phone camera)?

I believe what is missing is this: reg.{lc}.lineKeys="{lines}"