Vodia PBX

Hmm. Ideally, you run Wireshark during the day (with rotating files) and if it happens again, the agent should pencil down the time and the number as far as he can remember. Then we can start digging in the data what is going on. Also it would be good to know when exactly the outside parties get connected together. Does the agent do anything like pushing a button or does that happen without interaction of the agent? What PSTN termination are you using, which model? Any firewall involved (especially when using a service provider)?

Can this be reproduced or is it random? For example, if you use two cell phones for testing and do this, does it happen?

So are you sure that the trunk did not appear in the web interface any more?! I assume that the file system is not full, right? What PBX version are you on?

You mean two wrong guys got connected together? Of course this should never happen, I remember we had a case years ago where the was an IP address conflict in the LAN (static IP addresses ). It was very difficult to chase this one down. If you have any more hint where the problem is, that would be of course useful. E.g. if you have lots of other devices in the network and this happens only with m9, well then we would have to dig deeper on the m9.

What platform are you using (Windows/Linux/snom ONE mini/...)?

Well, for snom ONE the automatic provisining of PAP2 was removed (for pbxnsip versions, it is still there). You have to create those files on your own, see the documentation of the PAP2T. You can put them into the tftp directory in the working directory of the PBX, so that at least you dont have to set up a TFTP.

Could be a problem with the XML encoding? Remember that < must be encoded like "<" and > as ">", so it would be <fkey idx="3" context="2" label="Night Mode" perm="">dest <sip:987@192.168.2.135;user=phone></fkey>

We also tried that a few days ago--and also did not get any response on the CSTA... Seems something got broken there.

When the PBX sends out HTTP requests it does not use port 80. TCP clients usually use a random port. Maybe thats the problem.

This is a "hot" topic. snom was using an old, proprietary method and with the latest firmware upgrades, the from-change RFC should be implemented in the latest firmware versions and snom ONE should be taking advantage of that. I am not sure where exactly the phone firmware and the snom ONE release are exactly right now, but they should be "converging" soon.

Can you copy & paste the text-form trunk settings here (click on text-based in the trunk settings)? Without the password.

Did you specify the outbound proxy on the trunk or explicitly set the addresses where the trunk sends SIP messages from?

That really sounds like a bug to me. The call should be returned to the extension that was connected to the other side.

The group mailbox functionality needs some rework IMHO. It is there for a long time; in the meantime we added functionality to copy messages into mailboxes, and operations like deleting affects all copies. That would be much more appropriate than having the phone to deal with two or more mailboxes, which is very confusing, not only for the phone.

The snom 300 is a somewhat special case compared to the 320/370. The snom_300_fkeys.xml contains a setting for the DND key, you might have to take it out in the template. Then it is the same like on the 320/370 devices, and should also behave the same. After performing the change, you better factory reset the 300 to make sure that the DND key is clean.

Das working directory ist das Arbeitsverzeichnis der PBX, wird im Status angezeigt (sowas wie /usr/local/snomONE bei Linux). Am besten einfach ZIPpen und dann irgendwo herunterladbar machen (einfach einen Link als private message hier im Forum schicken). Es ist schon besser das gesamte Directory zu schicken, da es offenbar nicht nur einfach ein simples Problem mit den Sternchen-Codes ist.

Sounds like a problem with DNS to me or you are trying to sniff on the loopback interface.

Wenn wir das Working Directory bekommen als ZIP können, dürfte uns das leichter machen das Problem zu reproduzieren... Mit Versionsnummer welche PBX im Einsatz ist...

If you have only one name that you want to see there, this is the username in the trunk settings. Trunks have username and authentication name seperate, so it should be possible to present the username that they expect.

Not being the biggest Yealink expert, I would assume the address of the PBX. Usually phones start with TFTP and then continue the provisioning on their own with a more reliable protocol like HTTP or HTTPS.

Hmm. We have to double check, maybe there are differences between the other phones and the 7xx series.

Did you PnP those phones?

Did anybody from the sales department get back to you?

Looks like there is absolutely nothing coming back from the service provider. I assume this is because the From-Header has nothing in it that matches the subscriber database. This is debatable, but (in the light of DoS) understandable. I would change the From header to always use the subscriber information, for example "{trunk}" (without the quotes).

Check out the files in /etc/init.d, there is something like snomone (not sure which one is it, just grep for snom: cd /etc/init.d; grep -i snom *). There you must edit the executable as well.