IRC Devel Meeting - 2012-11-22

miconda: hi!
[4:00pm] pdunkley: Hello
[4:00pm] miconda: time to start ...
[4:01pm] miconda: not easy to find a day where people are available …
[4:01pm] miconda: happy Thanksgiving Day to everyone celebrating it! (if anyone here  )
[4:02pm] miconda: so, first topic ...
[4:02pm] osas: those are busy shopping now
[4:02pm] miconda: outstanding issues
[4:03pm] miconda: anyone that should be discussed here?
[4:03pm] miconda: nope, then looks we are doing well here … done

[4:04pm] miconda: next minor release
[4:04pm] miconda: perhaps before mid of December - that's what I had in my mind
[4:04pm] carstenbock joined the chat room.
[4:04pm] miconda: haven't checked if there are many fixes since 3.3.2
[4:05pm] miconda: but probably enough to make a release before Christmas holidays
[4:05pm] miconda: other opinions about 3.3.3?
[4:05pm] jbmanwe: well, I think people should not rely that much on you for backporting commit from trunk
[4:06pm] jbmanwe: I see commit
[4:06pm] jbmanwe: commits that are bugfixes not being automatically ported to other branches. Then just before a release you take care of doing so
[4:06pm] carstenbock: When will we release 3.3.3?
[4:06pm] jbmanwe: shouldn't developers take more care about that?
[4:07pm] miconda: jbmanwe: yes, each developer should take care of own commits
[4:07pm] carstenbock: I recently had a crash on 3.3 (GIT), which i wanted to investigate further...
[4:07pm] miconda: I look at core and some important modules for backports
[4:07pm] miconda: but it happened that I missed some in the past
[4:07pm] miconda: so it is better that each developer does own backports
[4:08pm] miconda: carstenbock: 3.3.3 probably just before mid december
[4:08pm] miconda: it was my proposal to do it then
[4:09pm] miconda: carstenbock: so, about 3 weeks time from now
[4:10pm] carstenbock: okay,
[4:10pm] miconda: anything else for v3.3.3?!?
[4:11pm] jbmanwe: only small issues from my side. We're looking at them
[4:12pm] miconda: ok, sr-dev or tracker if you want others to assist
[4:12pm] miconda: I will let discussion about next major release more at the end

[4:12pm] miconda: let's look at the other topics now
[4:13pm] miconda: anoyne to give short update about IMS extensions, still work on them, plans for merging to git master branch, etc?!?
[4:13pm] miconda: two modules were already merged by jaybeepee (related to diameter client)
[4:14pm] carstenbock: I am still working on them, currently working on diameter-charging (Ro) interface,
[4:14pm] carstenbock: i wanted to check some functionality in the I-CSCF next.
[4:15pm] carstenbock: Jason and others are working asynchronous diameter.
[4:15pm] carstenbock: The IMS core is currently based on Kamailio 3.4 and rock-solid
[4:15pm] miconda: sounds good
[4:15pm] carstenbock: Jason, correct me if i'm wrong:
[4:16pm] carstenbock: There is currently no fixed timeline for merging back into the Kamailio core, since we are working on different aspects.
[4:16pm] jbmanwe: Are there still different IMS branches out there?
[4:17pm] carstenbock: Yes, there are.
[4:18pm] carstenbock: One main branch with other branches, where people work on custom extensions... (like on Kamailio GIT)
[4:18pm] admorten joined the chat room.
[4:19pm] jbmanwe: no different "modules" for the same functionality? any discussions to early merge them before merging to kamailio core? Is there any core mantainer of the IMS branches?
[4:20pm] jaybeepee: Sorry im here
[4:20pm] carstenbock: There is no main-maintainer of the IMS branches. I think, currently most work is done by the people at Smilecoms...
[4:20pm] jaybeepee: We will be trying to get all the IMS extensions in before the end of the year
[4:20pm] jaybeepee: we have spent much time on testing and we are close
[4:22pm] jaybeepee: yes Carsten is correct - we are not using the kamailio branches as we left those purely for the openims additions, our work is a quite a lot of rewrite and therefore not suited
[4:23pm] miconda: jaybeepee: ok, good to know is under work and the short term plans
[4:23pm] miconda: anything else about IMS?
[4:23pm] carstenbock: IMS rocks!
[4:23pm] jaybeepee: lol

[4:24pm] miconda: if not, next topic - msrp relay module
[4:24pm] miconda: pdunkley added it to the list
[4:24pm] pdunkley: Yes
[4:24pm] miconda: regarding generation of reports
[4:24pm] pdunkley: MSRP replies are hop-by-hop
[4:24pm] miconda: mentioned on the list, I plan some work on msrp module
[4:25pm] miconda: hopefully I will be able to do this one as well
[4:25pm] miconda: but of course, other can jump in
[4:25pm] pdunkley: So, if a SEND request has "Failure-Report: (yes|partial)" and you get an error back, or relaying the request failed, or it timed out, you need to generate a REPORT.
[4:26pm] pdunkley: I had a play around with trying to do it using htable() and caching the transaction IDs when REPORTs were required, but couldn't get it to work properly from the config. file.
[4:28pm] miconda: ok
[4:29pm] miconda: maybe you can detail on sr-dev how you tried and I can see if there is any solution using only htable
[4:29pm] pdunkley: The problem was with time-outs and internal (asynchronous) failures.
[4:29pm] pdunkley: Without transaction callbacks you can't handle them.
[4:30pm] miconda: ok
[4:30pm] miconda: anything else about msrp?
[4:30pm] miconda: anyone did extensive testing? all ok?
[4:30pm] pdunkley: Also, would need a method to construct a REPORT request.  You can't do that.  I just tried to catch the cases first and put out diags to see if it could be done.
[4:31pm] pdunkley: Been using MSRP here lots lately, including for binary file transfers chunked across multiple SENDs.
[4:31pm] pdunkley: It's working well.
[4:31pm] jaybeepee left the chat room. (Ping timeout: 252 seconds)
[4:31pm] miconda: good to know, thanks
[4:31pm] pdunkley: Only been testing it over WebSocket though.  Still haven't been able to get Blink working here, so it's only with our MSRP client stack I've tested.

[4:31pm] miconda: then next on presece
[4:32pm] miconda: pdunkley: your turn again
[4:32pm] pdunkley: Basic presence is working well.  But lots of more advanced features are missing.
[4:33pm] pdunkley: These are things that SIP SIMPLE clients sometimes use (xcap-diff on the XCAP server)
[4:33pm] miconda: perhaps new advanced features are spec'ed as we type …
[4:33pm] pdunkley: Many of the advanced SIP SIMPLE stuff on the list are required for OMA/RCS clients.  But it's hard to tell because they are all optional - so every client supports a different subset.
[4:34pm] miconda: those listed by you would require big devel effort?
[4:34pm] miconda: I guess the client should get the list of supported ones from the server, right?
[4:34pm] pdunkley: Some are.  XQuery is huge - but I think a proper XML database based XDMS would be more sensible when that is needed - so I included it for completeness.
[4:35pm] pdunkley: Unfortunately no.  The client can't ask the server about these.  Best it can do is try and use them and get back an appropriate error when the extension isn't supported.
[4:36pm] pdunkley: But...  most clients have very poor error handling.  Basically, server needs to support whatever the client wants because you can't rely on the client to handle it.
[4:36pm] pdunkley: None of the presence or RLS extensions are huge.  They vary from a couple of days to a couple of weeks each.
[4:37pm] pdunkley: But I don't have time to sit down and do them, so at the moment any I do will be one at a time as required here.
[4:37pm] pdunkley: Biggest jobs (and probably most helpful in general in the short-term) are xcap-diff on XCAP client and server, and conditional stuff on XCAP client.
[4:38pm] rnbrady: Yo peeps
[4:38pm] rnbrady: We are using siputils encode_contact and decode_contact
[4:38pm] pdunkley: That would make XCAP Server usable with things like blink, and XCAP Client able to work with more advanced, stand-alone, XCAP Servers.
[4:39pm] miconda: xcap-diff on server is about updating parts of xml docs?
[4:39pm] eloycoto joined the chat room.
[4:39pm] pdunkley: Sort of
[4:39pm] miconda: is it based on xpath?
[4:39pm] rnbrady: When we use decode_contact, the RURI and dst are fixed, but it still sends it out of the same physical interface according to route tables for the original IP
[4:39pm] pdunkley: After downloading the document with a GET you SUBSCRIBE to the document.
[4:39pm] pdunkley: When the document changes you get a NOTIFY with an XPath and a diff in it.  Then you can patch the document on the fly.
[4:40pm] rnbrady: We are using mhomed=1 like good kids, so I'm a bit baffled.
[4:40pm] pdunkley: XCAP clients in presence servers use it to find out when pres-rules have changed, and can update their cached copy.  XCAP clients in RLS use it for rl-services and resource-list for the same thing.
[4:41pm] pdunkley: XCAP clients in soft-phones use it so that if the same subscriber is logged in twice and changes the document on one soft-phone the other gets an instant update.
[4:41pm] pdunkley: In Kamailio it'd make it easier to have XCAP Server and Presence/RLS servers on separate machines.
[4:42pm] miconda: can it be a notify to tell to get the whole doc again? for example if the patch is too big?
[4:42pm] pdunkley: XCAP client would retrieve documents from server and cache in local xcap table.  Use xcap-diff to keep them up-to-date, and pres_update_watchers() etc could be called by XCAP client when an update is received.
[4:42pm] pdunkley: If using TCP patch can't be too big
[4:43pm] pdunkley: NOTIFYs in presence get huge, so it is safe to assume TCP will be used here.
[4:43pm] mbrit joined the chat room.
[4:43pm] admorten left the chat room. (Quit: admorten)
[4:43pm] miconda: i was just wondering if could be a quick devel to just notify to get the document again
[4:43pm] pdunkley: I'll check.
[4:44pm] admorten joined the chat room.
[4:44pm] pdunkley: BTW, it's RFC 5874
[4:44pm] miconda: anyhow, as you said, probably these extensions will be added as needed
[4:45pm] pdunkley: Looks like you can indicate a changed document without including a diff.  This should for a refetch.
[4:45pm] pdunkley: Less efficient, but a smaller development.
[4:46pm] pdunkley: Example in A.1. of the RFC
[4:46pm] miconda: ok
[4:46pm] miconda: could be the way to start
[4:47pm] miconda: and add the optimizations later
[4:47pm] pdunkley: Yes.  Blink looks like it is the most advanced open-source client these days (though I could never get some features to work).  It'd be good to support the stuff it does.
[4:48pm] pdunkley: That's all I have on presence
[4:48pm] miconda: about the polled presence?
[4:48pm] miconda: is anything required to be done?
[4:48pm] pdunkley: Yes.
[4:49pm] pdunkley: At the moment if you send a SUBSCRIBE with Expires: 0 to presence you get a NOTIFY with state terminated and no body.
[4:49pm] pdunkley: This is correct if the SUBSCRIBE is in-dialog, if the SUBSCRIBE has no to-tag the NOTIFY state should be terminated and you should get a body.
[4:49pm] admorten left the chat room. (Quit: admorten)
[4:50pm] pdunkley: In RLS it is more complex.  As there is no dialog you can send exactly one NOTIFY to the SUBSCRIBE.  This means you have to fire off all the back-end SUBSCRIBEs wait for all responses and send a single NOTIFY.  You can't do what currently happens and send multiple NOTIFYs (one every few seconds) as the results filter in.
[4:51pm] pdunkley: But because the NOTIFY must be sent "Immediately" you probably need to send the RLS NOTIFY within a few seconds of receiving the SUBSCRIBE even if you don't have all the back-end NOTIFYs yet.
[4:51pm] pdunkley: This is made hard because without establishing a dialog (as Expires: 0) how do you tie them all together.
[4:52pm] pdunkley: Polled presence isn't huge, but it will be a bit tricky to get right.
[4:53pm] miconda: ok
[4:53pm] pdunkley: FWIW, it is used in RCS for non-VIP presence.  The idea is that you don't SUBSCRIBE to everyone in your address book, just the important ones.  Then you ask for the presence of the rest as required.  To minimise the number of dialogs and NOTIFYs in the network.
[4:54pm] miconda: ok
[4:54pm] jbmanwe: I'm the only one thinking that all SIMPLE/XCAP/RLS should be dropped and IETF guys punished for it?
[4:55pm] miconda: next topic?!? rtpproxy?
[4:55pm] miconda: jbmanwe: at lest it should be simplified
[4:56pm] pdunkley: miconda: that's why I asked about OMA PAL (though it might just be a band-aid)

[4:56pm] pdunkley: rtpproxy.  The re-INVITE/UPDATE stuff is something Hugh mentioned to me.  Is he on here?
[4:57pm] hughw: I'm here
[4:57pm] pdunkley: hughw: Correct me if I'm wrong...
[4:58pm] pdunkley: re-INVITE/UPDATE etc works when there are no errors.  But when the re-INVITE/UPDATE gets an FXX the original media session should be kept.  This doesn't happen at the moment.
[4:58pm] jaybeepee joined the chat room.
[4:58pm] pdunkley: So if there is a re-INVITE/UPDATE that changes media, and there is a problem, you lose the call.
[4:59pm] pdunkley: There might be early-media related issues here too.  Especially if the early-media is from a media server, but the media for the established call will be somewhere else.  Basically, if you have an AS doing 3pcc behind the Kamailio proxy.
[4:59pm] bulkorok left the chat room. (Quit: gone with the wind...)
[5:04pm] hughw: Given what I know about the current rtpproxy protocol, I'm concerned that these scenarios may not work as expected
[5:04pm] hughw: and may leave a call with no media
[5:06pm] hughw: I think an rtpproxy enhancement should create new media sessions on re-INVITE and only delete the previous ones if the negotiation is successfull
[5:07pm] pdunkley: Other issues with the module are that it is not possible to take rtpproxy instances in and out of service, update the set of rtpproxies, and the module blocks on startup waiting for connection to each rtpproxy.  So if you have an rtpproxy instance down and Kamailio restarts for some reason you end up with it blocking for many seconds, if you have two rtpproxy instances down it blocks even longer, and so on.
[5:11pm] aXl: the blocking is an issue, but taking an rtpproxy out of service is no problem
[5:11pm] miconda: ok, so at least for startup, we can lower the timeout
[5:11pm] aXl: put them is separate sets and set the active set in shmem
[5:11pm] miconda: have it configurable, eventually
[5:12pm] pdunkley: What about taking it out of service, and keeping it out of service across Kamailio restarts?
[5:12pm] aXl: set the default set before you restart kamailio
[5:12pm] pdunkley: A bit of a pain if you have many servers.  That's why I suggested a DB table.
[5:13pm] miconda: overall, some work on rtpproxy would happen sooner or later
[5:13pm] miconda: we had last time a discussion about the control protocol
[5:13pm] jbmanwe: we're planning a new module, as extending rtpproxy module won't fit our needs
[5:13pm] pdunkley: miconda: I remember it being mentioned in the last meeting, which is why I thought I would add our list of possible enhancements too.
[5:13pm] miconda: having db support could be good as an option
[5:14pm] miconda: but moving all over db might not be very good
[5:14pm] pdunkley: Could support both mechanisms, in-memory as now, or db based on a mode modparam.
[5:14pm] miconda: pdunkley: yes, perhaps is time to start a wiki page for it
[5:16pm] aXl: it would be nice to be able to dynamically add a new rtpproxy (or remove)
[5:16pm] hughw: Loading from DB to mem at startup (instead of from modparams) would be easy. But I don't think the current in-memory hash can be changed 'live'
[5:16pm] pdunkley: The rtpproxy features I listed (as opposed to the module stuff) are mostly related to things found when working with WebRTC.  As long as client implementers don't support ICE, SRTP, or RTCP interoperability is going to be a problem.  Would be nice to have an easy solution to it.  The media content itself is fine, so deploying media servers for interop seems wasteful.
[5:17pm] pdunkley: hughw: But a different in-memory structure might be possible.
[5:17pm] hughw: yes
[5:18pm] pdunkley: Fixing the re-INVITE stuff will have an impact on this anyway, so it would need changed (at least a little) for that as, for a small period at least, there would need to be two hash entries for a particular signalling session.
[5:20pm] miconda: for webrtc, does rtpproxy need to encrypt/decrypt packages?
[5:20pm] pdunkley: If it is used it will do.
[5:20pm] pdunkley: WebRTC to WebRTC will use ICE, so no rtpproxy required.
[5:21pm] miconda: if wanted to work in between webrtc and classic sip phones
[5:21pm] jbmanwe: for webrtc you need amedia b2bua if you want to interop with "nomal" sip
[5:21pm] pdunkley: But some form of proxy could help with WebRTC to existing client.  Convert RTP/SAVPF to RTP/AVP.
[5:21pm] jbmanwe: ice, srtp...
[5:21pm] pdunkley: jbmanwe: Not sure you need a B2BUA
[5:21pm] jbmanwe: well. More than a simple relay
[5:22pm] jbmanwe: need to convert RTP/SAVPF to RTP/AVP as you said
[5:22pm] pdunkley: If you sent the full SDP to the rtpproxy (as was proposed last time), the rtpproxy could test the candidate lines, perform STUN pings, and generate an SDP answer.
[5:22pm] jbmanwe: that's something we're planning to do i nthe new module.
[5:22pm] jbmanwe: maybe a wiki page as Daniel says is a good idea to start with
[5:22pm] pdunkley: Converting RTP/SAVPF should just be decrypt/encrypt for the SAVP bit, and do the minimum to receive and generate RTCP for the AVPF bit
[5:23pm] pdunkley: Yes a wiki page would be a good idea.
[5:23pm] jbmanwe: breaking ICE should also be a feature. People do't realize that breking ICE should be needed for lawful interception requirements
[5:23pm] pdunkley: At the moment you have to do something like B2BUA through Asterisk for WebRTC...  But that is because of the media profile support required, not the SIP signalling.
[5:24pm] vlad_starkov joined the chat room.
[5:24pm] pdunkley: Agreed
[5:24pm] jbmanwe: yes, signaling is covered. It's just about the transport and kamailio/oversip... already support that quite well. Interoperability with normal sip is the issue at media level
[5:25pm] pdunkley: My basic point was that, rtpproxy enhancements were discussed last time, but actually there are a lot of important features missing for a lot of modern deployment scenarios.
[5:25pm] miconda: so, wiki to get all stuff collected
[5:26pm] pdunkley: These tend to be the reason that people have to buy SBCs.  Fixes all of these RTP problems, but seems to cause lots of SIP head-aches.
[5:26pm] pdunkley: Would be nice to have a world without them.
[5:26pm] miconda: then we will see about devel resources, who does what ...
[5:26pm] jbmanwe: we (sipwise)  will put our effords on extending our own mediaproxy-ng and a new kamailio-mediaproxy-ng protocol to cover all these needs. I don't think we'll invest much time in extending the current protocol/module any longer. But I guess Daniel talked to Andreas regarding that
[5:26pm] miconda: anyone volunteering to get the wiki page up?
[5:27pm] pdunkley: Would a new, easily extensible, rtpproxy and module make a good project or projects for something like Google Summer of Code?
[5:27pm] pdunkley: I'll do the wiki page.
[5:27pm] miconda: we talked about the control protocol
[5:27pm] pdunkley: I'll start with the list I put on the agenda.
[5:27pm] pdunkley: And add the control protocol stuff from last time.
[5:28pm] miconda: (me and Andreas and others at last LinuxTag and IRC meeting)
[5:28pm] javar_ joined the chat room.
[5:28pm] miconda: but proved no time in both sides
[5:28pm] miconda: rtpproxy still has good some features, not sure sipwise media proxy covers all right now
[5:29pm] miconda: like recording calls, repacketization, ...
[5:29pm] jbmanwe: no. Recording for example
[5:29pm] miconda: ok
[5:29pm] jbmanwe: rtpstats was requested by carster some days ago. We already added it
[5:29pm] miconda: but again, a clean and flexible, well documented control protocol would be good to add asap
[5:30pm] miconda: pdunkley: ok, thanks
[5:30pm] javar left the chat room. (Ping timeout: 252 seconds)
[5:30pm] javar_ is now known as javar.
[5:30pm] pdunkley: Any particular place on the wiki something like this should go?
[5:31pm] miconda: perhaps under development namespace
[5:31pm] pdunkley: OK
[5:32pm] miconda: like [[deve:rtpproxy-ng]] or similar
[5:32pm] miconda: [[devel:rtpproxy-ng]]
[5:32pm] pdunkley: Will get something up today or tomorrow.
[5:33pm] miconda: you see other such links/topics on the main page of the new wiki
[5:33pm] miconda: ok

[5:34pm] miconda: next topic: OMA PAL (Presence Access Layer) module - was mentioned, all clear with it?
[5:34pm] miconda: would it require an implementation from scratch?
[5:34pm] pdunkley: I only mentioned it to see if anyone had come across it.
[5:34pm] pdunkley: Someone asked me about it recently.
[5:35pm] miconda: here, first time looking at it
[5:35pm] pdunkley: It's an alternative and (allegedly) more efficient mechanism from a network point-of-view way of doing SIP presence.
[5:35pm] freckle joined the chat room.
[5:35pm] pdunkley: Idea is that on the back-end the data-structures are the same as SIP (or OMA) SIMPLE so you can have clients of both types.
[5:36pm] javi_ left the chat room. (Ping timeout: 252 seconds)
[5:36pm] pdunkley: It's a new OMA spec, not endorsed for any particular implementations yet.  But just wondered if anyone had seen any interest.
[5:36pm] pdunkley: Also, it's completely outside the IETF.
[5:37pm] pdunkley: It's something I am watching, and that I might do here if there is a demand amongst our customers.  Hard to tell if there will be though.
[5:37pm] miconda: i see
[5:38pm] pdunkley: Not sure anyone has implemented it
[5:38pm] miconda: it looks like for the other next major releases
[5:38pm] pdunkley: And if there are never any clients for it...
[5:38pm] miconda: being the first one might not be bad, but i guess one has to do the client as well
[5:38pm] miconda: right!
[5:39pm] miconda: so, anything else on particular topics?

[5:39pm] miconda: or we go for last one: next major release
[5:39pm] pdunkley: Sounds good to me.
[5:40pm] rnbrady: apologies for random questions earlier, didn't realise you guys were in a meeting!
[5:41pm] miconda: first, let's discuss oej's proposal on mailing list - should it be 3.4 or 4.0 because of the new transport layer (websockets) and other additions on non sip (such as msrp, xcap) … ?
[5:41pm] miconda: opinions?
[5:42pm] pdunkley: What has prompted changes from 1.x to 2.x or 2.x to 3.x in the past?
[5:42pm] miconda: rnbrady: no problem, I wanted to reply, but got distracted -- perhaps you can send an email to sr-users
[5:42pm] pdunkley: New features, or major architecture?
[5:42pm] jbmanwe: I have an opinion regarding that. Besides new (and great) features being added, IMHO sip-router 4.0 should be released single flavoured and single modules folder on it
[5:43pm] miconda: we did from 0.x to 1.x wen we added tls
[5:43pm] pdunkley: What about the merging of the modules with the same name from modules_s to modules_k?
[5:43pm] rnbrady: miconda: will do, but probably good learning curve for me to try work it out myself
[5:43pm] pdunkley: Aren't the DB structures different?  Are there still modules in modules_s that have features not available in modules_k?
[5:43pm] miconda: then we did from 1.x to 3.x after merging core with ser and got asynchronous on tcp (and later tls)
[5:45pm] miconda: jbmanwe: there will be no sip-router release, that was the name for the project of merging source code
[5:45pm] miconda: database structure is the most difficult stuff
[5:45pm] miconda: I am not missing any feature from modules_s
[5:46pm] jbmanwe: yes I know. But I would merge the flavours into a single one. Or at least, merge the modules. That would be the goal, the achivement to move to a new major release IMHO
[5:46pm] pdunkley: Is there a big base of people still using the module_s variants?  Any way to encourage them to migrate (cattle-prod?  big-stick?)
[5:46pm] miconda: but I am aware of one that could be nice -- keeping custom values/avps per contacts -- it is in modules_s/usrloc
[5:47pm] miconda: otherwise I think for common modules (auth, usrloc, etc), there are more features in modules_k version
[5:48pm] miconda: jbmanwe: the problem is in resources, who wants/has time to spend in merging
[5:48pm] pdunkley: Is it possible, at some-point, to remove modules_s from master.  Keep them maintained for a while, but effectively declare them end-of-life after a particular release.
[5:48pm] miconda: pdunkley: it is an option indeed
[5:48pm] pdunkley: That way, anyone who needs them in master has to take on porting/maintaining them?
[5:49pm] javi_ joined the chat room.
[5:50pm] miconda: not having time to analyse what is extra kept the dups there
[5:50pm] miconda: it doesn't cost much to have them in repo
[5:50pm] miconda: just not to lose anything
[5:50pm] miconda: but we will have to get to a decision soon and see who wants to maintain them
[5:51pm] miconda: and then has to put some efforts
[5:51pm] miconda: a quick workaround will be to rename the modules and the database tables
[5:51pm] vlad_starkov left the chat room. (Remote host closed the connection)
[5:51pm] miconda: to have like usrloc-uid (since ser is using kind of unique id internally)
[5:52pm] pdunkley: Renaming the tables could be part of the SQL script that gets provided to upgrade the tables for the major releases.
[5:53pm] pdunkley: I haven't seen any commits into modules_s (I think) in the two years I've been following the list.  So either no-one is using them, or no-one has found any bugs
[5:53pm] miconda: but since we have gruu in _k/usrloc and soon (maybe) full outbound, perhaps _s version will be unattractive anyhow
[5:54pm] miconda: anyhow, this stays open for further discussions on mailing lists
[5:54pm] blaszlo joined the chat room.
[5:54pm] miconda: any other points of 3.4 vs 4.0
[5:54pm] pdunkley: outbound is something I keep hoping to get back onto
[5:54pm] jbmanwe: if we can sync that with the ims merge and the new features, that would be a great 4.0 release
[5:54pm] jbmanwe: like Peter, haven't seen modules_s commits long time ago
[5:55pm] miconda: jbmanwe: i expected to say 40.0 release for all these features together
[5:55pm] blaszlo left the chat room.
[5:55pm] jbmanwe: and that would give us an idea of "merge completed"
[5:56pm] miconda: so if no other opinions, date for next major release
[5:56pm] jbmanwe: well, I think Linus started the arbitrary mayor release update with Linux 3.0. Asterisk did the same, Sipwise is thinking of doing so...
[5:56pm] pdunkley: Maybe put out a poll?  See if anyone on any of the lists still uses modules_s, and if they do what and why?
[5:56pm] jbmanwe: but I'd say that a mayor release should happen after a mayor goal or when you realize that your 3.x version is completely different from your 3.0 version
[5:56pm] miconda: yes, we will take some actions
[5:57pm] pdunkley: Put a poll up somewhere, and do a weekly reminder on the lists for a couple of months.  That way people should see it and remember to shout out if they have a problem.
[5:59pm] pdunkley: I want to finish outbound by end-of-February (if I can get some time).  I think I'll be needing it by then.
[5:59pm] pdunkley: Would like to get that into the next major if I can.
[6:01pm] miconda: hmm, devel by end of feb means release in april/may
[6:01pm] miconda: could be too long
[6:01pm] miconda: I think many people would like to get websockets labeled stable
[6:02pm] miconda: my idea was to start testing with february
[6:02pm] miconda: or we can do different
[6:02pm] pdunkley: Yes.  I'd like to get outbound done sooner, but haven't been able to do anything for the last couple of months and will be travelling more than at home until after Christmas.
[6:02pm] pdunkley: Maybe outbound needs to go into the next release.
[6:03pm] jbmanwe: we'd like to merge new mediaproxy module for next mayor release too
[6:03pm] miconda: I had also quite some plans till now, but postponed due to other stuff
[6:03pm] jbmanwe: it's a lot of new features. I guess IMS extensions will be merged too
[6:03pm] jbmanwe: Feb could be too optimistic
[6:04pm] pdunkley: If anyone out there wants to help...  I suppose the outbound stuff could be split a bit.  For example, updating registrar/usrloc to handle reg-id and remove dead contact bindings?
[6:04pm] miconda: jbmanwe: then we do 4.0 without it and then next one, 5.0 will have it
[6:04pm] miconda: anyhow, to summarize
[6:04pm] giavac joined the chat room.
[6:04pm] miconda: it seems lot of plans for mid-term devel
[6:05pm] miconda: so we can do:
[6:05pm] miconda: 1) do a longer devel cycle and wait for these additions
[6:05pm] miconda: 2) start sooner the testing, release the next major release with websockets and what so ever can get in
[6:06pm] miconda: then the rest goes in the following one
[6:06pm] miconda: shortening now, means the other one will be sooner as well
[6:06pm] miconda: like, start testing phase by end of year
[6:07pm] miconda: release in Februrary (for websockets demos with stable version at FOSDEM  )
[6:07pm] pdunkley: Perhaps we should do the next major release soon, but plan to have a shorter time than usual between it and the next release?
[6:08pm] miconda: we will put these two options on a poll on mailing lists
[6:08pm] pdunkley: FOSDEM would be good, but still don't think there is anyone running the telephony dev room?
[6:08pm] miconda: pdunkley: we can do shorter next one, aiming to release in summer
[6:09pm] miconda: don't know about telephony dev room, i'll check
[6:09pm] pdunkley: Might be best way.  Release early in the year and another late summer instead of just one release early summer.
[6:09pm] miconda: ok
[6:10pm] pdunkley: I was thinking about submitting a proposal for a talk on (MSRP|SIP) over WebSocket with a demo.
[6:10pm] javar left the chat room. (Quit: javar)
[6:10pm] miconda: would be good!
[6:11pm] miconda: anything else left to discuss?
[6:12pm] pdunkley: Nothing from me
[6:14pm] miconda: ok
[6:14pm] miconda: thanks everyon
[6:15pm] miconda: we will continue on mailing lists and wiki
[6:15pm] miconda: expect very interesting news soon!
[6:15pm] miconda: I will take the log and post it on the wiki page of the irc meeting