Mobicents weekly chat 11th of November 2009

[Alexandre Mendonça]

Attendees:
 Amit,Pavel,Alex, Bartek, Eduardo, Jean, Luis, Oleg, Vladimir, Ivelin

Summary:
#1 Hudson, docs build, google wave, GAE - prototype of automated roadmap
generation ready, patch 980 ready
#2 MSS 1.1  - more bugfixes, on Stuttgard Jug, release hopefully ready
next week
#3 MMS 2.0 - SS7 close to target, release shifted one week later
#4 Diameter 1.x - started working on HSS prototype and on Sh-server
porting to Mobicents 2.x
#5 JSLEE 2.0 - more testing on BETA2, close to release, regarding 1.2.7
almost all issues are closed
#6 QE - SIP HA, Media Testing - testing jbcp patch 980, planning for FY
2011, testing BETA2 next week

Log:

[17:07] <ivelin2> #1 Hudson, docs build, google wave, GAE
[17:07] <ivelin2> #2 MSS 1.1
[17:08] <ivelin2> #3 MMS 2.0
[17:08] <ivelin2> #4 Diameter 1.x
[17:08] <ivelin2> #5 JSLEE 2.0
[17:08] <ivelin2> #6 QE - SIP HA, Media Testing
[17:09] <ivelin2> what else?
[17:13] <ivelin2> ok, #1 then
[17:13] <ivelin2> oh
[17:13] <ivelin2> just to let you know, I have a dentist appointment in
less than an hour
[17:13] <slegrik> looks like it is me :)
[17:13] <ivelin2> postponed it 3 times already, but the dentits got mean
to me. I don't want them to be too mean :)
[17:13] <slegrik> let me first update, what I have reached
[17:13] <baranowb> I bet its "she"
[17:14] <ivelin2> so I'll step out of the chat for about 30 minutes and
then get back in
[17:14] <slegrik> I was working on the roadmap automatic generation
tool. The prototype is ready. I have used  the Sip Servlets 1.2.00
version for proof of concept
[17:14] <ivelin2> Pavel, since your name popped up first, do you mind
keeping notes and sending out after the meeting?
[17:14] <slegrik> The outcome can be seen at
http://hudson.qa.jboss.com/hudson/view/Mobicents/job/MobicentsRoadmap/ws/Roadmap-draft/mobicents-google-app-engine-checkout/mss-roadmap.html
[17:15] <slegrik> ivelin2, I do not mind I will send the notes
afterwards
[17:15] <slegrik> We need to define, what will be the next steps
regarding roadmap
[17:16] <slegrik> besides I was working on the patch
[17:16] <slegrik> patch 980 (Hotfix for the customers), it is ready in
QA, once tested will be shipped.
[17:17] <jeand> barreiro, did you have time to test it out ?
[17:17] <barreiro> jeand, yees, it's almost finished.
[17:18] <jeand> what is the ETA for delivery ?
[17:18] <barreiro> today
[17:18] <jeand> great
[17:19] <ivelin2> so where does gwaves come in?
[17:19] <ivelin2> the result looks nice, btw
[17:19] <jeand> it doesn't
[17:20] <slegrik> ivelin2, well I want to have automated job on Hudson,
which check for updates on the svn for mobicents-google-app
[17:20] <slegrik> ivelin2, so only what we need to have ability to
deploy on GAE
[17:20] <jeand> just the gmail account was to be used from the hudson
job to upload mobicents.org files from the google code svn
[17:21] <ivelin2> not following
[17:21] <ivelin2> gmail, hudson?
[17:21] <jeand> to be able to upload files to GAE you need credentials
[17:22] <jeand> those credentials could be the one from the
mobicents.wave gmail account
[17:22] <jeand> so that nobody can't get access to one of our personal
gmail account
[17:23] <vralev> but the tool is already a Java app and GAE can host
Java apps that generate web pages )it's servlets), so it makes sense to
just host the tool in GAE as a GAE app and generate the page when
visting
[17:24] <jeand> oh it's a java app ? I thought it was a python app
[17:24] <vralev> well GAE can host pythin too :)
[17:24] <jeand> in any case, even without the roadmap generation
[17:24] <jeand> it could be nice to have a hudson job taking care of
updating the website automatically
[17:24] <jeand> instead of us doing it manually
[17:25] <slegrik> vralev, this is also possible way to go
[17:25] <jeand> even though it's a small burden
[17:25] <jeand> and for future customers
[17:25] <jeand> they would just need to worry about committing to trunk
[17:26] <jeand> customers wanting to contribute to doco or frameworks
[17:26] <jeand> doco
[17:26] <jeand> and the hudson job will publish automatically
[17:27] <slegrik> jeand, yeah this was the goal - whatever update to
mobicent-google app in svn will be updated immediatly
[17:27] <vralev> right, only prob i see is an error in the job could
delete the whole mobicents.org
[17:28] <ivelin2> why not have a scheduled task in the mobicents.org GAE
app
[17:28] <jeand> same problem when doing it manually
[17:28] <jeand> as long as the svn copy is intact we are fine
[17:28] <mart1ns> ones of us could do the same terror
[17:28] <ivelin2> to pull updates occasionally
[17:28] <ivelin2> hudson would send an email when ready and GAE will
pull the files
[17:28] <jeand> need to check if those tasks have access to the GAE SDK
to be able to update
[17:29] <slegrik> I thought GAE was not allowed to make a pulls...
[17:29] <ivelin2> there is also a gateway that triggers URL call when an
email is sent to it
[17:29] <slegrik> only to push it there
[17:30] <ivelin2> well, you can't pull new files on GAE, but you can
store and serve content from the DB
[17:30] <ivelin2> for more static web pages, the new Google Sites API
might be more handy
[17:31] <ivelin2> in any case, how would hte google wave account work?
Do you just need the credentials, and not the wave functionality?
[17:32] <jeand> ivelin2, yes just the credentials of a gmail account
[17:32] <jeand> we could even create a new one just for that
[17:32] <jeand> the only thing is that this gmail account should be
allowed to upload files to GAE
[17:32] <jeand> oh they did a new google sites ? I thought it was
shutted down
[17:33] <ivelin2> they shut down google pages
[17:33] <ivelin2> but sites has been evolving, it replaced pages
[17:34] <ivelin2> http://code.google.com/apis/sites/
[17:35] <ivelin2> GAE is where live server side code resides, GSites -
static content with versioning, etc.
[17:35] <slegrik> so, how do we approach further ? How about preparing
the complete Sip Servlets roadmap, which is automaticaly generated from
issues and then we continue further... how about that ?
[17:36] <jeand> ivelin2, it would be much more work to move
mobicents.org to google sites no ?
[17:36] <jeand> and we would still need some credentials
[17:36] <jeand> to be shared
[17:36] <jeand> the good thing about having the doco in svn
[17:36] <jeand> is that it is versionned
[17:37] <jeand> so we can recover if something goes wrong
[17:37] <ivelin2> lets create  new account and I'll grant it access to
mobicents GAE  so files can be uploaded
[17:37] <jeand> ok
[17:37] <slegrik> ivelin2, ok
[17:37] <ivelin2> actually, Vladimir, who owns the Mobicents GAE
account?
[17:37] <vralev> ivelin2: you own it
[17:39] <ivelin2> ok
[17:39] *** barreiro_ has joined #mobicents
[17:39] <ivelin2> let's move on wih the agenda
[17:39] <ivelin2> I'm jumping out to see dentist
[17:39] <ivelin2> will re-join later
[17:39] <slegrik> ivelin2, good luck
[17:39] <jeand> good luck man !
[17:40] <jeand> ok I guess it's MSS
[17:40] <slegrik> I hate dentist appoitments
[17:40] <jeand> #2 MSS 1.1
[17:40] <vralev> lets hope dentist is just an euphimism for something
else :)
[17:40] <jeand> There was more bug fixing on MSS
[17:40] <jeand> vralev, LOL
[17:41] <jeand> and we investigating a mem leak a potential customer
reported
[17:41] <jeand> there is more problems repported by this prospect that
we are investigating at the moment
[17:41] <jeand> and this is a blocker for the next release
[17:42] <jeand> on the community side, one more bug was reported but it
looks like a jsip issue
[17:42] <jeand> same INVITE is creating 2 diffrernt STX
[17:42] <jeand> I mean INVITE and its retransmission
[17:43] <jeand> then I went to the Stuttgart JUG
[17:43] <jeand> but it didn't go as well as expected and the attendance
was pretty low
[17:44] <jeand> online promotion is much more effective
[17:44] <jeand> I would recommend doing JUGs only locally for now (close
to where we live)
[17:45] <jeand> vlad added HTTP balancing based on Netty
[17:45] <jeand> to the SIP Load balancer
[17:45] <jeand> vralev, can you update on that ?
[17:45] <vralev> ok
[17:46] <vralev> yeah there have been 2 major revisions to the LB last
week
[17:46] <slegrik> jeand, do you mean by the blocker, that there will
more one off patches ? for them ? Cant they wait till 1.2.2 ?
[17:46] <vralev> 1. HTTP balancer, which behaves like mod_jk, but also
supports special affinity keys
[17:47] <vralev> 2. SIP routing was changed and the algortihm interface
has changed to support better proxy cases. Not both the inbound and the
outbound proxy requests go through the SIP LB
[17:47] <vralev>
http://docs.google.com/present/view?id=dc5jp5vx_89cxdvtxcm
[17:47] <jeand> slegrik, I will talk with somil but it might be needed
to have more patches indeed
[17:48] <vralev> see slides 15-18 for HTTP LB and converged
[17:48] <vralev> slides 13-17 i mean
[17:48] <jeand> not sure about the strategy but indeed since we can make
hot fixes if we release 1.2.2 we can do iterations indeed
[17:49] <jeand> ivelin2, can you comment on that when you're back ?
[17:49] <jeand> vralev, in 2 did you mean now instead of not ?
[17:49] <vralev> so the thanks to netty and some HTTP test tools the
HTTP balancer part is very stable already and has good performance
[17:50] <vralev> jeand: I meant "Now", sorry
[17:50] <slegrik> jeand, you know one off patch is very rare thing by
other projects - normally the requests from customers are cumulated and
delivered in the Cp's
[17:50] <jeand> np, just to be sure
[17:50] <vralev> you can see what changed in 2 in slide 5
[17:51] <vralev> so this HTTP balancer feature was need to fill the gap
we have due to slipping one of the planned features and this way we are
also catching up completely with other sip servlets LBs, so it was
completely worth the stretch
[17:52] <vralev> since then I am testing heavily the SIP balancing, and
found some bugs
[17:53] <vralev> I have to dicuss them with Jean later, but they are not
that big and will ne be a delay
[17:53] <vralev> that's it if there are no questions
[17:54] *** abhayani_ has joined #mobicents
[17:54] <vralev> you can just go through the updated slides to see other
changes
[17:54] *** abhayani has quit (Read error: 131 (Connection reset by
peer))
[17:54] <vralev> there are some changes in the algorithms etc
[17:54] <vralev> nothing that big
[17:54] <jeand> I will check tomorrow
[17:55] <jeand> by the way, is the LB able to be colocated with the
nodes in JB5 version ?
[17:55] <jeand> I don't remember if that was already implemented
[17:56] <jeand> Does it make sense for the LB to have its own jdocbook
now as well, since it is shared between JSLEE and SIPS and in the future
will be used for diameter as well ?
[17:56] <vralev> well I made a bootstrapper, but it is out of date now
[17:56] <vralev> it's not an important feature
[17:57] <jeand> even for cloud like architecture ?
[17:57] *** barreiro has quit (Read error: 110 (Connection timed out))
[17:57] <jeand> I guess automatic LB detection based on multicast is
more important for cloud like architecture
[17:58] <vralev> clouds dont care about that afaik
[17:58] <vralev> yes
[17:58] <jeand> ok
[17:59] <mart1ns> so that architecture where each node would have a LB
is deprecated now?
[18:00] <jeand> I guess that's still possible even if the LB is not
deployed in the JBoss AS with the container
[18:00] <vralev> mart1ns: it is not deprecated, in fact it is supported
as of now, just configs are not deduced based on colocation and must be
done manually
[18:01] <mart1ns> ok
[18:02] <mart1ns> did you had a thought about that idea of the stack
adding the lb to route on client txs?
[18:02] <mart1ns> if it is present
[18:03] <vralev> I was thinking about it but I forgot what was the
result :)
[18:03] <mart1ns> too much pretty girls around you uh?
[18:03] <vralev> I think it's better to leave it to the container or the
apps in case of JSLEE
[18:04] <vralev> jeand: did you think about  it?
[18:04] <mart1ns> the good thing would be to have it done at stack
level, this independent of what uses the ha stack, what are the bad
things?
[18:04] <mart1ns> this=thus
[18:05] <vralev> mart1ns: what if some apps need to be tx-stateless
[18:05] <baranowb> does it mean that route headers are not used if there
is not tx ?
[18:05] <vralev> also for proxy sometimes you do statless stuff anyway
[18:06] <mart1ns> stateless can be detected right?
[18:06] <jeand> mart1ns, yeah through the sipprovider usage
[18:06] <mart1ns> doesn't jsip requires certain methods to be used?
[18:06] <jeand> yep
[18:06] <jeand> I guess this could be done
[18:06] <mart1ns> I'm still trying to figure the proper way to plug the
LB in slee
[18:07] <mart1ns> clearly this is off for beta2
[18:07] <vralev> route headers are used if there is no tx, but if we add
balancer support at tx level tx-stateless stuff will need to be handled
differently
[18:07] <vralev> ok let this slip for now unless someone has a
breakthrough that it is totoally useful
[18:07] <jeand> vralev, we could handle it as well in a
HASipProviderImpl
[18:07] <mart1ns> so I guess that not caring about the lb results in
fail over of established dialogs that send client tx requests are
screwed right?
[18:07] <jeand> but I think we can slip it for now as well
[18:08] <mart1ns> vralev, if it could be done it is a good thing
[18:08] <mart1ns> that is, if it doesn't intoduce any negative stuff
[18:09] <mart1ns> like I said, just stepping in without any base
knowledge :)
[18:09] <vralev> mart1ns: in JSLEE apps can just  caring about LB for
JSLEE can be done at app level
[18:10] <mart1ns> well, that would result in apps
[18:10] <mart1ns> that would need to know if they were running with a lb
or not
[18:10] <mart1ns> don't think that would be a good dependency
[18:10] <vralev> also note that care is only needed for requests
initiated by the container, for inbound requests containers do not care
at all
[18:11] <mart1ns> that is what I thought
[18:11] <mart1ns> right now in slee we already tamper the messages sent
by apps
[18:11] <vralev> it's very simple the LB is just a proxy
[18:11] <mart1ns> with dialog tags
[18:11] <vralev> you either want to go through that proxy or not
[18:11] <mart1ns> I guess we can do it too with lb stuff
[18:11] <mart1ns> but somehow sounds more a stack think
[18:12] <vralev> actually does JSIP support outboundProxy parameter?
[18:12] <vralev> if it does we are done
[18:12] <oleg> it does
[18:12] <jeand> vralev, yes it does
[18:13] <jeand> but not sure you can change it at runtime
[18:13] <mart1ns> so that is already present in nist stack?
[18:13] <jeand> if one of your LB dies
[18:13] <jeand> and you need to swithc to another
[18:13] <mart1ns> maybe a little hack :)
[18:13] <oleg> Jean, may be links with different sip settings
[18:13] <mart1ns> and go into gov nist code?
[18:13] <vralev> you dont need to switch at runtime
[18:14] <jeand> I said not sure, it might already be there
[18:14] <vralev> you just point it to the IP LB and it will do the
switching
[18:14] <jeand> oh right
[18:14] <jeand> we are good then
[18:14] <mart1ns> so, let me get this straight
[18:14] <mart1ns> that is a stack property right?
[18:15] <jeand> mart1ns, right
[18:15] <vralev> mart1ns: javax.sip.OUTBOUND_PROXY
[18:16] <mart1ns> and we now have a stack property to turn on the lb
client at the ha stack
[18:16] <jeand> JAIN SIP prop
[18:16] <jeand> right
[18:16] <mart1ns> could we figure out the outbond proxy
[18:16] <mart1ns> from the client
[18:16] <mart1ns> and inject the property
[18:16] <jeand> I guess we can
[18:16] <jeand> oh no
[18:16] <jeand> this is the IP LB IP address
[18:16] <jeand> which is needed
[18:16] <jeand> not the SIP LB
[18:17] <jeand> so depending on the setip
[18:17] <jeand> setup
[18:17] <jeand> you may have a config option for that too
[18:17] <mart1ns> so this would need to be manual?
[18:17] <jeand> if there is an IP LB
[18:17] <jeand> you provide the IP address manually
[18:17] <jeand> otherwise
[18:17] <jeand> it does the detection itself if there is only one SIP
LB
[18:17] <jeand> in the architecture
[18:18] <mart1ns> how far are we from a solution where we always start
the lb client and it finds out if the ip balancer is there, if it is
sets the stack outbond proxy and becomes active, if not it passivates
itself ?
[18:19] <jeand> didn't get you
[18:19] <mart1ns> that is, it would auto-configurate itself, the ha and
nist stack
[18:19] <vralev> Iam arfaid that's not possible for now
[18:19] <vralev> IP balancer can come from different vendors
[18:19] <vralev> and it can be hardware
[18:19] <jeand> we need a way to autodetect the ip lb
[18:19] <vralev> they dont have such interfaces
[18:20] <vralev> and you can assume that IP LB is always on and never
fails
[18:20] <mart1ns> well, doesn't need to have that feature for all
[18:20] <vralev> and never changes
[18:20] <mart1ns> just for one :)
[18:20] <mart1ns> and of course, possible manual override
[18:20] <jeand> I don't think that is so important
[18:20] <vralev> autodetect ip lb is not possible
[18:20] <mart1ns> ok :(
[18:21] <mart1ns> I would really like to have a single sip RA deployable
unit
[18:21] <mart1ns> that would work on local or cluster mode, with or
without lb
[18:21] <vralev> mart1ns: you can, IP LB is not stopping you
[18:21] <mart1ns> I feel we are close to that
[18:22] <jeand> mart1ns, you can just tweak the propertie
[18:22] <jeand> properties
[18:22] <jeand> as you do for the lb client thingie
[18:22] <mart1ns> ok
[18:22] <jeand> if IP_LB prop is set
[18:22] <jeand> use that for outbound proxy
[18:22] <jeand> otherwise use the one in balancers prop
[18:22] <jeand> the first one
[18:22] <mart1ns> well, actually it is transparent
[18:23] <mart1ns> I just forward properties to stack
[18:23] <jeand> I will update the jain sip HA to take care of that
[18:23] <mart1ns> it is fine, I guess this means all we need to ask the
user is to edit the meta data file in the du jar
[18:23] <slegrik> I must leave earlier today, I will let the applet
thing open and send the notes afterwards, bye guys
[18:24] <jeand> bye slegrik
[18:24] <mart1ns> jeand, why another property, the outbond proxy can't
be used?
[18:24] <jeand> oh right
[18:24] <jeand> I will still need to update JAIN SIP HA so that if
balancers is present and outbound proxy is not
[18:25] <jeand> it sets the outbound proxy prop based on the balancers
prop
[18:25] <mart1ns> ok
[18:26] <mart1ns> how much time do you think you need till jain sip 122
can be out and we can do the 0.1 release of the ha stack?
[18:26] <mart1ns> well, leave it for the slee discussion
[18:26] <mart1ns> and move on, otherwise we will dive in slee
[18:27] <jeand> I would have say tomorrow if there is no blocker on 122
[18:27] <jeand> we are done I guess for #2
[18:28] <oleg> #3 MMS 2.0
[18:29] <oleg> this week we was playing with native i/o
[18:29] <oleg> today Bartek reported about good news that link is
in_service state
[18:29] <oleg> but mtp3 now fails and remote side is switching to down
state
[18:30] <vralev> wow
[18:30] <vralev> so the native compoenet is already working and talking
to the java code?
[18:30] <oleg> during tests was discovered that mtp 2 is very sensitive
for CPU ussage and delays on thread
[18:30] <oleg> Vlad, yes
[18:31] <oleg> but if Java thread delays it lose data anyway
[18:31] <oleg> so now all logging are disbaled to prevent any possible
delays
[18:32] <vralev> is SS7 fault-tolerant enough to keep the state active
when something like this happens in the real world?
[18:32] <baranowb> y, it will reainit
[18:32] <baranowb> alignment
[18:32] <oleg> and it makes debugging a bit difficult
[18:32] <baranowb> of link failure
[18:32] <baranowb> of = on
[18:33] <oleg> SS7 fault tolerant suppose > 1 links in up state
[18:33] <oleg> layer 4 takes first available
[18:33] <oleg> but link should be in_service
[18:34] <oleg> MTP is not involved into fault-tolerant message delivery
[18:34] <oleg> so
[18:35] <vralev> which protocol is at layer 4?
[18:35] <oleg> we are continue debug SS7 part and looks like we already
near the target
[18:35] <oleg> ISUP, SCCP, TUP
[18:35] <oleg> SCCP->TCAP-MAp
[18:35] <oleg> SCCP-TCAP-INAP
[18:36] <vralev> oh ok
[18:36] <oleg> MTP is tooo low level
[18:36] <oleg> Video:
[18:38] <oleg> we analysed current component/channel architecture with
MUX/DEMUX for multiformat data and made a decision to split multiplexed
channel into dedicated channels for each media type
[18:38] <oleg> it makes config longer but gives us several benefits in
processing and performance
[18:39] <oleg> so this issue still a blocker for next release
[18:39] <oleg> so we want to shift release date on one week
[18:40] <oleg> and try to be ready for end of next week
[18:40] <oleg> that's it for MMS
[18:41] <jeand>  #4 Diameter 1.x
[18:41] <jeand> alexandre,  ?
[18:42] <alexandre> yeah
[18:42] <alexandre> I've started to work on the HSS prototype
[18:43] <alexandre> for that, also started to port the Sh-Server to
Mobicents 2.x
[18:43] <alexandre> and not much done, should begin full speed after
JSLEE's releases which should be happening soon
[18:44] <alexandre> baranowb: anything from you?
[18:44] <baranowb> nope. tried to fix some simple issues reported bu
users as break but did not finish
[18:45] <alexandre> for the HSS prototype, I've started working on the
DB, by looking at TS's and OpenIMS DB schema
[18:46] <alexandre> after that, just need a basic service to answer the
requests, not caring for authorizations and stuff for this first
iteration
[18:46] <baranowb> cant we reuse xdm?
[18:46] <baranowb> I mean parts(might be missing some knowledge here)
[18:47] <mart1ns> wasn't supposed for you guys to sync with me on the
hss design ? :p
[18:47] <alexandre> for provisioning... maybe. the idea is that they
share same part of data, related to suer profile
[18:47] <mart1ns> not really, they sahre the data source
[18:47] <alexandre> mart1ns: just started yesterday, looking at docs and
reading old mil threads
[18:48] <mart1ns> that is the idea, converge both user data stores in
ims
[18:48] <alexandre> yes
[18:48] <mart1ns> so the network only needs a backend datasource config
( which probably is faul tolerant)
[18:49] <mart1ns> it should be pretty simple if you manage to create xsd
schemas
[18:49] <mart1ns> generate jaxb pojos
[18:49] <baranowb> schemas are in TS I think
[18:49] <mart1ns> then an sbb which listents to sh server
[18:50] <alexandre> yes
[18:50] <mart1ns> iirc the model is now very similar to xdm
[18:50] <mart1ns> you can have a sip subscribe interface
[18:50] <mart1ns> or a diameter subscribe ?!?
[18:51] <mart1ns> either way you need to know about data updates, thus
you need an RA, guess what, the xdm has it :p
[18:51] <alexandre> hmmm
[18:52] <alexandre> not sure about that. if data updates outside
diameter interface is to be notified
[18:52] <baranowb> y
[18:52] <mart1ns> I think whataver the update done, you need to notify
[18:52] <baranowb> it may be some administrative update or whatever
[18:52] <mart1ns> the subscription is on data
[18:52] <mart1ns> not interface
[18:52] <baranowb> and IMS needs to know of cahnge
[18:53] <baranowb> for instance user gets another TEL URI
[18:53] <baranowb> to which requests can be forwarded
[18:53] <baranowb> this is done by operator, not diameter I think
[18:53] <baranowb> but thats jsut a guess
[18:53] <alexandre> yeah, probably
[18:54] <alexandre> ok, so for now my idea is to migrate OpenIMS db and
to have an sbb to answer requests
[18:55] <alexandre> when we have that, we can care about other major
issues
[18:55] <jeand> ok gotta go guys
[18:55] <baranowb> dentist?
[18:55] <alexandre> and that's it from diameter
[18:55] <alexandre> lol baranowb
[18:55] <jeand> later in the evening if we talk about the same
dentist :-)
[18:57] <jeand> before leaving
[18:57] <jeand> #5 JSLEE :-)
[18:57] <jeand> mart1ns, your turn
[18:57] <mart1ns> tks jeand
[18:57] <jeand> bye guys
[18:57] <mart1ns> see you
[18:57] <alexandre> CYA
[18:58] <mart1ns> not much to report, snapshot release test happening
atm as most of you are aware
[18:58] <mart1ns> so the release festival can start in a couple hours,
tomorrow, ...
[18:59] <mart1ns> asawhagl
[18:59] <mart1ns> as soon as we have a green light
[18:59] <mart1ns> :)
[18:59] <baranowb> and documentation to come :)
[18:59] <mart1ns> regarding 1.2.7, most issues are closed or near that
status
[19:00] <mart1ns> I think it is possible to have them all closed till
the end of the week
[19:00] <mart1ns> sure, documentation will be a major part of followup
work
[19:00] <mart1ns> we all know that the code is bug free and we don't
have nothing to fix
[19:01] <mart1ns> some bad news
[19:01] <mart1ns> the jopr console won't be part of beta2
[19:02] <mart1ns> we feel it is not ready and provides added value
compared with jmx console
[19:02] <mart1ns> and does not provides ...
[19:03] <alexandre> agered
[19:03] <alexandre> *agreed.
[19:04] <mart1ns> any question?
[19:06] <mart1ns> ok
[19:06] <mart1ns> next
[19:08] <alexandre> #6 QE - SIP HA, Media Testing
[19:10] <alexandre> barreiro_
[19:10] <barreiro_> On my end been busy with JBCP patch ...
[19:11] <barreiro_> it is almost ready, and I will make the announce
today, as I already said.
[19:12] <barreiro_> other stuff included finishing the planning for
FY11, and presenting Mobicents to JBoss QA team ...
[19:13] <barreiro_> ... It was not easy to speak about everything in 40
minutes, but in the end they appreciated it, and there was also room for
a couple of questions.
[19:14] <mart1ns> audio conf?
[19:15] <barreiro_> mart1ns, yes. We do it every couple of weeks, and
there is always time to someone present some stuff that is considered
interesting to the team.
[19:16] <mart1ns> how big is the team
[19:16] <barreiro_> Jboss QA manager thought that it would be
interesting to present Mobicents to the team, so I did it.
[19:17] <barreiro_> It's around 25 people, for all jboss projects.
[19:18] <barreiro_> For next week there is jain-SLEE Beta2 coming, and I
want to put my hands on it.
[19:18] <barreiro_> And that's pretty much it from my end.
[19:18] <mart1ns> yes, give it pain
[19:18] <vralev> planning for FY11?
[19:19] <vralev> that's two yers from now :)
[19:19] <barreiro_> yep. I will brake it.
[19:20] <mart1ns> his plan is
[19:20] <mart1ns> test mobicents
[19:20] <mart1ns> test mobicents
[19:20] <barreiro_> vralev, I don't know exactly how the fiscal calendar
works, but the plan is for next year.
[19:20] <mart1ns> and test mobicents
[19:20] <mart1ns> then sometimes he also does test mobicents
[19:20] <mart1ns> :)
[19:20] <barreiro_> mart1ns, not quite ... more JBCP than mobicents ;)
[19:21] <mart1ns> right
[19:21] <vralev> yeah :) I think I will plan my FY 12 tomorow
[19:21] <mart1ns> I would like to plan FY50
[19:22] <mart1ns> still testign slee 2.x beta2
[19:22] <barreiro_> I'm not sure how many days a fiscal year is, so with
the creativity that they usually put into those things, it might
happen.

[Sachin Parnami]

>>[18:54] <alexandre> ok, so for now my idea is to migrate OpenIMS db and
to have an sbb to answer requests

Regarding HSS prototype, Do we have HSS architecture document ready, which one we are following ?
if i understand correctly, you are planning to have ?

SBB(Sh, Cx, Dx, Si)                              SBB(HSS)                            DB
             |                    Request                      |                                        |
             |---------------------------------------->  |               DB Query        |
             |                                                          |--------------------------->  |
             |                                                          |        DB Response      |
             |                                                          | <--------------------------- |
             |                     Response                  |                                        |
             |   <--------------------------------------- |                                        |

2009/11/12 Alexandre Mendonça <brai...@gmail.com>

--
Regards,
Sachin Parnami

[aayush bhatnagar]

I can think of three basic SLEE services for the HSS: one for each
external interface.

For realizing each interface we can have a service.We have three
actors here corresponding to each external interface.

1. CSCFs (I AND S-CSCF) on the Cx interface
2. SIP-Application servers on the Sh interface
3. Database (to catch document updated events)

For each interface, we can have a root SBB. The CxRootSbb can listen
to the incoming protcol events and create a child sbb
CxRequestHandlerSbb that implements the procedures on this interface.

Similarly, we can have the ShRootSbb and ShRequestHandlerSbb.

We can have a DatasourceSbb that listens to updates to the user
profile of the subscriber. Once the user profile changes, it gets a
callback from the Datasource RA (currently in the XDM Project).

Now, this sbb creates the CxRequestHandler child sbb to send out a PPR
to the S-CSCF and the ShRequestHandler child sbb to send out a SNR to
the interested SIP AS.

Let me know if it makes sense.

Regards
aayush.

--
aayush
======

[Sachin Parnami]

Exactly Aayush,
IMHO its perfectly makes sense, this is what i was thinking of ;)

--
Regards,
Sachin Parnami

[aayush bhatnagar]

Ready to rock then Sachin ??

--
aayush
======

[Sachin Parnami]

Lets Rock !!

--
Regards,
Sachin Parnami

[rajat]

I have some question.

Ques 1: Is this going to be open ims hss re-use code or build from scratch onwards ? 

Ques 2: Is it going to be build in ims oss project or mobicents project ?

[aayush bhatnagar]

Ans 1: It will be built from the scratch on the JAIN SLEE container. Open IMS HSS will only be treated as a reference implementation.

Ans 2: Mobicents as far as i think...but i am not sure about this one.

--
aayush
http://in.linkedin.com/in/abhatnagar19
======

[Alexandre Mendonça]

Hi guys,

Sorry for the lack of answers.. busy days testing SLEE 2.0 BETA2 :)

Yes, it will be built from scratch under JAIN SLEE container, Open IMS is some reference to look at in case of doubts, as any other implementation we have access to should be, such as http://code.google.com/p/hss/ :)

It will be part of Mobicents product, which IMS OSS can benefit from also, as usual :)

Regarding architecture, I agree with a service per interface but I don't see the need of child SBB's for processing requests, why not do it on the Root SBBs?

cHeerSS! =)

Alexandre Mendonça
JBoss R&D

[aayush bhatnagar]

We can do it in the root sbb's as well.

However, as some of the procedures are very elaborate with a lot of checks to perform, we will need to break them down in the form of some helper classes and delegate the procedural implementation to them.

If there are too many checks to perform (as is the case in some procedures, where DB queries are involved to post-process results in addition to business logic checks) , the root sbb can delegate to the child sbb, so that the SBB event handler returns and does not block. 

The child can then make an async callback to the parent later on.

There are some special cases (such as sending of a RTR and PPR), that I think should go in the child sbb once the parent sbb catches the event. These events are triggered by very rare administrative actions (maybe through a MBean), and not protocol events. 

Eg: provisioning of new IMPUs, or barring/unbarring of an IMPU, or HSS initiated de-registration request etc trigger PPRs and RTRs. Sometimes both have to be sent together. Also, SNRs may need to be sent here to the SIP-AS's when the profile is modified.

Just my 2 cents..

Regards

Aayush

2009/11/13 Alexandre Mendonça <brai...@gmail.com>

[aayush bhatnagar]

On second thoughts..invoking a child sbb from the parent will still be a sync call. Isn't it ? 

My bad.

[aayush bhatnagar]

Using custom events will be an overhead as well for achieving asynchronism. 

Sometimes, I delegate processing to a background worker thread to do the job managed by a thread pool, in case the processing is too time consuming.

[Bartosz Baranowski]

On Fri, Nov 13, 2009 at 5:40 PM, aayush bhatnagar <abhatnag...@gmail.com> wrote:

On second thoughts..invoking a child sbb from the parent will still be a sync call. Isn't it ? 

Y, sbb local interface call is just like a cal to pojo, but with overhad of creating sbbe. still going through docs, bit by bit. SLEE 2.x takes its toll :)

--
Bartosz Baranowski
JBoss R & D
==================================
Word of criticism meant to improve is always step forward.

[Sachin Parnami]

In that case, i guess that would be better to have them Root Sbbs. and breaking the external process in helper classes as Aayush suggested. No?
Do we have any Bottleneck here as well?

Are we going to design UML for these? or direct approach?

--
Regards,
Sachin Parnami

[Eduardo Martins]

As soon as SLEE 2.0 BETA2 is out the XDM will be migrated to JDK6 and
SLEE 1.1, the HSS can be very similar in architecture and reuse the
XDM Data RA idea. As for child sbbs, usually one starts with a single
root sbb and if it gets big or needs to be invoked sync by another sbb
then childs are created, in this case I don't see any reason (yet) to
use childs.

-- Eduardo