Vodia PBX

No, they convert 1:1. You get exactly what you had before, but when switching to the snom ONE you have the third-party restriction (which would then allow zero third party registrations...). Probably a bad deal, so I would recommend to stay with the pbxnsip builds if you have old pbxnsip license.

From the trace it looks like the PBX does not pass the Re-INVITE to the other side. Seems there is something special in the call flow. Can you upload a PCAP (filtered for SIP should be enough)?

Check the ringtones.xml file (in admin/email/texts), maybe you need to edit the content there.

As far as I can see the phone cancels the call: 2010/10/22 08:44:55: SIP Rx udp:10.0.1.20:5060: CANCEL sip:0419275642@10.0.1.9:5060 SIP/2.0 Via: SIP/2.0/UDP 10.0.1.20:5060;branch=z9hG4bK-bec56812 From: "Study" <sip:10@10.0.1.9>;tag=2ee313253e138a52o0 To: "David Mobile" <sip:0419275642@10.0.1.9> Call-ID: cb32e5e1-aab976c6@10.0.1.20 CSeq: 102 CANCEL Max-Forwards: 70 Authorization: Digest username="10",realm="10.0.1.9",nonce="98778396f04a6faf7c8fc9510728eec9",uri="sip:0419275642@10.0.1.9:5060",algorithm=MD5,response="de8ea57e799ccaf0ead067704fc28557"\ User-Agent: Linksys/SPA942-6.1.5(a) Content-Length: 0 The call starts at 2010/10/22 08:44:18 (37 seconds), that smells like another problem: The call was never connected! What do we get from the service provider? 2010/10/22 08:44:18: SIP Rx udp:58.96.1.2:5060 SIP/2.0 100 Giving a try Via: SIP/2.0/UDP 10.0.1.9:5060;branch=z9hG4bK-788da3e8c08e13808dd46012212dc33e;rport=38116;received=220.233.7.137 From: "Silvereye" <sip:0280905395@58.96.1.2>;tag=599761217 To: <sip:0419275642@58.96.1.2;user=phone> Call-ID: 3b4df2ec@pbx CSeq: 17597 INVITE Server: Exetel Voip Content-Length: 0 and then 2010/10/22 08:44:23: SIP Rx udp:58.96.1.2:5060 SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 10.0.1.9:5060;received=220.233.7.137;branch=z9hG4bK-788da3e8c08e13808dd46012212dc33e;rport=38116 Record-Route: <sip:58.96.1.2;lr=on;ftag=599761217;nat=yes> From: "Silvereye" <sip:0280905395@58.96.1.2>;tag=599761217 To: <sip:0419275642@58.96.1.2;user=phone>;tag=as59355012 Call-ID: 3b4df2ec@pbx CSeq: 17597 INVITE User-Agent: ExetelVoip Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:0419275642@58.96.1.7:5091> Content-Type: application/sdp Content-Length: 303 v=0 o=root 1279 1279 IN IP4 58.96.1.7 s=session c=IN IP4 58.96.1.2 t=0 0 m=audio 56164 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - - a=ptime:20 a=sendrecv No 200 Okay after that in the log. Maybe the service provider wants to be nice and dont want to start the billing period... But the PBX does not receive a 200 Ok. I would say either the provider has a problem or the NAT timeout is very short and your firewall closes the UDP ports very quickly, so that the 200 Ok gets blocked. Are you able to receive inbound calls (SIP messages from the provider to the PBX after a relatively long time of port inactivity)? That would be an indidation that the firewall is not the problem.

The snom ONE yellow and blue don't have a maintenance program right now. There will be updates available as bugs are being fixed, hopefully not too frequent. But the goal is clearly to minimize "surprises" when applying software updates. There is a special warning in the admin landing page where we can notify customers that updates are available. In pure snom phone environments, customer can use the snom ONE builds instead, the pbxnsip license key is compatible with the snom license keys but AFAIK it does not include the third party licenses. When third party devices are in the game, therefore customers better stay with the pbxnsip builds to avoid "surprises" of the other kind. In any case, before upgrading guys make backups of the working directory. Then you can always roll back with no regrets.

I would install Wireshark on the PBX host and see what is going on on the packet level. Maybe just a simple problem with the routing table. At least you can make sure that everything is okay on the pbxnsip side.

You can change the format now in the system/admin/email section (we probably have the rename the email to something that better fits it new purpose)

As many of you probably already know, pbxnsip is now part of snom (see http://www.snom.com/en/news/press-releases...p-pbx-snom-one/ for the press announcement). What does this mean and what are the next steps? If you downloaded the snom ONE free edition, you will see that not too much has changed. The software is essentially the same, just a few changes: The web interface is the same, just the banner and the copyright texts and links have been changed. That means if you know how to use pbxnsip, you will know how to use snom ONE. The product now needs to be activated through an activation code. The PBX will then fetch the real license key from a snom server and provisions the key. This was necessary in order to sell the product through standard distribution channels which are not able to handle complex license codes. The PBX is now stricter with the certificates. This makes it possible to provision snom phones without passwords (well, at least those models that come with a built-in certificate). This is a big step forward regarding simplicity of installation. We also started to include 64-bit versions in the build process on a regular basis. This is to deal with the increasing number of devices that use TLS connections for secure communications. Registrations now check what phone type is registering. Only a certain number of "third party" devices are tolerated on the different versions. This is tribute to the trend in the industry to sell complete systems and subsidize the sale of endpoints or PBX (depending on what view you have). We will keep selling pbxnsip builds under the pbxnsip brand for some time for those that want to use other devices; however those licenses will obviously not be subsidized. All in all, I think this is good news as pbxnsip is now part of a bigger team. This will be piece of mind for many corporate customers that were worried about the company size and it will help getting more marketing and sales power behind it. The last few weeks were quite exciting and we are more optimistic than ever that this PBX will be a fantastic product in the SME market space.

Thats a constantly moving target... The service also change their software, so you never know what caused the problem. A standard would be good, or at least a common agreement in the SIPO industry on how to indicate the caller-ID.

You can try wireshark to see what is going on on the laptop. Also interesting read is http://kiwi.pbxnsip.com/index.php/Office_w...ic_IP_addresses in case that you want to mix different IP addresses on the server. SIP is not HTTP!

I first guess is that the ATA has problems detecting what ports should be open. AFAIK the ATA monitors the traffic and then makes a decision which ports should be opened for RTP. This would mean that you dont have to explicitly set them up IMHO. Is the PBX still running on a public IP address (routable, in the DMZ)? Maybe there something went wrong during the migration.

Right, now the problem is that the UA keeps the To-tag, even after retrying after the Answer-After. This is "one step forward, two steps back"... Anyway, the way to solve this problem it to take a look at the standard. Nice, that would mean the PBX should send a NOTIFY? I doubt that this would solve the problem, as the UA probably will still keep the To-Tag. IMHO the dialog will time out eventually and then the UA must send a new subscription, which must not have a To-tag. That would solve the problem.

Yea, kind of annoying. The problem is that the Caller-ID needs to be reversed on both sides of the call, because otherwise the one that you are calling back would have the same effect. However, if you get a call from "yourself" then you can know this is the PBX and it will not steal your time with some stupid questions.

I guess for this we need the SIP messages, can you turn SIP Message logging on? Transcoding does not have to be a problem. Are you using a PSTN gateway or a ITSP? 30 second timeout smells like a problem with the ACK message, maybe a problem with the routing of the SIP messages. # host license.pbxnsip.com license.pbxnsip.com has address 173.166.77.221 This is the license server, obviously down right now . Not beautiful, but that should not have any effect for the calls.

I would make a file system backup and just install the version 3 executable. There might be some hickups with the new features, but the core should be still working.

Does the "410 Gone" include the "Retry-After" header?

Call the outside line and then blind transfer it into the conference room. Or attended transfer should also do.

The problem is that G.729 is a CPU-killer (well at least for embedded systems). The CS410 has only a small ARM CPU and G.729 is pushing it to the limits very soon.

In the SIP trace, you must have number "18" in the codec list. In the license key, there should be some kind of hint (the key is base64-encoded, so if you decode it you can also see what features were included. "lowrate" is the keyword for the codec 18).

Well, also the pbxnsip default config got some major changes: Passwords: The passwords are not 40, 41, 42, 43 any more. Now the PBX generates passwords after booting up which are reasonably secure. Same for the domain provisioning password, which is actually quite sensitive. A couple of typos. By default, intercom is still not on. This would be a major security problem, if everyone can practically listen in to any other extension. Think about home office!

Right. There is this small blind spot when using AJAX! That's why multipart/mime (like MJPEG) would be better or CSTA. Anyway, what is there today is CSTA, "M-XML" might be an option later.

You also need the codec license on the PBX...

Can you check what the PBX is sending to the phones? There should be something like "404 Not Found" being sent to the phone... Are you receiving emails about this event? There should be something like "CO-line allocation failed on trunk xxx".

Consider using the recording option. Then the user first has to record the message, and after hanging up it will be played back. This will definitevely help with the echo, maybe also with the accidential dial.

Thats actually a very good point. However, not sure if thats possible on snom 870 right now!