Vodia PBX

Well you could match the from and the to information. But I think because the CSTA concept is linked to the extension device, the call-ID are different.

If you can use VLC, that's probably the easiest. There is a Wiki article on the subject, check out http://wiki.snomone.com/index.php?title=Streaming_VLC_and_snom_ONE.

I would park the call with *85 and then pick it up with *86.

What you can do is to send the call to an extension instead of a trunk. If the request still times out, then it must really be linked to the auto attendant. If it all does not help, it might be good to take a look at the SIP packets.

Na das wird durch snom gesteuert. Allerdings wage ich zu bezweifeln dass dort jemand ein Vodafone-Telefon in ein "unlocked" Telefon umwandelt. Siehe Handy... Bei der Dokumentation haben wir nach Aufholpotenzial... Aber wir freuen uns natürlich immer wenn wir auch mal ein Lob bekommen...

Eh I don't understand the question... Vista or visa? Do you want to stream audio from the built-in audio connector? Or from a network socket? On which page in the web interface are you.

Option 67 einfach frei lassen oder auf /prov/snom821-000413123456.htm setzen (MAC entsprechend anpassen). Wenn ich mal http://provisioning.snom.com/snom821/snom821.php?mac=000413530441 aufrufe, bekomme ich "setting_server: https://cs.vodafone-ip.de:22160/snom/getConfig.xml?mac={mac}". Mit anderen Worten: die Telefone werden "magisch" von Vodafone angezogen (dagegen können wir hier definitiv nichts unternehmen). Das dürfte auch erklären, warum diese Telefone sich so sehr dagegen sträuben, an der lokalen PBX anzumelden. Aber vermutlich ist DHCP option 66 stärker als die Cloud-Provisionierung. Ich schätze dass da irgendwie eine "Schleife" entstanden ist, die alle Nebenstellen einbezieht. Wenn Nebenstelle A MAC 1 und 2 beinhaltet, und Nebenstelle B MAC 1 und 3, dann werden alle in diesen Strudel hineingezogen. Wenn das alles nicht klappt, würde ich die m9 manuell konfigurieren; denn bei denen gibt es eigentlich nicht viel einzustellen.

I can understand that Nextiva does not know what to do with numbers starting with 9. This is actually a reason why we advocate to use "real" numbers without funny prefixes. Now we need to find out where the "9" crept in and undo this.

Thanks. We will have to wait until the image has been tested and released, so that snom ONE customers have a positive experience when they upgrade.

Thanks. This is more like a reminder that some translations are missing and have to be added from our side. They are not critical.

Hmm, would the setting redirect on busy not do that? For people with a lot of calls, it should be rather a ACD (with the extension as the only agent in it), so that callers can be lined up for later pickup.

When it comes to the phone's firmware we have to live with what is available. I am not sure if another PBX can solve that problem.

Of course you can also store the duration in version 4.5; however you need to calculate that. If you use e.g. PHP this should be easy to do by calculating the difference between the end of the call and the time when the call was connected.

Inactive means that the extension has not been used over the last 30 days. It has no effect to the behavior of the PBX, just for the reporting for the billing.

Does the 870 extension have a different dial plan assigned? I still don't think that it is really related to the phone type, but it sure depends on the extension. Edit: Why does the phone call 9xxxxxxxxxx? It is supposed to call 1xxxxxxxxxx or just xxxxxxxxxx.

I don't think it makes any difference what phones you are using. The problem is the trunk. In the trace above, the call seems to be sent out on the NetborderExpressGateway trunk, not the Nextiva trunk. Maybe you need to double check your dial plan if it really sends the call to Nextiva.

What if you blind transfer into the park orbit?

We are starting to get the GXP-2100 working. I think the differences to the GXP-2200 are marginal.

It means that the PIN of that extension is not secure enough (1234, 0000).

Inbound calls or outbound? For inbound the SIP headers in the trunk don't matter at all. On the phone, the problem is like this. The phone receives a packet like this: From: Donald Duck <sip:2121234567@domain;user=phone> To: Daisy Duck <sip:123@domain;user=phone> You can see what the PBX sends in the INVITE packet in the log. Some phones also do a LDAP look-up on incoming calls, that could complicate the situation. Then the next step is what the phone makes out of it.

Ich würde mal einfach den anrufen, der auch das Netzteil getauscht hat.

Ich schätze da bleibt nur RMA

Hmm. Dann haben wir hier ein mini-ITX Türstopper der nicht hochfahren will.

Unfortunately, the Caller-ID presentation is a difficult topic in the SIP world. Most SIP trunking providers simply don't allow presenting numbers that are not owned by the trunk (spoofing danger). What provider is it? Do they have documentation? Maybe we can add them to the drop-down. Apart from that, the trunk ANI (DID is for inbound, BTW) might have higher priority than the extension ANI. If you want to define a default ANI, consider doing that on the domain level.

Sieht so aus als ob das Linux bootet, aber irgendwo steckenbleibt. Macht es einen Unterschied ob the Sangoma-Karte drinsteckt oder nicht? Vielleicht wird da irgendein Treiber nicht richtig geladen und der Kernel steckt in einer Endlosschleife.