[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 ===== 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 ===== memcached module ===== [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? ===== rtpproxy_ng ===== [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