Vodia PBX

If you activated the Blue license in the past few weeks, the PBX will not drop calls because of 3rd party registrations. Maybe we have a SIP problem here. Did you see the REFER request in the log and the answer from snom ONE?

Can you check in the status screen how much file system space is left? Maybe you just ran out of file system space. Also, can you log on to the system with SSH?

Das Problem is definitv bei den neuen Headern für SIP Trunks (Leitungen). Ich würde die Leitung nochmal zum editieren aufrufen (im Webinterface) und dann einfach nochmal "save" drücken. Es scheint so dass da bei bestimmten Einstellungen nicht alle header korrekt gespeichert werden. Wenn das nicht hilft, einfach nochmal die verschiedenen Modi kurz durchprobieren und wenn das auch nicht hilft müssen wir ins Detail und die Header nochmal manuell konfigurieren. Basierend auf dem funktionierenden Beispiel auf 4.3 würde ich es mit folgenden Einstellungen versuchen: Request-URI: Let the system decide From: Extension ANI To: Same like Request-URI P-Asserted-ID: Dont use header P-Preferred-ID: Dont use header Remote-Party-ID: Extension ANI P-Charging-Vector: Dont use Privacy Indication: Dont use Wenn die Rufnummerunterdrückung nicht klappt, würde ich bei Remote-Party-ID herumschrauben, aber nicht bei Privacy Indication. Sorry für das Chaos, aber leider sind die vielen RFC und Implementierungen im Bereich SIP Trunking inzwischen mit einem einfachen Drop-Down nicht mehr zu handhaben. Dokumentation gibt es unter http://wiki.snomone.com/index.php?title=Trunk_Custom_Headers.

There were bugs in some firmware versions of the phone. The latest is 8.4.35 (see http://wiki.snom.com/Firmware/V8/Features).

Yes, but PnP is only for snom phones.

We did not put all languages there because we did not want to use up all the space only for languages. There are a lot of things on the box that are not used, e.g. Perl, PHP that you can throw off the Flash and then you would be able to fit everything in. The point is you need to look into the debian documentation. Unfortunately, for this production series we were using a pretty old Flash image; we'll do the cleanup for the next production round so that we should have much more space then.

I dont see anything special about that DNS address: $ host -t NAPTR voip.eutelia.it $ host -t SRV _sips._tcp.voip.eutelia.it Host _sips._tcp.voip.eutelia.it not found: 3(NXDOMAIN) $ host -t SRV _sip._tcp.voip.eutelia.it Host _sip._tcp.voip.eutelia.it not found: 3(NXDOMAIN) $ host -t SRV _sip._udp.voip.eutelia.it _sip._udp.voip.eutelia.it has SRV record 0 0 5060 voip.eutelia.it. $ host -t AAAA voip.eutelia.it $ host -t A voip.eutelia.it voip.eutelia.it has address 83.211.227.21

65 % is a lot. The PBX always runs on one core, otherwise you would a lot of jitter when the OS shifts it from one core to another. Recording does take it's toll. Saving to the harddrive can slow down the fetching of files in toto; the result would be that the prompts are played back with a delay, but once that they are in memory they are played continuously. Options Use a faster server Turn the compression off for the recordings. That will occupy more space for the recordings in the beginning; however if you can use a small script that grabs the files and then actually compresses it in MP3 format (not sure though how to do this on Windows) this would become a feature Make sure that the hard drive does not take additional CPU horse power (e.g. flash access). Check if you are using G.711 codec. If you are using other codecs like G.729A, GSM, even G.726 they also consume CPU horse power SRTP also takes its toll. Not sure if you want to turn this off and this is a totally trusted environment.

I would first try to keep the AA out and send the call directly to the FAX to make sure that the T.38 works. It does not only depend on the ATA, it also depends on the PSTN side. If you have a PSTN gateway, it has to support T.38 or elsewise you just have to use G.711 (in a LAN, that should be okay). If you ahve a service provider, things might get tricky, because many ITSP have a hard time supporting T.38 and you cannot just use G.711 because of the packet loss.

With yellow you can register extensions; we recenty changed the third party registration policy, so you are able to register 20 phones e.g. from Aastra. However these devices are not provisioned automatically by snom ONE, and also the support is limited to the forum. With blue there is no limitation for the number of extensions.

You are experiencing the famous "NAT" problem. In a nutshell, in VoIP you must make sure that the PBX runs on a "routable" IP address. Routable means routable for the registered phones and PSTN gateways, and also sometimes routable for service providers that dont have a session border controller. You can achieve the routable by running the PBX at least on one interface on a "public" IP; here you must make sure that the routing table is set up properly, sometimes the OS picks the private IP address as the "preferred" IP address which would cause problems then. Another way to get routable IP addresses is to use a VPN for the company. This also solves the problem as if everything would be in the LAN. Putting the PBX into a DMZ is possible, but very tricky because especially the RTP ports can be very hard to predict and TCP port forwarding also can be tricky. IPv6 offers very cheap routable IP addresses, but is as of today not widely available. One nice day when IPv6 is available, we can save a lot of time for things like this.

Wir arbeiten auch an einer "Virtuellen Appliance" für VMware, sehr spannended Thema....

Es sieht wirklich so aus, als ob die Rufnummernunterdrückung eingeschaltet ist (Privacy: id, bei Interesse mal RFC 3325, § 9.3 durchlesen). Das funktioniert offenbar hervorragend. Bitte nochmal unbedingt überprüfen, ob bei Herrn Gödde die "Telefonnummer bei ausgehenden Anrufen unterdrücken" eingeschaltet ist (im Webinterface, ganz unten bei den Settings für die nebenstelle).

Well all I remember that there was a bug some versions ago. IMHO it is worth trying to upgrade.

This is for office 365, right? There is a nice video at http://help.outlook.com/en-US/140/cc188672.aspx#FindTheServerSettings explain this and I guess that is where you got the settings from. It could actually be that the certificate that is being used by office 365 is not installed in the standard snom ONE installation. If you go to the certificates page in the admin mode, try to import the following certificate as trusted server certificate Root CA. Maybe that solves the problem. -----BEGIN CERTIFICATE----- MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0 aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjEL MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2ln biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp U2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1 nmAMqudLO07cfLw8RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbex t0uz/o9+B1fs70PbZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIz SdhDY2pSS9KP6HBRTdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQG BO+QueQA5N06tRn/Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+ rCpSx4/VBEnkjWNHiDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/ NIeWiu5T6CUVAgMBAAGjgbIwga8wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAH BgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVy aXNpZ24uY29tL3ZzbG9nby5naWYwHQYDVR0OBBYEFH/TZafC3ey78DAJ80M5+gKv MzEzMA0GCSqGSIb3DQEBBQUAA4IBAQCTJEowX2LP2BqYLz3q3JktvXf2pXkiOOzE p6B4Eq1iDkVwZMXnl2YtmAl+X6/WzChl8gGqCBpH3vn5fJJaCGkgDdk+bW48DW7Y 5gaRQBi5+MHt39tBquCWIMnNZBU4gcmU7qKEKQsTb47bDN0lAtukixlE0kF6BWlK WE9gyn6CagsCqiUXObXbf+eEZSqVir2G3l6BFoMtEMze/aiCKm0oHw0LxOXnGiYZ 4fQRbxC1lfznQgUy286dUV4otp6F01vvpX1FQHKOtw5rDgb7MzVIcbidJ4vEZV8N hnacRHr2lVz2XTIIM6RUthg/aFzyQkqFOFSDX9HoLPKsEdao7WNq -----END CERTIFICATE-----

I think the other trick is to just hit the save button on the trunk, because the upgrade changes might not have done the trick yet.

The problem seems to be related to a snom m9 that streched over a couple of extensions that also have other phones provisioned. This kind of "glues" everything together. I remember there was a reason for that; but I just can't recall why.

OMG. The next name will probably be "Coma Berenicids".

Hmm. I dont know how Swedish tones sound; but all it takes is the ringback.wav and the busy.wav file in the audio_se directory.

Only if you import accounts by CSV.

Das kann man im Admin-Modus bei "Protokoll" einstellen: "Nachrichten von Gesprächen anzeigen" einstellen.

Also das Problem besteht mit dem Patton Gateway? Bei snom ONE plus dachte ich zuerst an Probleme mit Sangoma... Wir müßten uns mal die Header ansehen. Das ist der Klassiker für Probleme beim Upgrade auf 4.5. Beim Trunk ist "Remote-Party-ID" eingeschaltet und das könnte für Patton okay sein (ich bin da leider nicht de rgrößte Experte). Einfach mal ein paar andere Kombinationen kurz ausprobieren. Aber es würde helfen, wenn wir hier eine Kopie des SIP INVITE Paketes sehen könnten welches and das Gateway geschickt wird. P.S. Ich würde beim Trunk die Erkennung "Ton für aufgelegten Anruf erkennen" ausschalten. Das ist nur erforderlich wenn das Gateway das nicht unerstützt; das sollte aber bei Patton kein Problem sein und es kann bei snom ONE nur zu unerwünschten Gesprächsabbrüchen führen.

If you connect an Ethernet cable directly between the PC and the box you might have the simple problem that the polarities are not okay and there is no link (old problem, all switches have automatic discovery today, no more "uplink", but many endpoint like PC dont have autodetection). Ideally you should use an Ethernet hub, but most switches are also okay and you should see at least some IPv6 annoucements. Not even IPv6 messages going out?! If you have a static IPv4 address, you would obviously not see any DHCP traffic. I guess this one then needs to go back to the snom clinic, seems like only JTAG will help to reanimate it.

Okay, getting closer. Now you have the SIP traffic (where jitter is not so important). Maybe you should just grab all the traffic so we can be sure that you also get the media (RTP) data.

The idea here was to use the Ethernet switch to do a port mirroring. This guarantees that Wireshark is not introducing new problems to the system. Then you can use another system to run Wireshark on the port mirror.