Attendees:
Alex, Amit, Bartek, Eduardo, Luis, Jean, Oleg, Vladimir, Ivelin
Summary:
#1 MMS: 2.1.CR released last week, 2.2 advancing on predictability and
RTSP
#2 JSLEE: preparing for 2.6 release next week
#3 Diameter: several bug fixes
#4 SS7: advancing with CAP
#5 TelScale/MSS: MSS 1.7 ported to latest Tomcat 6 and 7
#6 RestComm: no update
#7 QE: ported all MSS jobs and JSR 309 job to cloudbees
Log:
----------
[09:04] <ivelin> #1 MMS 2.2.x status, community feedback, 2012Q1 roadmap
[09:05] == uijltje [~tuijld...@ip-80-113-12-132.ip.prioritytelecom.net] has
joined #mobicents
[09:05] <ivelin> #2 Video extensions to MMS 2.2
[09:05] <ivelin> #3 MMS 2.1.x status, community feedback, 2012Q1 roadmap
[09:06] <ivelin> Oleg, Yulian, what else should we add to the agenda?
[09:06] <yulian_o> nothing on 2.2 i guess
[09:07] <okulikov> I have suggestion to separate names
[09:07] <okulikov> to prevent confusing
[09:07] <okulikov> may be we can discuss this question?
[09:08] <okulikov> during first chat in this year we just briefly touched
this question
[09:08] <ivelin> #4 Consolidation path for MMS
[09:08] <ivelin> let's discuss it under 4
[09:08] <ivelin> let's begin with #1
[09:09] <yulian_o> CR1 released last week
[09:09] <yulian_o> currently goal is to make media path stable and its
under testing. looks very good
[09:09] <yulian_o> planning to add more codecs , starting with GSM
FR/HR/EFR this/next week
[09:10] <yulian_o> optimize quality is another goal
[09:10] <yulian_o> thats it i guess
[09:10] <ivelin> what are the quality problems at this stage?
[09:11] <yulian_o> i am testing the media under 3G networks now , with high
jitter and mess of packets.
[09:11] <yulian_o> currently i can define 2 problems : one is gain control
[09:12] <yulian_o> some clients shoulds very loud , some normal volume
under same conditions
[09:12] <yulian_o> so i guess some dynamic gain control will be needed
[09:12] <yulian_o> another issue is jitter buffer optimization .
[09:12] <ivelin> you think that's because of integration with 3g networks?
[09:13] <ivelin> different interfaces feed/read differently the signal
to/from mms?
[09:13] == svetyutnev [4e6a6dc7@gateway/web/freenode/ip.78.106.109.199] has
joined #mobicents
[09:14] <yulian_o> yes of course. you dont have a problem with packets
arrival in wifi with 30Mb Adsl line , 99% arrive in time
[09:14] <yulian_o> while in 3G all the time you receive 3-4 sometimes 10
packets in same time , then a big delay , then once again several packets
[09:15] <ivelin> and this messes up the jitter outside of MMS control?
[09:15] <yulian_o> basically yes , so there should be good algorthim to
resolve this mess on jitter buffer level
[09:17] <yulian_o> i have already completely rewritted the jitter buffer ,
resolved a lot of problems caused by it , but still there is need for
dynamic jitter buffer size
[09:17] <ivelin> I see. Are there known algorithms for this problem?
[09:17] <yulian_o> not that i know
[09:18] <ivelin> Oleg, do you know of any known algorithms for this kind of
issue?
[09:19] <okulikov> it is only one
[09:19] <okulikov> encapsulated in jitter buffer definition
[09:19] <okulikov> but it wont help anyway because jitter buffer consumer
jitters itself
[09:20] <ivelin> what would you suggest then for this type of delays from
the 3g network
[09:21] <okulikov> jitter buffer
[09:21] <okulikov> if I am correct Yulian is talking about receiver side on
mms, right? not on the client side
[09:22] <ivelin> MMS is receiving packets from the 3G network in bursts
[09:22] <ivelin> 10 packets at once then big delay
[09:22] <yulian_o> yes , when mms receives packets from client on 3G
[09:22] <okulikov> jitter buffer is presented on mms, and it transforms
random jitter into fixed delay
[09:22] <yulian_o> looks like they are collected on antenna , and then send
in bursts
[09:22] <okulikov> the size it changable
[09:23] <sgarcia> one question
[09:23] <sgarcia> how much is the dealy?
[09:23] <yulian_o> the problem is that sometimes its 3 packets , sometimes
it becomes 10 , and then it can go back to 3
[09:23] <okulikov> expand to worst case
[09:23] <sgarcia> but the delay should be always
numberofpackets*packetduration
[09:24] <yulian_o> 2 sgarcia : there is also processing time
[09:24] <yulian_o> and network time when you send a packet from ms to client
[09:24] <sgarcia> yes, but you cannot avoid that
[09:25] <sgarcia> the only thing that you can do is add a delay
[09:25] <sgarcia> but not solve it
[09:25] <okulikov> agree
[09:25] <yulian_o> the problem is that with 1s delay you fill it
[09:25] <okulikov> but I am thinking the root of problem in other place
[09:26] <yulian_o> in my network i have 2ms servers on the way ( thats
internal call and while going to other network it at least 3 )
[09:26] <yulian_o> so not much left for each server
[09:27] <okulikov> what is the bandwith of your channel and average delay?
[09:27] <yulian_o> in any case it needs further inverstigation
[09:28] <yulian_o> i can tell one thing , bandwidth is very bad , they
promise 1mb but its far from that
[09:28] <sgarcia> couldn't you remove the jitter if connection is between
two ms servers?
[09:28] <okulikov> exact number needed
[09:28] <sgarcia> bursting also packets to the next ms to not introduce
more delay?
[09:29] <okulikov> but even 64 kbits will be enough to g711 speech
[09:29] <okulikov> so 1mb - a lot in this sense
[09:29] <yulian_o> that in theory Oleg , in practice its far from that. i
have tested 711 sith VoipSwitch we have and its same , very pure quality
[09:30] <okulikov> not adjusted
[09:30] <yulian_o> in any case it needs further inverstigation since till
now i focused on stability issues and not on quality.
[09:30] <okulikov> but if this is defintely network problem then it is out
of our capabilities
[09:31] <ivelin> someone just told me offline that it could be the 3G
network being hostile to VoIP traffic
[09:31] <yulian_o> what do you mean hostile?
[09:32] <ivelin> like the split IP NAT problem you had to fight before
[09:32] <ivelin> it will be interesting to hear more what you find out
[09:32] <ivelin> when do you plan on the next release?
[09:32] <yulian_o> i have a war with them thats for sure , one of networks
have sip alg , that changes the ip address in traffic and not the port ,
and does noty keeps sip session
[09:32] <yulian_o> so each new request comes from different port
[09:33] <okulikov> I used 3G network with VoIP without problem
[09:33] <yulian_o> i had to modify jain slee stack to support that thing
[09:33] <yulian_o> for next release i plan GSM codec with HR , FR and EFR
[09:33] <yulian_o> bug fixes if will find more ( till now one resolved )
[09:33] <yulian_o> and quailty optimization
[09:35] <ivelin> would you have some time to document all these new
features going in?
[09:36] <yulian_o> thats my weak side - documentation , but it will do my
best :)
[09:36] <ivelin> maybe some of your contributors would help out on that
front
[09:37] <ivelin> what is the level of community feedback recently?
[09:37] <yulian_o> not much actually. as i know only several people are
using it, not much information received from that. there was 2 bugs and one
changes request till now
[09:38] <ivelin> ok, a little more docs should help attract more users
[09:39] <ivelin> for some reason most devs are intimidated by undocumented
code
[09:39] <ivelin> let's go to #2
[09:39] <ivelin> #2 Video extension to MMS 2.2
[09:39] <ivelin> Sergio, are you able to comment or you are in a meeting?
[09:40] <yulian_o> its in plan to add video support for ms , but i think i
will go into it after all codecs will be implemented and quality optimized
[09:40] <sgarcia> i am here
[09:40] <sgarcia> I will work with TomQ to deploy my jsr309 implementation
on the new hardware
[09:41] <sgarcia> and work to define an implement an apealing application
for a demo use case
[09:41] <sgarcia> i have not worked much on the implementation itself last
weeks
[09:41] <sgarcia> but will like to get traction again
[09:42] <sgarcia> so anyone that would be interested in any particular use
case to test, it will be great if they share it with me
[09:42] <sgarcia> so i implement something that at least is going to be
tested by someone.. :)
[09:43] <ivelin> I have one - telehealth - patient connecting to a doctor's
office. Patient is on their phone (maybe SIP) and doctor on their office PC.
[09:43] <yulian_o> 2 sgarcia : is your development based on 2.2?
[09:45] <sgarcia> in fact it is implemented in my own media server
[09:46] <sgarcia> i am able to do that.. but it is not possible with jsr309
[09:46] <sgarcia> (if doctro is in web i mean)
[09:46] <ivelin> but you are currently integrating with MMS 2.2, right?
[09:46] <sgarcia> currently it is a different server
[09:47] <ivelin> ok, so the doctor has to have a sip phone on the desktop
too? That's acceptable.
[09:47] <ivelin> until some point in the future when there is a widely
implemented standard for web video.
[09:47] <ivelin> what jsr309 impl do you use?
[09:48] <sgarcia> mine.. :)
[09:49] <okulikov> sorry, brb
[09:50] <ivelin> ok, I thought you are using some version of MMS :)
[09:51] <sgarcia> not so far
[09:51] <sgarcia> was one of the question I raised to you in the past
[09:52] <sgarcia> I am not really sure how to integrate both developments..
or even if it is possible
[09:52] <ivelin> sorry, please remind me what was the decision point.
[09:52] <ivelin> oh ok, I now remember
[09:53] <ivelin> you needed to implement a subset of 309 for the MCU
[09:53] <ivelin> ok, got it now
[09:53] <sgarcia> yes, I will focus on video
[09:53] <sgarcia> it is not in my scope to provide all the funcionalities
MMS is providing for audio
[09:54] <ivelin> can you not reuse the jsr309 client/driver?
[09:54] <okulikov> back
[09:54] == jean [~j...@lns-bzn-56-82-255-218-134.adsl.proxad.net] has
joined #mobicents
[09:55] <sgarcia> i am not implementing mgcp
[09:55] <sgarcia> i have defined a custom xmlrpc interface that matches
almost 1-1 the jsr309 requirements
[09:55] <sgarcia> so I don't face the same problems that you had to solve
with MMS
[09:56] <okulikov> what kind of problems was with MGCP?
[09:56] == baranowb [55de5643@gateway/web/freenode/ip.85.222.86.67] has
joined #mobicents
[09:56] <baranowb> test
[09:56] <okulikov> it is also 1-1 to jsr-309
[09:56] <ivelin> oh, yes, that's right
[09:56] <baranowb> hi
[09:56] <ivelin> hi Bartek, we are on MMS
[09:56] <baranowb> k
[09:57] <ivelin> Oleg, when Sergio started on the JSR309 integration, he
already had XML-RPC interface to MCU
[09:57] <okulikov> I remember, but would be wrong to think that MGCP has
issues with jsr-309 mapping
[09:58] <ivelin> Sergio, have you figured how to prepare binary packages
for MCU, so its easier to test?
[09:59] <sgarcia> not yet
[09:59] <sgarcia> but I will try to do that
[09:59] <sgarcia> at least for some platforms
[09:59] <okulikov> Bartek,
http://code.google.com/p/mobicents/issues/detail?id=3043
[09:59] <ivelin> ok, would be good for marketing if the live demo on Tom's
cloud links to downloadable bins
[10:00] <ivelin> let's move to #3 because we're low on time
[10:00] <ivelin> #3 MMS 2.1.x status, community feedback, 2012Q1 roadmap
[10:01] <okulikov> ok
[10:02] <okulikov> we continue to work under feasibility test, priority
queues and task requirements
[10:03] <okulikov> Vassiliy is working under fast and deterministic RTSP
protocol implementation
[10:03] <okulikov> me is doing same thing for media containers: wav, mpeg,
3gp, etc
[10:04] <okulikov> this is mostly optimizations with goal to improve
deterministic cpabilities
[10:04] <ivelin> what is the status of the feasibility testing?
[10:04] <okulikov> in progress
[10:05] <okulikov> there is no final solution
[10:05] <okulikov> yet
[10:06] <okulikov> community feadback not so bad: number of downloads
stable, periodicaly receiving bug reports. all mentioned bugs solved and
tested by users
[10:07] <ivelin> what is the goal for a final solution?
[10:07] <ivelin> or criteria
[10:07] <okulikov> in sense of roadmap: finish feasibility test, add more
mgcp packages and streamign capabilties
[10:07] <okulikov> you mean for feasibility test?
[10:08] == vra [5f2a9ef6@gateway/web/freenode/ip.95.42.158.246] has joined
#mobicents
[10:09] <ivelin> yes
[10:09] <ivelin> how would you know when the feasibility test is
sufficiently good?
[10:10] == jean [~j...@lns-bzn-56-82-255-218-134.adsl.proxad.net] has quit
[Quit: Leaving]
[10:10] == jean [~j...@lns-bzn-56-82-255-218-134.adsl.proxad.net] has
joined #mobicents
[10:10] <okulikov> when we wont have missed tasks
[10:10] <okulikov> more then limit
[10:12] <okulikov> at the moment we are not trying to talk about cpu
utilization limit
[10:13] <ivelin> you said offline that the current algorithm is a big
improvement and the predictability is very good at 25% CPU utilization
[10:13] <ivelin> something in the order of 100 IVR calls on a laptop
[10:13] <ivelin> that seems to me like a good freezing point
[10:14] <okulikov> it is when we talked about G729?
[10:15] <ivelin> when the tasks are of various sizes?
[10:16] <okulikov> I said that we can run currently existing G729 codec
ONLY for one connection, no more and CPU utilization will be around 25%
[10:17] <okulikov> so for the first look it seems like we can add more
however already for second such connection we can not quarantee anything
[10:17] <okulikov> that's another sense
[10:18] <okulikov> same for IVR connections - estimation is to handle 250
[10:18] <okulikov> the estimation is based only on execution time of tasks
[10:18] <okulikov> but!
[10:19] <okulikov> feasibility test will limit this value - how? I don't
know yet
[10:19] <ivelin> so 250 G7111 tasks or 1 G729?
[10:19] <okulikov> yes
[10:19] <okulikov> seems strange?
[10:20] <okulikov> this is result of non-deterministic execution
[10:20] <okulikov> plus note, the upper limit of performance is not fixed
and may vary
[10:20] <okulikov> this is due to non preemtive execution
[10:21] <ivelin> its not strange at all
[10:21] <ivelin> encoding can be intensive
[10:21] <ivelin> can we freeze a stable version for g711 then?
[10:21] <okulikov> so there is some wildcard present and the goal of
feasibility test to switch a red light
[10:22] <okulikov> I am not consdering g729 even now
[10:22] <okulikov> irrepective of codecs feasibity test must be implemented
[10:22] <ivelin> when do you expect to wrap up the work on the feasibility
test? Do you have visibility on that?
[10:22] <okulikov> it does not depend from codec
[10:22] <okulikov> quite difficult question
[10:22] <okulikov> I can only do another work in parallel
[10:23] <okulikov> as I said offline, there is only necessary condition for
feasibility test
[10:24] <ivelin> ok, what is the MPEG work about? Experiementing with video
streaming, mixing?
[10:24] <okulikov> with codec implementation only
[10:24] <okulikov> encoding/decoding colored lines
[10:25] <vra> if g729 is infeasible what's left for MPEG condecs
[10:26] <okulikov> who said that G729 codec is infeasible?
[10:26] <okulikov> I said current implementation is very non-deterministic
[10:27] <okulikov> don't mix the things
[10:27] <vra> it's not that undeterministic
[10:28] <vra> most codecs are desgined to be easy for hardware
implementations which must be deterministic
[10:28] <okulikov> do you have test diagram?
[10:28] <vra> g729 also has a low complexity mode in annex a
[10:29] == baranowb [55de5643@gateway/web/freenode/ip.85.222.86.67] has
quit [Ping timeout: 258 seconds]
[10:29] <okulikov> the question is not how g729 was designed, the question
is how it is implemented in trunk
[10:29] <okulikov> try to test what we have in trunk and you will
undertsnad about what I am talking
[10:30] <vra> there is one optimization possible - avoid coverting strings
to bitstream at the end
[10:30] <vra> i left this step to strings to be easy to run the original
g729 testsuite
[10:30] <okulikov> if there are string then it means a lot of optimizations
:)
[10:30] <vra> once this is removed there is almost nothing you can do
better in java
[10:31] <vra> it's a very small determinitstic O(n) step
[10:31] <vra> if that's the problem something must be wrong elsewhere
[10:31] <okulikov> you forget about GC
[10:31] <okulikov> how many job for GC it leaves?
[10:31] <okulikov> where?
[10:32] <vra> 20 bytes per 20ms
[10:32] <vra> thats the gc
[10:32] <vra> for this step
[10:32] <okulikov> tests shows another result
[10:33] <vra> anything other change in this algorithm will be incredibly
complex to rewrite properly
[10:33] <vra> even if more efficient implementation can be done in java
[10:33] <okulikov> so, suggestions? leave as is?
[10:34] <vra> suggestion is leave as is and think about native codecs
[10:34] <ivelin> let's continue this offline
[10:34] <ivelin> need to continue with the general meeting
[10:35] <ivelin> I would say however that there wold be a lot of value in a
G711 only, stable MMS
[10:36] <ivelin> maybe freeze the scope for MMS 2.1.x to be linear codecs
and start work in MMS 2.3 for others
[10:36] <okulikov> that's why feasibity test is still a primary question
[10:37] <okulikov> native codecs does not give any benefits, only problems
[10:37] <yulian_o> its not so true , in 3G networks for example 729 or AMR
is a must
[10:38] <okulikov> and?
[10:39] <ivelin> that's fine. I'm not saying there is no need for other
codecs.
[10:39] <yulian_o> most of systems today supports 729 at least , and for my
opinion you can not base solution on one codec only.
[10:39] <ivelin> However there is a big class of use cases solved by g711.
These will benefit from a stable MMS branch.
[10:40] <yulian_o> buts indeed its better to start with one stable but
other codecs should be added lately
[10:40] <ivelin> Yulian, many of the Mobicents use cases are in operator
networks that expose linear media.
[10:41] <ivelin> the compression in these cases is left to a more
peripheral layer outside the core telco network
[10:41] <ivelin> sure
[10:41] <ivelin> ok, let's switch to the general meeting now
[10:42] <ivelin> #1 MMS (summary)
[10:42] <ivelin> #2 JSLEE
[10:42] <ivelin> #3 Diameter
[10:42] <ivelin> #4 SS7
[10:42] <ivelin> #5 TelScale/MSS
[10:42] <ivelin> #6 RestComm
[10:42] <ivelin> #7 QE
[10:42] <ivelin> what's missing?
[10:42] == okulikov [~okuli...@31.180.163.207] has quit [Ping timeout: 240
seconds]
[10:44] == baranowb [55de5643@gateway/web/freenode/ip.85.222.86.67] has
joined #mobicents
[10:45] == AntonKuzovikhin [1f808b49@gateway/web/freenode/ip.31.128.139.73]
has quit [Quit: Page closed]
[10:45] <ivelin> ok, let's start then
[10:45] <ivelin> #1 MMS (summary)
[10:46] <ivelin> MMS 2.2.CR was released last week. Ongoing work on
stability, new codecs and 3g network integration cases
[10:48] <ivelin> MMS 2.1 - ongoing work on predictability, RTSP and new
codecs. Will focus on stabilizing for linear codecs like G711.
[10:48] <ivelin> Live Video conferencing demo is being setup on Tom Q's
cloud
[10:48] <ivelin> #2 JSLEE
[10:48] == moy [~...@173.239.155.74] has joined #mobicents
[10:48] <@mart1ns> hi all
[10:49] <@mart1ns> we are in the middle of testing 2.6.0 snapshot
[10:49] <@mart1ns> struggling a bit with the latest media server
[10:49] <@mart1ns> we also a few new issues on eclipslee to handle, but
nothing serious
[10:50] == okulikov [~okuli...@31.180.149.232] has joined #mobicents
[10:50] <@mart1ns> it should be out soon, but there is a big chance that we
will bundle a snapshot of fixed media server
[10:50] <@mart1ns> since the one released is not good for the slee examples
[10:50] <@mart1ns> baranowb: wanna say something about this?
[10:51] == sgarcia [~Ser...@79.173.183.130] has left #mobicents []
[10:51] <baranowb> not quite sure if there is anything more to say, simple
as that statement
[10:51] <ivelin> which mms?
[10:51] <baranowb> olegs branch is tested si far\
[10:52] <baranowb> Im not at home atm so did not have chance to runs
against yulians
[10:52] <@mart1ns> alex: wanna update also on web console and eclipslee?
[10:52] == uijltje [~tuijld...@ip-80-113-12-132.ip.prioritytelecom.net] has
quit [Quit: Leaving.]
[10:53] <@alexandrem> hey
[10:54] <@alexandrem> well, the web console is ready for release, we've
fixed several issues found by villius/elitnet and also integrated two
features they contributed: RA Usage Parameters and SLEE Alarms
[10:55] <@alexandrem> Documentation has also been made for the console,
already covering these two contributions
[10:55] <@alexandrem> regarding EclipSLEE, not much to say.. haven't yet
check the reported bugs.
[10:56] <@mart1ns> ok
[10:56] <@mart1ns> that's it for slee then, we hope to release 2.6 very soon
[10:57] <ivelin> can you point to the URLS of the Elitnet contributions?
[10:58] <@alexandrem> issues ?
[10:59] <@alexandrem> from
[10:59] <@alexandrem>
https://code.google.com/p/mobicents/issues/detail?id=3005
[10:59] <@alexandrem> to
https://code.google.com/p/mobicents/issues/detail?id=3011
[11:00] <vilpan> correct, reported 3005-3011, implemented 3009, 3010
[11:01] <ivelin> cool
[11:01] <ivelin> thanks, Villius
[11:01] <vilpan> that was my colleague, Povilas, actually, I just initiated
that ;)
[11:02] <ivelin> just saw that in the case, thanks Povilas and Alex :)
[11:02] <ivelin> ok, thanks for the JSLEE update
[11:02] <ivelin> #3 Diameter
[11:02] <@mart1ns> np
[11:03] <jean> mart1ns, can you update the acknowledgements page
[11:03] <jean> ?
[11:03] <jean> http://www.mobicents.org/acknowledgements.html
[11:03] <@alexandrem> is that page linked somewhere in the site? I don't
seen any direct like
[11:04] <@alexandrem> I will add a link to it in the diameter section
[11:04] <baranowb> hmm in faq I think, but not sure
[11:04] <@alexandrem> but we should have a top level link to that
[11:04] <@mart1ns> that's a long task you know, have to track the "old"
contributors
[11:04] <@alexandrem> or something in the frontpage.. it's deserved :)
[11:04] <@mart1ns> but will try
[11:04] <jean> mart1ns, at least add any new contributions here
[11:04] <jean> alexandrem, right
[11:05] <jean> in community I guess
[11:06] <ivelin> true, long overdue
[11:06] <ivelin> #3?
[11:07] <@alexandrem> ok, Diameter.
[11:07] <@alexandrem> We have been fixing several bugs that users report in
community, both forum and issue tracker.
[11:07] <@alexandrem> most are not major issues, but rather details that
make interop with other implementations harder
[11:08] <@alexandrem> but there's one major problem, with OctetString
encoding, which should consist of a byte[] and we are encoding it as
String.. yulian_o had already reported this a while ago, we are now making
this fix
[11:09] <@alexandrem> we expect to fix these quickly and try to release CR2
during the next days
[11:11] <ivelin> which 3rd party Diameter systems are being interconnected?
[11:12] <@alexandrem> not sure, wasn't mentioned
[11:13] == baranowb [55de5643@gateway/web/freenode/ip.85.222.86.67] has
quit [Ping timeout: 258 seconds]
[11:13] <@alexandrem> the user just said that it would not comply with his
customer diameter server due to that
[11:14] <ivelin> ok, please ask. Its good to know who are the other vendors
in the field.
[11:14] <ivelin> #4 SS7
[11:14] <@alexandrem> ok
[11:15] <abhayani> The work has begun for CR3 release after vacation pause
[11:15] <abhayani> nothing more to update as of now. Sergey please update
on your CAP/MAP activity
[11:16] <svetyutnev> This week I implemented CAP service
[11:17] <svetyutnev> Most of CAP parameters has been implemented now
[11:17] <svetyutnev> And I am implementing CAP services now
[11:18] <svetyutnev> (for telephony)
[11:18] <abhayani> nice! I assume you have already added the service
information in spread sheet
[11:18] <abhayani> like we have for MAP
[11:19] <svetyutnev> I am updating the list of parameters and messages that
have been implemented
[11:20] <abhayani> ok
[11:21] <ivelin> that's all for SS7?
[11:22] <ivelin> interesting community feedback?
[11:22] <svetyutnev> I think yes
[11:23] <abhayani> There were few issues reported in forum
[11:23] <abhayani> but turned out to be wrong config
[11:23] <abhayani> I guess its resting season of the year :)
[11:23] <ivelin> good kind of issues
[11:24] <ivelin> new blogs coming out for CAP? ;)
[11:24] <abhayani> will do once we release 2.0.0.BETA1
[11:24] <abhayani> CAP is only for 2.x releases
[11:27] <ivelin> ok
[11:27] <ivelin> #5 TelScale/MSS
[11:28] <jean> #1 MSS in Arquillian - Closed another issue on Arquillian.
porting part of the MSS testsuite before a first ALPHA release.
[11:28] <jean> #2 CDI, MTF, Sip Servlets 2.0 - no updates here
[11:28] <jean> #3 RestComm - No updates due to work for a customer
[11:28] <jean> #4 OpenVBX - Henrique, please update offline
[11:28] <jean> #5 MSS on AS7 - the forking of web AS7 subsystem as the only
solution to integrate SIP Servlets is confirmedhttp://
lists.jboss.org/pipermail/jboss-as7-dev/2011-December/004935.html
[11:28] <jean> #6 Cloud/HA datagrid - No News here. vacations
[11:28] <jean> #7 MSS 1.7 - MSS ported to latest releases of Tomcat 6.X and
Tomcat 7.X. Migration of SIP Servlets jobs to CloudBees is complete, see
https://mobicents.ci.cloudbees.com/view/TelScale/ but results still need to
be optimized
[11:30] <jean> regarding #5, contributor from solaiemes will try to take a
shot at it
[11:32] <ivelin> what does it mean to fork web as 7?
[11:32] <jean> in as 7 there is the web subsystem that is responsible
[11:32] <jean> for starting and defining the connectors
[11:33] <jean> + deployment
[11:33] <jean> this system is not open at all
[11:33] <jean> and won't be
[11:33] <jean> so it has to be forked
[11:33] <jean> to provide convergence with SIP Servlets
[11:36] <ivelin> huh
[11:36] <ivelin> as7 is not open source?
[11:36] <jean> it is
[11:36] <jean> but there aren't any API to extend it so far
[11:37] <jean> so you need to copy the code, modify it and maintain your
own version instead of relying on extension points
[11:37] <vra> if these guys from ericsson are already doing open source as7
deployment module code we could wait and take it from their open source
server :)
[11:39] <jean> vra, I tried to contact those guys
[11:39] <jean> to work collaboratively on it
[11:39] <jean> but to no avail so far
[11:39] <ivelin> so it won't be possible to build as7 all from source in
the public repo?
[11:40] <jean> we could just download as7 as we do now
[11:40] <jean> and build our own web-sip subsytem
[11:40] <jean> and overwrite the jars in the as7 distribution
[11:40] <jean> of the web susbsytem with ours
[11:41] <jean> and modify the config file as well
[11:41] <jean> to ship by default with the sip connectors
[11:41] <ivelin> sounds like a lot of trouble
[11:41] <ivelin> what's the diff with using Tomcat?
[11:41] <jean> you get java ee 6
[11:41] <jean> EJBs etc
[11:42] <ivelin> not unless you pull in the whole as7, right?
[11:42] <jean> right just like we have now with as5
[11:42] <jean> but you don't need to pull the full source
[11:42] <jean> it uses maven deps
[11:43] <jean> and we will base our work on a tagged version
[11:43] <jean> 7.1 probably
[11:46] <ivelin> phew
[11:47] <vra> as71 added some nasty new stuff for clustering
[11:47] <ivelin> quite an interesting model. How will an open source
extension be possible supported by RHT?
[11:47] <vra> each replicated object has different replication policy,
sfsbs go to REPL, http session go to DIST and other things just invalidate
[11:48] <vra> we will need to discuss if we want to follow on this model or
do it independently
[11:48] <ivelin> Vladimir, what are you referring to?
[11:49] <vilpan> clustering
[11:49] <vra> different things in the server use different modes of ISPN
replication making it even tigher than before
[11:50] <vra> so if we must decie if we want to follow this model or do
cassandra etc stuff otherwise it is more complexity
[11:51] <vra> just saying.. it's not immediate concern now
[11:52] <ivelin> I see
[11:53] <ivelin> ok, good to know that Solaimaes will put some time to
scope the effort
[11:53] <ivelin> #6 was covered already, so lets go to 7
[11:53] <ivelin> #7 QE
[11:55] <jean> on my side
[11:55] <jean> the MSS jobs were ported to cloudbees
[11:56] <jean> and luis sent m the jsr 289 zip he uses
[11:56] <jean> so I updated th job to use this one which should be more
pristine than mie
[11:56] <jean> mine
[11:56] <ivelin> the jsr 309 tck against mms 2.2?
[11:56] <vra> is there a quota problem with cloudbees?
[11:58] <jean> vra, what do you mean ?
[11:58] <jean> we are on the FOSS Subscriptin
[11:58] == vilpan [~vil...@88-119-197-33.static.zebra.lt] has quit [Quit:
Leaving.]
[11:58] <jean> subscription
[11:59] <vra> jobs taking too long
[11:59] <jean> http://www.cloudbees.com/foss/foss-dev.cba
[11:59] <jean> ah no the quota was due to our usage
[12:00] <jean> we took the premium
[12:02] <ivelin> Luis, anything from your end?
[12:03] <vra> cluster tests dont seem to like ithttps://
mobicents.ci.cloudbees.com/view/TelScale/job/MobicentsSipServletsClusterTes tsJBoss5/lastCompletedBuild/testReport/
[12:05] <jean> yeah I know
[12:05] <jean> it needs tuningther
[12:05] <jean> there
[12:05] <jean> the as takes longer to start on those instances it seems
[12:06] <jean> same thing for
https://mobicents.ci.cloudbees.com/view/TelScale/job/MobicentsSipServ...
[12:07] <jean> ivelin the 2.2 branch is oleg branch ?
[12:07] <jean> or yullian ?
[12:08] <jean> if it's yullian the job is located here
[12:08] <jean>
https://mobicents.ci.cloudbees.com/job/Mobicents-MediaServer-2.x-JSR3...
[12:09] <ivelin> 2.2 is Yulian
[12:09] <ivelin> Oleg's branch (2.1) doesn't pass 309
[12:09] <barreiro> ivelin, nothing from me on the mobicents front.
[12:10] <ivelin> ok
[12:10] <ivelin> let's wrap up the meeting
[12:10] <ivelin> thanks everyone for joining
