Mobicents weekly meeting notes, March 7, 2012

[Ivelin Ivanov]

Location: IRC freenode.net #mobicents

Attendees:

  Alex, Amit, Bartek, Jean, Luis, Oleg, Tom, Sergio, Yulian, Ivelin

Summary:

  #1 MMS: ILBC in progress for MMS 2.2; Vostok testing new scheduling optimization
  #2 JSLEE: Eduardo surfing in Morocco
  #3 Diameter: release delayed by a week due to support work
  #4 SS7: 1.0.0.CR4 release delayed to incorporate enhancements requested by users; SCCP patch ready for 2.0.0.Beta1 
  #5 SIP Servlets: progress with Arquillian, AS7 port, MSS 1.7; 
  #6 RestComm Alpha 2 released
  #7 QE: no news

  

Log:

-----------

[09:35] <ivelin> hi team. I'm in position.
[09:35] <ivelin> #Vostok update
[09:35] <ivelin> #2 MMS 2.2.CR2 feedback, CR3 progres
[09:35] <ivelin> progress*
[09:35] == svetyutnev [4e6b0690@gateway/web/freenode/ip.78.107.6.144] has joined #mobicents
[09:35] <ivelin> #3 Video update
[09:36] == yulian_o [3edb727f@gateway/web/freenode/ip.62.219.114.127] has joined #mobicents
[09:36] <ivelin> Oleg, please lead the way to the stars
[09:36] <okulikov> k
[09:37] <okulikov> I am finishing refactoring, have plan to migrate next week to git by the way (best time during refactring)
[09:37] <ivelin> ok. Did you create a clone for Vostok?
[09:37] <okulikov> for next week planing to start from simple testing
[09:37] <okulikov> not yet
[09:38] <ivelin> ok, its easy from the gcode gui
[09:38] <okulikov> I will do it from scratch
[09:38] <okulikov> did not touch this question yet
[09:38] <ivelin> ok, ask if you have questions about git
[09:38] <okulikov> Dmitry has progress with scheduler, starts testing
[09:39] <okulikov> Anton learning MGCP details
[09:39] <ivelin> by next week we should know if the new algorithm is a better optimization of task scheduling?
[09:40] <okulikov> it is better 100%, we will know did we reach the optimization
[09:40] <ivelin> what are the plans for MGCP?
[09:40] <okulikov> or something blocks it
[09:40] <okulikov> for MGCP plans as before - finalize support of used packages
[09:40] <okulikov> and I need some additional forces on this front
[09:41] <okulikov> so we need to finish: AU package
[09:41] <okulikov> RTP package
[09:41] <okulikov> Basic package
[09:41] <okulikov> DTMF package
[09:41] <okulikov> at the moment all of them only partialy implemented
[09:42] <okulikov> I would say at the "begning" leve, which is mostly used
[09:43] <ivelin> I think MMS 2.2 now implements a lot of the AU package. Could you borrow some of that work?
[09:44] <okulikov> the difference with B3/B4 is not big
[09:44] <okulikov> may be in two parameters
[09:45] <okulikov> however our implementation is completely different because it is driven by scheduler not by thread pool
[09:46] <ivelin> have you had time to put SNMP on the roadmap?
[09:46] <okulikov> oh, SNMP is in high priority
[09:47] <okulikov> it plugs very nice
[09:47] <okulikov> I am not sure that we will be able to include it into this release but into next definitely
[09:48] <ivelin> have you outlined the SNMP get parameters and traps for MMS?
[09:49] <okulikov> only at top level
[09:49] <okulikov> and like a draft
[09:49] <okulikov> this question still open and actually we can finislize it again after scheduler
[09:50] <okulikov> what we can guarantee to deliver
[09:50] <ivelin> why don't you publish the draft for community feedback
[09:50] <okulikov> and what is means what inside
[09:51] <ivelin> several people voiced interest in SNMP support. They might want to participate in the discussion.
[09:51] <okulikov> will publish when I will have something more concrete
[09:51] <ivelin> ok
[09:51] <ivelin> anything else on Vostok?
[09:51] <okulikov> it depends how we will fit to call lost clear condition model
[09:53] <okulikov> sorry, Lost-calls-cleared conditions
[09:54] <okulikov> that's it from our side
[09:55] <ivelin> ok, thank you, Vostok team. Looking forward the the test results.
[09:55] <ivelin> #2 MMS 2.2.CR2 feedback, CR3 update
[09:56] <yulian_o> not much news here , a lot of work with ILBC codec , still working on it.
[09:58] <ivelin> I sent an email to the public list about testing mms 2.2.cr2 via restcom alpha2 with Tom Q
[09:58] <ivelin> playback and conferencing of g711 lines seems solid
[09:59] <yulian_o> i have also made testing on my side , with all codecs and indeed its solid and stable
[09:59] <ivelin> does anyone else have questions or comments about MMS 2.2?
[09:59] <yulian_o> need to complete codec implementation add several params requested by community and will release
[10:00] <ivelin> on the SNMP topic, have you thought what parameters should be exposed?
[10:00] <ivelin> are there standard MIBs for media servers?
[10:01] <yulian_o> i did not though about that since it will come with new structure , i am planning to remove current config file , add dynamic load , etc.
[10:02] <ivelin> how would configuration be done?
[10:03] <yulian_o> db / jdbc for initial load with web services / soap for management
[10:05] <ivelin> we should have an open discussion about that
[10:05] <yulian_o> ok
[10:05] <ivelin> db/jdbc for configuration is not too popular, because you have to configure that db connectivity as well :)
[10:06] <vilpan> and JMX is the de facto standard for management
[10:06] <yulian_o> thats correct but the problem in current configuration is that its static
[10:06] <ivelin> also soap is long out of favor for web services. REST has won the XML web services argument.
[10:06] <yulian_o> what happens if you want to enable codec on server?
[10:06] <yulian_o> same with endpoints , their number is static
[10:06] <ivelin> the configuration file doesn't have to be static
[10:06] <yulian_o> number of connections per endpoint
[10:06] <yulian_o> etc,etc
[10:06] <ivelin> the server could pick-up modifications
[10:07] <ivelin> the server could also update the config file if someone makes a remote config change over REST
[10:07] <ivelin> CLI configuration is also still very popular
[10:08] <yulian_o> the question is how much time operation takes
[10:08] <yulian_o> write to file is slower then to db
[10:09] <ivelin> tools like puppet and chef are commonly used to manage configuration changes and upgrades via CLI, REST, or config file manipulation
[10:09] <ivelin> which operation?
[10:09] <yulian_o> write , when you save a file and read when you reread a config file
[10:09] <yulian_o> from db you take one row of clean data , from file you read complete xml and search
[10:10] <abhayani> look how SS7 stack persists configuration data
[10:11] <abhayani> it has CLI
[10:11] <abhayani> via which configuration can be done
[10:11] <abhayani> xml stored in flat file
[10:11] <abhayani> and if system reboots
[10:11] <abhayani> it brings itself back to same state as before system crashed
[10:11] <abhayani> its not worth to think of performance here
[10:11] <abhayani> because config is once
[10:11] == uijltje [~tuij...@ip-80-113-12-132.ip.prioritytelecom.net] has quit [Quit: Leaving.]
[10:12] <yulian_o> i dont say its not possible , but perfomance should be counted in my opinion
[10:12] <ivelin> Amit, SS7 runtime changes are done via CLI, not editing the file?
[10:12] <abhayani> right ivelin
[10:12] <abhayani> if SS7 stack is already started
[10:13] <abhayani> it wont go to file again for reading
[10:13] <abhayani> everything in memory already
[10:13] <ivelin> and CLI changes are written to the config file?
[10:13] <abhayani> thats right
[10:13] <abhayani> every CLI modification makes changes in memory and file
[10:13] <ivelin> there is some kind of conflict resolution if the file is edited at runtime?
[10:13] <abhayani> no
[10:14] <abhayani> while system is cleanly shutdown
[10:14] <abhayani> it will just overwrite the file with in memory snapshot
[10:14] <abhayani> if it was crash and someone changed file
[10:14] <abhayani> next time changed data will be read
[10:14] <abhayani> but I think this is acceptable
[10:15] <ivelin> ok, so CLI changes are not immediately flushed to the config file?
[10:15] <abhayani> it is immediate too :)
[10:15] <yulian_o> several comments
[10:15] <yulian_o> 1) cli is not too user friendly
[10:16] <yulian_o> 2) remote services allows to manage more then one server from one point
[10:16] <abhayani> but I am giving example where you not playing with CLI, but directly trying to make change on file while system is running
[10:16] <ivelin> Amit, I think that behavior is pretty reasonable
[10:16] <ivelin> Yulian, 1) why?
[10:16] <abhayani> yulian_o while I agree with both points
[10:16] <svetyutnev> "1) cli is not too user friendly" GUI tool can be created to operate via CLI interface
[10:17] <abhayani> and now we planing to have UI for managing SS7
[10:17] <abhayani> but UI is just wrapper over existing CLI
[10:17] <abhayani> it still connects SS7 stack over TCP
[10:17] <abhayani> still passes commands as CLI
[10:17] <abhayani> UI just wrapps everything and gives nice experience to user
[10:17] <yulian_o> is your UI local or allows remote connection?
[10:18] <abhayani> both CLI and UI remote
[10:18] <abhayani> that is CLI talks to SS7 only over TCP
[10:18] <abhayani> so run where ever you want, local or remote
[10:18] <yulian_o> so you created some sort of network protocol to manage it?
[10:18] <abhayani> right yulian_o
[10:18] <yulian_o> thats acceptable but more complicated
[10:19] <yulian_o> but i will check this option also
[10:20] <yulian_o> now about db : i am planning to put there logs and other stuff , so i dont think it will be an option to use files
[10:20] <ivelin> JBoss AS used to have a tool that allowed CLI interaction with JMX MBeans
[10:20] <ivelin> that was great, because it could be reused for various services
[10:21] <ivelin> but I think its now gone
[10:21] <yulian_o> let me show you following scenario : server is running for 2-3 monthes with 10-20 simultanious calls all the time.
[10:21] <ivelin> I agree that reinventing new TCP protocol is not optimal, because we have to worry about security issues and firewall holes for each case
[10:21] <yulian_o> i need to log some data , and then allow to read it from management
[10:22] <yulian_o> if i will use xml file , or text file , i will be in troubles
[10:22] <yulian_o> while with db i can use incremental log reading
[10:23] <jean__> ivelin, no it is called twiddle
[10:23] <jean__> 1) cli is admin friendly
[10:23] <jean__> sysadmins usually love to script stuff to integrate in their existing infra
[10:24] <jean__> 2) is not incompatible with one
[10:24] <jean__> the CLI can also be exposed over REST
[10:24] <ivelin> Jean, why can't twiddle be made admin friendly?
[10:24] <jean__> ivelin, I meant CLI in general is admin friendly
[10:24] <jean__> and I include twiddle in that statement
[10:25] <ivelin> JDK 5+ actually allow remote JMX access that can be secured. We can look at that for a standard protocol.
[10:25] <ivelin> http://docs.oracle.com/javase/1.5.0/docs/guide/management/agent.html#remote
[10:25] <@baranowb> you can create scripts combined with tools like awk to make big ass management script
[10:25] <@baranowb> I mean CLI scripts
[10:25] <ivelin> yes, I guess we are all arguing for the usefulness of CLI
[10:25] <@baranowb> if its not interactive console
[10:26] <ivelin> Amit, have you looked at the JMX remote API for the SS7 CLI?
[10:26] <jean__> ivelin, we use it in the LB
[10:26] <ivelin> Jean wrote a plugin that can map JMX MBeans to SNMP MIB parameters
[10:27] <jean__> the plugin for SNMP would need a it of adaptation
[10:27] <jean__> as it is currently coupled to JBoss
[10:27] <jean__> for the startup and shutdown at least
[10:27] <jean__> and maybe some parsing stuff
[10:27] <abhayani> Ivelin I am thinking of JMX too as an option
[10:27] <ivelin> that's useful for leveraging existing management tools. SNMP is the common denominator. But there are also good tools for JMX. jConsole comes with the JDK. Useful for dev and testing.
[10:28] <jean__> we will need to do it anyway to port SNMP to Tomcat
[10:28] <ivelin> yes, would be handy if ss7 or mms adopt it for standalone mode
[10:29] <ivelin> Yulian, about your concern with reading log files
[10:29] <yulian_o> can JMX be accessed from c# for example?
[10:30] <ivelin> not readily. You would have to use some kind of ORBA adaptor.
[10:30] <yulian_o> so i guess webservices will be the best solution then
[10:30] <ivelin> that reminds me that there used to be a JMX to REST adaptor
[10:31] <ivelin> pretty simple mapping of URLs to JMX MBeans. Not sure if its still there in AS.
[10:31] <yulian_o> my goal is to make system manageable from web , nevermind on which platform ( asp,net , php , java , etc )
[10:32] <jean__> yulian_o, that makes sense to me
[10:32] <yulian_o> about the logs , the concern is that they grows and if i need to get parf of data from them its impossible
[10:32] <ivelin> there are actually several open source jmx to rest adaptors
[10:32] <ivelin> http://opendmk.java.net/contributions/rest-adaptor/readme.html
[10:32] <yulian_o> for example take 10 raws from middle of log
[10:32] <ivelin> http://docs.codehaus.org/display/LIVETRIBE/LiveTribe-JSON
[10:33] <yulian_o> Restful JMX Adaptor will be good for all i guess
[10:34] == tomq [~tho...@173-162-114-110-miami.hfc.comcastbusiness.net] has joined #mobicents
[10:34] <yulian_o> if i am not mistaken it will allow both options
[10:34] <jean__> yep
[10:34] <ivelin> https://blogs.oracle.com/jmxnetbeans/entry/restful_access_to_jmx_instrumentation1
[10:35] <ivelin> Yulian, about the log question
[10:35] <ivelin> that is separate from configuration
[10:36] <yulian_o> but if you add connection to db , why not to use it for all?
[10:36] <ivelin> you need a db that supports high volume writes of temporal data
[10:36] <ivelin> with ability to query on time ranges
[10:37] <ivelin> something like Cassandra or MongoDB would be a more appropriate option
[10:37] <ivelin> we need to solve this problem in general for Mobicents
[10:37] <yulian_o> or with rawid in this case
[10:37] <yulian_o> why not to use mysql?
[10:37] <ivelin> CDRs are another example of log like data
[10:37] <yulian_o> i am using mysql for billing data also ( cdrs)
[10:38] <ivelin> mysql is fine, but it hits its limits as the data grows
[10:38] <yulian_o> you can cluster it
[10:38] <ivelin> there is no easy way to add more resources to handle more data as it grows
[10:39] <ivelin> you can through in a few more boxes to cassandra and it will use them to distribute data
[10:39] <ivelin> to split mysql data between servers is a pain
[10:39] <yulian_o> does Cassandra and MongoDB have jdbc driver?
[10:39] <tomq> well the problem with MySQL clusters is that you can only write to the master which created a huge bottleneck
[10:39] <tomq> You can't horizontally scale writes
[10:39] <tomq> that's the first problem
[10:39] <ivelin> they are NoSQL databases. Don't offer the same ACID features as an RDBMS
[10:40] <tomq> then after about 500GB of data MySQL starts suffering unless you start sharding your data
[10:40] <tomq> and atomic transaction become a pain
[10:40] <jean__> http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/
[10:41] <vilpan> anyway, knowing the company that's behind MySQL, I wouldn't bet on it's long term availability. Anyone thinking "MySQL" should start thinking "MariaDB".
[10:41] <tomq> jean_, facebook is notorious for trying to scale non-scalable techs
[10:42] <tomq> for example they wrote hiphop to cross compile php to machine code
[10:43] <tomq> In any case MySQL is a wonderful piece of tech it's just not a silver bullet and some of it's deficiencies are exposed when used in real-time high volume telecom environments.
[10:43] <yulian_o> so whats the final offer? :)
[10:44] <yulian_o> and how can it be accessed from JAIN SLEE SBB , and from "standart" java code?
[10:44] <jean__> what will you log exactly yulian_o here ?
[10:44] <tomq> By the way ivelin, Mongo is really close to MySQL in rich query features
[10:44] <ivelin> Yulian, spend some time researching Cassandra and Mongo DB
[10:44] <ivelin> I will send offline some links.
[10:44] <yulian_o> ok
[10:45] <tomq> yulian_o, if you don't have very large write volumes or are not producing data in excess of 500GB MySQL is fine :)
[10:46] <tomq> otherwise I would really investigate MongoDB if you would like rich queries and Cassandra is you're going waaaaayyyy big.
[10:46] <yulian_o> i am in development stages so better solution - better results is currently the only option
[10:46] <yulian_o> bad that there is no standart access for mysql and mongo , this  way i was able just to change db
[10:47] <tomq> In RestComm I created a DAO layer that abstracts out the db implementation
[10:47] <yulian_o> bottom line : Restful JMX Adaptor with some scalable db
[10:47] <tomq> for MMS?
[10:47] <jean__> http://www.hibernate.org/subprojects/ogm.html
[10:47] <tomq> Sorry, I got in to the conversation late
[10:47] <yulian_o> yes
[10:48] <tomq> awesome!!!!
[10:48] <jean__> is aimed to provide JPA for DataGrids
[10:48] <yulian_o> 2 tomq: i have also DAL layer , but its based on datasource , PreparedStatement , etc
[10:48] <tomq> ahh gotcha
[10:48] <ivelin> Jean, is OGM progressing well? It seems like there is only an Infinispan adapter.
[10:49] <ivelin> Yulian, to your bottom line
[10:49] <ivelin> Restful JMX Adaptor, SNMP adaptor, CLI for admins, flat file for persistent config and scalable db for logging
[10:50] <jean__> I think Infinispan is the main target
[10:50] <jean__> it will take time before it matures
[10:50] <tomq> Yes monitoring is crucial in data center environments
[10:50] <yulian_o> why not to store config in db?
[10:50] <jean__> typically even JPA is know as not performing well enough for raw performance usually
[10:50] <yulian_o> SNMP is separate task , and its acceptable
[10:51] == dmitriy [b24e1f0d@gateway/web/freenode/ip.178.78.31.13] has quit [Ping timeout: 245 seconds]
[10:51] <tomq> I like SNMP
[10:51] <tomq> the reason being...
[10:52] <tomq> My Extreme Switches, Fiber Channel Switches, San, etc. all support SNMP
[10:52] <yulian_o> snmp is good :)
[10:52] <yulian_o> why not to store config in db?
[10:52] <tomq> So I can use Zenoss to monitor my entire infrastructure
[10:52] <tomq> no argument from me
[10:53] <yulian_o> Restful JMX Adaptor, SNMP adaptor, CLI for admins, db for persistent config and scalable db for logging
[10:53] <ivelin> Yulian, multiple reasons:
[10:53] <ivelin> 1. You need to configure db connections somehow
[10:53] <yulian_o> you can make it as command line params
[10:53] <ivelin> 2. DBs can crash occasionally. You may not be even able to start the server until you recover the db.
[10:54] <yulian_o> it will have a copy in memory in both cases ( file or db ) and will work with memory only
[10:54] <ivelin> 3. DB can and usually is for production on a remote machine
[10:54] <yulian_o> just when it will make update and startup read/write will be either to db or to file
[10:55] <ivelin> 4. Admins like to be able to see in plain text the configuration parameters of what they are installing
[10:56] <ivelin> 5. In many companies, the database is managed by a different person (DB admin) than the people managing the IT systems.
[10:57] <tomq> numbe 4 is a big one
[10:57] <yulian_o> i have a solution for you : we will add import export to cli this way you will be able to read a file , and i will be taking care of perfomance
[10:57] <ivelin> there is of course a line where configuration can become so much that it takes a db to manage it. But I don't think this is the concern for MMS.
[10:58] <yulian_o> thats currently :)
[10:59] <tomq> I personally like my applications to be decoupled from the underlying data source but that is a matter of preference. I do agree with Ivelin that admins like config files.
[10:59] <yulian_o> i have a solution for you : we will add import export to cli this way you will be able to read a file , and i will be taking care of perfomance
[11:00] <tomq> A lot of times infrastructure admins have to go through DBAs to get to the DB server
[11:00] <tomq> and that is not always so smooth
[11:00] <yulian_o> once again there will be db anyway for logs , so anyway you will have to go to DBA :)
[11:01] <tomq> Maybe there should an option to dump logs to file
[11:01] <ivelin> Yulian, after you do your thinking, why don't you post a short document how you plan to attach the problem so we can coordinate
[11:01] <yulian_o> possibly
[11:01] <tomq> but if there won't be then you're right if you're going to need the db for logging then who cares might as well use it for everything else.
[11:01] <ivelin> the management, monitoring, logging, CLI issues are across all projects
[11:02] <ivelin> hopefully we won't end up with silos that do the same thing in many ways
[11:02] <yulian_o> its already a way it works :(
[11:02] <ivelin> let's transition to the next topic, we are behind on the agenda
[11:02] <ivelin> #3 Video
[11:02] <yulian_o> ok
[11:02] <ivelin> Sergio, online?
[11:03] <sgarcia> Yes
[11:03] <sgarcia> Still waiting for tomasq
[11:03] <ivelin> ok, I thought so. Tom was focused on the new release.
[11:03] <sgarcia> He has told me that he will be able to have the server ready during the week
[11:04] <sgarcia> Yes
[11:04] <tomq> :) yep
[11:04] <tomq> Actually Sergio...
[11:04] <sgarcia> I would like to start working also in webrtc
[11:05] <tomq> I'm going to be providing Ivelin and Jean a section of my cloud and so they can provision VMs on behalf of the team on the web.
[11:05] <tomq> I'm almost done putting up the dashboard
[11:05] <sgarcia> Great
[11:05] <ivelin> there were several webrtc announcements this week
[11:05] <ivelin> looks like its moving along
[11:06] <ivelin> Opera also announced supporrt
[11:06] <sgarcia> Yes
[11:06] <ivelin> Voxeo showed a demo for the PhonoSDK
[11:06] <sgarcia> I have to study it in detail
[11:06] <tomq> WebRTC will be huge for most of our projects. The idea of running things like softphones in the browser is awesome
[11:06] <ivelin> that's great. Hope it keeps momentum.
[11:07] <jean__> Did they finally agree on the signalling protocol ?
[11:07] <tomq> It might end up being XMPP :(
[11:07] <sgarcia> When the signalling is clear it woul be grat to have a framework in mobicents to handle it
[11:07] <ivelin> I don't think its decided yet.
[11:07] <jean__> otherwise websockets addition in MSS might help here
[11:08] <sgarcia> Like kind of webrtc-servlets
[11:08] <tomq> That would be awesome and RestComm would greatly benefit from WebRTC
[11:08] <sgarcia> At the end is just receiving the sdp
[11:09] <sgarcia> And we could use jsr309 with webrtc
[11:09] <jean__> sgarcia, would you like starting to draft and take up the lead on WebRTC in Mobicents ?
[11:09] <ivelin> right, its not that important what signaling protocol will be the standard as long as there is one.
[11:09] <tomq> agreed
[11:10] <sgarcia> I would love to
[11:10] <sgarcia> But not sure if i have enought time
[11:10] == Tili [~Ti...@16.97.77.188.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
[11:10] <sgarcia> But i can share my investigations
[11:11] <sgarcia> For sure i will like to add vp8 and srtp to the mcu media server
[11:13] <ivelin> ok, let's move on
[11:13] <ivelin> general meeting agenda
[11:13] <ivelin> #1 MMS (already done)
[11:14] <ivelin> #2 JSLEE 2.7
[11:14] <ivelin> #3 Diameter
[11:14] <ivelin> #4 SS7
[11:14] <ivelin> #5 SIP Servlets
[11:14] <ivelin> #6 RestComm
[11:14] <ivelin> #7 QE
[11:14] <ivelin> Eduardo, online?
[11:15] == sgarcia [~sga...@80.27.102.196] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]
[11:15] <ivelin> Bartek, can you fill in?
[11:15] <jean__> eduardo is on vacations in marocco
[11:15] <jean__> IIRC
[11:15] <ivelin> oh yes, I forgot. Darn surfers.
[11:16] <@baranowb> yeah, he is away, enjoying sun
[11:16] <ivelin> any updates on JSLEE?
[11:17] <@baranowb> not much to tell here, we have 3 issues reported by community, awaiting input on one
[11:18] <ivelin> ok
[11:18] <ivelin> #3 Diameter
[11:18] <@alexandrem> no update on diameter also, due to work on support
[11:19] <@alexandrem> hopefully next week we can resume work on pending tasks (mainly TLS) and start to prepare CR3
[11:20] <ivelin> ok
[11:20] <ivelin> can you please clarify on the public forum the licensing issue with cwolf. There is apparently confusion on his/her part.
[11:21] <ivelin> #4 SS7
[11:21] <abhayani> the 1.0.0.CR4 release is delayed due to number of reasons
[11:22] <@alexandrem> sure
[11:22] <abhayani> 1) there are some features requested in community
[11:22] <abhayani> 2) We added multi-homing support for SCTP which took some time and we are yet to test this
[11:23] <abhayani> 3) spent time on completing the Moicents GW to be compatible with latest SS7 stack
[11:23] <abhayani> I guess release will be delayed by a week
[11:24] <abhayani> regarding 2.0.0.BETA1 we have first version of SCCP patch ready
[11:24] <abhayani> thats it from SS7
[11:25] <ivelin> what are the new features? for 1)
[11:26] <abhayani> asp-id is currently generated by M3UA stack
[11:26] <abhayani> faizan requested that it should be configurable
[11:27] <abhayani> as some of the STP's doesn't like this and doesn't allow M3UA link to come up
[11:28] <ivelin> the STPs expect IDs that they hand out?
[11:29] <abhayani> correct
[11:30] <ivelin> Yay. Will go buy a lottery ticket now.
[11:30] <ivelin> #5 SIP Servlets
[11:31] <abhayani> lol
[11:31] <jean__> #1 MSS in Arquillian - 2 issues fixed by Georges - TLS, repeatability
[11:31] <jean__> #2 CDI, MTF - no updates here
[11:31] <jean__> #3 RestComm -  ALPHA 2 released https://groups.google.com/forum/?fromgroups#!topic/mobicents-public/ruHrVesPd-8
[11:31] <jean__> #4 OpenVBX -  Henrique work will be finalized now that RestComm ALPHA 2 is out
[11:31] <jean__> #5 MSS on AS7 - Jose from Solaiemes making great progress. JNDI/Resource injection done, working on creating nightly snapshots.
[11:31] <jean__> #6 Cloud/HA datagrid - No News here.
[11:31] <jean__> #7 MSS 1.7 - 5 Issues fixed and more in the pipeline. NIO in progress.
[11:31] <jean__> #8 MWC 2012 - http://jeanderuelle.blogspot.com/2012/03/mobile-world-congress-2012-write-up.html
[11:33] <ivelin> about #7. Does MSS 1.7 on Tomcat support SNMP?
[11:34] <jean__> not yet this is what I was saying earlier
[11:34] <jean__> SNMP Adaptor is still a bit coupled to JBoss
[11:34] <jean__> but it shouldn't be that hard to port it
[11:35] <ivelin> ok, just wanted to confirm
[11:35] <ivelin> which version of the JDK introduced the lightweight http servlets?
[11:35] <jean__> wdym by lightweight ?
[11:36] <jean__> I'm not aware of JDK introducing anything related to http servlets
[11:37] <ivelin> it was in discussion a few years ago for Java SE to support lightweight http requests
[11:37] <ivelin> maybe it didn't go in
[11:37] <ivelin> I can't find new references to that
[11:38] <ivelin> there it is
[11:38] <ivelin> http://stackoverflow.com/questions/3732109/simple-http-server-in-java-using-only-java-se-api
[11:39] <ivelin> it remained a hidden feature
[11:39] <ivelin> #6 RestComm
[11:39] <ivelin> this was already covered, but I just wanted to open the discussion to a broader audience
[11:40] <ivelin> Tom and I did some live testing yesterday. Great voice quality for IVR and Conferencing.
[11:40] <ivelin> Anyone else tested yet?
[11:40] <tomq> I will put up a demo server as soon as I'm done with the binaries
[11:40] <tomq> I will attach DIDs where ever possible
[11:41] <tomq> You will be able to find more info @ http://www.restcomm.org in  a few days.
[11:41] <tomq> I will also provide SIP URI for those of you that I can't provide DIDs for
[11:41] <tomq> :)
[11:42] <ivelin> sweet
[11:42] <tomq> That way everyone can call in and test RestComm
[11:42] <tomq> :)
[11:43] <ivelin> Tom, I forgot to mention before the release, but for the next release, use the MSS release notes template. Community users expect certain items in a release announcement.
[11:43] <tomq> We are less than 30 days from our Beta and first complete release
[11:43] <tomq> ah okay I was not aware of it
[11:43] <tomq> I will use it for future releases
[11:44] == vralev [4d556b16@gateway/web/freenode/ip.77.85.107.22] has quit [Ping timeout: 245 seconds]
[11:44] <ivelin> np, I just forgot. Many more releases to come.
[11:44] <tomq> yep :)
[11:44] <ivelin> ok, looking forward to reports from others about Alpha2
[11:44] <ivelin> #7 QE
[11:44] <ivelin> Luis, update?
[11:45] <tomq> Yes me too!
[11:45] <tomq> :)
[11:45] <barreiro> No update.
[11:46] <ivelin> JBCP 5.1.3 released?
[11:46] <barreiro> yes, like a month ago.
[11:48] <ivelin> no planned updates since?
________________________________
[11:49] <ivelin> ok, we can cover more offline
[11:50] <ivelin> thanks everyone for joining today.