Mobicents weekly meeting notes, November 14, 2012
62 views
Skip to first unread message
Ivelin Ivanov
Nov 14, 2012, 2:48:11 PM11/14/12
to mobicents-public
Public IRC chat @ freenode.net #mobicents
Every Wednesday at 10am CST
Attendees:
Alex, Amit, Charles, Eduardo, George, Jean, Pavel, Thomas Q, Sergey, Vladimir, Yulian, Ivelin
Summary:
#1 Restcomm: Fixing bugs and preparing docs for CR1; Restcfomm will handle EC2 NAT issues in CR1
#2 SIP Servlets: WebSockets TLS done; TLS memory optimized; bug fixes; started work on MSS 2.0 HA#3 Diameter/OCS: Reviewed 3 community contributed features; OCS JSLEE port almost ready
#4 SS7/GMLC/USSD/SMSC/EIR: Completed jSS7 2.0.0.BETA3; EIR docs committed; USSD Push almost ready
#5 Media Server: more bug fixes, preparing 3.0.0.Final
#6 JSLEE: still working on new Http Server RA
#7 Productization: finalized Telscale jss7 release script
#8 Docs: improving restcomm docs; testing jslee docs
#9 Admin tools: initiative started to unify admin APIs and tools across Mobicents projects
Log:
--------------
[10:10] <ivelin> #1 Restcomm
[10:11] <ivelin> tommyq^
[10:11] <tommyq> Okay
[10:11] <tommyq> hey guys, hope everyone is good.
[10:12] <ivelin> yes, we've been behaving
[10:12] <ivelin> why?
[10:12] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has joined #mobicents
[10:12] <ivelin> you got Christmas gifts for us?
[10:13] <abhayani> lol
[10:13] <tommyq> lol
[10:13] <gvag> :-)
[10:13] == okulikov [~okul...@178.35.156.160] has joined #mobicents
[10:13] <tommyq> On the RestComm side we have been focusing heavily on reliability which means bug fixes and docs as promised. I have also started work on WebUI and production documents.
[10:14] <ivelin> what's production documents?
[10:14] <ivelin> hello?
[10:14] <tommyq> integration with puppet and open source tools like open sips (until we have our own) and just general thoughts
[10:15] <tommyq> things that people will need to seriously deploy RestComm for production
[10:16] <tommyq> The docs are still very new I will share when there is enough meat but I am constantly working on them when I pause or have to do something that involves me waiting
[10:16] <ivelin> on the sbc topic, we need that document to describe the use cases that need to be covered.
[10:16] <tommyq> By the way I will only share with core these are for TeleStax
[10:16] <tommyq> yes sir
[10:16] <tommyq> :)
[10:16] <tommyq> I am taking a use case approach it's easy for everyone to understand
[10:16] <ivelin> there was another offline discussion about integration with our HA layer
[10:17] <tommyq> HA, not fail over, right?
[10:17] <ivelin> its understood for the most part how our converged LB works with the app servers behind it
[10:17] <ivelin> failover and load balancing
[10:18] <tommyq> failover is not necessary just HA
[10:18] <ivelin> but its not well understood what variables SBC introduces
[10:18] <tommyq> LB is important and we can use any tool we like
[10:18] <jean_> tommyq, yulian_o was syaing in Rio we should do the NAT thing in restcomm itself
[10:18] <tommyq> well OpenSIPs can act as an SBC but it's very flexible it will do what we need it to do and nothing else.
[10:19] <jean_> tommyq, the idea was to reduce infra costs
[10:19] <tommyq> @jean_, yes that is on the roadmap for Telscale distro
[10:19] <jean_> and have less layer to manager
[10:19] <jean_> manage
[10:19] <jean_> openSIPs had its own issues back in the day
[10:19] <jean_> where you had to put fixes into it
[10:19] <yulian_o> the problem starts where you want to change something and you have 3rd party module , in nat there is plenty of different situatuion which are not correctly handled , and they must be done in code
[10:20] <jean_> when we had it on EC2 last year
[10:20] <tommyq> of course like all software as it matures :)
[10:20] <yulian_o> i had to change sip stack to resolve problems
[10:20] <jean_> I wouldn't go that route again
[10:20] <tommyq> actually
[10:20] <tommyq> okay
[10:20] <tommyq> no fixes where for opensips itself
[10:20] <jean_> yulian_o, I was looking at the SIP issue
[10:20] <tommyq> it was config oversights
[10:20] <jean_> yday
[10:20] <jean_> can you pvide a diff for it
[10:20] <jean_> diff patch
[10:20] <jean_> this is the full class right now and it's hard to see where the changes are
[10:20] <yulian_o> i can provide the udp channel file :)
[10:21] <jean_> yulian_o, a diff for the udpchannel
[10:21] <tommyq> with opensips we actually never had a problem where opensips was the issue
[10:21] <yulian_o> i dont have source , i had to disassemble it!
[10:21] <jean_> yulian_o, what ?
[10:21] <jean_> http://code.google.com/p/jain-sip/source/checkout
[10:22] <yulian_o> its now \
[10:22] <jean_> tommyq, I see the NAT is for this release
[10:22] <jean_> http://code.google.com/p/restcomm/issues/detail?id=62
[10:23] <jean_> next CR1 release I meant
[10:23] <tommyq> which one CR1
[10:23] <tommyq> ?
[10:23] <jean_> so let's get it done when you have cycles to work on it
[10:23] <jean_> instead of using opensips
[10:23] <tommyq> okay so moving on we can definitely handle NAT in RestComm and put the Mobicents LB on the edge along with DNS SRV records to have as few layers as possible.
[10:23] <tommyq> Doing it is simple
[10:23] <jean_> right
[10:25] <tommyq> That's it for me, George my friend please add anything on your end.
[10:25] <gvag> nothing new since yesterday from me.
[10:26] <jean_> we might include a STUN/TURN server to support ICE in the future
[10:26] <jean_> as this is something we will probably need for WebRTC as well
[10:27] <tommyq> Sure, I believe George had it working with STUN at one point but not sure.
[10:27] <tommyq> :)
[10:27] <ivelin> so is it agreed then that for the restcomm live case, we can handle nat in restcomm itself?
[10:27] <gvag> yeah but that was STUN setting on the sip client
[10:28] <tommyq> yes
[10:28] <ivelin> no need for opensips?
[10:28] <tommyq> no since we aren't going to deal with fail-over where the media has to be failed over as well we don't need it
[10:28] <yulian_o> i have sent the file
[10:28] <tommyq> it would be overkill and an extra unnecessary hop
[10:29] <ivelin> issue #62 says that restcomm will integrate with an sbc, not that it will handle NAT directly
[10:29] <tommyq> huh
[10:29] <gvag> d
[10:29] <tommyq> yeah
[10:29] <tommyq> I think that had to do with sipXecs
[10:29] <tommyq> a real sbc wouldn't need any integration
[10:29] <tommyq> SIP is it
[10:30] <ivelin> so 62 needs to be renamed to Handle NAT directly in Restcomm ?
[10:31] <tommyq> No there should be a separate ticket for that
[10:31] <ivelin> what component will handle rtp address/port NAT?
[10:31] <tommyq> I opened it in Rio
[10:31] <tommyq> http://code.google.com/p/restcomm/issues/detail?id=109
[10:32] <ivelin> I see. 109 is now targeted for cr1 and 62 goes to the backburner?
[10:32] <tommyq> I'm not sure.
[10:32] <tommyq> George would you like to elaborate on 62 for us
[10:32] <tommyq> i guess with 109 62 will not be fixed
[10:32] <gvag> the idea behind 62 was to handle nat issue on Restcomm
[10:33] <tommyq> oh was it
[10:33] <tommyq> I'm sorry
[10:33] <tommyq> I wouldn't have opened a duplicate
[10:33] <gvag> we can tag as invalid
[10:33] <tommyq> perfect
[10:33] <ivelin> so 62 should be marked as dupe and closed?
[10:34] <tommyq> yep as invalid and closed :)
[10:34] <ivelin> would our sip lb sit in front of restcomm?
[10:34] <tommyq> yes
[10:35] <ivelin> so the restcomm sip servlet will handle SIP NAT
[10:35] <ivelin> what about rtp
[10:35] <ivelin> what component will handle rtp address/port NAT?
[10:35] <tommyq> and then we would use SRV records for DNS fail-over or we can use floating IPs and a heartbeat
[10:35] <tommyq> MMS
[10:35] <tommyq> MMS can already handle NAT
[10:35] <tommyq> for RTP
[10:35] <ivelin> MMS will be on public IP?
[10:35] <tommyq> Well nothing on EC2 is on a real IP
[10:36] <tommyq> It's static nat
[10:36] <tommyq> So EC2 Firewall -> MMS
[10:36] <ivelin> but there are IPs that are visible from the world and IPs that are only visible from EC2
[10:36] <tommyq> correct
[10:36] <tommyq> and you forward desired traffic from public to private
[10:37] <yulian_o> mms works now without sbc before it right?
[10:37] <tommyq> right
[10:37] <ivelin> MMS will be visible from the world or only the restcomm sip servlet?
[10:37] <tommyq> well the MGCP interface only from restcomm
[10:37] <tommyq> and the rtp interfaces the whole world
[10:37] <tommyq> it would be nice if we can configure an rtp port range
[10:37] <tommyq> for added security
[10:38] <gvag> you will need to have a firewall rule for rtp range to be accesible from any io
[10:38] <gvag> *ip
[10:38] <tommyq> right now it's tough because it's random I believe
[10:38] <tommyq> correct
[10:38] <yulian_o> 2 ivelin : there are 2 ip addresses you can configure on mms , local and remote , mgcp always run on local ip , rtp by default on external , but you can add typeOfNetwork.Local to crcx request
[10:38] <gvag> the rtp range is specific but huge
[10:38] <ivelin> thanks, Yulian. Makes sense
[10:39] <tommyq> yulian_o, how hard would it be to make the rtp range configurable?
[10:39] <yulian_o> not hard
[10:39] <tommyq> By the way RestComm will have a local and remote IP as well.
[10:39] <tommyq> it's the only way it will work on EC2
[10:39] <ivelin> which module will be resposible for SDP rewrite in the SIP exchange?
[10:39] <tommyq> because we must use the remote IP
[10:39] <tommyq> but we have to bind to the local
[10:39] <tommyq> RestComm
[10:40] <yulian_o> its actually configurable!
[10:40] <tommyq> Sweet! How do I we do it? That is awesome when sitting behind firewalls
[10:40] <ivelin> I see. Tom please diagram the use case for restcomm live in the doc.
[10:41] <tommyq> I will
[10:41] <yulian_o> and highestPort and lowestPort params to localhost bean
[10:41] <tommyq> By the way this doc is for core only.
[10:41] <yulian_o> it will make difference only for external ip address
[10:41] <yulian_o> which is logically good since you dont have to limit your local interface
[10:41] <yulian_o> seehttps://code.google.com/p/mediaserver/source/browse/io/network/src/main/java/org/mobicents/media/server/io/network/UdpManager.java#207
[10:42] <tommyq> we may want to just because other machines inside EC2 may be able to reach ours.
[10:43] <yulian_o> what do you mean?
[10:43] <tommyq> I have to do a bit more homework on how they route internal traffic but we should be on different vlans
[10:43] <tommyq> if we are not on a different vlan on the EC2 network and other VMs can see ours then we will need a firewall on the VM itself
[10:44] <tommyq> but this is something I'm not sure of so I wouldn't worry about it until it's a problem
[10:44] <tommyq> I will do the right homework and ask you questions as I go
[10:44] <yulian_o> you have external ip on mms for everything that is not part of your network
[10:44] <tommyq> correct
[10:44] <yulian_o> and you have internal ( mostly 127.0.0.1 or some internal ip address if you have several mms servers )
[10:45] <yulian_o> on internal there is no option to set a limit of ports , since they should not be firewalled anyway
[10:45] <tommyq> the VMs on EC2 are part of a class A network with 16,000,000 other VMs
[10:45] <yulian_o> on external you have option to set them
[10:45] <tommyq> most of which don't belong to us
[10:45] <yulian_o> in your case all VMs should contact external ip address
[10:45] <tommyq> That's what I'm not sure about and those policies are out of our control
[10:46] <yulian_o> everything that is out of your controll === external ip for mms :) even when its 10.0.0 , or 172
[10:46] <ivelin> ok, glad we have a NAT plan. Looking forward to see it in writing.
[10:46] <yulian_o> btw you never use typeofnetwork.local in restcomm :)
[10:47] <yulian_o> its not documented either yet
[10:47] <tommyq> no, I didn't know
[10:47] <tommyq> :)
[10:47] <tommyq> but now I can ;)
[10:47] <ivelin> #2 SIP Servlets
[10:47] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
[10:48] <ivelin> SIP Servlets gang?
[10:48] <jean_> vralev,
[10:48] <jean_> can you update
[10:48] <vralev> ok
[10:48] <jean_> between yday travel and visa today
[10:48] <jean_> I couldn't check the backlog
[10:49] <jean_> yet
[10:49] <vralev> WebSocket TLS is checked in together with TLS memory optimization, TLS is now about the same footprint as TCP with the occasinal overhead of the framgemented buffers and SSLEngine
[10:49] <vralev> then
[10:50] <vralev> there are a couple of other fixes in JSIP again - timers config, memleak fix
[10:50] <vralev> arquillian gets another fix too
[10:51] <vralev> and clustering for AS7 starting too now
[10:52] <vralev> that's all I think
[10:52] <ivelin> what's the plan for MSS 2.0 clustering?
[10:53] <vralev> first just use the HTTP clustering as a base and then we will see if something else is needed I think
[10:53] <vralev> HTTP clustering is so much easier, they have just 5 testcases and it covers it all
[10:54] <vralev> there is a plan about pluggable replication and if HTTP is indeed so easy we might do alternative HTTP clustering as well for tomcat
[10:54] <jean_> right
[10:54] <jean_> that's the plan
[10:54] <vralev> but those are not final, first just the normal clustering closely following the AS7 built-in replication layer
[10:55] <ivelin> what clustering framework will do the cross-node replication?
[10:57] <vralev> infinispan embedded
[10:57] <ivelin> ok
[10:58] <ivelin> cassandra is not on the test roadmap yet?
[10:58] <jean_> not yet
[10:59] <jean_> easier to tune the API with ISPN first
[10:59] <vralev> cassandra requires a completely different approach
[10:59] <vralev> so that would be a huge rewrite if we ever want to do it
[10:59] <jean_> not if we use the cluster fwk right ?
[11:00] <vralev> what fwk is that?
[11:01] <jean_> the cluster framework used by MSS And SLEE for Timers
[11:01] <jean_> SLEE uses it for everything related to HA
[11:01] <jean_> http://code.google.com/p/commscale.cluster
[11:01] <vralev> you mean combine cassandra with infinispan?
[11:02] <jean_> no
[11:02] <jean_> I mean
[11:02] <jean_> MSS uses Cluster as an API
[11:02] <jean_> for replication
[11:03] <jean_> and the Cluster uses a pluggable technology
[11:03] <jean_> ISPN
[11:03] <jean_> or Cassandra
[11:03] <jean_> that is configured at startup tim
[11:03] <vralev> ok, but you remember I wronte a huge document explaining that some APIs just can't be implemnted using cassandra and the likes
[11:03] <vralev> the nodeModified callbacks and etc
[11:04] <jean_> riht
[11:04] <jean_> right
[11:04] <@mart1ns> do you really need that in the api seen by mss?
[11:04] <jean_> I See what you mean in term of rewrite now
[11:04] <jean_> it would need adaptation at the cluster fwk
[11:05] <@mart1ns> we used so far only data removed callback
[11:05] <vralev> mart1ns: we dont need it per se, but it's going to change a lot of things
[11:06] <@mart1ns> in timers, jsip ha, slee, diameter
[11:06] <@mart1ns> doesn't cassandra have any callbacks?
[11:06] <vralev> dataRemoved is in the same boat, there are simply no callbacks in thrift, hotrod or any of the remote protocols for caching
[11:07] <vralev> although I got to check again these days
[11:08] <@mart1ns> anyway, I still think that a remote cache like cassandra has no latency for the job in mobicents
[11:08] <vralev> I will check again, but last time I checked there were no callbacks in any of those
[11:08] <vralev> hotrod2 had them on the roadmap
[11:08] <ivelin> the cassandra route would be probably fundamentally different
[11:08] <@mart1ns> cassandra mimics database perf requirements, not caches
[11:08] <ivelin> instead of maintaining up to date in-memory cache, the new node would have to restore state as needed from the cassandra copy wherever it is
[11:08] <@mart1ns> there is another apache cache that is good performance wise
[11:09] <@mart1ns> but it requires nodekeys to be strings
[11:09] <@mart1ns> and that is a PITA
[11:10] <ivelin> I think we covered this many times - full replication is only required in a few rare cases
[11:11] <@mart1ns> zookeeper
[11:11] <ivelin> dropped calls aren't that uncommon for the vast majority of applications
[11:11] <@mart1ns> ivelin: iirc everyone wants early dialog failover
[11:12] <@mart1ns> that's far far away from high availability only
[11:12] <jean_> ivelin, this is not what we settled on
[11:12] <jean_> we settled on reverse
[11:12] <ivelin> its really the app's decision what and how to replicate. For conferencing for example, the conference context can be in a db, individual callers can drop and redial if needed as long as the conf room is alive.
[11:12] <jean_> people that will need replication will need high consistency
[11:13] <jean_> if they are willing to tolerate dropped calls
[11:13] <@mart1ns> for restcomm I think high availability can be enough
[11:13] <jean_> they can go for load balancing only
[11:13] <@mart1ns> the call dropping can be re-established
[11:13] <jean_> but failover requires high consistency
[11:13] <@mart1ns> but for AS customers high availability is not enough
[11:13] <ivelin> right, for those use cases like 911, the synced replication is a deal saver.
[11:14] <jean_> for telepresence for high end customers as well
[11:14] <jean_> like CEOs etc
[11:14] <ivelin> right
[11:14] <jean_> or for core network IMS
[11:14] <jean_> for billing, CDRs
[11:14] <jean_> for generating*
[11:14] <vralev> someone's got to check if 911 really need replication or just 99.999, because those are different
[11:15] <jean_> what we need is a solution with high consistency that can scale
[11:15] <ivelin> so there are two fundamentally different ways apps can go -> high cost, full replication or low cost failover with partial static context saved in the db
[11:16] <jean_> I think you can tune Cassandra to choose which concept of the CAP theorem
[11:16] <jean_> you can drop
[11:16] <jean_> in favor of te 2 others but not sure
[11:17] <ivelin> cassandra can provide high consistency when configured for it
[11:18] <jean_> then the deal breaker would be on performance
[11:18] <vralev> but consistency is only needed at the app layer for money transactions, not on the system layer I imagine
[11:18] <ivelin> the new node will incur a hit to restore state, but that's most likely invisible to the caller. Should be within ms.
[11:19] <vralev> system layer can fail all it wants, we just need to feed the app proper events so it can recover (end charging etc)
[11:19] <jean_> ivelin, depends on the size of the state to recover
[11:19] <ivelin> yes, I think Vladimir is right. As long as there is a log of events that can help restore good state, the time it takes to do it should be pretty fast.
[11:20] <@mart1ns> ivelin: that is thinking on a call failure
[11:20] <@mart1ns> not on a busy node failure
[11:20] <@mart1ns> which has thousands of calls to be recovered by other nodes
[11:21] <@mart1ns> anyway recover time is not really important
[11:21] <@mart1ns> what is important is the replication cost at runtime, that is, when all works fine
[11:22] <ivelin> Jean, the size of the state for a phone call is negligible compared to the kind of data modern dbs are designed to handle.
[11:22] <@mart1ns> if you store data in a database (remote or not), it's going to screw the server performance
[11:22] <ivelin> Eduardo, I agree. The runtime cost of synced multi-node replication is so high.
[11:22] <@mart1ns> it adds latency in every msg
[11:22] <@mart1ns> and that is severe for cpu
[11:23] <ivelin> well now, that's just nonsense
[11:23] <@mart1ns> there is a reason why telco apps have different latency requirements than enteprise
[11:23] <ivelin> the throughput of nosql dbs is insanely high these days.
[11:24] <ivelin> yet another piece of mythology
[11:24] <@mart1ns> it's not throughput, it's latency
[11:24] <@mart1ns> it's not a myth lol
[11:24] <ivelin> ok, let the tests prove that
[11:24] <@mart1ns> if I add 1ms on each cluster call on a slee perf test
[11:24] <vralev> i sense everyone is now talking about different things already :)
[11:24] <@mart1ns> it ruins by hundreds of cps
[11:25] <jean_> vralev, I have the same feeling :-)
[11:25] <@mart1ns> and the latency increase on db is way higher than 1ms
[11:25] <ivelin> Vlarev is probably right again :)
[11:25] <@mart1ns> you put everything on old on IO ports
[11:25] <@mart1ns> due to that latency increase
[11:26] <@mart1ns> hold
[11:26] <ivelin> IO ports are there for any kind of replication
[11:26] <@mart1ns> it's incredible how severe is the impact we had on slee on every optimization
[11:26] <@mart1ns> for saving latency in very small things
[11:26] <@mart1ns> now if I change 4 or 5 calls to jbosscache to a db
[11:27] <@mart1ns> it's insane :)
[11:28] <@mart1ns> I'm not saying you can't be right
[11:28] <@mart1ns> it can become fast
[11:28] <@mart1ns> but each time the db gets fast, the cache gets too
[11:29] <@mart1ns> and every customer will enjoy every load increase
[11:29] <@mart1ns> it's where they spend $$
[11:31] <vralev> we are offtopic, but to add more fire for design issues - also DBs incling JDBC, thrift, hotrod will need to be consumed in synchronous way meaning any glitch in the TCP connection gets you deadlocked and will snowball into a crash in few secs
[11:31] <@mart1ns> hadoop performance/latency wise system is zookeeper
[11:32] <vralev> there is async versions of these, but replacing the current calls with those will be insanely difficult
[11:32] <@mart1ns> but like I mentioned before, has a terrible requirement of string data keys
[11:32] <ivelin> ok, let's leave it to test numbers to speak
[11:32] <@mart1ns> vralev: you don't need to see that in the cluster api
[11:33] <vralev> mart1ns: you do
[11:33] <@mart1ns> you just need a key,value api and a few more basic features
[11:33] <vralev> well cluster API will need to have cache.put() and cache.putAsync() or only putAsync
[11:34] <@mart1ns> I was able to switch from ISPN to hazelcast in 2 days with an api that is enough for what we need
[11:34] == okulikov [~okul...@178.35.156.160] has quit [Ping timeout: 245 seconds]
[11:34] <ivelin> Vralev, TCP may be a theoretical problem, but is that happening in practice. See the amounts of apps that depend on these APIs.
[11:35] <@mart1ns> basically you need put/get + relations
[11:35] <vralev> this is not theoretical problem, I am dealing with it everyday
[11:35] <@mart1ns> relations is where the perf may degrade
[11:35] <vralev> if you remember Jonas reported the same issue although not with DB
[11:35] <@mart1ns> I suspect this is why I got bad rrsults with ISPN some time ago
[11:36] <vralev> anyway, I am probably not explaining it right and it's not that important right now
[11:37] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has joined #mobicents
[11:38] == abhayani [~abha...@41.206.1.3.vgccl.net] has quit [Ping timeout: 246 seconds]
[11:38] <@mart1ns> imho the ability to switch the underlying framework is a must, even if we need to code a bit more on our side due to have only basic features
[11:38] <jean_> right
[11:39] <ivelin> Vladimir, is TCP connections are unreliable, there must be a solution that is used for these massive reads/writes to nosql dbs
[11:39] <@mart1ns> batches?
[11:43] <vralev> well switching underlying framework certainly forces you to generalize your API in some portable way, so no callbacks, no async methods, no delta serialization, no hashed destinations and so on. You lose powerful features each underlying implementation has
[11:44] <@mart1ns> no, you do that our cluster impl
[11:44] <ivelin> HA is always a fun topic, isn't it
[11:44] <@mart1ns> you adapt the impl to take the best advantage of the underlying framework
[11:44] <ivelin> let's take it offline
[11:44] <ivelin> #3 Diameter/OCS
[11:44] <@alexandrem> hi all
[11:44] <vralev> It's not that TCP connections are unreliable, it's just that they synchrounly block until they receive the response, which can be delayed for a number of everyday reasons and once you have all (100 or so) threads stuck the requests accumulate in the queue beyond the available capacity
[11:45] <@mart1ns> while in high level you depend only on the basics
[11:45] <@alexandrem> ok.. I'll wait :)
[11:45] <@mart1ns> yet listeners are a must ;-)
[11:45] <@mart1ns> sorry alexandrem, go on
[11:45] <@alexandrem> np
[11:45] <vralev> I agree, better to move on
[11:45] <@alexandrem> regarding diameter, I have been reviewing the patch contributed with several enhancements, split it into 3 major ones:
[11:45] <@alexandrem> Improve Diameter Router Performance & Footprint (http://code.google.com/p/jdiameter/issues/detail?id=23)
[11:45] <@alexandrem> Improve Peer FSM to be Multi-Threaded (http://code.google.com/p/jdiameter/issues/detail?id=24)
[11:46] <@alexandrem> TCP Transport to use non-blocking I/O (http://code.google.com/p/jdiameter/issues/detail?id=25)
[11:46] <@alexandrem> we are currently discussing some of the drawbacks of some approaches taken in the patch and I've been also performing some perf tests to see the benefits
[11:47] <@alexandrem> but mostly these changes should be integrated as they provide good results
[11:48] <@alexandrem> with respect to OCS, the JSLEE prototype is pretty much ready, just needs a few more adjustments and I will put it live
[11:48] <@alexandrem> should be a good start point for someone wanting to play with it
[11:49] <@alexandrem> btw, ivelin, shall I create a standalone gcode project to include it or for now just have it under diameter examples tree ?
[11:51] <ivelin> OCS is a new project
[11:51] <ivelin> is the main point of migrating to JSLEE so that it can support SS7 API?
[11:54] <vilpan> I just want to stress the importance of indexing all the projects in a central place with nice descriptions and such. The multitude of different projects is really great, but new users feel lost all the time
[11:54] <@alexandrem> ivelin: possibly. having it on JSLEE allows to much better integration with other protocols
[11:55] <@alexandrem> vilpan: I agree. a reference to any Diameter related project will always be present in the main diameter project, as it is now, referencing the JSLEE RAs
[11:56] <vilpan> alexandrem: yes, I just brought it up once again in this context, though I mean all the projects, including GMLC, jEIR, OCS, etc.
[12:00] == barreiro [~barr...@2.82.247.174] has quit [Ping timeout: 268 seconds]
[12:01] <ivelin> Vilipan, we try to keep the index up to date
[12:01] <ivelin> telestax.com/opensource/
[12:01] <ivelin> if you see anything missing, raise a flag
[12:02] <ivelin> also keep in mind that most users are looking for one particular type of technology. They often land on the page of the project that offers what they need.
[12:02] <ivelin> Its not common that someone needs the full stack from the start.
[12:03] <ivelin> Alex, do you want to brave an initial release date?
[12:03] <vilpan> ivelin: looks nice, maybe I was still with the impression of the mobicents.org that was a bit outdated for some time
[12:03] <ivelin> mobicents.org is now also updated
[12:03] <ivelin> thanks to Jean
[12:04] <vilpan> ivelin: yes, just checked it, of course :)
[12:05] <@alexandrem> ivelin: I will commit a first version this week. I think we can aim for a release in 1st week of Dec
[12:06] <ivelin> awesome, Alex
[12:06] <ivelin> #4 SS7/GMLC/USSD/SMSC/EIR
[12:07] <svetyutnev> let me update SS7 today
[12:07] <svetyutnev> 1) Completed 2.0.0.BETA3 issues like sccp xml is now properly formatted instead of including class names.
[12:07] <svetyutnev> Interfaces created so JMX management can use these API's for managing resources and rules
[12:07] <svetyutnev> more or less ready for jss7 2.0.0 BETA3 release (target is this weekend)
[12:07] == vilpan [~0...@88-119-197-33.static.zebra.lt] has quit [Quit: Leaving.]
[12:07] <svetyutnev> MAP Geo primitives implementation in progress (they are needed for location services - GMLC project)
[12:08] <svetyutnev> MAP error messages implementation is also completed. Now error messages for CAP and MAP protocols are fully implemented
[12:08] <svetyutnev> 2) EIR : documentation part is getting over (from commits of Normandes)
[12:08] <svetyutnev> 3) USSD Push more or less ready (Bartek can update more)
[12:12] <ivelin> Bartek?
[12:13] == barreiro [~barr...@bl21-247-174.dsl.telepac.pt] has joined #mobicents
[12:16] <ivelin> thank you, Sergey
[12:16] <ivelin> #5 Media Server
[12:16] <yulian_o> not much upate here , still mgcp client perfomance issue opened , working on it
[12:17] <yulian_o> thats it
[12:19] <ivelin> are all issues for 3.0.0.Final closed ?
[12:19] <yulian_o> except this one , and making mgcp endpoints name last node as numeric yes
[12:20] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
[12:20] <ivelin> the latter is to avoid pre-allocating large numbers of end-points, right?
[12:21] <yulian_o> correct
[12:21] <yulian_o> to allow mms expand the number of endpoints when needed
[12:24] == Guest22222 has changed nick to fcr
[12:25] == fcr has changed nick to Guest11785
[12:26] <ivelin> great. thanks.
[12:26] <ivelin> #6 JSLEE
[12:28] <@mart1ns> there are no significant updates on SLEE land this week
[12:28] <ivelin> @martins^
[12:29] <ivelin> what's the plan?
[12:30] <@mart1ns> the http client ra is not yet finished, in fact I was not able this week to make any progress
[12:31] <@mart1ns> alexandrem: any update on your side?
[12:32] <@mart1ns> the plan is all on Telscale side till the end of the year, except for the new/updated RAs
[12:32] <@mart1ns> with Telscale SLEE 6.1.2 around xmas
[12:33] <ivelin> what are the goals for telscale jslee through the end of the year?
[12:34] <ivelin> #7 Productization
[12:34] <@mart1ns> Telscale SLEE release at the end of December with common admin, snmp, new nio based http client RA, new http server RA, smpp with another stack
[12:34] <ivelin> slegrik^
[12:34] <ivelin> oh, darn, this is what I forgot!
[12:34] <slegrik> eduardo, my turn ?
[12:34] <@mart1ns> the new http server ra may be hard, still no news on this one previously assigned to Normandes
[12:35] <ivelin> #9 Admin tools
[12:35] <ivelin> Pavel, you're on.
[12:35] <@mart1ns> slegrik: seems so
[12:35] <@mart1ns> :)
[12:35] <slegrik> ok
[12:35] <slegrik> This week I have finished with preparation of Telscale jss7 release script, so we are ready for Telscale-ss7-6.1.3.GA once 2.0.0.Beta3 ss7
[12:35] <slegrik> is out (as Sergey mentined, target for jss7 2.0.0.Beta3 is this weekend).
[12:35] <slegrik> I've jsut started with preparation of telscale ussdgw release script, which I think will be ready till end of this week
[12:35] <slegrik> I have also started with license key enforcement topic, just made a preliminary research and will continue with designing the possible
[12:35] <slegrik> solution for Telscale products.
[12:36] <slegrik> The overall basic idea is to have set up a licencing server, which will authenticate every product request for licence key validation.
[12:36] <slegrik> Anyway, once I have more concreate idea will send to core to share with others for broader discussion.
[12:36] <slegrik> that's it
[12:38] <ivelin> thanks Pavel, you're getting the idea with the licensing keys.
[12:39] <ivelin> #8 Docs
[12:39] <ivelin> Charles?
[12:39] <ivelin> charles_r^
[12:39] <charles_r> Is @alexandrem still online? Alexandre could you spare a few moment after the meeting to help with JainSLee?
[12:39] <charles_r> Ok
[12:40] <charles_r> Restcomm update with a little graph http://telestax.com/2012/10/24/getting-started-with-restcomm/
[12:41] <@alexandrem> charles_r: sure, I can assist you
[12:42] <charles_r> are you online in the chat with your telestax account ?
[12:43] <ivelin> there is a typo
[12:43] <ivelin> "Saves time"
[12:43] <charles_r> ok
[12:43] <charles_r> note taken
[12:43] <ivelin> what's the status with slee docs?
[12:44] == yulian_o [51dac2ab@gateway/web/freenode/ip.81.218.194.171] has quit [Quit: Page closed]
[12:44] <ivelin> also, any update from Vinu?
[12:45] <charles_r> little progress from slee doc apart from the diameter doc that was reviewed.
[12:46] <ivelin> do you know what Vinu is working on?
[12:46] <charles_r> s
[12:46] <charles_r> It was difficult to review some docs because of the way they were written and with little understanding of way it work
[12:47] <charles_r> I under a bit more and hopefully with the help of @alexandrem I can proceed with the slee doc review
[12:47] <ivelin> which docs?
[12:47] <charles_r> I mean the slee docs
[12:48] <charles_r> No news from Vinu
[12:49] <charles_r> maybe amit as more info
[12:50] <charles_r> the other comment doesn't make much sense, what I meant was that doc slee review will be faster after testing
[12:51] <ivelin> ok, we can get an offline update from her
[12:51] <charles_r> restcomm and slee in progress
[12:51] <charles_r> that's all
[12:52] <ivelin> what tool do you use for the restcomm diagrams?
[12:54] <charles_r> gimp
[12:55] <ivelin> I see. The style reminds me of ppt diagrams from the 90s
[12:55] <ivelin> does gimp have more modern look and feel diagrams?
[12:56] <ivelin> I think even the free Google Draw diagrams look more modern
[12:56] <@alexandrem> I've registered for an online diagram tool which seems cool.. let me try to find the link
[12:56] <charles_r> retro feel lol
[12:57] <ivelin> yes it is retro
[12:57] <ivelin> the text font is also retro
[12:57] <charles_r> I'll look into the google draw tool
[12:57] <@alexandrem> https://www.gliffy.com/
[12:59] <charles_r> thanks for the link
[13:00] <charles_r> I'll try the graphic and send to core to see what everyone thinks
[13:00] <ivelin> this tool's examples look slightly better than Google Draw
[13:01] <ivelin> let's move on
[13:01] <ivelin> #9 Admin tools
[13:01] <ivelin> Alex, have you been able to think about this topic? Unified admin tooling - UI, CLI?
[13:04] <@alexandrem> well, we have talked about it a while. will try to work on o PoC for a common web console, where items can be plugged and/or discovered
[13:05] <@alexandrem> ie, being able to deploy new modules to the existing SLEE web console
[13:05] <ivelin> right, the task is harder than that
[13:06] <ivelin> SIP Servlets, Restcomm management, SS7 products
[13:06] == babak11 [~ba...@2.178.120.19] has quit [Quit: Nettalk6 - www.ntalk.de]
[13:06] <@alexandrem> right.. the idea would be to deploy an SS7 module, and once it's deployed new entries for managing SS7 will be shown
[13:06] <ivelin> even the CLI is not unified now
[13:07] <@alexandrem> well, regarding CLI I think it may be easier.. as it's a matter of supporting new sets of commands
[13:08] <@alexandrem> I don't have much experience with CLI dev, but I think it should be easily extensible in that sense
[13:08] <ivelin> it should be easier, but we don't use the same server APIs nor the same client tool
[13:08] <@alexandrem> I can do some research regarding that
[13:09] <ivelin> curl seems to be the defacto standard CLI tool for SaaS
[13:09] <@alexandrem> that's a matter of the communicating interface
[13:09] <ivelin> a few weeks ago it was brought up that the new AS7 CLI tool is more appropriate for java CLI, even though its not as ubiquitous for sysadmins
[13:10] <@alexandrem> curl is an HTTP client, so all we'd need is an HTTP lib. I guess. Maybe I'm over-simplifying :)
[13:10] <ivelin> well there is jmx to rest bridge, so in theory it should be straightfoward to standardize
[13:12] <@alexandrem> right. still we can have the CLI talk many languages, depending on the command, if that's required.. I think/hope :)
[13:13] <ivelin> http://stackoverflow.com/questions/1571600/is-there-any-jmx-rest-bridge-available
[13:15] <@alexandrem> Jolokia looks like an option
[13:16] <ivelin> I was just looking at it
[13:16] <ivelin> ASL 2 license
[13:16] <@alexandrem> JS client. may come handy :)
[13:16] <ivelin> http://nurkiewicz.blogspot.com/2011/03/jolokia-highcharts-jmx-for-human-beings.html
[13:17] <ivelin> yup
[13:19] <ivelin> ok, the topic is officially kicked off. It has place on the agenda from now on.
[13:20] <ivelin> anything else we need to cover team?
[10:11] <ivelin> tommyq^
[10:11] <tommyq> Okay
[10:11] <tommyq> hey guys, hope everyone is good.
[10:12] <ivelin> yes, we've been behaving
[10:12] <ivelin> why?
[10:12] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has joined #mobicents
[10:12] <ivelin> you got Christmas gifts for us?
[10:13] <abhayani> lol
[10:13] <tommyq> lol
[10:13] <gvag> :-)
[10:13] == okulikov [~okul...@178.35.156.160] has joined #mobicents
[10:13] <tommyq> On the RestComm side we have been focusing heavily on reliability which means bug fixes and docs as promised. I have also started work on WebUI and production documents.
[10:14] <ivelin> what's production documents?
[10:14] <ivelin> hello?
[10:14] <tommyq> integration with puppet and open source tools like open sips (until we have our own) and just general thoughts
[10:15] <tommyq> things that people will need to seriously deploy RestComm for production
[10:16] <tommyq> The docs are still very new I will share when there is enough meat but I am constantly working on them when I pause or have to do something that involves me waiting
[10:16] <ivelin> on the sbc topic, we need that document to describe the use cases that need to be covered.
[10:16] <tommyq> By the way I will only share with core these are for TeleStax
[10:16] <tommyq> yes sir
[10:16] <tommyq> :)
[10:16] <tommyq> I am taking a use case approach it's easy for everyone to understand
[10:16] <ivelin> there was another offline discussion about integration with our HA layer
[10:17] <tommyq> HA, not fail over, right?
[10:17] <ivelin> its understood for the most part how our converged LB works with the app servers behind it
[10:17] <ivelin> failover and load balancing
[10:18] <tommyq> failover is not necessary just HA
[10:18] <ivelin> but its not well understood what variables SBC introduces
[10:18] <tommyq> LB is important and we can use any tool we like
[10:18] <jean_> tommyq, yulian_o was syaing in Rio we should do the NAT thing in restcomm itself
[10:18] <tommyq> well OpenSIPs can act as an SBC but it's very flexible it will do what we need it to do and nothing else.
[10:19] <jean_> tommyq, the idea was to reduce infra costs
[10:19] <tommyq> @jean_, yes that is on the roadmap for Telscale distro
[10:19] <jean_> and have less layer to manager
[10:19] <jean_> manage
[10:19] <jean_> openSIPs had its own issues back in the day
[10:19] <jean_> where you had to put fixes into it
[10:19] <yulian_o> the problem starts where you want to change something and you have 3rd party module , in nat there is plenty of different situatuion which are not correctly handled , and they must be done in code
[10:20] <jean_> when we had it on EC2 last year
[10:20] <tommyq> of course like all software as it matures :)
[10:20] <yulian_o> i had to change sip stack to resolve problems
[10:20] <jean_> I wouldn't go that route again
[10:20] <tommyq> actually
[10:20] <tommyq> okay
[10:20] <tommyq> no fixes where for opensips itself
[10:20] <jean_> yulian_o, I was looking at the SIP issue
[10:20] <tommyq> it was config oversights
[10:20] <jean_> yday
[10:20] <jean_> can you pvide a diff for it
[10:20] <jean_> diff patch
[10:20] <jean_> this is the full class right now and it's hard to see where the changes are
[10:20] <yulian_o> i can provide the udp channel file :)
[10:21] <jean_> yulian_o, a diff for the udpchannel
[10:21] <tommyq> with opensips we actually never had a problem where opensips was the issue
[10:21] <yulian_o> i dont have source , i had to disassemble it!
[10:21] <jean_> yulian_o, what ?
[10:21] <jean_> http://code.google.com/p/jain-sip/source/checkout
[10:22] <yulian_o> its now \
[10:22] <jean_> tommyq, I see the NAT is for this release
[10:22] <jean_> http://code.google.com/p/restcomm/issues/detail?id=62
[10:23] <jean_> next CR1 release I meant
[10:23] <tommyq> which one CR1
[10:23] <tommyq> ?
[10:23] <jean_> so let's get it done when you have cycles to work on it
[10:23] <jean_> instead of using opensips
[10:23] <tommyq> okay so moving on we can definitely handle NAT in RestComm and put the Mobicents LB on the edge along with DNS SRV records to have as few layers as possible.
[10:23] <tommyq> Doing it is simple
[10:23] <jean_> right
[10:25] <tommyq> That's it for me, George my friend please add anything on your end.
[10:25] <gvag> nothing new since yesterday from me.
[10:26] <jean_> we might include a STUN/TURN server to support ICE in the future
[10:26] <jean_> as this is something we will probably need for WebRTC as well
[10:27] <tommyq> Sure, I believe George had it working with STUN at one point but not sure.
[10:27] <tommyq> :)
[10:27] <ivelin> so is it agreed then that for the restcomm live case, we can handle nat in restcomm itself?
[10:27] <gvag> yeah but that was STUN setting on the sip client
[10:28] <tommyq> yes
[10:28] <ivelin> no need for opensips?
[10:28] <tommyq> no since we aren't going to deal with fail-over where the media has to be failed over as well we don't need it
[10:28] <yulian_o> i have sent the file
[10:28] <tommyq> it would be overkill and an extra unnecessary hop
[10:29] <ivelin> issue #62 says that restcomm will integrate with an sbc, not that it will handle NAT directly
[10:29] <tommyq> huh
[10:29] <gvag> d
[10:29] <tommyq> yeah
[10:29] <tommyq> I think that had to do with sipXecs
[10:29] <tommyq> a real sbc wouldn't need any integration
[10:29] <tommyq> SIP is it
[10:30] <ivelin> so 62 needs to be renamed to Handle NAT directly in Restcomm ?
[10:31] <tommyq> No there should be a separate ticket for that
[10:31] <ivelin> what component will handle rtp address/port NAT?
[10:31] <tommyq> I opened it in Rio
[10:31] <tommyq> http://code.google.com/p/restcomm/issues/detail?id=109
[10:32] <ivelin> I see. 109 is now targeted for cr1 and 62 goes to the backburner?
[10:32] <tommyq> I'm not sure.
[10:32] <tommyq> George would you like to elaborate on 62 for us
[10:32] <tommyq> i guess with 109 62 will not be fixed
[10:32] <gvag> the idea behind 62 was to handle nat issue on Restcomm
[10:33] <tommyq> oh was it
[10:33] <tommyq> I'm sorry
[10:33] <tommyq> I wouldn't have opened a duplicate
[10:33] <gvag> we can tag as invalid
[10:33] <tommyq> perfect
[10:33] <ivelin> so 62 should be marked as dupe and closed?
[10:34] <tommyq> yep as invalid and closed :)
[10:34] <ivelin> would our sip lb sit in front of restcomm?
[10:34] <tommyq> yes
[10:35] <ivelin> so the restcomm sip servlet will handle SIP NAT
[10:35] <ivelin> what about rtp
[10:35] <ivelin> what component will handle rtp address/port NAT?
[10:35] <tommyq> and then we would use SRV records for DNS fail-over or we can use floating IPs and a heartbeat
[10:35] <tommyq> MMS
[10:35] <tommyq> MMS can already handle NAT
[10:35] <tommyq> for RTP
[10:35] <ivelin> MMS will be on public IP?
[10:35] <tommyq> Well nothing on EC2 is on a real IP
[10:36] <tommyq> It's static nat
[10:36] <tommyq> So EC2 Firewall -> MMS
[10:36] <ivelin> but there are IPs that are visible from the world and IPs that are only visible from EC2
[10:36] <tommyq> correct
[10:36] <tommyq> and you forward desired traffic from public to private
[10:37] <yulian_o> mms works now without sbc before it right?
[10:37] <tommyq> right
[10:37] <ivelin> MMS will be visible from the world or only the restcomm sip servlet?
[10:37] <tommyq> well the MGCP interface only from restcomm
[10:37] <tommyq> and the rtp interfaces the whole world
[10:37] <tommyq> it would be nice if we can configure an rtp port range
[10:37] <tommyq> for added security
[10:38] <gvag> you will need to have a firewall rule for rtp range to be accesible from any io
[10:38] <gvag> *ip
[10:38] <tommyq> right now it's tough because it's random I believe
[10:38] <tommyq> correct
[10:38] <yulian_o> 2 ivelin : there are 2 ip addresses you can configure on mms , local and remote , mgcp always run on local ip , rtp by default on external , but you can add typeOfNetwork.Local to crcx request
[10:38] <gvag> the rtp range is specific but huge
[10:38] <ivelin> thanks, Yulian. Makes sense
[10:39] <tommyq> yulian_o, how hard would it be to make the rtp range configurable?
[10:39] <yulian_o> not hard
[10:39] <tommyq> By the way RestComm will have a local and remote IP as well.
[10:39] <tommyq> it's the only way it will work on EC2
[10:39] <ivelin> which module will be resposible for SDP rewrite in the SIP exchange?
[10:39] <tommyq> because we must use the remote IP
[10:39] <tommyq> but we have to bind to the local
[10:39] <tommyq> RestComm
[10:40] <yulian_o> its actually configurable!
[10:40] <tommyq> Sweet! How do I we do it? That is awesome when sitting behind firewalls
[10:40] <ivelin> I see. Tom please diagram the use case for restcomm live in the doc.
[10:41] <tommyq> I will
[10:41] <yulian_o> and highestPort and lowestPort params to localhost bean
[10:41] <tommyq> By the way this doc is for core only.
[10:41] <yulian_o> it will make difference only for external ip address
[10:41] <yulian_o> which is logically good since you dont have to limit your local interface
[10:41] <yulian_o> seehttps://code.google.com/p/mediaserver/source/browse/io/network/src/main/java/org/mobicents/media/server/io/network/UdpManager.java#207
[10:42] <tommyq> we may want to just because other machines inside EC2 may be able to reach ours.
[10:43] <yulian_o> what do you mean?
[10:43] <tommyq> I have to do a bit more homework on how they route internal traffic but we should be on different vlans
[10:43] <tommyq> if we are not on a different vlan on the EC2 network and other VMs can see ours then we will need a firewall on the VM itself
[10:44] <tommyq> but this is something I'm not sure of so I wouldn't worry about it until it's a problem
[10:44] <tommyq> I will do the right homework and ask you questions as I go
[10:44] <yulian_o> you have external ip on mms for everything that is not part of your network
[10:44] <tommyq> correct
[10:44] <yulian_o> and you have internal ( mostly 127.0.0.1 or some internal ip address if you have several mms servers )
[10:45] <yulian_o> on internal there is no option to set a limit of ports , since they should not be firewalled anyway
[10:45] <tommyq> the VMs on EC2 are part of a class A network with 16,000,000 other VMs
[10:45] <yulian_o> on external you have option to set them
[10:45] <tommyq> most of which don't belong to us
[10:45] <yulian_o> in your case all VMs should contact external ip address
[10:45] <tommyq> That's what I'm not sure about and those policies are out of our control
[10:46] <yulian_o> everything that is out of your controll === external ip for mms :) even when its 10.0.0 , or 172
[10:46] <ivelin> ok, glad we have a NAT plan. Looking forward to see it in writing.
[10:46] <yulian_o> btw you never use typeofnetwork.local in restcomm :)
[10:47] <yulian_o> its not documented either yet
[10:47] <tommyq> no, I didn't know
[10:47] <tommyq> :)
[10:47] <tommyq> but now I can ;)
[10:47] <ivelin> #2 SIP Servlets
[10:47] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
[10:48] <ivelin> SIP Servlets gang?
[10:48] <jean_> vralev,
[10:48] <jean_> can you update
[10:48] <vralev> ok
[10:48] <jean_> between yday travel and visa today
[10:48] <jean_> I couldn't check the backlog
[10:49] <jean_> yet
[10:49] <vralev> WebSocket TLS is checked in together with TLS memory optimization, TLS is now about the same footprint as TCP with the occasinal overhead of the framgemented buffers and SSLEngine
[10:49] <vralev> then
[10:50] <vralev> there are a couple of other fixes in JSIP again - timers config, memleak fix
[10:50] <vralev> arquillian gets another fix too
[10:51] <vralev> and clustering for AS7 starting too now
[10:52] <vralev> that's all I think
[10:52] <ivelin> what's the plan for MSS 2.0 clustering?
[10:53] <vralev> first just use the HTTP clustering as a base and then we will see if something else is needed I think
[10:53] <vralev> HTTP clustering is so much easier, they have just 5 testcases and it covers it all
[10:54] <vralev> there is a plan about pluggable replication and if HTTP is indeed so easy we might do alternative HTTP clustering as well for tomcat
[10:54] <jean_> right
[10:54] <jean_> that's the plan
[10:54] <vralev> but those are not final, first just the normal clustering closely following the AS7 built-in replication layer
[10:55] <ivelin> what clustering framework will do the cross-node replication?
[10:57] <vralev> infinispan embedded
[10:57] <ivelin> ok
[10:58] <ivelin> cassandra is not on the test roadmap yet?
[10:58] <jean_> not yet
[10:59] <jean_> easier to tune the API with ISPN first
[10:59] <vralev> cassandra requires a completely different approach
[10:59] <vralev> so that would be a huge rewrite if we ever want to do it
[10:59] <jean_> not if we use the cluster fwk right ?
[11:00] <vralev> what fwk is that?
[11:01] <jean_> the cluster framework used by MSS And SLEE for Timers
[11:01] <jean_> SLEE uses it for everything related to HA
[11:01] <jean_> http://code.google.com/p/commscale.cluster
[11:01] <vralev> you mean combine cassandra with infinispan?
[11:02] <jean_> no
[11:02] <jean_> I mean
[11:02] <jean_> MSS uses Cluster as an API
[11:02] <jean_> for replication
[11:03] <jean_> and the Cluster uses a pluggable technology
[11:03] <jean_> ISPN
[11:03] <jean_> or Cassandra
[11:03] <jean_> that is configured at startup tim
[11:03] <vralev> ok, but you remember I wronte a huge document explaining that some APIs just can't be implemnted using cassandra and the likes
[11:03] <vralev> the nodeModified callbacks and etc
[11:04] <jean_> riht
[11:04] <jean_> right
[11:04] <@mart1ns> do you really need that in the api seen by mss?
[11:04] <jean_> I See what you mean in term of rewrite now
[11:04] <jean_> it would need adaptation at the cluster fwk
[11:05] <@mart1ns> we used so far only data removed callback
[11:05] <vralev> mart1ns: we dont need it per se, but it's going to change a lot of things
[11:06] <@mart1ns> in timers, jsip ha, slee, diameter
[11:06] <@mart1ns> doesn't cassandra have any callbacks?
[11:06] <vralev> dataRemoved is in the same boat, there are simply no callbacks in thrift, hotrod or any of the remote protocols for caching
[11:07] <vralev> although I got to check again these days
[11:08] <@mart1ns> anyway, I still think that a remote cache like cassandra has no latency for the job in mobicents
[11:08] <vralev> I will check again, but last time I checked there were no callbacks in any of those
[11:08] <vralev> hotrod2 had them on the roadmap
[11:08] <ivelin> the cassandra route would be probably fundamentally different
[11:08] <@mart1ns> cassandra mimics database perf requirements, not caches
[11:08] <ivelin> instead of maintaining up to date in-memory cache, the new node would have to restore state as needed from the cassandra copy wherever it is
[11:08] <@mart1ns> there is another apache cache that is good performance wise
[11:09] <@mart1ns> but it requires nodekeys to be strings
[11:09] <@mart1ns> and that is a PITA
[11:10] <ivelin> I think we covered this many times - full replication is only required in a few rare cases
[11:11] <@mart1ns> zookeeper
[11:11] <ivelin> dropped calls aren't that uncommon for the vast majority of applications
[11:11] <@mart1ns> ivelin: iirc everyone wants early dialog failover
[11:12] <@mart1ns> that's far far away from high availability only
[11:12] <jean_> ivelin, this is not what we settled on
[11:12] <jean_> we settled on reverse
[11:12] <ivelin> its really the app's decision what and how to replicate. For conferencing for example, the conference context can be in a db, individual callers can drop and redial if needed as long as the conf room is alive.
[11:12] <jean_> people that will need replication will need high consistency
[11:13] <jean_> if they are willing to tolerate dropped calls
[11:13] <@mart1ns> for restcomm I think high availability can be enough
[11:13] <jean_> they can go for load balancing only
[11:13] <@mart1ns> the call dropping can be re-established
[11:13] <jean_> but failover requires high consistency
[11:13] <@mart1ns> but for AS customers high availability is not enough
[11:13] <ivelin> right, for those use cases like 911, the synced replication is a deal saver.
[11:14] <jean_> for telepresence for high end customers as well
[11:14] <jean_> like CEOs etc
[11:14] <ivelin> right
[11:14] <jean_> or for core network IMS
[11:14] <jean_> for billing, CDRs
[11:14] <jean_> for generating*
[11:14] <vralev> someone's got to check if 911 really need replication or just 99.999, because those are different
[11:15] <jean_> what we need is a solution with high consistency that can scale
[11:15] <ivelin> so there are two fundamentally different ways apps can go -> high cost, full replication or low cost failover with partial static context saved in the db
[11:16] <jean_> I think you can tune Cassandra to choose which concept of the CAP theorem
[11:16] <jean_> you can drop
[11:16] <jean_> in favor of te 2 others but not sure
[11:17] <ivelin> cassandra can provide high consistency when configured for it
[11:18] <jean_> then the deal breaker would be on performance
[11:18] <vralev> but consistency is only needed at the app layer for money transactions, not on the system layer I imagine
[11:18] <ivelin> the new node will incur a hit to restore state, but that's most likely invisible to the caller. Should be within ms.
[11:19] <vralev> system layer can fail all it wants, we just need to feed the app proper events so it can recover (end charging etc)
[11:19] <jean_> ivelin, depends on the size of the state to recover
[11:19] <ivelin> yes, I think Vladimir is right. As long as there is a log of events that can help restore good state, the time it takes to do it should be pretty fast.
[11:20] <@mart1ns> ivelin: that is thinking on a call failure
[11:20] <@mart1ns> not on a busy node failure
[11:20] <@mart1ns> which has thousands of calls to be recovered by other nodes
[11:21] <@mart1ns> anyway recover time is not really important
[11:21] <@mart1ns> what is important is the replication cost at runtime, that is, when all works fine
[11:22] <ivelin> Jean, the size of the state for a phone call is negligible compared to the kind of data modern dbs are designed to handle.
[11:22] <@mart1ns> if you store data in a database (remote or not), it's going to screw the server performance
[11:22] <ivelin> Eduardo, I agree. The runtime cost of synced multi-node replication is so high.
[11:22] <@mart1ns> it adds latency in every msg
[11:22] <@mart1ns> and that is severe for cpu
[11:23] <ivelin> well now, that's just nonsense
[11:23] <@mart1ns> there is a reason why telco apps have different latency requirements than enteprise
[11:23] <ivelin> the throughput of nosql dbs is insanely high these days.
[11:24] <ivelin> yet another piece of mythology
[11:24] <@mart1ns> it's not throughput, it's latency
[11:24] <@mart1ns> it's not a myth lol
[11:24] <ivelin> ok, let the tests prove that
[11:24] <@mart1ns> if I add 1ms on each cluster call on a slee perf test
[11:24] <vralev> i sense everyone is now talking about different things already :)
[11:24] <@mart1ns> it ruins by hundreds of cps
[11:25] <jean_> vralev, I have the same feeling :-)
[11:25] <@mart1ns> and the latency increase on db is way higher than 1ms
[11:25] <ivelin> Vlarev is probably right again :)
[11:25] <@mart1ns> you put everything on old on IO ports
[11:25] <@mart1ns> due to that latency increase
[11:26] <@mart1ns> hold
[11:26] <ivelin> IO ports are there for any kind of replication
[11:26] <@mart1ns> it's incredible how severe is the impact we had on slee on every optimization
[11:26] <@mart1ns> for saving latency in very small things
[11:26] <@mart1ns> now if I change 4 or 5 calls to jbosscache to a db
[11:27] <@mart1ns> it's insane :)
[11:28] <@mart1ns> I'm not saying you can't be right
[11:28] <@mart1ns> it can become fast
[11:28] <@mart1ns> but each time the db gets fast, the cache gets too
[11:29] <@mart1ns> and every customer will enjoy every load increase
[11:29] <@mart1ns> it's where they spend $$
[11:31] <vralev> we are offtopic, but to add more fire for design issues - also DBs incling JDBC, thrift, hotrod will need to be consumed in synchronous way meaning any glitch in the TCP connection gets you deadlocked and will snowball into a crash in few secs
[11:31] <@mart1ns> hadoop performance/latency wise system is zookeeper
[11:32] <vralev> there is async versions of these, but replacing the current calls with those will be insanely difficult
[11:32] <@mart1ns> but like I mentioned before, has a terrible requirement of string data keys
[11:32] <ivelin> ok, let's leave it to test numbers to speak
[11:32] <@mart1ns> vralev: you don't need to see that in the cluster api
[11:33] <vralev> mart1ns: you do
[11:33] <@mart1ns> you just need a key,value api and a few more basic features
[11:33] <vralev> well cluster API will need to have cache.put() and cache.putAsync() or only putAsync
[11:34] <@mart1ns> I was able to switch from ISPN to hazelcast in 2 days with an api that is enough for what we need
[11:34] == okulikov [~okul...@178.35.156.160] has quit [Ping timeout: 245 seconds]
[11:34] <ivelin> Vralev, TCP may be a theoretical problem, but is that happening in practice. See the amounts of apps that depend on these APIs.
[11:35] <@mart1ns> basically you need put/get + relations
[11:35] <vralev> this is not theoretical problem, I am dealing with it everyday
[11:35] <@mart1ns> relations is where the perf may degrade
[11:35] <vralev> if you remember Jonas reported the same issue although not with DB
[11:35] <@mart1ns> I suspect this is why I got bad rrsults with ISPN some time ago
[11:36] <vralev> anyway, I am probably not explaining it right and it's not that important right now
[11:37] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has joined #mobicents
[11:38] == abhayani [~abha...@41.206.1.3.vgccl.net] has quit [Ping timeout: 246 seconds]
[11:38] <@mart1ns> imho the ability to switch the underlying framework is a must, even if we need to code a bit more on our side due to have only basic features
[11:38] <jean_> right
[11:39] <ivelin> Vladimir, is TCP connections are unreliable, there must be a solution that is used for these massive reads/writes to nosql dbs
[11:39] <@mart1ns> batches?
[11:43] <vralev> well switching underlying framework certainly forces you to generalize your API in some portable way, so no callbacks, no async methods, no delta serialization, no hashed destinations and so on. You lose powerful features each underlying implementation has
[11:44] <@mart1ns> no, you do that our cluster impl
[11:44] <ivelin> HA is always a fun topic, isn't it
[11:44] <@mart1ns> you adapt the impl to take the best advantage of the underlying framework
[11:44] <ivelin> let's take it offline
[11:44] <ivelin> #3 Diameter/OCS
[11:44] <@alexandrem> hi all
[11:44] <vralev> It's not that TCP connections are unreliable, it's just that they synchrounly block until they receive the response, which can be delayed for a number of everyday reasons and once you have all (100 or so) threads stuck the requests accumulate in the queue beyond the available capacity
[11:45] <@mart1ns> while in high level you depend only on the basics
[11:45] <@alexandrem> ok.. I'll wait :)
[11:45] <@mart1ns> yet listeners are a must ;-)
[11:45] <@mart1ns> sorry alexandrem, go on
[11:45] <@alexandrem> np
[11:45] <vralev> I agree, better to move on
[11:45] <@alexandrem> regarding diameter, I have been reviewing the patch contributed with several enhancements, split it into 3 major ones:
[11:45] <@alexandrem> Improve Diameter Router Performance & Footprint (http://code.google.com/p/jdiameter/issues/detail?id=23)
[11:45] <@alexandrem> Improve Peer FSM to be Multi-Threaded (http://code.google.com/p/jdiameter/issues/detail?id=24)
[11:46] <@alexandrem> TCP Transport to use non-blocking I/O (http://code.google.com/p/jdiameter/issues/detail?id=25)
[11:46] <@alexandrem> we are currently discussing some of the drawbacks of some approaches taken in the patch and I've been also performing some perf tests to see the benefits
[11:47] <@alexandrem> but mostly these changes should be integrated as they provide good results
[11:48] <@alexandrem> with respect to OCS, the JSLEE prototype is pretty much ready, just needs a few more adjustments and I will put it live
[11:48] <@alexandrem> should be a good start point for someone wanting to play with it
[11:49] <@alexandrem> btw, ivelin, shall I create a standalone gcode project to include it or for now just have it under diameter examples tree ?
[11:51] <ivelin> OCS is a new project
[11:51] <ivelin> is the main point of migrating to JSLEE so that it can support SS7 API?
[11:54] <vilpan> I just want to stress the importance of indexing all the projects in a central place with nice descriptions and such. The multitude of different projects is really great, but new users feel lost all the time
[11:54] <@alexandrem> ivelin: possibly. having it on JSLEE allows to much better integration with other protocols
[11:55] <@alexandrem> vilpan: I agree. a reference to any Diameter related project will always be present in the main diameter project, as it is now, referencing the JSLEE RAs
[11:56] <vilpan> alexandrem: yes, I just brought it up once again in this context, though I mean all the projects, including GMLC, jEIR, OCS, etc.
[12:00] == barreiro [~barr...@2.82.247.174] has quit [Ping timeout: 268 seconds]
[12:01] <ivelin> Vilipan, we try to keep the index up to date
[12:01] <ivelin> telestax.com/opensource/
[12:01] <ivelin> if you see anything missing, raise a flag
[12:02] <ivelin> also keep in mind that most users are looking for one particular type of technology. They often land on the page of the project that offers what they need.
[12:02] <ivelin> Its not common that someone needs the full stack from the start.
[12:03] <ivelin> Alex, do you want to brave an initial release date?
[12:03] <vilpan> ivelin: looks nice, maybe I was still with the impression of the mobicents.org that was a bit outdated for some time
[12:03] <ivelin> mobicents.org is now also updated
[12:03] <ivelin> thanks to Jean
[12:04] <vilpan> ivelin: yes, just checked it, of course :)
[12:05] <@alexandrem> ivelin: I will commit a first version this week. I think we can aim for a release in 1st week of Dec
[12:06] <ivelin> awesome, Alex
[12:06] <ivelin> #4 SS7/GMLC/USSD/SMSC/EIR
[12:07] <svetyutnev> let me update SS7 today
[12:07] <svetyutnev> 1) Completed 2.0.0.BETA3 issues like sccp xml is now properly formatted instead of including class names.
[12:07] <svetyutnev> Interfaces created so JMX management can use these API's for managing resources and rules
[12:07] <svetyutnev> more or less ready for jss7 2.0.0 BETA3 release (target is this weekend)
[12:07] == vilpan [~0...@88-119-197-33.static.zebra.lt] has quit [Quit: Leaving.]
[12:07] <svetyutnev> MAP Geo primitives implementation in progress (they are needed for location services - GMLC project)
[12:08] <svetyutnev> MAP error messages implementation is also completed. Now error messages for CAP and MAP protocols are fully implemented
[12:08] <svetyutnev> 2) EIR : documentation part is getting over (from commits of Normandes)
[12:08] <svetyutnev> 3) USSD Push more or less ready (Bartek can update more)
[12:12] <ivelin> Bartek?
[12:13] == barreiro [~barr...@bl21-247-174.dsl.telepac.pt] has joined #mobicents
[12:16] <ivelin> thank you, Sergey
[12:16] <ivelin> #5 Media Server
[12:16] <yulian_o> not much upate here , still mgcp client perfomance issue opened , working on it
[12:17] <yulian_o> thats it
[12:19] <ivelin> are all issues for 3.0.0.Final closed ?
[12:19] <yulian_o> except this one , and making mgcp endpoints name last node as numeric yes
[12:20] == gg608f [~Ad...@c-67-180-129-182.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
[12:20] <ivelin> the latter is to avoid pre-allocating large numbers of end-points, right?
[12:21] <yulian_o> correct
[12:21] <yulian_o> to allow mms expand the number of endpoints when needed
[12:24] == Guest22222 has changed nick to fcr
[12:25] == fcr has changed nick to Guest11785
[12:26] <ivelin> great. thanks.
[12:26] <ivelin> #6 JSLEE
[12:28] <@mart1ns> there are no significant updates on SLEE land this week
[12:28] <ivelin> @martins^
[12:29] <ivelin> what's the plan?
[12:30] <@mart1ns> the http client ra is not yet finished, in fact I was not able this week to make any progress
[12:31] <@mart1ns> alexandrem: any update on your side?
[12:32] <@mart1ns> the plan is all on Telscale side till the end of the year, except for the new/updated RAs
[12:32] <@mart1ns> with Telscale SLEE 6.1.2 around xmas
[12:33] <ivelin> what are the goals for telscale jslee through the end of the year?
[12:34] <ivelin> #7 Productization
[12:34] <@mart1ns> Telscale SLEE release at the end of December with common admin, snmp, new nio based http client RA, new http server RA, smpp with another stack
[12:34] <ivelin> slegrik^
[12:34] <ivelin> oh, darn, this is what I forgot!
[12:34] <slegrik> eduardo, my turn ?
[12:34] <@mart1ns> the new http server ra may be hard, still no news on this one previously assigned to Normandes
[12:35] <ivelin> #9 Admin tools
[12:35] <ivelin> Pavel, you're on.
[12:35] <@mart1ns> slegrik: seems so
[12:35] <@mart1ns> :)
[12:35] <slegrik> ok
[12:35] <slegrik> This week I have finished with preparation of Telscale jss7 release script, so we are ready for Telscale-ss7-6.1.3.GA once 2.0.0.Beta3 ss7
[12:35] <slegrik> is out (as Sergey mentined, target for jss7 2.0.0.Beta3 is this weekend).
[12:35] <slegrik> I've jsut started with preparation of telscale ussdgw release script, which I think will be ready till end of this week
[12:35] <slegrik> I have also started with license key enforcement topic, just made a preliminary research and will continue with designing the possible
[12:35] <slegrik> solution for Telscale products.
[12:36] <slegrik> The overall basic idea is to have set up a licencing server, which will authenticate every product request for licence key validation.
[12:36] <slegrik> Anyway, once I have more concreate idea will send to core to share with others for broader discussion.
[12:36] <slegrik> that's it
[12:38] <ivelin> thanks Pavel, you're getting the idea with the licensing keys.
[12:39] <ivelin> #8 Docs
[12:39] <ivelin> Charles?
[12:39] <ivelin> charles_r^
[12:39] <charles_r> Is @alexandrem still online? Alexandre could you spare a few moment after the meeting to help with JainSLee?
[12:39] <charles_r> Ok
[12:40] <charles_r> Restcomm update with a little graph http://telestax.com/2012/10/24/getting-started-with-restcomm/
[12:41] <@alexandrem> charles_r: sure, I can assist you
[12:42] <charles_r> are you online in the chat with your telestax account ?
[12:43] <ivelin> there is a typo
[12:43] <ivelin> "Saves time"
[12:43] <charles_r> ok
[12:43] <charles_r> note taken
[12:43] <ivelin> what's the status with slee docs?
[12:44] == yulian_o [51dac2ab@gateway/web/freenode/ip.81.218.194.171] has quit [Quit: Page closed]
[12:44] <ivelin> also, any update from Vinu?
[12:45] <charles_r> little progress from slee doc apart from the diameter doc that was reviewed.
[12:46] <ivelin> do you know what Vinu is working on?
[12:46] <charles_r> s
[12:46] <charles_r> It was difficult to review some docs because of the way they were written and with little understanding of way it work
[12:47] <charles_r> I under a bit more and hopefully with the help of @alexandrem I can proceed with the slee doc review
[12:47] <ivelin> which docs?
[12:47] <charles_r> I mean the slee docs
[12:48] <charles_r> No news from Vinu
[12:49] <charles_r> maybe amit as more info
[12:50] <charles_r> the other comment doesn't make much sense, what I meant was that doc slee review will be faster after testing
[12:51] <ivelin> ok, we can get an offline update from her
[12:51] <charles_r> restcomm and slee in progress
[12:51] <charles_r> that's all
[12:52] <ivelin> what tool do you use for the restcomm diagrams?
[12:54] <charles_r> gimp
[12:55] <ivelin> I see. The style reminds me of ppt diagrams from the 90s
[12:55] <ivelin> does gimp have more modern look and feel diagrams?
[12:56] <ivelin> I think even the free Google Draw diagrams look more modern
[12:56] <@alexandrem> I've registered for an online diagram tool which seems cool.. let me try to find the link
[12:56] <charles_r> retro feel lol
[12:57] <ivelin> yes it is retro
[12:57] <ivelin> the text font is also retro
[12:57] <charles_r> I'll look into the google draw tool
[12:57] <@alexandrem> https://www.gliffy.com/
[12:59] <charles_r> thanks for the link
[13:00] <charles_r> I'll try the graphic and send to core to see what everyone thinks
[13:00] <ivelin> this tool's examples look slightly better than Google Draw
[13:01] <ivelin> let's move on
[13:01] <ivelin> #9 Admin tools
[13:01] <ivelin> Alex, have you been able to think about this topic? Unified admin tooling - UI, CLI?
[13:04] <@alexandrem> well, we have talked about it a while. will try to work on o PoC for a common web console, where items can be plugged and/or discovered
[13:05] <@alexandrem> ie, being able to deploy new modules to the existing SLEE web console
[13:05] <ivelin> right, the task is harder than that
[13:06] <ivelin> SIP Servlets, Restcomm management, SS7 products
[13:06] == babak11 [~ba...@2.178.120.19] has quit [Quit: Nettalk6 - www.ntalk.de]
[13:06] <@alexandrem> right.. the idea would be to deploy an SS7 module, and once it's deployed new entries for managing SS7 will be shown
[13:06] <ivelin> even the CLI is not unified now
[13:07] <@alexandrem> well, regarding CLI I think it may be easier.. as it's a matter of supporting new sets of commands
[13:08] <@alexandrem> I don't have much experience with CLI dev, but I think it should be easily extensible in that sense
[13:08] <ivelin> it should be easier, but we don't use the same server APIs nor the same client tool
[13:08] <@alexandrem> I can do some research regarding that
[13:09] <ivelin> curl seems to be the defacto standard CLI tool for SaaS
[13:09] <@alexandrem> that's a matter of the communicating interface
[13:09] <ivelin> a few weeks ago it was brought up that the new AS7 CLI tool is more appropriate for java CLI, even though its not as ubiquitous for sysadmins
[13:10] <@alexandrem> curl is an HTTP client, so all we'd need is an HTTP lib. I guess. Maybe I'm over-simplifying :)
[13:10] <ivelin> well there is jmx to rest bridge, so in theory it should be straightfoward to standardize
[13:12] <@alexandrem> right. still we can have the CLI talk many languages, depending on the command, if that's required.. I think/hope :)
[13:13] <ivelin> http://stackoverflow.com/questions/1571600/is-there-any-jmx-rest-bridge-available
[13:15] <@alexandrem> Jolokia looks like an option
[13:16] <ivelin> I was just looking at it
[13:16] <ivelin> ASL 2 license
[13:16] <@alexandrem> JS client. may come handy :)
[13:16] <ivelin> http://nurkiewicz.blogspot.com/2011/03/jolokia-highcharts-jmx-for-human-beings.html
[13:17] <ivelin> yup
[13:19] <ivelin> ok, the topic is officially kicked off. It has place on the agenda from now on.
[13:20] <ivelin> anything else we need to cover team?
Thomas Quintana
Nov 16, 2012, 11:53:54 AM11/16/12
to mobicent...@googlegroups.com
Hey guys,
So George and I are starting work on the RestComm Web UI and I realized that some of us are trying to produce a unified admin panel for the entire Mobicents stack. I really don't think this will work as the stack of products is diverse and a unified we interface would be a huge undertaking. If what we are looking of is a unified look and feel there are plenty of JS frameworks to help with that along with pluggable widgets and all the other necessities for building web apps. Please check out the YUI library as an example of a complete framework for building client side apps.
Tom
Ivelin Ivanov
Nov 16, 2012, 1:08:33 PM11/16/12
to mobicent...@googlegroups.com, mobicent...@googlegroups.com
When it comes to generic UI things are tricky. I agree with that. Look&feel guidelines may be a reasonable common denominator.
The Restcomm Web UI is targeting broader scope than sysadmins/devops. Most of the UI and API will be used by consumers of Restcomm as a service, i.e. app developers.
Parallel to that, a set of metrics that would be useful to Restcomm instance admins should fit in the admin framework that Alex is trying to design.
Ivelin
Reply all
Reply to author
Forward
0 new messages