Vodia PBX

If you use the "green" edition then the transfer works with all RFC compliant devices (green as in green light )

3 minutes generally sounds like there is a demo key involved somewhere? The old pbxnsip demo keys cut the calls off after 3 minutes, that was a common "problem".

Well, Microsoft had a different customer focus in mind. If you want to support companies with more than 10000 employees, you need a different architecture. For (relatively) small insallations, it is reasonable to keep things simple and use the B2BUA model. Intel, AMD & Co will help to push the number of calls and extensions up.

Probably a problem with the route setup. Check "route print" if the default gateway is set up the right way. Also the good old Wiki has some useful information about this: http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses.

This requires some major changes, including new audio prompts. This will take some time.

I would guess like this: <?xml version="1.0"?> <ringtones> <tone name="custom1"> <vendor></vendor> </tone> <tone name="custom2"> <vendor></vendor> </tone> <tone name="custom3"> <vendor></vendor> </tone> <tone name="custom4"> <vendor></vendor> </tone> <tone name="internal" type="internal"> <vendor></vendor> </tone> <tone name="external" type="external"> <vendor></vendor> </tone> <tone name="intercom" type="intercom"> <vendor ua="snom.*" type="call-info"><{from-uri}>;answer-after=0</vendor> <vendor type="answer-mode">Auto</vendor> </tone> </ringtones>

Well, how should it look like on the PBX? The PBX dials a number on the trunk, then waits until the call gets connected and then starts pumping out DTMF tones?

So we figured out how to solve this problem. The settings about the recording in the PBX web interface actually define when the recording starts. Once the recording started, transfers will not change the recording going on; only the hangup of the call leg will change it (it will end as well). That seems to handle all use cases that came to our mind in a good way.

Really really weird. Seems it does receive the first block, but then does not continue the download. There must be something really bad goin on. Are other TFTP clients clients in the same subnet able to download the image? Maybe try pumpkin as the client and see if that is able to get the file.

You probably see the following in the log: "[4] 2011/03/10 15:49:45: Certificate for Equifax Secure Certificate Authority not available" (TLS). You need to import the following certificate to make gmail happen (see http://www.geotrust.com/resources/root-certificates/): -----BEGIN CERTIFICATE----- MIIDIDCCAomgAwIBAgIENd70zzANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJV UzEQMA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2Vy dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTk4MDgyMjE2NDE1MVoXDTE4MDgyMjE2NDE1 MVowTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0B AQEFAAOBjQAwgYkCgYEAwV2xWGcIYu6gmi0fCG2RFGiYCh7+2gRvE4RiIcPRfM6f BeC4AfBONOziipUEZKzxa1NfBbPLZ4C/QgKO/t0BCezhABRP/PvwDN1Dulsr4R+A cJkVV5MW8Q+XarfCaCMczE1ZMKxRHjuvK9buY0V7xdlfUNLjUA86iOe/FP3gx7kC AwEAAaOCAQkwggEFMHAGA1UdHwRpMGcwZaBjoGGkXzBdMQswCQYDVQQGEwJVUzEQ MA4GA1UEChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlm aWNhdGUgQXV0aG9yaXR5MQ0wCwYDVQQDEwRDUkwxMBoGA1UdEAQTMBGBDzIwMTgw ODIyMTY0MTUxWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAUSOZo+SvSspXXR9gj IBBPM5iQn9QwHQYDVR0OBBYEFEjmaPkr0rKV10fYIyAQTzOYkJ/UMAwGA1UdEwQF MAMBAf8wGgYJKoZIhvZ9B0EABA0wCxsFVjMuMGMDAgbAMA0GCSqGSIb3DQEBBQUA A4GBAFjOKer89961zgK5F7WF0bnj4JXMJTENAKaSbn+2kmOeUJXRmm/kEd5jhW6Y 7qj/WsjTVbJmcVfewCHrPSqnI0kBBIZCe/zuf6IWUrVnZ9NA2zsmWLIodz2uFHdh 1voqZiegDfqnc1zqcPGUIWVEX/r87yloqaKHee9570+sB3c4 -----END CERTIFICATE----- Go to admin/settings/certificates and import it as "Trusted Root CA for server authentication". Then it should work.

Ja das ist ein grosses Problem bei SIP. Jeder ITSP hat dazu eine andere Meinung, es gibt nicht wirklich einen gemeinsamen Standard. In der nächsten Version werden wir dazu eine umfangreiches Feature-Update machen, damit die PBX auch mit jedem ITSP klar kommt.

Try to set other values for the privacy indication. P-Asserted-Identity seems to be a problem here. Try "No Indication", that does the trick with many providers. Though you will loose the ability to ahow the original Caller-ID.

Well, you should see TFTP packets! Did you set the port number for the tftp server (by accident)? That would explain is right away, and also all other problems. Or did you set the provisioning to FTP or HTTP? Probably not, because otherwise it would not log anything about TFTP. In Wireshark, you can choose "Decode as" when selecting the packet (right mouse button). Does it display something useful when you decode it as TFTP?

Well it would be interesting to know why it times out. Does the server send the request to the right IP and does it repeat it? Does the transmission actually end somewhere in the middle or does not any packet make it?

Okay, one step further... Seems you must get it going with the standard TFTP server first before it makes sense to use the PBX for this job again. Firewall issues? TFTP is not a very firewall-friendly problem, even the "personal" firewall on the server might be an issue. You could try installing Wireshark to see what is going on on the network level.

Hmm... That all looks good now with the boot loader... The retransmit worries me now. What you can do is run an independent tftp server, put the files there and see if you can get the phones boot from there. Maybe the files got corrupted somehow (CRLF Windows Linux conversion)? Anyway, now it is time to narrow down the problem, and thats why it might be a good idea to see if you can get these phones up and running at all without the PBX being involved. Also, you can check if the boot loader version is the right one for the firmware version. I think there were also some comments on which firmware requires which bootloader, and what the upgrade path looks like.

Actually I believe the behavior was like that always! I would not understand how a phone firmware change could cause this. Did you try pressing * during the annoucement?

Of course the WAV trick is a short-term workaround. We probably need some more settings for the paging account, including the settings for the tones.

The sip.ld should be a pretty big file. But I think you also need the files for the bootloader, which as it looks are not there. I remember we also had problems because the bootloader files were not present.

You can always change the WAV file...

Did you put that 30 MB ZIP from Polycom into the tftp directory? It should contain the boot loader and the firmware for the phones, maybe that's where it got stuck. Also, do you see files being put into the generated directory? That would be a good sign, because it would mean that the PBX recognizes the extension and starts provisioning it.

The hunt group has an option to set the from header, for example based on which group was called. I believe that is also available for the ACD. Maybe this is the way to go.

Maybe a problem with mixing mailbox prefix up? All mailboxes start with 8. Maybe try to rename it to lets say 78 and see if that makes adifference?

The web interface shows only a part of what is stored internally. "From" and "To" headers are not neccessarily what has been called originally, especially when call redirection and trunks are bring used. It is a long discussion what From, To, the local party and the remote party should be, and how the numbers should be represented. In short words, every one wants somethign else. So we just display something that can be used for identifying which call is which. The CDR will show a lot more detail.

Should be no harm; but agreed does not look beautiful