Vodia PBX

That sounds to me like the provisioning does not work from home any more. Polycoms by default download a large firmware file in the beginning and if that should happen via TFTP, it will be a problem if you try this from home. Actually, it would be interesting if the phone downloads any of the configurations file properly. Make sure that you select HTTP as the protocol and put the username and the password in the bootloader of the phone. You can check the generated directory in the PBX filesystem later on what the PBX has generated for this device.

64 bit on the client??? Whow, for that we did not compile the TAPI...

I see two possibilities for that. The first one is that the PBX changes the codec during the call setup. We introduced a flag calls "lock codec" later, make sure that it is turned on. The other thing is the loopback calls. This continues to be a pain in the neck. SIP is very complicated when it comes to sending a request our and then it comes back to the system with all those tricky strict and loose routing and loop detection RFC... The easiest way to address this problem is to run it through another B2BUA, typically a PSTN gateway and implement the loop on the PSTN side. Yea, we decided to use email a lot more than before. Most of the emails are early warnings, e.g. for the case when the call gets disconnected while there is a one-way audio situation but not long enough for a PBX-initiated hangup. Typically, if both parties are real persons, one will look into the handset, say "heh?" and then hangup. We wanted to be able to capture these kind of problems as well. FAX is a situation like this, because T.38 is a very strange protocol with long periods of media flowing only into one direction (well, after all sendin ga page goes only into one direction). A email rule in your email client might do the trick here to fish out the fax-related false alarms.

Some systems use username like number;extension=ext in the username. For example, the URI would then look like this: sip:9787462777;extension=123@domain.com;user=phone. It is a kind of stress test for the parser, but that is how SIP was specified. The big question is how the PSTN gateway will react. If it ignores the parameter in the username you should be in a good shape.

What do you mean by "service flag extension"? Service flag or extension? IMHO you cannot park a call on a service flag...

The key question is who rejects the call. The PBX or the trunk provider? The log should tell you that. If you see a response coming back from the trunk provider, then you have to finetune the trunk settings. Otherwise it is probably the dial plan in the PBX.

Are you using country code "1"? Then check you dial plan. If you want to match a domestic call destination, this must be in 10-digit format (no leading 1).

If you are calling from the cell, you should be able to do this. When you hear the annoucement, press the key for an internal call and then this should work. If you are calling from any number, yes that it will be difficult. Maybe the calling card account can help in this case, if you enable internal calls.

Are you using TLS or STARTTLS in the email? If yes, you will probably have a problem with the certificate. The easiest solution is to set Exchange up so that it just accepts traffic from a specific IP address, which works okay if this is a private IP address (no risk that someone from the public internet does something bad). Or just use a simple authentication scheme, but no encryption on both sides.

This is about the question which agent should be called by what queue. If there is a agent available for both queues and both queues have callers waiting, it shoul pick the queue with the higher priority. Things get tricky when the polling interval gets changed (that is why we took the setting out in the beginnnig of version 4). Then the behavior can get random. Hopefully that is under control now and the queue with the higher priority gets the call.

Difficult question. The only way that I see to clean this up would be to change the To-tag in the SUBSCRIBE. However that would mean that the PBX would have to reject the SUBSCRIBE with something like "4xx Dialog does not exist" and then the phone would have to come up with a new SUBSCRIBE (with the To-tag empty). But I am not sure if the phones would work with this. We added a function that can perform a bulk check-sync. Maybe this helps to reduce the problem. We could add a feature that says check-sync all phones after they re-register. Then it would be clear that all phones also get a fresh restart after the PBX was restarted.

still busy with some low-level problems... But it is not forgotten

Good point. From the PBX there is nothing really that can be done there, especially in multicast mode (moving the topic to the snom section). It is really a policy question if paging should be audible for the phone. I don't think paging is really being used for emergency purposes, such stuff happens on overhead paging. So I would tend to say by default multicast paging should be disabled.

That would not convince me... Probably the only thing you can do is to try the latest beta 8.4.18 available from dms.snom.com (username beta, password beta). If it would be a NAT problem it must be the router. Some routers try to be smart (or very stupid) and screw everything up. If you have a different router it is also worth a try.

Yea, that is a pain... There was a post here http://forum.pbxnsip.com/index.php?showtopic=3450 that explained how to use openssl. If you want to get a signature from someone you can trust, you need to generate a CSR file (certificat signing request or so) and have it signed by the authority. The PBX itself does not issue the certificate.

IIS forwarding the request?! It should not... The PBX is running its own web server on a different port. For example, if the PBX runs it's service on port 8080, then you would use a HTTP URL like this: http://192.168.1.1:8080 (the http:// part is important for most browsers). You can try to let the IIS server send a 302 redirection code when accessing a certain page, then the web browser would go to the PBX after the redirection.

Can you generate a sample that you can share with us here (especially the private key part...). As you know, the private key and the certificate must match, so we need both to check what is going on.

It needs to be 8 kHz, mono 16 bit/sample (uncompressed) WAV file.

It is not easy. The PBX does not just pass the media through. It also takes care about NAT/SBC, about SRTP decoding/encoding/transcoding, codec transcoding, packet length conversion, DTMF transcoding (inband/out of band/INFO), busy tone detection, gain measurement, call recording, barge/teach/intercept, one way media detection, RTCP-XR (QoS) measurement, did I forgot something? How can you do this without the PBX in the loop? It is class 5, not class 4. After all.

Actually I am nore sure... If there is a setting I assume it changes something. But I remember that we did a (necessary) major cleanup in 4 with this topic, so it might be buggy/a mess in version 3. The problem was about the trunk failover time, we mixed that up with the SIP request timeout and that was not a good idea. Maybe if you are running 3 just give it a shot and see if it works as you would expect it...

Version 3? Nothing changed in V3... In version 4 it is adjustable. Not sure if from the web interface, but the duration is a setting which can be changed like all other global settings.

That setting is still there in V4 (called "max_ring_duration"). I know we changed the login with the trunk timeout and that required some clean up. But V4 should be in a good shape regarding this topic.

You mean that phone A sends RTP directly to phone B, not through the PBX? I don't get the point here.

The overwriting is really something that we need to fix. I had the same problem some time ago... The two-hour limit can be solved by making the max call duration of the system longer. Though I think this is a *feature* (two hours in a conference would make me flip). Recording all conferences automatically would raise the question how to deliver the recording. Those files can get huge, do sending them as email does not seem like a good idea to me.