Preparing for 2.0 Release Candidate 1

[supergus]

I've installed the r1390 image and found following strange behaviour :
I just add one phone and while adding it to an existing group I remark that all the phone drag&dropable list were mixed up :

The name of phone doesn't correspond anymore with the extension number. It seems that the name is correct but not the extension. This is true only in the group "Dialplan: Call Groups: Edit "

@supergus : Could you tell me the exact steps needed to recreate this bug? I have tried for more than an hour now to break call groups without success. Something like:
 - added SIP phone 104
 - added SIP phone 105
 - added Call Group 100, added 104 and 105
 - added IAX phone 106
 - added 106 to Call Group 100
 - broken config

Thanks in advance! Others have reported this but I've not yet been able to track it down.

My sequence which I can reproduce also with image 2.0 RC1 :

- added SIP phone 201
 - added SIP phone 202
- added SIP phone 203
 - added Call Group 103
- added SIP phone 200 (opertor)
- broken config in Call group 103

Might be because 200 < 201-203 ?

[Michael]

Thanks for the report, I've been able to track down the problem. A fix will be in the next release.

You were right, it is because 200 is less than the previous extension numbers. Internally the pbx was sorting things for display. However, it still uses a uniqid pointer to find entries in the xml file. This pointer still points to its old entry position in the file, not the newly sorted position in memory.

[Dave]

A very minor bug is that when someone calls externally and it transfer the call to the answer-phone, the internal extension number is read instead of the external number.
But everything seems to be working on the Soekris platform now.

[Michael]

New Snapshot available for testing. This snapshot finally fixes the long reported bug in call groups. They would break in a very specific and hard to track down situation. Thanks to supergus for the step-by-step report. Users reporting echoes should now hopefully be saved by the superior OSLEC algorithm. Also, ISDN ports are now properly configured so all of their channels can be used.

Developer Snapshot r1395:
 - http://downloads.askozia.com/pbx/snapshots/r1395

Changes since r1390
 - fixed hardware port selector on analog phone and provider accounts
 - changed echo canceller from mg2 to OSLEC
 - fixed ISDN config generation so multiple b-channels can now be used simultaneously
 - fixed call groups

A very minor bug is that when someone calls externally and it transfer the call to the answer-phone, the internal extension number is read instead of the external number.
But everything seems to be working on the Soekris platform now.

What is your call flow exactly? From what kind of provider to what kind of phone? Most provider accounts in askozia have a read-back number option which may be what you're looking for. Good to hear Soekris is working now. Not easy when I don't have one to test.

[giovanni.v]

Just for fun, another hardware report... boots and goes up without problems on Asus B202 via CF/SATA adapter.
Like in any other tested hardware won't boot via usb, the bios says the media isn't bootable.

[Michael]

New Snapshot Available. If testing goes well on this, it will be released as RC2 this week.

Developer Snapshot r1406:
 - http://downloads.askozia.com/pbx/snapshots/r1406

Changes since r1395
 - provider port groups now supported
 - connectivity status bubbles for sip and iax phone and provider accounts working
 - possible fix for some hfc-s cards
 - updated to Asterisk 1.6.1.17
 - added double-clocked hfc-s4 card support
 - fixed en -> en-us symlinking, applications no longer need to specify a default language (by Devon)
 - fixed wakeme 95% of the way (touch -t backport still needed) (by Devon)
 - fixed display of voicemail user defined e-mail text upon save
 - fixed element library for applications
 - fixed fxs port parsing when port in unpowered and in a fail state

[giovanni.v]

- provider port groups now supported

A good step forward.

- possible fix for some hfc-s cards

The fix fixed! Now using a quite standard generic hfc-s pci card the D channel goes up, making an get calls is now possible; apparently quite good audio quality despite the card price.
No further testing done at this time but looks promising.

[Michael]

RC2 Released! : http://www.askozia.com/news/2010/3/12/20-release-candidate-2.html

[giovanni.v]

RC2 Released! : http://www.askozia.com/news/2010/3/12/20-release-candidate-2.html

My compliments to the chef  for some interesting recipes like phpagi and the syntax highlighting... I hope to have something like that available in the plain dialplan editor.

[Michael]

Glad you like it! My goal is to get merge 'v1' of Dialplan applications into this new page. Configurations will be updated automatically and syntax highlighting for asterisk configs will be included.

Also, I think the files tab in the Integrator Panel could use a better editor

[devon]

- fixed wakeme 95% of the way (touch -t backport still needed)

App_wakeme.c update:

I've finished the backport of 'touch -t' in busybox 1.14.3 and have one remaining issue to sort out. App_wakeme reads back the time input as GMT, even though the spool files are stamped with the correct local time and wakeup calls are attempted at the correct local time. I'll try to code in some debugging to see where the time structure is getting broken. Any suggestions would be welcomed.

Devon

[Michael]

I've already updated busybox to 1.15.3 after testing it on all platforms and not having any troubles. Sorry for not announcing that somewhere but it was mentioned in commits.

The readback time probably has something to do with this:
 - http://forums.askozia.com/index.php/topic,1001.0.html

Thanks for putting in time on this, I never would have had the chance to get app_wakeme working any time soon. Sorry for the doubled-up effort!

[devon]

I've already updated busybox to 1.15.3 after testing it on all platforms and not having any troubles.

I see that now, 4 commits back. No problem, a lot can happen in 4 days!

[helvetic]

The internal extension of the phone will be sent as the MSN. This is the current behavior which is not very flexible. Maybe another field should be made available which allows the user to set this phone's caller id when dialing out through a provider? For each provider?

I really hate complexity...if anyone has some straightforward suggestion on this, I'm welcome to it.

Any Update on this? I still have those CLIP Problems with ISDN. Also for the voip Providers its sometimes desirable to set different ID depending on the extension calling, as workaround i duplicate the SIP and ISDN Provider Account for each Extension just to be able to set different Caller ID. I would highly appreciate the flexibility of clip settings on the phone settings page and for each provider separately. Is something planned or will this implemented any time soon? Thanks allot.

[Michael]

I can't get to this before 2.0.0 is out unfortunately. It WILL be in 2.0.x as soon as my schedule allows and is at the top of the priority list. The line has to be drawn somewhere and I apologize that it's right before this feature.

(We also have pressure to get this implemented from two commercial entities so I can assure you again that it is a top priority.)