Vodia PBX

Ouch! That is not good. If you are using a local Exchange, then the number of unsuccessful should be zero. Maybe also clean up the spool directory, maybe there is a old email in there that causes the problems.

This must be triggered by a nightly CDR report. Maybe there timezone of the system has a three hour offset from the local time which would explain the nightly activity. The only thing that comes to my mind is that the email cannot be deleted from the spool directory, that's why it keeps hanging there.

Okay. I think all of these wishes are reasonable. No matter what we do, we must be careful to keep things simple for joe average.

Did you put a call on hold - the stream is opened on demand. And did you change the setting on domain level?

Well, the initial INVITE does not contain a SDP offer, so the PBX sends a 200 Ok with the offer. But the ACK does not come back with the answer. That is stange. The whole IETF way of doing MOH is sick. This is just one one example that underlines this statement.

The Aastra phones are a little bit strange with their default packet size. It is 30 ms, while most of the other devices uses 20 ms. We also had problems in hte lab. Try to set it to 20 ms. We have a plug and play profile for the 57i, maybe it also works for the 480ict?

\r = registrar \1 = Param1 (as in the registration tab for the extension) \2 = Param2 \3 = Param3 That's currently all.

This is serious. RTP timeout usually means one-way audio. The second header is even more remarkable, there is obviously something completely strange going on on the SIP port. At least it does not look like a SIP packet what is arriving on the SIP port. There must be something very strange in your setup...

On the "LAN" port (eth0) it is DHCP, on the "WAN" (eth2) port it is "192.168.1.99". Of course, you can use both ports also in the LAN, they are just regular ethernet interfaces. See http://wiki.pbxnsip.com/index.php/Installi...P-PBX_Appliance.

Yes, I think it would make sense to have at least the star code so that people on the road have a change to actually lower the number of messages in their mailbox.... 2.1.6!

Plus we should mention that dial plans are used really only for outbound calls that will (well, most probably) run over a trunk. Dial plans are not used for inbound calls and they are not used for stuff like telling what ring melody to use when calling an extension. In most cases, dial plans should be something simple that most admin's don't hve to worry too much about.

The PBX makes a difference between the devices that seem to come from a routable address and devices that seem to use a address that is not routable. A address is routable if the seen IP address matches the one in the top Via header. Also, if the user agent includes a outbound hint, the PBX will always assume that the device is behind NAT. If the address is routable, it just checks if the proposed refresh time is within the minimum and maximum refresh time and if it is too short or too long it puts it back into the limits. If the address in not routable, it picks the NAT refresh time.

You should sonsider assigning tel: alias names to the extensions. For example, if an extension has the DID number 2121234567, use the name tel:2121234567 as one of the alias names for the acconut (you can have several). For representing the number on outbound calls, try RFC3325 and the other methods in the trunk setup. This really depends on the operator how they want to have it. See http://wiki.pbxnsip.com/index.php/Outbound_Calls_on_Trunk. Inbound is another story. If you want to send all calls to the same auto attendant, things are simple. Just tell the trunk where to send all calls. Take a look at http://wiki.pbxnsip.com/index.php/Inbound_Calls_on_Trunk for other scenarios.

Having more than 1000 entries scares me... But it is probably a good idea to make that adjustable. There must he a limit somewhere.

Australia really does not make it easy to keep track of what time it is... http://en.wikipedia.org/wiki/Time_in_Australia Looks like we need the following time zones are neccessary for Australia, maybe you can check if that is right? <item id="AUS1">Western Australia</item> <item id="AUS2">South Australia</item> <item id="AUS3">Northern Territory</item> <item id="AUS4">Queensland</item> <item id="AUS5">New South Wales</item> <item id="AUS6">Australian Capital Territory</item> (that would include Victoria and Tasmania) <zone name="AUS1"> <description>Western Australia</description> <gmt_offset>28800</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>10</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>Last</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>3</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>Last</dst_stop_week_of_month> </zone> <zone name="AUS2"> <description>South Australia</description> <gmt_offset>34200</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>10</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>Last</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>4</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>1</dst_stop_week_of_month> </zone> <zone name="AUS3"> <description>Northern Territory</description> <gmt_offset>34200</gmt_offset> </zone> <zone name="AUS4"> <description>Queensland</description> <gmt_offset>36000</gmt_offset> </zone> <zone name="AUS5"> <description>New South Wales</description> <gmt_offset>36000</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>10</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>Last</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>4</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>1</dst_stop_week_of_month> </zone> <zone name="AUS6"> <description>Australian Capital Territory</description> <gmt_offset>36000</gmt_offset> <dst_offset>3600</dst_offset> <dst_start_day_of_week>1</dst_start_day_of_week> <dst_start_month>10</dst_start_month> <dst_start_time>02:00</dst_start_time> <dst_start_week_of_month>Last</dst_start_week_of_month> <dst_stop_day_of_week>1</dst_stop_day_of_week> <dst_stop_month>4</dst_stop_month> <dst_stop_time>02:00</dst_stop_time> <dst_stop_week_of_month>1</dst_stop_week_of_month> </zone>

The dial plan processing is based on the extended regular expressions (ERE). Because they are not very popular for regular people, there is a simplified interface on top of it that translates simple patterns into ERE. The ERE are a little bit difficult to read, even more difficult to write, but understandable. The latest version shows how this translation works. It just shows what it uses as ERE when simple pattern are used. That means sometimes it might be difficult to come up with the right pattern, but looking at the log with the translated ERE you can figure out what is wrong (if there is something wrong). I think that should solve many problems that we had ourselves trying to figure out what the dial plan is doing.

I remember there was a post a few weeks before with a problem. This problem might go away with version 2.1.6 as we changed a couple of things in the offer/answer model.

We did that in the beginning. The problem is that (outside of America), you want to be able to call another extension directly without having the cell phone detection kicking in. In USA, most of the time the AA is sitting on the main DID number and then it is okay if the PBX detects that a user is calling.

Call into the mailbox, press 9 and select the right option. From the web interface - yes that might be difficult at the moment...

I don't think that would be noise.wav ("comfort noise"). Extreme loud scrambling sounds like SRTP trouble to me. Maybe there is old SRTP equipment somwhere in the voice path that does not check the MAC of the SRTP before accepting it.

Yea, we had some discussions about this topic last year already. There is even a IETF draft out there that defines a lot of interesting information (like collecting QoS information on the call).

That's no problem... Interoperability is what drives this industry!

Maybe it makes sense to get an Wireshark trace and see what exactly goes back and forth. What version are you running?

We probably have to accept this way of proposing SRTP, that's true. As for Polycom, good luck with the interoperability. It is simple not backward compatible with most of the stuff that is out there. Just adding two crypto lines sounds much more backward compatible to me. If everything goes well, the IETF will use DTLS on the RTP connection to negotiate the keys "end to end" anyway soon. Maybe that will solve the problems that we have with the key negotiation depending on the transport layer soon. Hopefully this will not increase the setup time too much. Well, if you are behind NAT you have no other choice than to lie. Or how else would you find out what port the router is using? Is STUN the answer here? Or Turn (LoL)? The PBX has no other choice than to deal with this. Actually the PBX does not even look at the contact. You can write there "0.0.0.0" or just "have.a.nice.day". The only thing that counts for the PBX is the TCP connection, this is stored in the internal registration database. When the PBX wants to send something to the phone, it just used the existing connection. Simple. I know that is not what the IETF envisioned. But in a lack of sense for reality, the IETF requires that there is no NAT for using SIP. If we want to sell a product today, we cannot listen to such bright ideas. Maybe the answer is that everybody should use Cisco Call Manager. The CCM does not have any of such problems, it just works on a persistent TLS connection for Skinny through anything. Sometimes I have the feeling that Cisco sends engineers to the IETF that have nothing better to do than propose standards that are impossible to roll out. Like the idea on how SIP should use TCP and TLS.

Oh, does the Grandstream support REFER? I would a be little bit surprised if it does and forwards the redirection request via FXO to the carrier. The other problem is that this stops call recording, and it is also impossible to keep the CDR for this redirected call. And you cannot barge into a call.