[16:00 - [16:06] are missing from my chat client, sorry
[16:06] <miconda> the last one was sent to sr-dev, iirc
[16:06] <miconda> the minutes
[16:07] <miconda> oej: yes, it seems for the last one are only on sr-dev (at least not on wiki)
[16:07] <miconda> Vicente was sending them
[16:08] <miconda> ok … no outstanding issues for now
[16:08] <miconda> next topic

[16:08] <miconda> let's do planning for next minor release
[16:08] <miconda> and do major release at the end
[16:09] <miconda> after we see the near future plans for development.
[16:09] <ZogG_laptop> hello
[16:09] <miconda> last minor release was in August 15
[16:09] <miconda> perhaps we can do one by end of September or so (before Astricon)
[16:10] <henningw> sounds good
[16:10] <miconda> I haven't looked at patches since 4.0.3, but I remember I did a few of them
[16:11] <linuxmaniac> one crash is fixed on ua_redirect
[16:11] <miconda> linuxmaniac: ok, thanks for it
[16:11] <linuxmaniac> miconda: my pleasure
[16:12] <ZogG_laptop> oh not shure if patch was sent but there is small bug in presence module
[16:12] <ZogG_laptop> at least it's still at 4.0.3
[16:12] <miconda> ok then – 4.0.4 by end of September
[16:12] <linuxmaniac> \o/
[16:12] <miconda> ZogG_laptop: send it over sr-dev
[16:12] <miconda> or put it on the tracker
[16:12] <miconda> if already fixed, will be marked as done
[16:13] <miconda> what people prefer to do now – the techical (devel) topics or the admin ones?
[16:14] <linuxmaniac> tech?
[16:14] <miconda> ok
[16:14] <miconda> first come first served
[16:14] <miconda> technical topics

[16:14] <miconda> one I wanted to get some input is about xcap-diff
[16:15] <miconda> as I said during last irc meeting I will try to do it before next major release
[16:15] <ZogG_laptop> miconda: not sure if it would be right one. the problem that docs states that reginfo_handle_notify() doesn't get any parameters while in code it does want one
[16:15] <ZogG_laptop> so just changing 1 to zero fixed the error from script
[16:15] <miconda> ZogG_laptop: maybe is not the right fix, if it expects some parameter
[16:16] <miconda> but report it and we look at
[16:16] <ZogG_laptop> ok thanks
[16:16] <ZogG_laptop> i'll do
[16:16] <miconda> carstenbock is the developer, iirc
[16:16] <carstenbock> That's right, i implemented it.
[16:16] <miconda> and I saw some reports on tracker this morning
[16:16] <carstenbock> Haven't looked at the recent bug-reports, though.
[16:17] <miconda> that ruid is not set for records
[16:17] <carstenbock> Putting the bug on the tracker is the best way.
[16:17] <miconda> some are already there (regarding reginfo)
[16:17] <miconda> ok, back to my xcap-diff, maybe pdunkley can comment
[16:18] <pdunkley> Definitely in favour of getting xcap-diff support.
[16:18] <miconda> from quick check of the specs, looks like the body for notifies has to be pretty much the xml chunk that was uploaded with put
[16:18] <miconda> is it right?
[16:19] <pdunkley> Sort-of.
[16:19] <miconda> I started to add, pua and presence should be able to handle them
[16:19] <miconda> the missing part is the publish from xcap-server
[16:19] <pdunkley> Problem is that NOTIFYs must be throttled, for example no-more than one per five second period per dialog.
[16:19] <pdunkley> So what do you do if there are two changes to the document in that period?
[16:19] <miconda> pdunkley: everything is sort-of in SIMPLE
[16:19] <miconda> throttling is required by specs?
[16:20] <pdunkley> And of course, you can only have one NOTIFY outstanding at a time, so you can't send the second until you have a final response to the first.
[16:20] <miconda> can we just say at some point, hey, just take the full docs
[16:20] <pdunkley> The base SUBSCRIBE/NOTIFY spec. mandates throttling and recommends 5s for presence.
[16:21] <pdunkley> It's up to each specification that defines an event-package to say what the throttle rate should be, but the spec. does have to say it.
[16:21] <pdunkley> If the xcap-diff spec. doesn't I'd think it needs to be the SUBSCRIBE/NOTIFY default of 5s.
[16:21] <pdunkley> I think you can basically say “the doc has changed and it is too complicated for a patch - so just get it again”.
[16:22] <pdunkley> That'd be a good starting point for the first version.
[16:22] <pdunkley> The presence module already has NOTIFY throttling in it, so if you do say “get the whole doc” all of the time it should just work (I think).
[16:22] <miconda> ok, so we can go with kind of workaround, if we have many changes within the throttling interval, then just mark it for complete refresh?!?
[16:23] <miconda> keeping the list of diffs can get complex otherwise
[16:24] <pdunkley> I agree.
[16:24] <miconda> ok, for now I am fine with this topuc
[16:24] <pdunkley> This is the server side of xcap-diff?
[16:24] <miconda> yes
[16:24] <pdunkley> So it allows presence servers and UAs to SUBSCRIBE to the XCAP server?
[16:25] <pdunkley> Is there any need or desire to do the client side of xcap-diff at some point?
[16:25] <miconda> yes, do you want a client?
[16:25] <miconda> maybe for those implementing sip clients…
[16:25] <pdunkley> This would mean the presence module and rls modules could subscribe to the XCAP server (including a non-Kamailio XCAP server) instead of the proprietary
internal links.
[16:26] <pdunkley> There is already the XCAP client module in Kamailio that can be used when presence/rls and xcap-server don't share a DB.
[16:26] <miconda> for now my focus is on server
[16:26] <pdunkley> OK, just checking.
[16:27] <pdunkley> Does anyone know of a good (and free) client that supports xcap-diff?
[16:27] <miconda> xcap client is just xcap – no sip/presence in it, which will be required here
[16:27] <miconda> so I assume it would have to be a pua_XXX module
[16:27] <pdunkley> The only one I know of is Blink. But not sure how good the other bits of Blink presence are…
[16:28] <miconda> pdunkley: probably not, but I though you will add it to your communicator
[16:28] <pdunkley> Lol
[16:28] <jh> i have tested sipclients presence and found bugs in it that have not been fixed
[16:28] <pdunkley> We are quite happily using XMPP in a CUSAX like way at the moment.
[16:28] <miconda> i am not aware of a good ones, free or not
[16:28] <miconda> pdunkley: ok
[16:29] <pdunkley> May do SIP presence and XCAP in the future, if there is demand for it.
[16:29] <miconda> ok, then let's mark this topic done
[16:29] <miconda> next one: dialog vs dialog_ng

[16:29] <miconda> I don't see Jason here for getting more details about dialog ng
[16:30] <miconda> anyone else here using it? (carstenbock)
[16:30] <carstenbock> I am a heavy user.
[16:31] <oej> so what are the differences?
[16:31] <carstenbock> There are some differences between dialog and dialog_ng. A big part is actually, that you can tear down calls even during setup-phase.
[16:31] <oej> What's the plan
[16:31] <ZogG_laptop> tear?
[16:31] <carstenbock> terminated
[16:31] <ZogG_laptop> oh
[16:31] <oej> hang up
[16:32] <carstenbock> e.g. if the network fails during call-setup (detected via Diameter-Rx), you can terminate a call if it is not connected yet.
[16:33] <miconda> but there were some parts missing from the old dialog, or all features of the old dialog are in dialog_ng?
[16:33] <carstenbock> That's about the main difference. I think another difference is, that the API has a direct function for terminating calls.
[16:33] <carstenbock> What is missing (as with most IMS-modules actually), is the database-backend.
[16:34] <carstenbock> All information is only in memory at the moment.
[16:34] <oej> are all the rpc commands there?
[16:35] <miconda> carstenbock: that's fine, kamailio just keeps running
[16:35] <miconda>
[16:35] <carstenbock> Exactly that's the case…
[16:35] <oej> Who needs to depend on databases then?
[16:35] <oej> A new definition of “no-sql”
[16:35] <carstenbock> Jason also mentioned, that they implemented a lot of the stuff that's was in a wiki page about improvements in the dialog module.
[16:36] <carstenbock> I don't know, what they all implemented from this page: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-design
[16:37] <miconda> ok, db backend is important – I will try to catch up with Jason on mailing lists
[16:38] <miconda> I had in mind to do some cleanup on the matching modes of the old dialog
[16:38] <miconda> probably I will still do it
[16:39] <ZogG_laptop> i see there is option to get dialog by cutom added key (from module doc — get_dlg_var (dlg, key) )
[16:39] <carstenbock> Regarding matching modes: dialog_ng does only matching on SIP-Elements, nothing else.
[16:39] <carstenbock> I don't think we have that in dialog_ng (yet).
[16:40] <miconda> carstenbock: yes, that was my plan as well, plus few optimizations for faster matching
[16:40] <miconda> I'll see if I have enough time
[16:40] <miconda> anything else on the technical side?
[16:41] <miconda> I assume the code restructuring will be postponed, doesn;t look like enough time for it
[16:41] <carstenbock> I can confirm, dialog_ng works excellent (for me in my setups)
[16:41] <miconda> carstenbock: all our homeworks worked at home
[16:41] <miconda> I don't disagree with you, actually
[16:42] <kolbu> in the old dialog module we still see a stuck dialog if a 486 and 200 is received at more or less exactly the same time
[16:42] <miconda> just that many features might be missing
[16:42] <ZogG_laptop> so regards that function, does it as well support dialog properties?
[16:42] <miconda> kolbu: with latest 4.0 branch?
[16:42] <kolbu> running 4.0.3 ++
[16:42] <kolbu> that is, a few days after 4.0.3
[16:43] <miconda> kolbu: what state it hangs on?
[16:43] <kolbu> 4
[16:43] <ZogG_laptop> e.g. from_tag/caller_contact/etc or it does support only custom added ones from set_dlg_var ?
[16:43] <iZverg> are read dialogs from db in dialog-ng ?
[16:43] <kolbu> which is good, because then we can close it with the dlg_end_dlg fifo
[16:43] <iZverg> are read dialogs from db in dialog-ng _planned_?
[16:43] <ZogG_laptop> iZverg: afaik no db implantation was made for dialog_ng
[16:44] <carstenbock> Not yet. That will follow.
[16:44] <miconda> kolbu: maybe you can open a tracker item and add some details there
[16:44] <carstenbock> DB-Support is definitely planned, but not scheduled yet…
[16:45] <iZverg> i think in dialog need ability to read dialogs from db

[16:46] <iZverg> and memcached multiple servers. as i see no developer for memcached now?
[16:46] <kolbu> miconda: ok, will do
[16:46] * dr wants the memcached module that compiles with libmemcached in kamailio 4.0.4 :)
[16:46] <miconda> iZverg: memcached module was refactored rather recently
[16:46] <kolbu> worth mentioning that the dialog module in 4.0 is sooo much more reliable than in 3.3
[16:46] <miconda> so there are developers for it
[16:47] <miconda> kolbu: ok
[16:47] <miconda> dr: I think devel version compiles with that lib
[16:47] <miconda> perhaps henningw or cchance can confirm that
[16:47] <dr> yes miconda, we've been testing it , it works
[16:47] <miconda> ok
[16:47] <iZverg> yes, it compiled but only one server supported
[16:48] <henningw> the library has support for more server, i think
[16:49] <henningw> should be not to hard to extend, patches are as always welcome :)
[16:49] <henningw> the devel version uses the new library
[16:49] <henningw> s/new/good library
[16:49] <miconda> ok
[16:49] <miconda> anything else on technical aspects?
[16:50] <miconda> other modules to add/fix/remove?

[16:50] <ZogG_laptop> the presence one
[16:50] <miconda> ZogG_laptop: what you mentioned already, right?
[16:50] <ZogG_laptop> nope
[16:51] <ZogG_laptop> improvemnet
[16:51] <ZogG_laptop> there is force_single mode or something like that
[16:51] <ZogG_laptop> which would send only 1 state in xml
[16:51] <ZogG_laptop> early/confirmed/etc
[16:51] <ZogG_laptop> it would pick up mostly randomly
[16:52] <miconda> you refer to presence_dialoginfo module?
[16:52] <admorten> I've got a bunch of updates to the sca module to pull into 4.x and master.
[16:52] <ZogG_laptop> leme check
[16:53] <ZogG_laptop> miconda: yes
[16:53] <miconda> admorten: ok, you should do it soon so they get tested
[16:53] <miconda> ZogG_laptop: ok
[16:53] <admorten> Will do.
[16:53] <ZogG_laptop> miconda: the priority should be early→confirmed→terminated
[16:53] <miconda> ZogG_laptop: again, perhaps opening an item on tracker will help not forgetting and checking it
[16:54] <dr> having working dialog profiles would be nice
[16:54] <ZogG_laptop> miconda: ok. i even may try to get patch for this one
[16:54] <miconda> ZogG_laptop: that is even better, thanks
[16:54] <ZogG_laptop> miconda: it would be better though if it would be checked before applied
[16:54] <miconda> dr: they seem fine, you have troubles with?
[16:55] <admorten> Re: our own sca module deployment. We now have 8345 SCA subscribers, and I've been hearing from a number of other places that they're rolling it out.
[16:55] <miconda> ZogG_laptop: sure, they will be reviewed
[16:55] <miconda> admorten: nice, thanks for sharing the numbers
[16:55] <miconda> admorten: is a single sca server?
[16:56] <admorten> Yes, at the moment.
[16:56] <dr> # set_dlg_profile(“caller”, “count”);
[16:56] <dr> ## get_profile_size(“caller”,“count”,“$avp(callcount)”);
[16:56] <dr> ## xlog(“L_INFO”,“number of simultaneous dialogs: $avp(callcount)\n”);
[16:56] <miconda> not bad then, for handling lots of xml docs
[16:56] <dr> i want it to decrement automatically
[16:56] <admorten> Right. We have a replicated environment for failover.
[16:56] <dr> it doesn't , it always increments that counter
[16:56] <admorten> miconda: SCA doesn't use XML. :)
[16:56] <miconda> admorten: ok, that;s different
[16:57] <miconda> but you said at some point that does dialog-info as well
[16:57] <miconda> or I misunderstood?
[16:57] <miconda> or you don't use that part…
[16:57] <admorten> That'd be BLA, which we struggled with.
[16:57] <kethzer> Need to know how to enable kamailio to send file over a NATED network
[16:57] <kethzer> any hel
[16:57] <kethzer> help???/
[16:57] <admorten> XML bodies would grow massive, then packet fragmentation would overwhelm the handsets.
[16:58] <admorten> Inconsistent state across the groups.
[16:58] <miconda> dr: it will be decremented when the dialog is ended/destroyed
[16:58] <miconda> kethzer: you have to wait a bit for support questions, we are doing development and admin meeting
[16:58] <dr> miconda, that's what I thought too, but this does not happen with my script
[16:59] <dr> i had to put the counter in memcache , and increment / decrement manually
[16:59] <miconda> I do use it in many places, no problem so far…
[16:59] <miconda> what version are you using?
[16:59] <dr> 4.0.2
[17:00] <miconda> you should shift to latest in 4.0 branch, there were some fixes for negative replies
[17:00] <miconda> or do dialog related things just before t_relay()
[17:01] <ZogG_laptop> dr:are you trying to get total dialogs per subscriber?
[17:01] <dr> and http_query() from the utils module , it might need some heavy improvements, it returns only the first line from the buffer
[17:01] <oej> It is documented to only do that
[17:01] <dr> ZogG_laptop, no , total number of dialogs

[17:02] <oej> But yes, we need improvements in http_client
[17:02] <oej> Sorry, I would say we need a http_client module that consolidates all http clients
[17:02] <oej> We have several different ones
[17:02] <miconda> dr: speaking of that, I think carstenbock did some work on http client lately
[17:03] <miconda> but iirc, he pushed on a personal branch
[17:03] <oej> There's one in utils, one in jsonrpc and one in xcap client and possibly sip identy
[17:03] <oej> From the top of my head. Some use libcurl.
[17:03] <miconda> oej: right, maybe we should pull out http client part from all modules and have one that will be reused
[17:04] <oej> I think that would be a good thing moving forward.
[17:04] <miconda> jsonrpc client uses netstrings, iirc
[17:04] <miconda> is not over http
[17:04] <oej> Then we could get IPv6 in every one and solve happy eyeballs once.
[17:04] <dr> miconda, thx . one more thing: i don't think the dialog module works very good with event_route[tm:local-request] either . $DLG_TIMEOUT is not getting set
[17:05] <miconda> dr: has to be checked, not using it like that so I cannot comment now – open an issue on tracker to have it in mind
[17:05] <miconda> carstenbock: any comments on your recent work on http cleint?
[17:05] <dr> $DLG_lifetime, sorry
[17:06] <miconda> ok, let's move forward (probably carstenbock has left a bit)
[17:06] <miconda> anything else on tech stuff?
[17:06] <jh> how about mediaproxy-ng module?
[17:07] <admorten> Question about core support for maximum branches. We're currently limited by a 32-bit mask to 30 branches. I have some early work moving to 64-bit mask for branch tracking. Anyone else interested?

[17:07] <miconda> jh: rtpproxy_ng?
[17:07] <miconda> admorten: yes, could be interesting
[17:07] <ZogG_laptop> miconda: https://github.com/sipwise/mediaproxy-ng
[17:08] <miconda> push the patches somewhere for some review
[17:08] <jh> yes, ment rtpproxy-ng (naming is confusing)
[17:08] <admorten> miconda: OK
[17:08] <miconda> jh: yes, I know, quite confusing in both sides, even the external application
[17:08] <admorten> I'll put them up on sip-router tracker and post to sr-dev when ready.
[17:08] <jh> there was some bugs found. will those be fixed before next release?
[17:09] <miconda> probably yes. I don't see Richard here
[17:09] <miconda> but I guess sipwise is highly interested to get all bugs closed
[17:09] <linuxmaniac> miconda: :yes:
[17:09] <miconda> linuxmaniac may be able to comment more
[17:09] <miconda> I know some were fixed already
[17:10] <miconda> hughw: send some patches as well, e
[17:10] <miconda> were they done?
[17:10] <linuxmaniac> miconda: afaik yes

[17:10] <carstenbock> (sorry for the delay: i just added support for POST-requests to the http_query() function. Needs a little bit testing, but should be okay)
[17:10] <miconda> rephrasing: hughw sent some patches to rtpproxy-ng
[17:10] <linuxmaniac> I think they are been merged
[17:10] <miconda> linuxmaniac: ok
[17:11] <miconda> carstenbock: ok, maybe you should merge on master, to be easy to test for not-git gurus :D
[17:11] <oej> carstenbock: Using curl?
[17:12] <miconda> carstenbock: in short, it was a discussion to make a single http client module, as there are few other modules implementing one internally
[17:12] <carstenbock> miconda: Will do that.
[17:12] <carstenbock> oej: Yes.
[17:12] <oej> carstenbock: Which module is that?
[17:13] <carstenbock> oej: utils
[17:13] <miconda> ZogG_laptop: for clarification - the external application is named mediaproxy-ng, but the corresponding module in kamailio is named rtprpoxy-ng
[17:14] <ZogG_laptop> miconda: yeah, thanks, got it from conversation above and some google
[17:14] <ZogG_laptop> :)
[17:14] <oej> Ok, so we should propably build an improved http get in utils, as well as something similar to json that suspends transaction and returns in another route
[17:15] <ZogG_laptop> i think http get/post would be enuf and what would be needed are modules to parse responses (json/xml/whateverelse)
[17:17] <miconda> ok, done with tech stuff?

[17:17] <linuxmaniac> openSSL exception licence
[17:17] <linuxmaniac> license
[17:18] <linuxmaniac> oej: no mail from you on the mail list
[17:18] <miconda> linuxmaniac: ok, that was the next in list
[17:18] <oej> I did brainstorm about it earlier this week
[17:18] <oej>
[17:18] <miconda> but I thought of it more admin stuff
[17:19] <linuxmaniac> miconda: I can wait :)
[17:19] <miconda> no, it is on now
[17:19] <miconda> let's discuss it
[17:19] <miconda> one way is to implement tls module with gnutls
[17:20] <linuxmaniac> I think is “just” a matter add the exception clause
[17:20] <oej> carstenbock: How do I set content-type in the post data?
[17:20] <miconda> the other one is getting devels to agree with the exception
[17:20] <miconda> which most of them will do, but many are gone
[17:20] <miconda> from the early stage of ser
[17:20] <ZogG_laptop> oh, about that. i got kaamilio 4.x crashed with tls when having reregister or two calls at the same time :(
[17:20] * ZogG_laptop was talking about tls
[17:21] <miconda> also, lot of copyright is by fokus, which was sold to tekelec which was recently bought by oracle
[17:21] <oej> Oh yeah, let's consult Oracle lawyers
[17:21] <linuxmaniac> haha
[17:21] <miconda> so we may need to buy a beer to Larry
[17:21] <oej> So the problem here is that the tls module is not part of linux distros because of this, right?
[17:21] <henningw> hehe
[17:21] <miconda> ZogG_laptop: do you have a backtrace?
[17:21] <pdunkley> OpenSSL is used by other modules (for access to the randomness and crypto routines).
[17:22] <linuxmaniac> oej: I can't add tls on Debian because of that
[17:22] <pdunkley> websocket, outbound, auth_ephemeral all link to it - BTW I am fine with the exception.
[17:22] <oej> Yes, there's a few modules that Debian won't accept
[17:22] <miconda> linuxmaniac: the question is, all devs have to agree?
[17:22] <oej> so we can clear those three modules
[17:22] <ZogG_laptop> miconda: no here for sure. but i think i can emulate it anytime
[17:22] <miconda> linuxmaniac: or only devs to the modules that link to openssl?
[17:23] <miconda> because the core doesn't link to openssl, only few modules (tls among them)
[17:23] <ZogG_laptop> afaik i just read of some sip lib that switched for smaller lib for tls/ssl instead of openssl
[17:23] <linuxmaniac> miconda: don't know, but I will say just the ones that use openssl
[17:23] <miconda> ZogG_laptop: a backtrace would be good and eventually the log with debug=3
[17:23] <oej> What is the background of the TLS module, was code moved from the core to that?
[17:24] <ZogG_laptop> miconda: would try to get one to you thru maillist or tracker next week
[17:24] <miconda> linuxmaniac: that would be easier
[17:24] <pdunkley> Other modules are tls, osp, stun, auth_identity
[17:24] <miconda> Andrei reimplemented tls module
[17:24] <miconda> nothing from old openser core was used for it
[17:24] <miconda> I guess pdunkley has nothing against to agree for websocket module
[17:25] <pdunkley> Some of the stun stuff is mine, but most has been moved from Kamailio core. For my part I am happy with an exception for stun too (but the original author will need to confirm as well)
[17:25] <linuxmaniac> miconda: I can try to ask on debian-legal and see what they say
[17:25] <miconda> stun and auth_identity is from iptel.org guys
[17:25] <miconda> linuxmaniac: please do it, so we know what we have to do
[17:25] <oej> pdunkley has three modules to disclaim, but that should be fine
[17:25] <linuxmaniac> miconda: noted
[17:25] <miconda> linuxmaniac: mention also that we package tls module separately
[17:26] <ZogG_laptop> linphone apprantly switched from openssl to https://polarssl.org/
[17:26] <miconda> is not part of other package
[17:26] <oej> can we get agreement fron Andrei?
[17:26] <linuxmaniac> miconda: I will send you the mail draft before send it to them
[17:27] <pdunkley> Just checked, I can remove the OpenSSL dependency from stun with a trivial code change.
[17:27] <linuxmaniac> but anyways we have to add the exception
[17:27] <pdunkley> I am happy to disclaim my modules.
[17:27] <miconda> oej: probably iptelorg
[17:27] <pdunkley> That means websocket, stun, outbound, and auth_ephemeral are fine.
[17:27] <miconda> but at least we know the target, I will get in touch if it all we need
[17:27] <oej> miconda: back to larry
[17:27] <pdunkley> Leaves just tls, osp, and auth_identity
[17:28] <miconda> for osp I can approach the company that developed it
[17:28] <oej> Transnexus
[17:28] <miconda> although they were not very active, I guess they have nothing against
[17:28] <miconda> oej: yes
[17:28] <miconda> but not sure how many users that module has
[17:28] <oej> Auth_identity was a school, that should possibly be fine if we can track someone down
[17:28] <miconda> afaik, only that company had a solution to work with it
[17:29] <oej> tls is a tough nut to crack and an important one
[17:29] <miconda> yes, tls is the one that needs it most …
[17:30] <miconda> the other important one, websocket, is fine
[17:30] <miconda> for stun, I guess we can reimplement it
[17:30] <miconda> doesn't look that hard
[17:30] <miconda> and is not big
[17:30] <miconda> tls has lot of code, on the other hand
[17:30] <oej> Yep.
[17:31] <ZogG_laptop> ok i'm off. bye and goood luck to every one adn thanks for help.
[17:31] <miconda> but first let's see what linuxmaniac gets from debian-legal and then I will see how to approach for tls + stun
[17:31] <miconda> ZogG_laptop: thanks for joining!
[17:31] <miconda> anything else about openssl exception?
[17:31] <linuxmaniac> ok then
[17:32] <ZogG_laptop> and before i go i would paste again — may be polarssl can be replacement for openssl as it mentioned on their site curl/openvpn and others are using it and afaik linphone switched ot it lately
[17:32] <ZogG_laptop> bye
[17:32] <miconda> thanks, bye

[17:32] <miconda> next admin stuff: github
[17:32] <miconda> Andreas Granig secured kamailio name on github
[17:33] <miconda> pdunkley and few others expressed the willingness to maintain a clone of the repo there
[17:33] <linuxmaniac> we have a mirror at sipwise
[17:33] <pdunkley> Github would work best if that was the primary repo.
[17:34] <miconda> so, do we get enough work force to maintain a clone
[17:34] <pdunkley> Biggest advantage of Github is fork management etc.
[17:34] <miconda> pdunkley: from Andreas I understood is a matter of some scripts to merge back and forth
[17:34] <miconda> but in case of conflicts, someone has to care of …
[17:34] <pdunkley> Yes.
[17:35] <pdunkley> I suppose that is true.
[17:35] <linuxmaniac> pdunkley: but you can fork with no problem afaik
[17:35] <pdunkley> But it needs to be more than a simple clone, because if someone forks on Github and makes a push request that is accepted, then the repo on Github is updated.
[17:35] <miconda> the current repo is tied to many scripts and hooks around, so it will be quite some work not to keep it anyhow
[17:35] <oej> why did we leave sourceforge?
[17:36] <miconda> besides the fact that github started to have issues (e.g., availability)
[17:36] <linuxmaniac> pdunkley: the thing is that you have to do git am on our repo not github
[17:36] <miconda> oej: when we merged the code, we had svn on sourceforge and ser was cvs on berlios
[17:36] <miconda> we needed root privileges
[17:36] <miconda> to make things fit together
[17:37] <henningw> sf.org had also some issues that time (they still have). One reason to go for a dedicated git was to have the flexibility to merge the repos
[17:37] <oej> Right.
[17:37] <miconda> pdunkley: will not be a read only clone
[17:37] <oej> Will we end up in the same situation with github
[17:37] <miconda> github can get updates directly there
[17:37] <miconda> the scripts have to do sync both ways
[17:38] <miconda> Andreas said is something they do as well for some of their repos
[17:38] <linuxmaniac> afaik github is just a mirror for us
[17:38] <pdunkley> I guess the big question is whether enough people think that Github provides advantages to the project.
[17:38] <linuxmaniac> no changes from github onto our repo
[17:39] <miconda> linuxmaniac: check sr-dev for Andreas' email on this topic
[17:39] <pdunkley> My thinking is that the Github forking is a somewhat nicer model than having developers with lots of branches, and allows non-developers to work under source control without it automatically affecting the main project.
[17:40] <miconda> pdunkley: agree that there could be good benefits. on the other hand, not keeping current one as the main one will be tough and lot of work
[17:41] <miconda> so, at least have to keep/try both for a while just to see if github is good
[17:41] <linuxmaniac> miconda: “Everytime you push something to the internal repo, the github repo gets automatically synced and overwritten”
[17:41] <linuxmaniac> so no changes from github on our repo
[17:42] <miconda> linuxmaniac: “people have the possibility to send pull requests and everything”
[17:43] <linuxmaniac> miconda: yes
[17:43] <linuxmaniac> but no merge is done
[17:43] <miconda> so I assumed they are used …
[17:43] <linuxmaniac> miconda: you have to use git am on the “master” repo
[17:43] <pdunkley> linuxmaniac, miconda: but does the internal repo get sync'd and overwritten everytime the github repo is changed?
[17:44] <linuxmaniac> pdunkley: no changes are done on github
[17:44] <linuxmaniac> this is just “read-only”
[17:44] <pdunkley> OK. That's my point.
[17:44] <carstenbock> I am definitely no GIT expert, but the current solution “works for me”. Are there somewhere a list of what would be exactly better if we switch (or create a mirror on) to github?
[17:44] <pdunkley> If we don't make changes on Github, we can't use Github push requests etc for merging.
[17:44] <pdunkley> So there is no advantage to Github.
[17:45] <pdunkley> carstenbock: there was a discussion on the mailing list. But it boils down to better developer management, and merging plus integrated tracker that relates issues to commits.
[17:46] <linuxmaniac> pdunkley: just a nice web interface an the pull-request are received as mails
[17:46] <eloycoto> we can use http://gitlab.org/ in our server
[17:46] <miconda> pdunkley: maybe there are tutorials to do sync two ways
[17:47] <miconda> I thought Andreas said they do merge on both ways
[17:47] <miconda> maybe was on some private conversation
[17:48] <miconda> but the actual question here: if we can get it two ways sync, who is on board to configure it initially and then supervise it?
[17:48] <linuxmaniac> miconda: he is just in front of me. No changes from github
[17:48] <miconda> linuxmaniac: ok
[17:48] <miconda> i misunderstood
[17:48] <pdunkley> I am happy to help with some of this. Not sure what time I have over the next couple of months as I am travelling a lot.
[17:49] <pdunkley> It's conference season
[17:49] <miconda> this comes also to another point related to administration

[17:50] <miconda> building a tech admin group
[17:50] <miconda> with volunteers
[17:50] <miconda> to care of various aspects of the project
[17:50] <miconda> including releases, sysadmin work on servers
[17:50] <linuxmaniac> miconda: I'm still single, I have some time free. haha
[17:50] <miconda> typically was me, Henning and Jan
[17:50] <miconda> linuxmaniac: great
[17:51] <miconda> you are more than welcome to join
[17:51] <linuxmaniac> that will be great
[17:51] <oej> I can help more with the web site.
[17:51] <qxork> Would love to help out. LOD.com is also interested in donating servers, etc.
[17:52] <miconda> also, in this tech admin group, I want to be able to take some decissions regarding what software to use when we need something new, etc…
[17:52] <oej> qxork: I am willing to receive donations! Haha.
[17:52] <linuxmaniac> miconda: sounds reasonable
[17:53] <miconda> ok, so here we have linuxmaniac, oej, qxork and pdunkley (as volunteered for github stuff)
[17:53] <miconda> just as summary
[17:53] <miconda> me and Henning will stay in as well
[17:53] <miconda> anyone else interested to join is welcome (after some security clearance )
[17:55] <miconda> ok then, will ask also on mailing list
[17:55] <miconda> happy that we have a core group formed here
[17:55] <oej> Darn, does that mean I'm out. The security clearance?
[17:55] <oej> Yes, that's progress. Thanks for inviting us Miconda.
[17:55] <miconda> web access only doesn't require the high level
[17:55] <oej> Oh dear. Well, it's a start
[17:56] <oej> You can ask NSA about me… Obviously they know it all now.
[17:56] <miconda>
[17:56] <miconda> ok, next topic (not to get late here)
[17:56] <carstenbock> oej: They have known for years!

[17:57] <miconda> Kamailio World 2014 – I want to know if there are dates that should be avoided from mid March to mid May next year
[17:57] <miconda> apart of obvious dates for Easter (orthodox and catholic)
[17:58] <miconda> and other public holidays in Germany (because all will be closed)
[17:58] <miconda> anyone aware of conferences, events that we should not overlap?
[17:58] <oej> Possibly April Fool's day because no one will believe what you say
[17:58] <oej> I only see IETF, but that's March 3-7
[17:58] <miconda> the plan is to have it again in Berlin, being easy with administration
[17:59] <miconda> and good/cheap to reach from EU
[17:59] <carstenbock> miconda: That's great! I'm in!
[17:59] <oej> Berlin Works fine.
[17:59] <miconda> oej: April 1 looks as good candidate, thoug
[18:00] <miconda> anyway, keep in mind and ping me if you discover something
[18:00] <linuxmaniac> let's see if I can attend :/
[18:00] <oej> Well, then we can easily release Kamailio 5.0 for Windows supporting Lync
[18:00] <oej> ..and skype… and… WhatsApp
[18:00] <miconda> I'll make some proposals soon, once I see availability of locations
[18:00] <pdunkley> If you're going to do a Lync release it should be “Kamailio One” like the latest Xbox…
[18:00] <linuxmaniac> :)
[18:01] <oej> Scchhh. The marketing dept wanted that to be a secret.

[18:01] <miconda> other world wide events?
[18:01] <miconda> pdunkley seems already busy
[18:01] <miconda> I will go to Astricon and most probably Fosdem, in the near future
[18:02] <miconda> although fosdem is next year
[18:02] <oej> I will be at ElastixWorld and Voip2day
[18:02] <oej> voip2day is in November
[18:02] <qxork> Olympics
[18:02] <pdunkley> I'm currently planning AstriCon, WebRTC Expo (November), DevCon5 (December), and FOSDEM.
[18:02] <miconda> so, if anyone goes to events, add news on the website
[18:02] <miconda> or ask us if you don't have write access
[18:02] <pdunkley> Also Telecoms API conference in London in November.
[18:02] <oej> Where's WebRTC expo?
[18:03] <pdunkley> oej: Santa Clara. DevCon5 is in LA.
[18:03] <oej> We need URLs folks, send us the URLs
[18:03] <qxork> I will be at Astricon this year from 2013-10-07 to 2013-10-10
[18:03] <pdunkley> Might be some events at Google Campus London coming up too.
[18:03] <oej> We should have a pre-FOSDEM meeting. ANy dates set for Fosdem?
[18:03] <pdunkley> oej: FOSDEM 14 website is up
[18:03] <miconda> oej: the rule was first weekend in Feb
[18:04] <miconda> I guess they didn't change
[18:04] <pdunkley> Telecom APIs: http://iir-telecoms.com/
[18:05] <pdunkley> WebRTC Conference: http://www.webrtcworld.com/conference/west/
[18:05] <pdunkley> DevCon5: http://www.html5report.com/conference/california/
[18:05] <linuxmaniac> oej: 1&2 of Feb
[18:05] <pdunkley> Someone from Crocodile will be at the Upperside WebRTC conference in Paris in December too. http://www.uppersideconferences.com/webrtc2013/webrtc2013intro.html
[18:06] <pdunkley> oej: URLs a plenty
[18:06] <oej> THank you!
[18:06] <miconda> ok, looks like we don't miss many events out there
[18:07] <miconda> so last on agenda
[18:07] <miconda> next major release
[18:07] <pdunkley> Actually we miss loads
[18:07] <pdunkley> Too many events.
[18:07] <miconda> pdunkley: I know
[18:07] <pdunkley> Anyone here going to TADS in Thailand (at the same time as the November WebRTC conference)?
[18:07] <miconda> even in Berlin are like 2-3 per week that look interesting
[18:07] <carstenbock> Exactly: For example FOKUS FUSECO Conference in November (http://www.fuseco-forum.org), i will be there.
[18:08] <miconda> pdunkley: don't think so, I got an invite, but I can't make it, planning for some trainings instead
[18:08] <pdunkley> Must be someone who can find the budget for Thailand
[18:08] <oej> I need to work… Three weeks on the road in October will be expensive.
[18:09] <miconda> maybe you get donations

[18:09] <miconda> back to 4.1
[18:09] <oej> Is that the skype/lync release?
[18:10] <miconda> do you think we can freeze by end of september?
[18:10] <carstenbock> oej: No that would be Kamailio One.
[18:10] <miconda> any big dev plans still for it?
[18:10] <carstenbock> I hope, i get the documentation ready for IMS-Charging (Diameter-Ro).
[18:10] <pdunkley> I have some additions I want to make to auth_ephemeral over the next couple of weeks. But I am happy with websocket, stun, and outbound now.
[18:10] <oej> I have some new funcitonality in snmp to work with. I hope to complete it soon.
[18:10] <oej> Fighting with net-snmp…
[18:11] <kethzer> Any help with Kamailio NAT configuration I am unable to send file might be NATED issue
[18:11] <kethzer> ?
[18:11] <carstenbock> kethzer: We are still in the developers meeting…
[18:11] <oej> kethzer: Please send e-mail to sr-users and you will get answers. We're in the middle of a meeting
[18:12] <miconda> ok, i have one or two modules in mind, but they can wait if I don't have the time
[18:12] <pdunkley> I'd like to address some of the issues with MSRP, but I won't have the time.
[18:12] <miconda> so, let's plan freezing for end of the month
[18:13] <carstenbock> Okay.
[18:13] <miconda> if need it, we can prolong a bit
[18:13] <miconda> otherwise, is going to be time also for the 4.2

[18:13] <pdunkley> oej: have you had any success with getting your TLS enhancements.
[18:13] <miconda> we need new features for that version too
[18:13] <oej> I have had no time for TLS. Just applied for funding for working with it.
[18:13] <oej> Personally I got lost in the code.
[18:14] <pdunkley> You wanted to be able to set conditions on whether to use a new connection when you call t_relay()?
[18:14] <oej> Yes, after TLS connect I want to inspect certificates and decide if we're going to send the message or close the connection and fail.
[18:14] <pdunkley> Something like if the connection didn't get negotiated/validated the way you wanted you could choose not to use it.
[18:15] <pdunkley> Ah yes. That was what I suggested the xavp for. I remember now.
[18:15] <pdunkley> Need to find a friendly TLS module expert
[18:15] <oej> Yep.
[18:15] <oej> At some point I would like to add DANE support according to the draft I wrote.
[18:16] <oej> We do have DNSsec.
[18:16] <miconda> oej: hmm, you wrote the draft before the code?!?! that's not good…
[18:16] <pdunkley> oej: this security stuff will never take off. NSA and GCHQ are listening anyway.
[18:16] <oej> Yes, we should enable null ciphers by default.
[18:17] <oej> I run Kamailio through some TLS tests but could not get it to be approved. There's updates needed somewhere.
[18:17] <miconda> any official topic to discuss?
[18:17] <oej> I am happy to see interest in DMQ
[18:17] <miconda> any other official topic to discuss?
[18:18] <miconda> oej: yes, glad that cchance jumped in
[18:18] <oej> IPv6 support in all modules
[18:18] <miconda> we will grant git access
[18:18] <oej> Should we try to set that as requirement for the next release?
[18:18] <miconda> oej: those I use have ipv6
[18:18] <oej> Or 4.2 at least
[18:18] <miconda> only the provider doesn't have
[18:18] <oej> I noticed that json was hard coded to the IPv4 legacy protocol
[18:19] <oej> I haven't reviewed the others.
[18:19] <pdunkley> oej: I remember people saying IPv6 was needed right now back when I was at university. That was 15 years ago.
[18:19] <pdunkley> IPv4 still working for me
[18:19] <oej> 15 years ago I had ping6 working on Windows PCs!
[18:20] <oej> We should at least have that as a requirement for new modules
[18:20] <pdunkley> All my Amazon servers are IPv4 only. Think it'll take a miracle to get them onto IPv6.
[18:20] <oej> Or just a tunnel from sixxs.net
[18:20] <carstenbock> IPv6 is quite important.
[18:21] <oej> I will set up a Hall of shame list on the wiki.
[18:21] <carstenbock> It's a big topic with german ISPs.
[18:21] <oej> Cool.
[18:21] <carstenbock> Kamailio IMS is IPv6 ready…
[18:21] <pdunkley> oej: need to make sure you tell the Hall of Shame entrants you've added them. Might help get them moving
[18:22] *** QbY nennt sich jetzt QbY_AFK.
[18:22] <oej> Oh yes, you will know the moment we nail you to that wiki.
[18:23] <voipjedijoe> Hey QbY how do i check by fault to see if it happens before session progress
[18:23] <oej> …he said with a dark voice
[18:23] <oej> We're still working on Happy Eyeballs for UDP in the SIP Forum IPv6 wg…
[18:23] <carstenbock> Any other topics?
[18:23] <oej> –none–

[18:24] <miconda> ok
[18:24] <miconda> I will follow up with some emails in the next days
[18:24] <miconda> about releases, and major suggestions here, etc…
[18:24] <carstenbock> miconda: Thanks for the great work & organizing everything around Kamailio!
[18:25] <miconda> thanks everyone for participating!
[18:25] <linuxmaniac> I've to leave, see you guys!
[18:25] <miconda> linuxmaniac: married?!?
[18:25] <miconda> carstenbock: welcome!
[18:25] <oej> thank you everyone!
[18:25] <linuxmaniac> miconda: see you next month
[18:25] <miconda> will be fun
[18:26] <miconda> better beer than in Alicante last winter
[18:26] <linuxmaniac> miconda: sure
[18:26] <oej> Going to Astricon?
[18:26] <qxork> oej: yes
[18:26] <miconda> btw, free discussion now, not anymore in transcripts
[18:26] <linuxmaniac> miconda: some are on me
[18:26] <oej> See you there!
[18:26] <miconda> oej: yes
[18:26] <oej> — This chat room is now open for normal questions/answers/thoughts/recommendations and SIPpy things
[18:26] <miconda> qxork: I think I have some emails to reply
[18:26] <qxork> Yeni is staying home this year.
[18:27] <miconda> just got my laptop back
[18:27] <qxork> home as in, the bakery
[18:27] <pdunkley> So there will be quite a Kamailio gathering at AstriCon.
[18:27] <qxork> miconda: I hate timemachine, btw
[18:27] <pdunkley> oej: I see you're doing a keynote
[18:27] <oej> Yep I am. Short one.
[18:27] <miconda> qxork: proved to be the hdd cable
[18:27] <miconda> so all data is intact
[18:27] <voipjedijoe> hey everyone, I am having an issue with dispatcher not failing over calls to the next destination when kamailio gets back a 503
[18:27] <voipjedijoe> any suggestions on how to fix that?
[18:27] <oej> qxork: Say hello to Yeni!
[18:28] <miconda> I had backups, but still would have killed lot of time to restore
[18:28] <qxork> oej:
[18:28] <miconda> voipjedijoe: do you intercept 503 in failure route?
[18:28] <oej> Ok, dinner time. See you around folks!
[18:28] <qxork> Talk with all of you soon!
[18:28] <qxork> cheers.
[18:29] <voipjedijoe> no at the moment I only intercept on 500s
[18:29] <voipjedijoe> I need to intercept the 503 but only when it's coming from my freeswitch and not sessioned by my vendor via freeswitch
[18:29] <voipjedijoe> it's an odd problem me thinks
[18:29] <miconda> voipjedijoe: add also 503 in the condition to re-route in falure_route
[18:30] <miconda> iirc, 503 should be replaced by 500 when forwarding
[18:30] <miconda> so you should get 503 only from fs
[18:30] <miconda> otherwise is hard to detect
[18:30] <miconda> unless fs adds some custom reason phrase or special header
[18:31] <voipjedijoe> I agree, but what if my vendor sends me a 503 and I need to session that to my customer. If I add the 503 to my reroute condition all 503s would get rerouted
[18:31] <voipjedijoe> and since in fs I am getting this when I hit max sessions or max cpu on freeswitch I don't think I can add a customer header
[18:33] <miconda> you can use different failure routes for sending to freeswitch
[18:33] <miconda> you send to customers and then to freeswitch?
[18:33] <miconda> or what's the routing logic
[18:34] <voipjedijoe> invite to kam-lb –> route via dispatcher to fs
[18:34] <miconda> kethzer: for the nat problem, you would need to send some network traces
[18:34] <miconda> so you better use mailing list
[18:35] <voipjedijoe> I always get a 100 trying back from freeswitch and then if I hit a limit I get a 503 Maximum Calls In Progress.
[18:36] <miconda> so when you get other 503?
[18:36] <QbY> voipjedijoe: so, have your invite come handled by route_a, set a variable, the moment you see the 100 in the on_reply, change that variable..
[18:36] <QbY> if you see a 503, first check that variable, if that variable says you haven't seen the 100 then send it to your next destination
[18:36] <voipjedijoe> I don't know how to do that
[18:37] <voipjedijoe> ok but I get a 100 back from freeswitch all the time
[18:37] <QbY> http://kamailio.org/dokuwiki/doku.php/pseudovariables:3.1.x
[18:37] <QbY> you shouldn't see a 100 if FS is rejecting the call because of max sessions
[18:37] <voipjedijoe> I am
[18:38] <voipjedijoe> I currently have one of my fs servers set to a max sessions of 2 at the moment, which will allow me 1 complete call. Once I fill up that call I get a 503 back after I get a 100
[18:38] <voipjedijoe> its xrazy
[18:39] * QbY looks at something
[18:39] <voipjedijoe> what do you mean?
[18:40] <QbY> voipjedijoe: what do you have for sip-options-respond-503-on-busy in sofia?
[18:41] <QbY> http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options
[18:41] <voipjedijoe> I looked at this, but it seems to only be for option requests
[18:44] <voipjedijoe> so I just tested that, and I still get a 503
[18:45] <QbY> after getting a 100?
[18:47] <voipjedijoe> yep
[18:49] <voipjedijoe> I could change it in the c
[18:49] <voipjedijoe> but that doesn't seem like the best idea