Kamailio SIP Server Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Chat log IRC Devel Meeting - 2013-09-12 ======
===== outstanding issues at this time, if any =====
[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\\ 
===== roadmap to next major release =====
[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\\ 
===== xcap-diff - purpose and testing =====
[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?\\ 
===== presence_dialoginfo module =====
[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\\ 
===== http modules =====
[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\\ 
===== http modules =====
[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?\\ 
===== OpenSSL licence exception =====
[17:17] <linuxmaniac> openSSL exception licence\\ 
[17:17] <linuxmaniac> license\\ 
[17:18] <linuxmaniac> oej: no mail from you on the mail list :-P\\ 
[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\\ 
===== github clone =====
[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\\ 
===== technical administration group =====
[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 :-D )\\ 
[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!\\ 
===== Kamailio World 2014 =====
[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.\\ 
===== Other world wide events =====
[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\\ 
===== 4.1 release planning =====
[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\\ 
===== TLS enchancements =====
[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--\\ 
===== open discussion =====
[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 :-P\\ 
[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\\