Vodia PBX

Whow how did you get these HUGE screenshots? First, I would always use the outbound proxy. Many SIP devices don't like it when the PBX says send it to "localhist"... Don't use the STUN server (STUN is nonsense anyway). Question: Why do you use a trunk on the PBX? I think you would register the Grandstream as an extension. Who is registering where? PBX trunks send REGISTER out, but do not receive REGISTER messages.

If you can, use an SNMP tool to poll the PBX for data like how many calls are on. If the PBX does not respond, there is trouble going on. It is *not* a good idea to stress the system with lots ot http/https requests to see if it is (still) responding. SNMP is very lightweight and has practically no impact on the operation.

Ehh... FXO is not FXO... Maybe we really need to think about a couple of settings, like "check polarity change", "loop disconnect timeout time". We are using this new Comcast service and I love it. No such problems, just great audio over a very short FXO cable.

Did you check if the time is correct on the system? Are you using the right time zone for the system, domain and extension?

If I don't have a buddy list on the Polycom then I have a (slight) problem now. Below the line button there is a image popping up from time to time, which is a little bit annoying. Still on 2.2.2. When I provision a buddy there things look okay. Running 2.1.6.2448, of course.

Well, sending to port 0 is not an option in IP, so that must be changed anyway. If that was the last obstable? You never know!

Yes that is definitevely a problem. Broadvox is usually quite responsive, would be great to have them provide this kind of service! Did you also ask them if they can do anything about it?

Did you check out http://wiki.pbxnsip.com/index.php/Changing_the_Appearance?

Cool. Make sure you are using 7.1.30 or higher on the. Previous versions have their problems!

If you want that a SIP device only uses DNS A or DNS AAAA then specify the port number behind the domain name (e.g. domain.com:5060). This is a little RFC3262 trick. 482 is really strange. IMHO the PBX should never do that on a REGISTER request. Is 11.222.195.38 the address that you expect?

I would not enable ENUM on the phone just to be able to dial regular numbers. ENUM is a long long topic that you probably don't want to touch just to solve that problem. I would solve the problem with that dial plan on the PBX above.

No password for the service flag, please! The caller has to authenticate himself e.g. in a calling card and then he can call the service flag also from home or on the road.

I think the problem is that the Polycom sends a 6xx code, which is a very high priority code?

So you want to have two locations that can call each other? You should set up two trunks between them and then use the dial plan to route the calls between them. Just pick a nice prefix that they can use to call each other, or just pick the PSTN number of the PBX as prefix. Not sure what that has to do with phones...

Maybe you should try a dial plan with the pattern 011* and the replacement +*... Then users can call 01133123456 and the ITSP will see +33123456.

In head, yes. Actually no third mode, just filtering for edge state changes. That should do the job without too many changes in the code and in the web interface.

I would give that a try for the sake of finding out if that is the problem. Then we can decide what to do with it.

Oh, see http://wiki.pbxnsip.com/index.php/Log_Setup#SIP_Logging

Did you set it to use only g711u? Currently it answeres with multiple codecs, and that is a common source for problems.

We have been to a couple if SipIt since SipIt 8 in Cardiff (different company at that time). Fortunately the SIP interop problems that we have in our day-to-day life are not the biggest problems (thanks to the B2BUA nature). You can't test a hunt group there, it mostly about spirals, tags, etc. It would be exciting if companies like Microsoft or Cisco show up with their flagship products.

Maybe we can introduce a third mode for the flag in addition to "manual" and "automatic", which would be "semi-automatic" - this way we can definitevely keep backward compatibility.

Do you have the SIP packets that cause the disconnect? Turn SIP packet logging on ("other" packets). If you see a CANCEL, the PBX causes the hangup; if you see a 200 Ok as a response to the INVITE, then the call was really connected. It sounds like the call was never connected. Maybe a problem with the provider, a SIP trace will reveal more information.

Exchange really asks the PBX to call "5001;phone-context=PBXnSIP-exchangesp1.ourdomain.com", no kidding (no idea why the number must include all those strange parameters, but it is legal according to the RFC). The dial plan now must match also those strange parameters! My idea for ERE in the dial plan: ([0-9]*);phone-context=.* That should really fish out only requests that were initiated by the Exchange. Maybe a feature!

Ouch. Hmm. I think I am using the same device from the same manufacturer, no problems... Can you set the codecs on the Pirelli or the PBX to use only one codec? Maybe that helps to track the problem down...

I don't know. I have never seen a installation where people had to put a + sign at the beginning of a number in order to dial out. I would rather look at the dial plan and then maybe put the + at the front of the number.