Mobicents meeting notes; November 18, 2009
4 views
Skip to first unread message
Ivelin Ivanov
Nov 18, 2009, 4:01:21 PM11/18/09
to mobicents-public
Attendees:
Alex, Bartek, Eduardo, Luis, Jean, Pavel, Vladimir, Ivelin
Summary:
#1 JBCP 1.2.2 release: Top priority for everyone; Must release by
end of November. Currently blocked on MSS 1.1. and JSLEE 1.2.7. Both
components targeted for release by Tuesday, November 24
#2 QE plan for 1.2.2: Luis will upload document to intranet and link
to the Product Release doc
#3 MSS 1.1: bug fixes and HA work; code freeze by tomorrow for
release on Tuesday; converged load balancer advanced - produces 600cps
and up to 300 http requests per second
#4 MMS 2.0: SS7 works well with JNI and native Unix IO code; Oleg
will contact OpenJDK team to discuss possible solution that will
remove MMS dep on native code; Making progress with Video; aiming for
November 30 release
#5 JSLEE 2.0: First beta going out today; HA infrastructure present
to cover broad spectrum of cases; will leverage MSS SIP HA test
framework for broad coverage
#6 Diameter: design phase for HSS; still converting RAs to JSLEE
2.0; no new requests for Diameter apps
Log:
----------
<ivelin> #1 JBCP 1.2.2 release
<ivelin> #2 QE plan for 1.2.2.
<ivelin> #3 MSS 1.2
<ivelin> #4 MMS 2.0
<ivelin> #5 JSLEE 2.0
<ivelin> #6 Diameter
<ivelin> what else?
<baranowb> Docs update?
* Received a CTCP VERSION from freenode-connect
* #mobicents :[freenode-info] help freenode weed out clonebots,
please register your IRC nick and auto-identify:
http://freenode.net/faq.shtml#nicksetup
<baranowb> hmm, but noone is here
<jeand> #3 MSS 1.1 not 1.2
<baranowb> Amit wont make it
<ivelin> oops
<ivelin> is he OK?
<baranowb> y, power cuts
<ivelin> ah ok
<ivelin> lets start then
<ivelin> Pavel, what is the chance that we get 1.2.2. in the next week
<jeand> ivelin I guess that's not possible since MSS 1.1 is not out yet
* slegrik (n=sle...@186.136.broadband9.iol.cz) has left #mobicents
<ivelin> what else is blocking 1.2.2?
* slegrik2 (n=sleg...@186.136.broadband9.iol.cz) has joined #mobicents
<slegrik2> sorry,
<slegrik2> well, we are waiting for MSS 1.1 and slee 1.2.7 still
<slegrik2> Jeand, martins what is the state of those modules ?
<mart1ns> 1.2.7 goes out in the next few days
<jeand> I'm for starting the QA process of MSS at the end of the week
<jeand> we should have fixed all bugs
<slegrik2> well for the productization, it will take about 2-3 days
to pass to QA
<slegrik2> then we need tests Luis makes it aprox in 3-5 days
<jeand> this will be QA process within MSS team to make sure all
examples work OK and HA as well
<jeand> then pass it over to Luis
<slegrik2> ivelin, I am notoptimistic about having 1.2.2 ready by
next week - we can try at least !
<barreiro> slegrik2, QA in 3 to 5 days is very optimistic.
<ivelin> lets tighten this up
<slegrik2> barreiro, I know
<ivelin> there are two large contracts on the line for this release
<jeand> in being optimistic I can get MSS 1.1 out next week
<ivelin> Eduardo, what's outstanding for JSLEE 1.2.7?
<mart1ns> a few bug fixes
<slegrik2> jeand, Monday ?
<jeand> end of next week
<jeand> or middle of next week
<jeand> let's say Tuesday morning
<jeand> all new bugs found against MSS will go into MSS 1.2 from now on
<mart1ns> jeand getting ready for a busy weekend :)
<slegrik2> mart1ns, is slee 1.2.7 going to be ready by Tuesay morning ?
<mart1ns> yes, can be
<jeand> mart1ns, yeah the weekdays are not enough for me
<jeand> I'll try to break the record of working hours in a single week :-)
<mart1ns> slegrik2, yes can be
<ivelin> so Tuesday, November 24, release for JSLEE and MSS?
* alexandrem (n=brai...@a85-138-27-15.cpe.netcabo.pt) has joined #mobicents
<slegrik2> ivelin, if we have both ready on Tuesday morning then I
will start working on the jbcp 1.2.2 straingt forward - estimating to
pass QA by Wednesday evening my local time, so LUis can start right
away
<jeand> ivelin, we will do our best so that it happens
<slegrik2> barreiro, what is your estimation ?
<slegrik2> barreiro, are you able to make the testing faster, even
before next weekend ?
<barreiro> 7 to 10 days.
<slegrik2> barreiro - 3 days - Wednesday - Friday ?
<barreiro> the only way to test faster is to test less.
<jeand> barreiro, just remove the first 7 days and it fits :-)
<slegrik2> barreiro, not good to test less
<jeand> yeah QA on HA is very important a customer contract depends on it
<slegrik2> guys, I will count on Tuesday next week MSS 1.1 and slee
1.2.7 are ready - deal ?
<jeand> oops I wanted to say Thursday morning, I guess it's too late
<mart1ns> how much is the bride
<jeand> I always confuse one ofr the other
<mart1ns> jeand, I had that fealing
<mart1ns> feeling
<mart1ns> since tuesday morning is far from middle of the week
<mart1ns> ;)
<jeand> yes indeed
<ivelin> let's prepare properly for a good Christmas
<ivelin> 1.2.2 is now a top priority for everyone, right?
<slegrik2> ivelin, for sure
<jeand> right
<ivelin> if anyone is working on things different than 1.2.2 an can
help with it, please raise hand
<ivelin> next topic
<baranowb> QE
<baranowb> #2 QW
<baranowb> #3 MSS 1.1
<baranowb> sorry
<jeand> ok more MSS bugs
<jeand> + JSIP bugs
<ivelin> #2 QE for 1.2.2.
<barreiro> ok, so on QA the last week, there were some trouble with
the JBCP patch ...
<ivelin> Luis where is the updated test plan for it?
<barreiro> ... although I run some extra tests on B2B Ua scenario,
client says that there is still a leak.
<barreiro> I have things planned for next year, including a details
on what should be covered.
<ivelin> ok, lets focus on 1.2.2. That is my question.
<barreiro> That can't be put in practice in this release, but can be adapted.
<ivelin> where is the test plan document?
<barreiro> it's not public. I can send it to you.
<jeand> barreiro, the leak was for HTTP converged session
<jeand> that were not being cleaned up correctly, a ref was still
present in a threadlocal
<barreiro> jeand, our fault or theirs ?
<jeand> ours
<jeand> but the fix should have fixed that
<ivelin> not even on the intranet?
<ivelin> it should be linked off of the product plan?
<barreiro> ok, let's discuss offline how can we test that.
<jeand> barreiro, ok
<ivelin> Pavel, where was the product plan for 1.2.2?
<slegrik2> let me send it to you
<barreiro> ivelin, it's not on intranet ... not yet.
<ivelin> ok, Luis, please put it on the intranet today. Give
everyone a chance to review and comment so nothing big is missed in
the QE cycle
<ivelin> 1.2.2 will be around for some time
<ivelin> since we are then switching to 2.0
<barreiro> ok.
<ivelin> ok, thanks.
<ivelin> Next topic
<ivelin> unless you have anything to add for QE
<jeand> ok more MSS bugs + JSIP bugs +customer prob investigation
<jeand> thre is one bug pending to pass the TCK
<jeand> that should be fixed by tomorrow evening
<jeand> and then full throttle on testing MSS 1.1
<jeand> for release
<jeand> so code freeze tomorrow evening
<ivelin> sounds like a good plan
<ivelin> next?
<ivelin> #4 MMS ?
<oleg> ok
<baranowb> y
<ivelin> do we have a set release for JBCP 1.2.2.
<oleg> we did not change 1.x
<oleg> so it is ready for 1.2.2
<oleg> for 2.0 we have good news with SS7 - link is now in service and stable
<oleg> still small unhandled errors wich we can catch and fix in the feature
<jeand> oleg, JSIP changed
<jeand> can it be handled manually without re releasing MSS 1;X ?
<oleg> Jean, yes
<oleg> for video we hit on smal problem with AMR codec which we never
used before
<oleg> it is because 3gp files ussualy contains audio encoded with AMR
<oleg> and no one from us know clearly how to synchronize it with video sream
<oleg> the file contains track for sampling and we now working on
interpretation of hint tracks
<ivelin> on SS7 - is the link over JNI. CAn you tell us just a bit
more about the solution
<oleg> in addition we agreed to split audio and video channels
instead of using mux/demux. This part of work mostly completed
<oleg> yes, we use JNI for access card
<oleg> native code is used for read and write only
<oleg> it seems that native is only one working way
<oleg> because when we are using java.io it blocks for reading for 128ms always
<oleg> and data received is partially corrupted
<baranowb> or out of sync
<oleg> native code very simple
<oleg> no any specific dependencies
<oleg> standrd io only
<ivelin> so it it should work on RHEL and Solaris?
<oleg> yes
<vralev> you will still have to make separate build for 64bit/solaris etc
<oleg> Vlad yes
<oleg> but code is simple so I do not think that comipling on Solaris
will be difficult
<oleg> guys, I think we should not shy JNI in case of SS7
<oleg> because SS7 is very specific
<oleg> and mms plays a role of gateway
<oleg> for signaling and voice
<oleg> all custom logic still pure Java on SLEE or SIPs
<ivelin> you know that Red Hat is now active player in Open JDK
<ivelin> do you want to talk to some of the Open JDK folks to see if
they can help?
<oleg> interested
<oleg> we shoud try
<slegrik2> Oleg, ping pavel Tisnovsky, he is one of the folks I think
QA for Open JDK - in Brno
<oleg> ok, thanx Pavel
<ivelin> cool. would be great if there is a way to work this through
Open JDK so we don't have to test many different builds
<ivelin> what else is new Oleg?
<oleg> as I said we working on interpretation of AMR tracks
<oleg> and splitting voice/video inside mms
<oleg> this part ready
<ivelin> what's left before release?
<oleg> only AMR sampling remains
<vralev> is it just sampling or there is some math to be done in AMR?
<ivelin> what is AMR?
<oleg> AMR - audio codec
<oleg> Vlad, we need to corectly split raw bytes into packets using hint track
<oleg> it is a bit different structure then wav
<oleg> but I think we can complete it in two days
<vralev> right, but after that there is some decompression algorithm?
<oleg> and also we need to perform sst test for upper layers - cammel
<oleg> Vlad, depends from sink
<oleg> if it supports comoressed audio (will decompress it localy) or
just forward to somewhere else
<oleg> we do not need decompression
<vralev> oh ok
<oleg> for example for RTP transmission we shoudn't
<oleg> but in common case of cource we need this codec
<oleg> but this is later
<oleg> so
<oleg> looks like we can complete all targets for this releas
<oleg> and one week for example tests
<vralev> actually i just looked at
http://en.wikipedia.org/wiki/Adaptive_Multi-Rate so it's not that
simple
<vralev> there is math involved ACELP stuff like g729
<vralev> might be hard to decode
<oleg> yes, it differs from codecs like g711
<oleg> and it is not a good thing to show video without voice in demo
<oleg> release date:
<oleg> next try for Nov, 30
<ivelin> that's right. Video only will be silly
<oleg> forget, Bartek archived <3% of cpu utilization for ss7 so it
give us change to handle several links
<ivelin> AMR is the codec usually used for voice with video?
<ivelin> nice
<jeand> depends to what you want to do with video there is some usage
where you don't want to care about the voice :-)
<ivelin> how can we test ss7 in QE?
<ivelin> lol
<oleg> Ivelin, AMR is moden codec for voice but 3gp files usualy
conatins it with video
<oleg> :) can we use such video for demo?
<vralev> it also says it's patented, not good
<baranowb> well, maybe emulate security app
<baranowb> whichii shows CCR feed
<baranowb> or make mms say: this is feed from corner of X and Y
<baranowb> bla bla and show video
<vralev> ah decoding is free
<mart1ns> brb
<oleg> I think we have learn how to transmitt it
<oleg> and leave decoding for end user terminal
<ivelin> lets take this offline
<ivelin> is there anything else on MMS?
<oleg> nope
<oleg> that's it
<oleg> sorry missed question about ss7 test in QE
<ivelin> is there a way to do that?
<ivelin> other than having access to MCS at a telco?
<oleg> partialy it is possible with local loop
<oleg> test machine should be equiped with ss7 card and two ports
joined between each other
<mart1ns> back
<ivelin> ok, this is something that can be tried. We need a SS7 card
and a Server for Luis
<ivelin> SS7 testing is not a priority yet, but it will be soon
<ivelin> let's move on
<ivelin> #5 JSLEE 2.0
<mart1ns> finished uploading to source forge, will do the
announcement in the next hour
<alexandrem> hurray :)
<mart1ns> from the announcement release notes
<mart1ns> First an overview of the changes in the container core,
where this release introduces clustering,
<mart1ns> be it simple high availability or full state replication,
including fault tolerant timers. The container
<mart1ns> also exposes a simple API for Fault Tolerant Resources
Adaptors, which may need to replicate
<mart1ns> and/or fail over their own data in the cluster. Also in the
same matter, there are different flavors for
<mart1ns> JAIN SLEE Profiles and Usage Parameters clustering, which
can be configured to be completely
<mart1ns> local or shared by all cluster nodes (requires external
database for profiles).
<mart1ns> With respect to included Resource Adaptors, the SIP one has
been completely reworked,
<mart1ns> it is now way faster (about 2x), and provides established
dialogs fail over. New in this release are
<mart1ns> the Diameter Base, Diameter Cca, Diameter sh Client, Http
Servlet, Http Client, MGCP, SMPP and
<mart1ns> XMPP Resource Adaptors, migrated and enhanced from
Mobicents JAIN SLEE 1.2.
<mart1ns> This release also now includes a well known example, Google
Talk Bot, which was migrated fro
<mart1ns> Mobicents JAIN SLEE 1.2.
<mart1ns> sorry, the irc client removed formatting
<alexandrem> nice :) you can say that more examples are available in
the svn tree :)
<ivelin> there were some issues with clustering
<ivelin> are the basic use cases tested now?
<mart1ns> we tested timers fail over
<mart1ns> and simple call setup failover
<mart1ns> there are many other cases needed to be tested, around b2bua
<mart1ns> but we had no time to setup such scripts
<jeand> mart1ns, nice
<ivelin> I imagine a lot of the test cases for MSS can be reused
<ivelin> is this happening?
<mart1ns> I'm not aware of those test cases, I guess we need to
converge and work togheter on it
<jeand> yeah we have a handful of scripts
<jeand> testing uas, uac, proxy, b2bua and c2c
<vralev> the sipp scripts can be reused, but someone must write the SLEE apps
<mart1ns> ok, will open an issue for it
<mart1ns> all those scripts are for established dialogs fail over?
<jeand> correct
<jeand> but there is a manual intervention to test the failover
<jeand> ie stopping the server at the right time
<mart1ns> ok
<mart1ns> that is acceptable
<jeand> if we could automate that, that would be even better, ie
reuse the smartfrog thingie maybe
<vralev> you also need the balancer running though
<vralev> do you use the balancer now>
<jeand> hum right
<jeand> vralev, vralev not sure because the release was done before the CL fix
<jeand> to ha core
<vralev> I forgot to update you on the balancer BTW, I will do at the end
<jeand> for accessing the LB
<vralev> yeah
<mart1ns> I redid the release
<mart1ns> of jsip ha and the sip ra
<jeand> oh so there is a new snapshot of jain sip ha ?
<vralev> good then
<jeand> still 1.1-SNAPSHOT ?
<mart1ns> y
<mart1ns> 0.2
<jeand> cool then that should
<jeand> work then
<jeand> so trunk is at 0.3 now ?
<jeand> 0.3-SNAPSHOT ?
<mart1ns> I redid the 0.1 release, and after I restored 0.2-SNAPSHOT,
pointing to the current parent sapshot and balancer 1.0.BETA9-SNAPSHOT
<mart1ns> full service :)
<ivelin> :)
<ivelin> next/
<ivelin> #6 Diameter
<jeand> :-)
<alexandrem> We are currently in requirements gathering for both HSS
and Web Services support for Diameter next release
<alexandrem> We've already ported the Sh Server RA to SLEE 2.x and
Cx/Dx is almost done too
<alexandrem> but after some discussion on the mailing list regarding HSS
<alexandrem> it showed up that we could benefit from XDM, as there's
some very similar behavior between it and the diameter profile update
noftification
<baranowb> generaly xml data handling :)
<alexandrem> so we may postpone it for a month or so, to do some work
together with Eduardo, as he's porting presence to 2.x too after the
SLEE's releases, I think
<mart1ns> y, right after my 1.2.7 issues are clear
<mart1ns> will focus on presence beta 6
<alexandrem> so we can both benefit from it, hopefully and do some
more work with integration between both in mind
<mart1ns> the sh server is in the svn already ?
<ivelin> why beta 6, instead of 1.0.gA?
<alexandrem> no, was waiting for you to finish release, so it won't
make any damage :)
<ivelin> for presence
<ivelin> the HSS and XDM synergy make sense
<mart1ns> actaully now I'm not sure it is beta6 or cr1
<mart1ns> let me check the roadmap
<jeand> if you move everything to SLEE 2.0 it should be another beta
<jeand> no ?
<ivelin> right, but then it should be a different release number
<ivelin> so we can maintain users on 1.x
<mart1ns> well, a CR may be seen as the last beta
<ivelin> while pushing the 2.x code base forward
<mart1ns> ivelin, the changes needed are minimal and will actually
simplify a lot the presence server, also being heavy processing apps
(sip subscriptions handling + db) its migration is almost mandatory to
achieve acceptable performance
<mart1ns> since the scheduled ga is right after slee 2 ga
<mart1ns> it sounds easier if we keep a single branch
<jeand> it was tech preview until now so I don't think that's a big
deal neither
<mart1ns> y
<mart1ns> also, from 1.2 experience
<mart1ns> presence servers push the limits of slee
<mart1ns> and bring up all the issues that may exist :)
<jeand> I would do another beta though
<mart1ns> not sure, maybe a cr1, and if something is wrong a cr2
<mart1ns> these are the last functionalities for 1.0
<mart1ns> if it becomes stable then the CR will become a waste of time
<mart1ns> and between another beta and a cr, I would really prefer the cr
<jeand> makes sense
<slegrik2> guys I gotta go, cat
<slegrik2> catch up later
<ivelin> thanks, Pavel
<mart1ns> have a nice trip back home, in the cool train
<slegrik2> bye
<ivelin> back to Diameter
<alexandrem> ok
<ivelin> do we have features planned for the Diameter RAs or stack itself
<ivelin> I haven't seen requests for new Diameter apps
<alexandrem> yes, we already cover all the most wanted ones
<alexandrem> so far the roadmap is still valid:
http://groups.google.com/group/mobicents-public/web/mobicents-diameter-roadmap
<alexandrem> stack and RAs seem stable, so nothing major to update,
except for some performance improvements and LB/HA features
<ivelin> The Ro/Rf examples are still red for the August release :)
<alexandrem> oops :)
<alexandrem> that's something to be fixed
<alexandrem> regarding the webservices which will be the major new
feature for next release
<alexandrem> we will start with Sh support
<alexandrem> and possibly try to include Rf too, depends on how it goes with Sh
<alexandrem> the idea would be to just provide server endpoint, but
as we need to test it... we'd need to make the client side too, for
showing it
<alexandrem> will provide the general ideas and architecture this week
<mart1ns> ivelin, where did this idea of proprietary WS interface came from?
<baranowb> aayush or some user
<baranowb> Alex we will have to have tests for HSS also
<baranowb> so we can reuse them for WS
<jeand> guys gotta go
<alexandrem> yeah, martins doesnt agree much with it, it seems :)
<mart1ns> HSS has not such interface
<mart1ns> alexandrem, I may digest it, but not as a major feature
<baranowb> y, I dont like it either as it is more like app not a standard
<alexandrem> mart1ns: it can have.. just be creative :)
<baranowb> standard is diam over byte stream :)
<jeand> later guys
<baranowb> cya
<mart1ns> HSS may take advantage of WS provisioning, but that is
nothing related with diameter
<mart1ns> and with an external sql db behind, not much need imho
<mart1ns> alexandrem, you can add whatever proprietary interfaces to it
<mart1ns> but it must be so desirable that customers will trade specs for it
<alexandrem> webservice are good for better and easier integrations
with 3rd party
<mart1ns> and that is where my truly doubts stand
<mart1ns> I have a very different opinion :p
<mart1ns> IMS already has the needed protocols
<mart1ns> no need for other proprietary ones
<mart1ns> unless they bring something new to the table
<mart1ns> that will later be adopted
<mart1ns> but sorry, imho this doesn't seem the case
<mart1ns> I'm fine with it, but don't make a release depend on it as
a major functionality
<alexandrem> well, as I have said, it can simplify a lot, when u can
say start_accounting(user, tariff) rather than creating a full
diameter message
<alexandrem> which the WS interface could hide
<mart1ns> well, tell the IMS boys to replace everything with WS
<mart1ns> lol :)
<baranowb> but tarrif is app specific, thats why there is so many
avps to describe it
<mart1ns> anyway, for apps
<mart1ns> the diameter interface
<mart1ns> is the same
<alexandrem> baranowb: a couple of them needed to specify that
<mart1ns> correct?
<mart1ns> so send them by diameter or ws is the same
<alexandrem> we may provide both raw diameter methods or methods for
simplifying it
<mart1ns> how it makes it simpler
<mart1ns> now that is a major feature, make an easier interface
<mart1ns> but with diameter behind
<baranowb> maybe, Im still not convinced and imho Ws should go only
after HSS B1 :)
<mart1ns> WS won't by any way make a simpler API
<mart1ns> the apps don't work with diameter transport details
<mart1ns> so to my eyes it is just a different API
<mart1ns> which can be done with diameter behind
<mart1ns> and like I said, that would be a major feature
<mart1ns> a child sbb for slee, a sync class for servlets
<alexandrem> and why not to make it on WS too?
<mart1ns> because the network uses diameter in specs
<alexandrem> it'd be good for anything else but WS ? :)
<mart1ns> you will need to have another proprietary endpoint
<mart1ns> in the other side
<alexandrem> it's a client, may be anything
<mart1ns> that is not good for a standard network
<mart1ns> imho nobody will care to implement it
<mart1ns> because they can't switch vendor
<mart1ns> and functionality is the same
<mart1ns> so resuming
<mart1ns> no added value
<mart1ns> proprietary
<mart1ns> do you think you can convince a costumer to use it instead
of pure diameter (with or whitout better api frontend)
<mart1ns> how would you justify it
<mart1ns> to lock in a vendor
<mart1ns> it is evrything they have been trying to get away :)
<alexandrem> mart1ns: but if they want it, they can have it.. also WS
is useful for bypassing gateways or firewalls, since HTTP protocol is
usually unrestricted, something that diameter may have issues with
<mart1ns> I find it hard to believe that someone will deploy a
firewall that blocks diameter
<vralev> IMO most users of the WS API would be the ppl who want
everything on HTTP and SIP, they dont want other sockets open, and
they might have constaints on opening sockets
<mart1ns> in an IMS network
<alexandrem> there are customers that'd like it probably, webservices
are widely used
<alexandrem> vralev: yes, exactly
<mart1ns> it is core protocol
<vralev> and WS is not exactly adopting proprietary stuff, there is SOA :)
<alexandrem> everything through the same "channel"
<mart1ns> vralev, sorry, it is vendor lock in, can't have app portability
<baranowb> and IMO its very doubtfull that diameter will be exposed freely
<baranowb> cmon, it deals with $$$$$
<mart1ns> for a core protocol of the business
<mart1ns> but like I said plenty of times
<mart1ns> it can be done
<mart1ns> but hard to justify
<alexandrem> mart1ns: there are the weirdest use cases out there...
this isn't the worst :)
<mart1ns> it is when you say it is a major feature
<mart1ns> hehe
<alexandrem> we get a common interface, easily extended...
<alexandrem> I said it's the major feature for this release
<mart1ns> well, nothing seems to be stopping you
<mart1ns> and you seem to like the idea
<mart1ns> so why not :)
<vralev> mart1ns: you can have app portability, WS are composable
with those orchestration engines
<vralev> if someone has different WS API he doesnt change his
original app, he writes the transform
<mart1ns> how so, this is the app communicating with the diameter server
<vralev> there are huge businesses based on that thing
<mart1ns> what other HSS or diameter server would understand it
<alexandrem> I dont even like WS's they are slow.. at least from my
experience :)
<mart1ns> sure, business
<mart1ns> not diameter
<vralev> tibco, etc
<alexandrem> but I can admit it can be handy and usable
<mart1ns> it is not even slow
<mart1ns> perf has been greatly enhanced
<mart1ns> last years
<alexandrem> I believe so
<alexandrem> but I always got that feeling...
<mart1ns> for instance
<mart1ns> consider the Mobicents HSS would expose such interface
<alexandrem> and the first message.. seems to take seconds to be
delivered, maybe that's old issues...
<mart1ns> and you are developing a app that uses diameter sh
<mart1ns> would you do it with diameter sh
<mart1ns> or do it with a proprietary ws
<alexandrem> well.. if the ws development would take 2 days, against
2months to learn the details and behaviors of diameter...
<mart1ns> well, at least look at parlay
<mart1ns> what? lol
<mart1ns> don't bring the easy to use api again
<mart1ns> that has nothing to do with diameter or ws
<alexandrem> it's obvious pure diameter would always be the BEST solution
<mart1ns> the ws invocation would still need a diameter msg inside
<alexandrem> but WS may be the easiest and at some scenarios, the only :)
<mart1ns> how so
<mart1ns> the only usage referenced here was the one from vlad
<mart1ns> but imho a telco app that has no access to diameter has
very limited value
<mart1ns> anyway, look at parlay x
<mart1ns> maybe they already provide this
<mart1ns> and that is a standard
<mart1ns> for anyone missing the details, parlay x provides telco app
apis through web services
<mart1ns> for everything an app needs to interact with the network
<mart1ns> sound incomplete if there is no accounting or user profile
<alexandrem> will check it
<mart1ns> need to go guys, good chat
<alexandrem> thanks :)
<mart1ns> ivelin ivelin ivelin ivelin ivelin ivelin
<vralev> let me update you about the balancer, it seems stable right
now - tests of a single balancer on latop show 600-700 cps for SIP
UAS, 300-900 jboss AS homepage loads for integrated HTTP forwarder (AS
CPU utilization limits the test), comet HTTP works flawlessly (this
very chat app was used in the test). The only lost calls are caused
by some probems in Sip Servlets with retransmissions, but those are
now eliminated.
<mart1ns> cool
<mart1ns> we can chat later, need to go now
<mart1ns> bye all
<vralev> ok also balancer docs are updated in the docbook
<vralev> they are mostly container neutral, but need to be reviewed
bu Jared, I sent him some notes
* oleg has quit ("Java user signed off")
<ivelin> I got pulled out at 12, right before the end of the chat
<ivelin> Vladimir, still on?
Alex, Bartek, Eduardo, Luis, Jean, Pavel, Vladimir, Ivelin
Summary:
#1 JBCP 1.2.2 release: Top priority for everyone; Must release by
end of November. Currently blocked on MSS 1.1. and JSLEE 1.2.7. Both
components targeted for release by Tuesday, November 24
#2 QE plan for 1.2.2: Luis will upload document to intranet and link
to the Product Release doc
#3 MSS 1.1: bug fixes and HA work; code freeze by tomorrow for
release on Tuesday; converged load balancer advanced - produces 600cps
and up to 300 http requests per second
#4 MMS 2.0: SS7 works well with JNI and native Unix IO code; Oleg
will contact OpenJDK team to discuss possible solution that will
remove MMS dep on native code; Making progress with Video; aiming for
November 30 release
#5 JSLEE 2.0: First beta going out today; HA infrastructure present
to cover broad spectrum of cases; will leverage MSS SIP HA test
framework for broad coverage
#6 Diameter: design phase for HSS; still converting RAs to JSLEE
2.0; no new requests for Diameter apps
Log:
----------
<ivelin> #1 JBCP 1.2.2 release
<ivelin> #2 QE plan for 1.2.2.
<ivelin> #3 MSS 1.2
<ivelin> #4 MMS 2.0
<ivelin> #5 JSLEE 2.0
<ivelin> #6 Diameter
<ivelin> what else?
<baranowb> Docs update?
* Received a CTCP VERSION from freenode-connect
* #mobicents :[freenode-info] help freenode weed out clonebots,
please register your IRC nick and auto-identify:
http://freenode.net/faq.shtml#nicksetup
<baranowb> hmm, but noone is here
<jeand> #3 MSS 1.1 not 1.2
<baranowb> Amit wont make it
<ivelin> oops
<ivelin> is he OK?
<baranowb> y, power cuts
<ivelin> ah ok
<ivelin> lets start then
<ivelin> Pavel, what is the chance that we get 1.2.2. in the next week
<jeand> ivelin I guess that's not possible since MSS 1.1 is not out yet
* slegrik (n=sle...@186.136.broadband9.iol.cz) has left #mobicents
<ivelin> what else is blocking 1.2.2?
* slegrik2 (n=sleg...@186.136.broadband9.iol.cz) has joined #mobicents
<slegrik2> sorry,
<slegrik2> well, we are waiting for MSS 1.1 and slee 1.2.7 still
<slegrik2> Jeand, martins what is the state of those modules ?
<mart1ns> 1.2.7 goes out in the next few days
<jeand> I'm for starting the QA process of MSS at the end of the week
<jeand> we should have fixed all bugs
<slegrik2> well for the productization, it will take about 2-3 days
to pass to QA
<slegrik2> then we need tests Luis makes it aprox in 3-5 days
<jeand> this will be QA process within MSS team to make sure all
examples work OK and HA as well
<jeand> then pass it over to Luis
<slegrik2> ivelin, I am notoptimistic about having 1.2.2 ready by
next week - we can try at least !
<barreiro> slegrik2, QA in 3 to 5 days is very optimistic.
<ivelin> lets tighten this up
<slegrik2> barreiro, I know
<ivelin> there are two large contracts on the line for this release
<jeand> in being optimistic I can get MSS 1.1 out next week
<ivelin> Eduardo, what's outstanding for JSLEE 1.2.7?
<mart1ns> a few bug fixes
<slegrik2> jeand, Monday ?
<jeand> end of next week
<jeand> or middle of next week
<jeand> let's say Tuesday morning
<jeand> all new bugs found against MSS will go into MSS 1.2 from now on
<mart1ns> jeand getting ready for a busy weekend :)
<slegrik2> mart1ns, is slee 1.2.7 going to be ready by Tuesay morning ?
<mart1ns> yes, can be
<jeand> mart1ns, yeah the weekdays are not enough for me
<jeand> I'll try to break the record of working hours in a single week :-)
<mart1ns> slegrik2, yes can be
<ivelin> so Tuesday, November 24, release for JSLEE and MSS?
* alexandrem (n=brai...@a85-138-27-15.cpe.netcabo.pt) has joined #mobicents
<slegrik2> ivelin, if we have both ready on Tuesday morning then I
will start working on the jbcp 1.2.2 straingt forward - estimating to
pass QA by Wednesday evening my local time, so LUis can start right
away
<jeand> ivelin, we will do our best so that it happens
<slegrik2> barreiro, what is your estimation ?
<slegrik2> barreiro, are you able to make the testing faster, even
before next weekend ?
<barreiro> 7 to 10 days.
<slegrik2> barreiro - 3 days - Wednesday - Friday ?
<barreiro> the only way to test faster is to test less.
<jeand> barreiro, just remove the first 7 days and it fits :-)
<slegrik2> barreiro, not good to test less
<jeand> yeah QA on HA is very important a customer contract depends on it
<slegrik2> guys, I will count on Tuesday next week MSS 1.1 and slee
1.2.7 are ready - deal ?
<jeand> oops I wanted to say Thursday morning, I guess it's too late
<mart1ns> how much is the bride
<jeand> I always confuse one ofr the other
<mart1ns> jeand, I had that fealing
<mart1ns> feeling
<mart1ns> since tuesday morning is far from middle of the week
<mart1ns> ;)
<jeand> yes indeed
<ivelin> let's prepare properly for a good Christmas
<ivelin> 1.2.2 is now a top priority for everyone, right?
<slegrik2> ivelin, for sure
<jeand> right
<ivelin> if anyone is working on things different than 1.2.2 an can
help with it, please raise hand
<ivelin> next topic
<baranowb> QE
<baranowb> #2 QW
<baranowb> #3 MSS 1.1
<baranowb> sorry
<jeand> ok more MSS bugs
<jeand> + JSIP bugs
<ivelin> #2 QE for 1.2.2.
<barreiro> ok, so on QA the last week, there were some trouble with
the JBCP patch ...
<ivelin> Luis where is the updated test plan for it?
<barreiro> ... although I run some extra tests on B2B Ua scenario,
client says that there is still a leak.
<barreiro> I have things planned for next year, including a details
on what should be covered.
<ivelin> ok, lets focus on 1.2.2. That is my question.
<barreiro> That can't be put in practice in this release, but can be adapted.
<ivelin> where is the test plan document?
<barreiro> it's not public. I can send it to you.
<jeand> barreiro, the leak was for HTTP converged session
<jeand> that were not being cleaned up correctly, a ref was still
present in a threadlocal
<barreiro> jeand, our fault or theirs ?
<jeand> ours
<jeand> but the fix should have fixed that
<ivelin> not even on the intranet?
<ivelin> it should be linked off of the product plan?
<barreiro> ok, let's discuss offline how can we test that.
<jeand> barreiro, ok
<ivelin> Pavel, where was the product plan for 1.2.2?
<slegrik2> let me send it to you
<barreiro> ivelin, it's not on intranet ... not yet.
<ivelin> ok, Luis, please put it on the intranet today. Give
everyone a chance to review and comment so nothing big is missed in
the QE cycle
<ivelin> 1.2.2 will be around for some time
<ivelin> since we are then switching to 2.0
<barreiro> ok.
<ivelin> ok, thanks.
<ivelin> Next topic
<ivelin> unless you have anything to add for QE
<jeand> ok more MSS bugs + JSIP bugs +customer prob investigation
<jeand> thre is one bug pending to pass the TCK
<jeand> that should be fixed by tomorrow evening
<jeand> and then full throttle on testing MSS 1.1
<jeand> for release
<jeand> so code freeze tomorrow evening
<ivelin> sounds like a good plan
<ivelin> next?
<ivelin> #4 MMS ?
<oleg> ok
<baranowb> y
<ivelin> do we have a set release for JBCP 1.2.2.
<oleg> we did not change 1.x
<oleg> so it is ready for 1.2.2
<oleg> for 2.0 we have good news with SS7 - link is now in service and stable
<oleg> still small unhandled errors wich we can catch and fix in the feature
<jeand> oleg, JSIP changed
<jeand> can it be handled manually without re releasing MSS 1;X ?
<oleg> Jean, yes
<oleg> for video we hit on smal problem with AMR codec which we never
used before
<oleg> it is because 3gp files ussualy contains audio encoded with AMR
<oleg> and no one from us know clearly how to synchronize it with video sream
<oleg> the file contains track for sampling and we now working on
interpretation of hint tracks
<ivelin> on SS7 - is the link over JNI. CAn you tell us just a bit
more about the solution
<oleg> in addition we agreed to split audio and video channels
instead of using mux/demux. This part of work mostly completed
<oleg> yes, we use JNI for access card
<oleg> native code is used for read and write only
<oleg> it seems that native is only one working way
<oleg> because when we are using java.io it blocks for reading for 128ms always
<oleg> and data received is partially corrupted
<baranowb> or out of sync
<oleg> native code very simple
<oleg> no any specific dependencies
<oleg> standrd io only
<ivelin> so it it should work on RHEL and Solaris?
<oleg> yes
<vralev> you will still have to make separate build for 64bit/solaris etc
<oleg> Vlad yes
<oleg> but code is simple so I do not think that comipling on Solaris
will be difficult
<oleg> guys, I think we should not shy JNI in case of SS7
<oleg> because SS7 is very specific
<oleg> and mms plays a role of gateway
<oleg> for signaling and voice
<oleg> all custom logic still pure Java on SLEE or SIPs
<ivelin> you know that Red Hat is now active player in Open JDK
<ivelin> do you want to talk to some of the Open JDK folks to see if
they can help?
<oleg> interested
<oleg> we shoud try
<slegrik2> Oleg, ping pavel Tisnovsky, he is one of the folks I think
QA for Open JDK - in Brno
<oleg> ok, thanx Pavel
<ivelin> cool. would be great if there is a way to work this through
Open JDK so we don't have to test many different builds
<ivelin> what else is new Oleg?
<oleg> as I said we working on interpretation of AMR tracks
<oleg> and splitting voice/video inside mms
<oleg> this part ready
<ivelin> what's left before release?
<oleg> only AMR sampling remains
<vralev> is it just sampling or there is some math to be done in AMR?
<ivelin> what is AMR?
<oleg> AMR - audio codec
<oleg> Vlad, we need to corectly split raw bytes into packets using hint track
<oleg> it is a bit different structure then wav
<oleg> but I think we can complete it in two days
<vralev> right, but after that there is some decompression algorithm?
<oleg> and also we need to perform sst test for upper layers - cammel
<oleg> Vlad, depends from sink
<oleg> if it supports comoressed audio (will decompress it localy) or
just forward to somewhere else
<oleg> we do not need decompression
<vralev> oh ok
<oleg> for example for RTP transmission we shoudn't
<oleg> but in common case of cource we need this codec
<oleg> but this is later
<oleg> so
<oleg> looks like we can complete all targets for this releas
<oleg> and one week for example tests
<vralev> actually i just looked at
http://en.wikipedia.org/wiki/Adaptive_Multi-Rate so it's not that
simple
<vralev> there is math involved ACELP stuff like g729
<vralev> might be hard to decode
<oleg> yes, it differs from codecs like g711
<oleg> and it is not a good thing to show video without voice in demo
<oleg> release date:
<oleg> next try for Nov, 30
<ivelin> that's right. Video only will be silly
<oleg> forget, Bartek archived <3% of cpu utilization for ss7 so it
give us change to handle several links
<ivelin> AMR is the codec usually used for voice with video?
<ivelin> nice
<jeand> depends to what you want to do with video there is some usage
where you don't want to care about the voice :-)
<ivelin> how can we test ss7 in QE?
<ivelin> lol
<oleg> Ivelin, AMR is moden codec for voice but 3gp files usualy
conatins it with video
<oleg> :) can we use such video for demo?
<vralev> it also says it's patented, not good
<baranowb> well, maybe emulate security app
<baranowb> whichii shows CCR feed
<baranowb> or make mms say: this is feed from corner of X and Y
<baranowb> bla bla and show video
<vralev> ah decoding is free
<mart1ns> brb
<oleg> I think we have learn how to transmitt it
<oleg> and leave decoding for end user terminal
<ivelin> lets take this offline
<ivelin> is there anything else on MMS?
<oleg> nope
<oleg> that's it
<oleg> sorry missed question about ss7 test in QE
<ivelin> is there a way to do that?
<ivelin> other than having access to MCS at a telco?
<oleg> partialy it is possible with local loop
<oleg> test machine should be equiped with ss7 card and two ports
joined between each other
<mart1ns> back
<ivelin> ok, this is something that can be tried. We need a SS7 card
and a Server for Luis
<ivelin> SS7 testing is not a priority yet, but it will be soon
<ivelin> let's move on
<ivelin> #5 JSLEE 2.0
<mart1ns> finished uploading to source forge, will do the
announcement in the next hour
<alexandrem> hurray :)
<mart1ns> from the announcement release notes
<mart1ns> First an overview of the changes in the container core,
where this release introduces clustering,
<mart1ns> be it simple high availability or full state replication,
including fault tolerant timers. The container
<mart1ns> also exposes a simple API for Fault Tolerant Resources
Adaptors, which may need to replicate
<mart1ns> and/or fail over their own data in the cluster. Also in the
same matter, there are different flavors for
<mart1ns> JAIN SLEE Profiles and Usage Parameters clustering, which
can be configured to be completely
<mart1ns> local or shared by all cluster nodes (requires external
database for profiles).
<mart1ns> With respect to included Resource Adaptors, the SIP one has
been completely reworked,
<mart1ns> it is now way faster (about 2x), and provides established
dialogs fail over. New in this release are
<mart1ns> the Diameter Base, Diameter Cca, Diameter sh Client, Http
Servlet, Http Client, MGCP, SMPP and
<mart1ns> XMPP Resource Adaptors, migrated and enhanced from
Mobicents JAIN SLEE 1.2.
<mart1ns> This release also now includes a well known example, Google
Talk Bot, which was migrated fro
<mart1ns> Mobicents JAIN SLEE 1.2.
<mart1ns> sorry, the irc client removed formatting
<alexandrem> nice :) you can say that more examples are available in
the svn tree :)
<ivelin> there were some issues with clustering
<ivelin> are the basic use cases tested now?
<mart1ns> we tested timers fail over
<mart1ns> and simple call setup failover
<mart1ns> there are many other cases needed to be tested, around b2bua
<mart1ns> but we had no time to setup such scripts
<jeand> mart1ns, nice
<ivelin> I imagine a lot of the test cases for MSS can be reused
<ivelin> is this happening?
<mart1ns> I'm not aware of those test cases, I guess we need to
converge and work togheter on it
<jeand> yeah we have a handful of scripts
<jeand> testing uas, uac, proxy, b2bua and c2c
<vralev> the sipp scripts can be reused, but someone must write the SLEE apps
<mart1ns> ok, will open an issue for it
<mart1ns> all those scripts are for established dialogs fail over?
<jeand> correct
<jeand> but there is a manual intervention to test the failover
<jeand> ie stopping the server at the right time
<mart1ns> ok
<mart1ns> that is acceptable
<jeand> if we could automate that, that would be even better, ie
reuse the smartfrog thingie maybe
<vralev> you also need the balancer running though
<vralev> do you use the balancer now>
<jeand> hum right
<jeand> vralev, vralev not sure because the release was done before the CL fix
<jeand> to ha core
<vralev> I forgot to update you on the balancer BTW, I will do at the end
<jeand> for accessing the LB
<vralev> yeah
<mart1ns> I redid the release
<mart1ns> of jsip ha and the sip ra
<jeand> oh so there is a new snapshot of jain sip ha ?
<vralev> good then
<jeand> still 1.1-SNAPSHOT ?
<mart1ns> y
<mart1ns> 0.2
<jeand> cool then that should
<jeand> work then
<jeand> so trunk is at 0.3 now ?
<jeand> 0.3-SNAPSHOT ?
<mart1ns> I redid the 0.1 release, and after I restored 0.2-SNAPSHOT,
pointing to the current parent sapshot and balancer 1.0.BETA9-SNAPSHOT
<mart1ns> full service :)
<ivelin> :)
<ivelin> next/
<ivelin> #6 Diameter
<jeand> :-)
<alexandrem> We are currently in requirements gathering for both HSS
and Web Services support for Diameter next release
<alexandrem> We've already ported the Sh Server RA to SLEE 2.x and
Cx/Dx is almost done too
<alexandrem> but after some discussion on the mailing list regarding HSS
<alexandrem> it showed up that we could benefit from XDM, as there's
some very similar behavior between it and the diameter profile update
noftification
<baranowb> generaly xml data handling :)
<alexandrem> so we may postpone it for a month or so, to do some work
together with Eduardo, as he's porting presence to 2.x too after the
SLEE's releases, I think
<mart1ns> y, right after my 1.2.7 issues are clear
<mart1ns> will focus on presence beta 6
<alexandrem> so we can both benefit from it, hopefully and do some
more work with integration between both in mind
<mart1ns> the sh server is in the svn already ?
<ivelin> why beta 6, instead of 1.0.gA?
<alexandrem> no, was waiting for you to finish release, so it won't
make any damage :)
<ivelin> for presence
<ivelin> the HSS and XDM synergy make sense
<mart1ns> actaully now I'm not sure it is beta6 or cr1
<mart1ns> let me check the roadmap
<jeand> if you move everything to SLEE 2.0 it should be another beta
<jeand> no ?
<ivelin> right, but then it should be a different release number
<ivelin> so we can maintain users on 1.x
<mart1ns> well, a CR may be seen as the last beta
<ivelin> while pushing the 2.x code base forward
<mart1ns> ivelin, the changes needed are minimal and will actually
simplify a lot the presence server, also being heavy processing apps
(sip subscriptions handling + db) its migration is almost mandatory to
achieve acceptable performance
<mart1ns> since the scheduled ga is right after slee 2 ga
<mart1ns> it sounds easier if we keep a single branch
<jeand> it was tech preview until now so I don't think that's a big
deal neither
<mart1ns> y
<mart1ns> also, from 1.2 experience
<mart1ns> presence servers push the limits of slee
<mart1ns> and bring up all the issues that may exist :)
<jeand> I would do another beta though
<mart1ns> not sure, maybe a cr1, and if something is wrong a cr2
<mart1ns> these are the last functionalities for 1.0
<mart1ns> if it becomes stable then the CR will become a waste of time
<mart1ns> and between another beta and a cr, I would really prefer the cr
<jeand> makes sense
<slegrik2> guys I gotta go, cat
<slegrik2> catch up later
<ivelin> thanks, Pavel
<mart1ns> have a nice trip back home, in the cool train
<slegrik2> bye
<ivelin> back to Diameter
<alexandrem> ok
<ivelin> do we have features planned for the Diameter RAs or stack itself
<ivelin> I haven't seen requests for new Diameter apps
<alexandrem> yes, we already cover all the most wanted ones
<alexandrem> so far the roadmap is still valid:
http://groups.google.com/group/mobicents-public/web/mobicents-diameter-roadmap
<alexandrem> stack and RAs seem stable, so nothing major to update,
except for some performance improvements and LB/HA features
<ivelin> The Ro/Rf examples are still red for the August release :)
<alexandrem> oops :)
<alexandrem> that's something to be fixed
<alexandrem> regarding the webservices which will be the major new
feature for next release
<alexandrem> we will start with Sh support
<alexandrem> and possibly try to include Rf too, depends on how it goes with Sh
<alexandrem> the idea would be to just provide server endpoint, but
as we need to test it... we'd need to make the client side too, for
showing it
<alexandrem> will provide the general ideas and architecture this week
<mart1ns> ivelin, where did this idea of proprietary WS interface came from?
<baranowb> aayush or some user
<baranowb> Alex we will have to have tests for HSS also
<baranowb> so we can reuse them for WS
<jeand> guys gotta go
<alexandrem> yeah, martins doesnt agree much with it, it seems :)
<mart1ns> HSS has not such interface
<mart1ns> alexandrem, I may digest it, but not as a major feature
<baranowb> y, I dont like it either as it is more like app not a standard
<alexandrem> mart1ns: it can have.. just be creative :)
<baranowb> standard is diam over byte stream :)
<jeand> later guys
<baranowb> cya
<mart1ns> HSS may take advantage of WS provisioning, but that is
nothing related with diameter
<mart1ns> and with an external sql db behind, not much need imho
<mart1ns> alexandrem, you can add whatever proprietary interfaces to it
<mart1ns> but it must be so desirable that customers will trade specs for it
<alexandrem> webservice are good for better and easier integrations
with 3rd party
<mart1ns> and that is where my truly doubts stand
<mart1ns> I have a very different opinion :p
<mart1ns> IMS already has the needed protocols
<mart1ns> no need for other proprietary ones
<mart1ns> unless they bring something new to the table
<mart1ns> that will later be adopted
<mart1ns> but sorry, imho this doesn't seem the case
<mart1ns> I'm fine with it, but don't make a release depend on it as
a major functionality
<alexandrem> well, as I have said, it can simplify a lot, when u can
say start_accounting(user, tariff) rather than creating a full
diameter message
<alexandrem> which the WS interface could hide
<mart1ns> well, tell the IMS boys to replace everything with WS
<mart1ns> lol :)
<baranowb> but tarrif is app specific, thats why there is so many
avps to describe it
<mart1ns> anyway, for apps
<mart1ns> the diameter interface
<mart1ns> is the same
<alexandrem> baranowb: a couple of them needed to specify that
<mart1ns> correct?
<mart1ns> so send them by diameter or ws is the same
<alexandrem> we may provide both raw diameter methods or methods for
simplifying it
<mart1ns> how it makes it simpler
<mart1ns> now that is a major feature, make an easier interface
<mart1ns> but with diameter behind
<baranowb> maybe, Im still not convinced and imho Ws should go only
after HSS B1 :)
<mart1ns> WS won't by any way make a simpler API
<mart1ns> the apps don't work with diameter transport details
<mart1ns> so to my eyes it is just a different API
<mart1ns> which can be done with diameter behind
<mart1ns> and like I said, that would be a major feature
<mart1ns> a child sbb for slee, a sync class for servlets
<alexandrem> and why not to make it on WS too?
<mart1ns> because the network uses diameter in specs
<alexandrem> it'd be good for anything else but WS ? :)
<mart1ns> you will need to have another proprietary endpoint
<mart1ns> in the other side
<alexandrem> it's a client, may be anything
<mart1ns> that is not good for a standard network
<mart1ns> imho nobody will care to implement it
<mart1ns> because they can't switch vendor
<mart1ns> and functionality is the same
<mart1ns> so resuming
<mart1ns> no added value
<mart1ns> proprietary
<mart1ns> do you think you can convince a costumer to use it instead
of pure diameter (with or whitout better api frontend)
<mart1ns> how would you justify it
<mart1ns> to lock in a vendor
<mart1ns> it is evrything they have been trying to get away :)
<alexandrem> mart1ns: but if they want it, they can have it.. also WS
is useful for bypassing gateways or firewalls, since HTTP protocol is
usually unrestricted, something that diameter may have issues with
<mart1ns> I find it hard to believe that someone will deploy a
firewall that blocks diameter
<vralev> IMO most users of the WS API would be the ppl who want
everything on HTTP and SIP, they dont want other sockets open, and
they might have constaints on opening sockets
<mart1ns> in an IMS network
<alexandrem> there are customers that'd like it probably, webservices
are widely used
<alexandrem> vralev: yes, exactly
<mart1ns> it is core protocol
<vralev> and WS is not exactly adopting proprietary stuff, there is SOA :)
<alexandrem> everything through the same "channel"
<mart1ns> vralev, sorry, it is vendor lock in, can't have app portability
<baranowb> and IMO its very doubtfull that diameter will be exposed freely
<baranowb> cmon, it deals with $$$$$
<mart1ns> for a core protocol of the business
<mart1ns> but like I said plenty of times
<mart1ns> it can be done
<mart1ns> but hard to justify
<alexandrem> mart1ns: there are the weirdest use cases out there...
this isn't the worst :)
<mart1ns> it is when you say it is a major feature
<mart1ns> hehe
<alexandrem> we get a common interface, easily extended...
<alexandrem> I said it's the major feature for this release
<mart1ns> well, nothing seems to be stopping you
<mart1ns> and you seem to like the idea
<mart1ns> so why not :)
<vralev> mart1ns: you can have app portability, WS are composable
with those orchestration engines
<vralev> if someone has different WS API he doesnt change his
original app, he writes the transform
<mart1ns> how so, this is the app communicating with the diameter server
<vralev> there are huge businesses based on that thing
<mart1ns> what other HSS or diameter server would understand it
<alexandrem> I dont even like WS's they are slow.. at least from my
experience :)
<mart1ns> sure, business
<mart1ns> not diameter
<vralev> tibco, etc
<alexandrem> but I can admit it can be handy and usable
<mart1ns> it is not even slow
<mart1ns> perf has been greatly enhanced
<mart1ns> last years
<alexandrem> I believe so
<alexandrem> but I always got that feeling...
<mart1ns> for instance
<mart1ns> consider the Mobicents HSS would expose such interface
<alexandrem> and the first message.. seems to take seconds to be
delivered, maybe that's old issues...
<mart1ns> and you are developing a app that uses diameter sh
<mart1ns> would you do it with diameter sh
<mart1ns> or do it with a proprietary ws
<alexandrem> well.. if the ws development would take 2 days, against
2months to learn the details and behaviors of diameter...
<mart1ns> well, at least look at parlay
<mart1ns> what? lol
<mart1ns> don't bring the easy to use api again
<mart1ns> that has nothing to do with diameter or ws
<alexandrem> it's obvious pure diameter would always be the BEST solution
<mart1ns> the ws invocation would still need a diameter msg inside
<alexandrem> but WS may be the easiest and at some scenarios, the only :)
<mart1ns> how so
<mart1ns> the only usage referenced here was the one from vlad
<mart1ns> but imho a telco app that has no access to diameter has
very limited value
<mart1ns> anyway, look at parlay x
<mart1ns> maybe they already provide this
<mart1ns> and that is a standard
<mart1ns> for anyone missing the details, parlay x provides telco app
apis through web services
<mart1ns> for everything an app needs to interact with the network
<mart1ns> sound incomplete if there is no accounting or user profile
<alexandrem> will check it
<mart1ns> need to go guys, good chat
<alexandrem> thanks :)
<mart1ns> ivelin ivelin ivelin ivelin ivelin ivelin
<vralev> let me update you about the balancer, it seems stable right
now - tests of a single balancer on latop show 600-700 cps for SIP
UAS, 300-900 jboss AS homepage loads for integrated HTTP forwarder (AS
CPU utilization limits the test), comet HTTP works flawlessly (this
very chat app was used in the test). The only lost calls are caused
by some probems in Sip Servlets with retransmissions, but those are
now eliminated.
<mart1ns> cool
<mart1ns> we can chat later, need to go now
<mart1ns> bye all
<vralev> ok also balancer docs are updated in the docbook
<vralev> they are mostly container neutral, but need to be reviewed
bu Jared, I sent him some notes
* oleg has quit ("Java user signed off")
<ivelin> I got pulled out at 12, right before the end of the chat
<ivelin> Vladimir, still on?
Sachin Parnami
Nov 18, 2009, 10:00:21 PM11/18/09
to mobicent...@googlegroups.com
Oleg regarding ss7 testing
>><oleg> partialy it is possible with local loop
>><oleg> test machine should be equiped with ss7 card and two ports
Can you please elaborate,
1>How it could be done if we have two ports on a Degium/ Sangoma card ?
2> Does loopback (pin 1<--> 4 and 2<--->5 (http://wiki.sangoma.com/Pinouts#A101/2/4%20Loop%20back) )in one port will help ?--
Regards,
Sachin Parnami
>><oleg> partialy it is possible with local loop
>><oleg> test machine should be equiped with ss7 card and two ports
1>How it could be done if we have two ports on a Degium/ Sangoma card ?
2> Does loopback (pin 1<--> 4 and 2<--->5 (http://wiki.sangoma.com/Pinouts#A101/2/4%20Loop%20back) )in one port will help ?
Regards,
Sachin Parnami
aayush bhatnagar
Nov 18, 2009, 11:05:43 PM11/18/09
to mobicent...@googlegroups.com
Guys, regarding the web service discussion...
Web service interfaces are not intended to replace DIAMETER in any way or to break the standard interfaces.
Using a web service opens the doors for integrating with 3rd party products and solutions while preserving DIAMETER interfaces towards the HSS and Charging System or even other IMS nodes.
Consider a case, where a legacy service needs to be deployed on the Mobicents platform. However, the operator wishes to charge all his services using Ro and Rf interfaces before he migrates his legacy service logic to an NGN one, rather than incurring the costs of supporting two charging platforms (one for legacy and another for NGN).
This is where a web service interface can add value, by providing him with an instant alternative to charge over Diameter while preserving his existing charging client logic (he need not re-write his logic in the form of a CTF, only needs to add a web service client to his existing module).
Moreover, web-based content intensive data applications (Web 2.0 apps provided from a 3rd party vendor) will find it much more easier to invoke a web service and integrate with a service delivery platform, than using a Diameter stack on his web application. Almost all Web 2.0 applications talk on Web services.
We must understand, that we cannot develop and deploy all services present in the universe on Mobicents. For doing so, we will need a super computer.
In addition to native development, there might also be a need for integrating with existing stable services provided by 3rd party vendors, while still preserving the 3GPP IMS interfaces (Ro and Rf, Sh etc). This is where Web services will provide you with flexibility and better time to market (as Alex described, that it will take barely 2 days to develop a web service interface).
Lastly, web services need not always be proprietary even if we take the case of IMS. If you wish to strictly follow the standard, we can follow the OSA API.
This was exactly the reason OSA was standardized (http://www.etsi.org/WebSite/Technologies/OSA.aspx) : To provide web service interfaces to a telco-operator's infrastructure.
3GPP defines elaborate web service interfaces for payment, charging, provisioning and even call control in the 29 series. This means, that if we envision mobicents as a Service Delivery Platform, the web service interfaces will behave as an interface to the OSA-SCS of the IMS architecture.
The 3GPP IMS architecture defines the following interfaces of the OSA-SCS towards other entities :
1. Towards the HSS (which is Sh).
2. Towards the OSA AS (which is a web service interface).
3. Towards the S-CSCF (which is ISC).
So, the DIAMETER contract or the SIP contract with the IMS nodes is not broken. Only the access to these IMS interfaces is further externalized by using Web services.
I hope it makes sense.
Just my 2 cents.
Amit Bhayani
Nov 18, 2009, 11:23:33 PM11/18/09
to mobicent...@googlegroups.com
Regarding Video Player
The track will give you pre -encoded AMR Audio and mpeg4 video byte's and we don't need to decode it. Just send it as it is. Yes but in future we may have to have a decoder to take care of transcoding.
Another challenge is some 3gpp files may not have constant decoding-time (hear-beat; for example 20ms) for every sample to be sent. So with every packet sent, next packet should be sent after 'x' ms or 'x+5' ms etc which comes from parsing of file.
Once this is ready, MMS can be complete RTSP server for sure.
The track will give you pre -encoded AMR Audio and mpeg4 video byte's and we don't need to decode it. Just send it as it is. Yes but in future we may have to have a decoder to take care of transcoding.
Another challenge is some 3gpp files may not have constant decoding-time (hear-beat; for example 20ms) for every sample to be sent. So with every packet sent, next packet should be sent after 'x' ms or 'x+5' ms etc which comes from parsing of file.
Once this is ready, MMS can be complete RTSP server for sure.
On Thu, Nov 19, 2009 at 2:31 AM, Ivelin Ivanov <ivelin.atan...@gmail.com> wrote:
Zelalem Sintayehu
Nov 19, 2009, 4:55:05 AM11/19/09
to mobicent...@googlegroups.com
Hi, I am wondering if you have seen the implementation of AMR codec (coder/decoder, packetizer and depacketizer) in Live555. I think you can write a java code based on that.
Cheers,
Zelalem
Cheers,
Zelalem
aayush bhatnagar
Nov 21, 2009, 8:39:02 AM11/21/09
to mobicent...@googlegroups.com
I believe the following is quite relevant to our web service discussion:
A significant development under way is the OneAPI project started by the GSMA.
It is defining a REST Web service API to be used by telco operators to expose capabilities of their network using web services. These capabilities can be used by web developers/ Web 2.0 applications.
Some of the APIs include (in alpha and beta stages for now):
1. Location info
2. User Profile access.
3. SMS and MMS
4. Payment and Charging
5. Data connection.
API details here: https://gsma.securespsite.com/access/Access%20API%20Wiki/Home.aspx
Home page here : https://gsma.securespsite.com/access/default.aspx
Eduardo Martins
Nov 21, 2009, 8:48:11 AM11/21/09
to mobicent...@googlegroups.com
What is the relation with Parlay X?
-- Eduardo
-- Eduardo
aayush bhatnagar
Nov 21, 2009, 8:51:27 AM11/21/09
to mobicent...@googlegroups.com
It is in addition to parlay-X. The point being, that there is a consistent effort for using web services as a standard interface in telecom.
Relation to Parlay-X and OneAPI is given in their FAQs as:
- Aren't there already APIs defined to accelerate application developments for the mobile world?
Seems like they wish to re-visit the Parlay-X API, as it was maybe not designed keeping Web 2.0 apps in mind.Yes, most notably with Parlay X Web Services. The GSMA Access group believe that the evolution of the Web to open APIs and collaborative efforts (‘Web 2.0’) provides an opportunity to revisit such work and represent it as an open, community-driven project.
Reply all
Reply to author
Forward
0 new messages