Vodia PBX

Interesting thought. You mean we should add another setting to the service flag which says "when that flag is active, this flag is also active". And probably another setting saying "when that flag is inactive, this flag is also inactive". Or we may as well add an expression that supports boolean logic, something like this: "(582 || !583) && 589"; this can probably be put into the service flag settings of the accounts.

The point is that the PBX puts the number into the format of the country before passing it to the dial plan. The country code is set in the domain settings. For example, if you set the country code to "1" and the user dials 19787462777@domain, then the PBX will present 9787462777@domain to the dial plan. Another example to make it more clear: LEts say the country code is "33" and the area code is "7" and the user dials 00331234@domain, then the PBX will present 01234@domain to the dial plan. This example should make clear that the user has many ways to dial the same number and it is difficult to deal with all of them in the dial plan. Essentially there are two systems in the world, the US-centric system with ten digits and the rest-of-the-planet system with 00 and 0 prefixes. The domain has to be in either of the system. Or in no system at all, that's when there is no country code set for the domain.

You can do this only if you are not using country codes. Otherwise consider using prefixes that correspond to real countries. If you dont use a country code, then it should be pretty simple. Pattern "55532*", replacement nothing or something like "01152*".

It is really difficult to give good advise here. What we need at this point is a clear problem analysis. If you could set the Ethernet switch up for a port mirroring, then you could connect a PC to the mirror and run Wireshark on it for a while, collecting the evidence what is going on with the registration .Unfortunately, the CS410 in an embedded system with limited capacity (you could try to use tcpdump to fetch the registration traffic at the risk of a file system full error later; however if you make it you can transfer to a PC and then use Wireshark to look at it). Once you have a dump it will be relatively easy to see what the problem is; if you don't see it you can post a link to it and we can take a look at it.

You have to differentiate between inbound and outbound. Inbound the best way is to assign alias names to the extensions which are telephone numbers. For example, the name for extension 40 could then be "40 978-746-2777". Then on an inbound call, when the service provider puts the "9787462777" into the Request-URI of the INVITE, the PBX would try to find it and then send the call to extension 40. Outbound calls are about ANI. Every extension and every account that can send calls to trunks has the ANI field. There you can specify what number should be sent to the trunk. The logic to translate that into a SIP packet is complicated, as the IETF failed to promote one clear way on how to do this (at least every service provider has a different opinion about it). But using RFC3325 on the trunk is a good shot.

How many messages are you logging? 500 already? Otherwise, just log to the file this will not purge messages

Maybe someone should mention there that pbxnsip is now part of snom...

The problem was that if the PBX accepts the subscription, the subscription dialog would be fine; however the sequence number of the notifications would randomly start with a lower number and the phone would reject it. Additionally, the notification XML bodies also contain sequence numbers which create additional problems. That is why the PBX tries to force the user agent to come up with a new subscription with reset sequence numbers. IMHO it is clearly a bug of the endpoints that they dont retry after some time with a new subscription. That would solve the problem 100 %.

Still the log starts with the ACK but not the INVITE: [0] 2011/01/03 08:44:58: SIP Rx udp:192.168.1.2:5060: ACK sip:patton@192.168.1.15:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bKc5be534e8ef8eee06 Max-Forwards: 70 From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83 To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78 Call-ID: dd8a0982e3e2df15 CSeq: 1065 ACK User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26 Content-Length: 0 Then the PBX receives the BYE: [0] 2011/01/03 08:45:44: SIP Rx udp:192.168.1.2:5060: BYE sip:patton@192.168.1.15:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.1.2:5060;branch=z9hG4bK283d7c36279b55e3d Max-Forwards: 70 From: <sip:anonymous@192.168.1.2:5060>;tag=d9a4a13a83 To: <sip:01158****@192.168.1.15:5060>;tag=c211bdee78 Call-ID: dd8a0982e3e2df15 CSeq: 1066 BYE User-Agent: Patton SN4552 2BIS EUI 00A0BA053BE6 R5.2 2009-07-09 SIP M5T SIP Stack/4.0.26.26 Content-Length: 0

Yea, multicast is a little bit tricky if you have multiple interfaces. The PBX needs to open a socket for each interface, and for the multicast provisioning stuff right now it uses only one socket. Multicast PnP on a public IP makes only limited sense anyway, the only thing I can think of would be multiple VLANs. But in such well-manages networks I would definitevely recommend to use option 66 anyway and don't rely one something like multicast PnP. Multicast PnP primary focus is on networks where you cannot set option 66 in the DHCP server (SoHo environments). They usually have only one interface on the PBX.

How do other products like Apache, IIS or SER deal with the port problem? Maybe we can learn how they solve the problem.

See http://forum.pbxnsip.com/index.php?/topic/4090-snom-821-provisioning-on-snomone/page__view__getnewpost__fromsearch__1

If you dont have the snom_821.xml file in the reg_texts.htm web page listed, create a html directory in the working directory of the PBX (where you also have audio_en, audio_moh and so on) and put the file snom_821.htm there with the following content: <?xml version="1.0" encoding="utf-8"?> <setting-files> <file url="{http-url}/snom_3xx_fw.xml?model=snom821" /> <file url="{https-url}/snom_820_phone.xml?model=snom821" /> <file url="{https-url}/snom_820_fkeys.xml?model=snom821" /> <file url="{https-url}/snom_web_lang.xml?model=snom821" /> <file url="{https-url}/snom_gui_lang.xml?model=snom821" /> </setting-files> It could be that this file did not make it into the build, we have seen that in other places too.

The draytek has a SIP ALG, try to disable it. SIP ALG are usually a source for such unexplainable trouble.

A router reboot sounds more like a problem with the router. Many NAT implementations have very small tables (e.g. 32 entries for NAT) and with 17 trunks you might have exchausted it. If you can, try to find out how many connections your router can handle at the same time and make sure this is far more than 17. You also need ports for RTP, DNS, and if you have other PC clients on the router, a lot more ports for all kinds of services.

Just make the log history longer (or write the log into a file), so that you can see the initial INVITE that has the same Call-ID as the BYE from the gateway. Then we can see all messages that are exchanged between the gateway and the PBX.

If you have a public IP, I would not "play" with the routing list. If you have more than one IP address on the server, make sure that the routing table (especially the default IP gateway) is using the public IP address. Then everything else should work without any changes. What is the output of "route print"?

This is a good old article that I recommend as a starting point: http://kiwi.pbxnsip.com/index.php/Office_with_private_and_public_IP_addresses

It is a little bit hard to say what exactly was going on, but what I can see is that the gateway sent a BYE to the PBX (search for Call-ID 417e9feaab32afab). I cannot see the other messages in this call, but it could be the problem that for whatever reason the gateway wants the call to disconnect.

It will match the username and the domain. However, if you use the "localhost" domain, it will match only the username. If the call comes from a trunk with the outbound or explicit inbound set, then the trunk will have higher precedence than the extension. But anyway, another item to check.

Could be a problem with their 2nd tier service providers. If the pass the packets through in a proxy model, their 2nd tier might not like certain things in the packet and then fail. IMHO there must be a B2BUA (SBC) because of this to ensure consistent service.

We have made a softphone out of the snom m9 cordless phone. This should help solving the problem that the snom ONE is so picky with the third party registrations. The m9 soft phone runs on Windows operating system and does pretty much every thing that the m9 base station does. The handset is obviously just a emulation, where features like alarm clock did not make it, but for example you can initiate a blind transfer and put calls on hold. The soft phone is "free" (see the long license agreement that pops up after installing it with all the "we break for nothing" stuff) and you can use it not only with snom ONE, you can use it with anything that talks proper SIP. http://wiki.snomone....om_m9_softphone has the manual. In this post I'll attach the ZIP; there is also marketing going on about the snom m9 soft phone and probably there will be other download locations; however fpr convenience I'll just attach it m9win1010.zip. Merry Christmas!

As long as the device is using UTF-8 the PBX should have no problem with it. However, we have seen that some PSTN gateways have problems with non-ASCII characters and like to return such messages to the PBX. Can you check if the PBX generates the message or just passes it back through to the phone?

Does the hangup occur from a analog line? Do you see a BYE hitting the PBX?

The idea of the rules is that the trunk with empty proxy should have a low precedence. This is essentialy for ENUM calls where you cannot say where the call will come from. But because SIP routing is so complicated, the complex rule construct above can have surprising side effects. Also, the PBX must make a decision if the call comes from an extension. Keep that in mind. If the From-header matches a username on the system, it wll think that the call does not come from a trunk, but from an extension.