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] \ the last one was sent to sr-dev, iirc
[16:06] \ the minutes
[16:07] \ oej: yes, it seems for the last one are only on
sr-dev (at least not on wiki)
[16:07] \ Vicente was sending them
[16:08] \ ok … no outstanding issues for now
[16:08] \ next topic
roadmap to next major release
[16:08] \ let's do planning for next minor release
[16:08] \ and do major release at the end
[16:09] \ after we see the near future plans for
development.
[16:09] \ hello
[16:09] \ last minor release was in August 15
[16:09] \ perhaps we can do one by end of September or so
(before Astricon)
[16:10] \ sounds good
[16:10] \ I haven't looked at patches since 4.0.3, but I
remember I did a few of them
[16:11] \ one crash is fixed on ua_redirect
[16:11] \ linuxmaniac: ok, thanks for it
[16:11] \ miconda: my pleasure :-)
[16:12] \ oh not shure if patch was sent but there is
small bug in presence module
[16:12] \ at least it's still at 4.0.3
[16:12] \ ok then -- 4.0.4 by end of September
[16:12] \ \o/
[16:12] \ ZogG_laptop: send it over sr-dev
[16:12] \ or put it on the tracker
[16:12] \ if already fixed, will be marked as done
[16:13] \ what people prefer to do now -- the techical
(devel) topics or the admin ones?
[16:14] \ tech?
[16:14] \ ok
[16:14] \ first come first served
[16:14] \ technical topics
xcap-diff - purpose and testing
[16:14] \ one I wanted to get some input is about xcap-diff
[16:15] \ as I said during last irc meeting I will try to do
it before next major release
[16:15] \ 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] \ so just changing 1 to zero fixed the error from
script
[16:15] \ ZogG_laptop: maybe is not the right fix, if it
expects some parameter
[16:16] \ but report it and we look at
[16:16] \ ok thanks
[16:16] \ i'll do
[16:16] \ carstenbock is the developer, iirc
[16:16] \ That's right, i implemented it.
[16:16] \ and I saw some reports on tracker this morning
[16:16] \ Haven't looked at the recent bug-reports,
though.
[16:17] \ that ruid is not set for records
[16:17] \ Putting the bug on the tracker is the best
way.
[16:17] \ some are already there (regarding reginfo)
[16:17] \ ok, back to my xcap-diff, maybe pdunkley can
comment
[16:18] \ Definitely in favour of getting xcap-diff
support.
[16:18] \ 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] \ is it right?
[16:19] \ Sort-of.
[16:19] \ I started to add, pua and presence should be able
to handle them
[16:19] \ the missing part is the publish from xcap-server
[16:19] \ Problem is that NOTIFYs must be throttled, for
example no-more than one per five second period per dialog.
[16:19] \ So what do you do if there are two changes to the
document in that period?
[16:19] \ pdunkley: everything is sort-of in SIMPLE :-)
[16:19] \ throttling is required by specs?
[16:20] \ 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] \ can we just say at some point, hey, just take the
full docs
[16:20] \ The base SUBSCRIBE/NOTIFY spec. mandates
throttling and recommends 5s for presence.
[16:21] \ 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] \ If the xcap-diff spec. doesn't I'd think it needs
to be the SUBSCRIBE/NOTIFY default of 5s.
[16:21] \ 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] \ That'd be a good starting point for the first
version.
[16:22] \ 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] \ 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] \ keeping the list of diffs can get complex
otherwise
[16:24] \ I agree.
[16:24] \ ok, for now I am fine with this topuc
[16:24] \ This is the server side of xcap-diff?
[16:24] \ yes
[16:24] \ So it allows presence servers and UAs to SUBSCRIBE
to the XCAP server?
[16:25] \ Is there any need or desire to do the client side
of xcap-diff at some point?
[16:25] \ yes, do you want a client?
[16:25] \ maybe for those implementing sip clients...
[16:25] \ 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] \ 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] \ for now my focus is on server
[16:26] \ OK, just checking.
[16:27] \ Does anyone know of a good (and free) client that
supports xcap-diff?
[16:27] \ xcap client is just xcap -- no sip/presence in it,
which will be required here
[16:27] \ so I assume it would have to be a pua_XXX module
[16:27] \ The only one I know of is Blink. But not sure how
good the other bits of Blink presence are...
[16:28] \ pdunkley: probably not, but I though you will add
it to your communicator :-)
[16:28] \ Lol
[16:28] \ i have tested sipclients presence and found bugs in it
that have not been fixed
[16:28] \ We are quite happily using XMPP in a CUSAX like
way at the moment.
[16:28] \ i am not aware of a good ones, free or not
[16:28] \ pdunkley: ok
[16:29] \ May do SIP presence and XCAP in the future, if
there is demand for it.
[16:29] \ ok, then let's mark this topic done
[16:29] \ next one: dialog vs dialog_ng
dialog vs. dialog_ng
[16:29] \ I don't see Jason here for getting more details
about dialog ng
[16:30] \ anyone else here using it? (carstenbock)
[16:30] \ I am a heavy user.
[16:31] \ so what are the differences?
[16:31] \ 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] \ What's the plan
[16:31] \ tear?
[16:31] \ terminated
[16:31] \ oh
[16:31] \ hang up
[16:32] \ 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] \ but there were some parts missing from the old
dialog, or all features of the old dialog are in dialog_ng?
[16:33] \ That's about the main difference. I think
another difference is, that the API has a direct function for
terminating calls.
[16:33] \ What is missing (as with most IMS-modules
actually), is the database-backend.
[16:34] \ All information is only in memory at the
moment.
[16:34] \ are all the rpc commands there?
[16:35] \ carstenbock: that's fine, kamailio just keeps
running
[16:35] \ :-)
[16:35] \ Exactly that's the case... ;-)
[16:35] \ Who needs to depend on databases then?
[16:35] \ A new definition of "no-sql"
[16:35] \ 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] \ I don't know, what they all implemented from
this page:
http:
[16:37] \ ok, db backend is important -- I will try to catch
up with Jason on mailing lists
[16:38] \ I had in mind to do some cleanup on the matching
modes of the old dialog
[16:38] \ probably I will still do it
[16:39] \ i see there is option to get dialog by cutom
added key (from module doc get_dlg_var (dlg, key) )
[16:39] \ Regarding matching modes: dialog_ng does only
matching on SIP-Elements, nothing else.
[16:39] \ I don't think we have that in dialog_ng
(yet).
[16:40] \ carstenbock: yes, that was my plan as well, plus
few optimizations for faster matching
[16:40] \ I'll see if I have enough time
[16:40] \ anything else on the technical side?
[16:41] \ I assume the code restructuring will be postponed,
doesn;t look like enough time for it
[16:41] \ I can confirm, dialog_ng works excellent (for
me in my setups)
[16:41] \ carstenbock: all our homeworks worked at home :-)
[16:41] \ I don't disagree with you, actually
[16:42] \ 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] \ just that many features might be missing
[16:42] \ so regards that function, does it as well
support dialog properties?
[16:42] \ kolbu: with latest 4.0 branch?
[16:42] \ running 4.0.3 ++
[16:42] \ that is, a few days after 4.0.3
[16:43] \ kolbu: what state it hangs on?
[16:43] \ 4
[16:43] \ e.g. from_tag/caller_contact/etc or it does
support only custom added ones from set_dlg_var ?
[16:43] \ are read dialogs from db in dialog-ng ?
[16:43] \ which is good, because then we can close it with the
dlg_end_dlg fifo
[16:43] \ are read dialogs from db in dialog-ng _planned_?
[16:43] \ iZverg: afaik no db implantation was made for
dialog_ng
[16:44] \ Not yet. That will follow.
[16:44] \ kolbu: maybe you can open a tracker item and add
some details there
[16:44] \ DB-Support is definitely planned, but not
scheduled yet...
[16:45] \ i think in dialog need ability to read dialogs from
db
===== memcached module ===== [16:46] \ and memcached multiple
servers. as i see no developer for memcached now?
[16:46] \ miconda: ok, will do
[16:46] * dr wants the memcached module that compiles with
libmemcached in kamailio 4.0.4 :)
[16:46] \ iZverg: memcached module was refactored rather
recently
[16:46] \ worth mentioning that the dialog module in 4.0 is
sooo much more reliable than in 3.3
[16:46] \ so there are developers for it
[16:47] \ kolbu: ok
[16:47] \ dr: I think devel version compiles with that lib
[16:47] \ perhaps henningw or cchance can confirm that
[16:47] \ yes miconda, we've been testing it , it works
[16:47] \ ok
[16:47] \ yes, it compiled but only one server supported
[16:48] \ the library has support for more server, i think
[16:49] \ should be not to hard to extend, patches are as
always welcome :)
[16:49] \ the devel version uses the new library
[16:49] \ s/new/good library
[16:49] \ ok
[16:49] \ anything else on technical aspects?
[16:50] \ other modules to add/fix/remove?
===== presence_dialoginfo module ===== [16:50] \ the
presence one
[16:50] \ ZogG_laptop: what you mentioned already, right?
[16:50] \ nope
[16:51] \ improvemnet
[16:51] \ there is force_single mode or something like
that
[16:51] \ which would send only 1 state in xml
[16:51] \ early/confirmed/etc
[16:51] \ it would pick up mostly randomly
[16:52] \ you refer to presence_dialoginfo module?
[16:52] \ I've got a bunch of updates to the sca module to
pull into 4.x and master.
[16:52] \ leme check
[16:53] \ miconda: yes
[16:53] \ admorten: ok, you should do it soon so they get
tested
[16:53] \ ZogG_laptop: ok
[16:53] \ Will do.
[16:53] \ miconda: the priority should be
early->confirmed->terminated
[16:53] \ ZogG_laptop: again, perhaps opening an item on
tracker will help not forgetting and checking it
[16:54] \ having working dialog profiles would be nice
[16:54] \ miconda: ok. i even may try to get patch for
this one
[16:54] \ ZogG_laptop: that is even better, thanks
[16:54] \ miconda: it would be better though if it would
be checked before applied
[16:54] \ dr: they seem fine, you have troubles with?
[16:55] \ 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] \ ZogG_laptop: sure, they will be reviewed
[16:55] \ admorten: nice, thanks for sharing the numbers
[16:55] \ admorten: is a single sca server?
[16:56] \ Yes, at the moment.
[16:56] \ # set_dlg_profile("caller", "count");
[16:56] \ ##
get_profile_size("caller","count","$avp(callcount)");
[16:56] \ ## xlog("L_INFO","number of simultaneous dialogs:
$avp(callcount)\n");
[16:56] \ not bad then, for handling lots of xml docs
[16:56] \ i want it to decrement automatically
[16:56] \ Right. We have a replicated environment for
failover.
[16:56] \ it doesn't , it always increments that counter
[16:56] \ miconda: SCA doesn't use XML. :)
[16:56] \ admorten: ok, that;s different
[16:57] \ but you said at some point that does dialog-info as
well
[16:57] \ or I misunderstood?
[16:57] \ or you don't use that part...
[16:57] \ That'd be BLA, which we struggled with.
[16:57] \ Need to know how to enable kamailio to send file
over a NATED network
[16:57] \ any hel
[16:57] \ help???/
[16:57] \ XML bodies would grow massive, then packet
fragmentation would overwhelm the handsets.
[16:58] \ Inconsistent state across the groups.
[16:58] \ dr: it will be decremented when the dialog is
ended/destroyed
[16:58] \ kethzer: you have to wait a bit for support
questions, we are doing development and admin meeting
[16:58] \ miconda, that's what I thought too, but this does not
happen with my script
[16:59] \ i had to put the counter in memcache , and increment /
decrement manually
[16:59] \ I do use it in many places, no problem so far...
[16:59] \ what version are you using?
[16:59] \ 4.0.2
[17:00] \ you should shift to latest in 4.0 branch, there
were some fixes for negative replies
[17:00] \ or do dialog related things just before t_relay()
[17:01] \ dr:are you trying to get total dialogs per
subscriber?
[17:01] \ and http_query() from the utils module , it might need
some heavy improvements, it returns only the first line from the
buffer
[17:01] \ It is documented to only do that :-)
[17:01] \ ZogG_laptop, no , total number of dialogs
===== http modules ===== [17:02] \ But yes, we need improvements
in http_client
[17:02] \ Sorry, I would say we need a http_client module that
consolidates all http clients
[17:02] \ We have several different ones
[17:02] \ dr: speaking of that, I think carstenbock did some
work on http client lately
[17:03] \ but iirc, he pushed on a personal branch
[17:03] \ There's one in utils, one in jsonrpc and one in xcap
client and possibly sip identy
[17:03] \ From the top of my head. Some use libcurl.
[17:03] \ oej: right, maybe we should pull out http client
part from all modules and have one that will be reused
[17:04] \ I think that would be a good thing moving forward.
[17:04] \ jsonrpc client uses netstrings, iirc
[17:04] \ is not over http
[17:04] \ Then we could get IPv6 in every one and solve happy
eyeballs once.
[17:04] \ 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] \ 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] \ carstenbock: any comments on your recent work on
http cleint?
[17:05] \ $DLG_lifetime, sorry
[17:06] \ ok, let's move forward (probably carstenbock has
left a bit)
[17:06] \ anything else on tech stuff?
[17:06] \ how about mediaproxy-ng module?
[17:07] \ 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] \ jh: rtpproxy_ng?
[17:07] \ admorten: yes, could be interesting
[17:07] \ miconda:
https:github.com/sipwise/mediaproxy-ng
[17:08] \ push the patches somewhere for some review
[17:08] \ yes, ment rtpproxy-ng (naming is confusing)
[17:08] \ miconda: OK
[17:08] \ jh: yes, I know, quite confusing in both sides,
even the external application
[17:08] \ I'll put them up on sip-router tracker and post to
sr-dev when ready.
[17:08] \ there was some bugs found. will those be fixed before
next release?
[17:09] \ probably yes. I don't see Richard here
[17:09] \ but I guess sipwise is highly interested to get all
bugs closed
[17:09] \ miconda: :yes:
[17:09] \ linuxmaniac may be able to comment more
[17:09] \ I know some were fixed already
[17:10] \ hughw: send some patches as well, e
[17:10] \ were they done?
[17:10] \ miconda: afaik yes
http modules
[17:10] \ (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] \ rephrasing: hughw sent some patches to
rtpproxy-ng
[17:10] \ I think they are been merged
[17:10] \ linuxmaniac: ok
[17:11] \ carstenbock: ok, maybe you should merge on master,
to be easy to test for not-git gurus :D
[17:11] \ carstenbock: Using curl?
[17:12] \ 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] \ miconda: Will do that.
[17:12] \ oej: Yes.
[17:12] \ carstenbock: Which module is that?
[17:13] \ oej: utils
[17:13] \ ZogG_laptop: for clarification - the external
application is named mediaproxy-ng, but the corresponding module in
kamailio is named rtprpoxy-ng
[17:14] \ miconda: yeah, thanks, got it from conversation
above and some google
[17:14] \ :)
[17:14] \ 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] \ i think http get/post would be enuf and what
would be needed are modules to parse responses (json/xml/whateverelse)
[17:17] \ ok, done with tech stuff?
OpenSSL licence exception
[17:17] \ openSSL exception licence
[17:17] \ license
[17:18] \ oej: no mail from you on the mail list :-P
[17:18] \ linuxmaniac: ok, that was the next in list
[17:18] \ I did brainstorm about it earlier this week
[17:18] \ :-)
[17:18] \ but I thought of it more admin stuff
[17:19] \ miconda: I can wait :)
[17:19] \ no, it is on now
[17:19] \ let's discuss it
[17:19] \ one way is to implement tls module with gnutls
[17:20] \ I think is "just" a matter add the exception
clause
[17:20] \ carstenbock: How do I set content-type in the post
data?
[17:20] \ the other one is getting devels to agree with the
exception
[17:20] \ which most of them will do, but many are gone
[17:20] \ from the early stage of ser
[17:20] \ 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] \ also, lot of copyright is by fokus, which was sold
to tekelec which was recently bought by oracle
[17:21] \ Oh yeah, let's consult Oracle lawyers
[17:21] \ haha
[17:21] \ so we may need to buy a beer to Larry
[17:21] \ So the problem here is that the tls module is not part
of linux distros because of this, right?
[17:21] \ hehe
[17:21] \ ZogG_laptop: do you have a backtrace?
[17:21] \ OpenSSL is used by other modules (for access to
the randomness and crypto routines).
[17:22] \ oej: I can't add tls on Debian because of
that
[17:22] \ websocket, outbound, auth_ephemeral all link to it
- BTW I am fine with the exception.
[17:22] \ Yes, there's a few modules that Debian won't accept
[17:22] \ linuxmaniac: the question is, all devs have to
agree?
[17:22] \ so we can clear those three modules
[17:22] \ miconda: no here for sure. but i think i can
emulate it anytime
[17:22] \ linuxmaniac: or only devs to the modules that link
to openssl?
[17:23] \ because the core doesn't link to openssl, only few
modules (tls among them)
[17:23] \ afaik i just read of some sip lib that switched
for smaller lib for tls/ssl instead of openssl
[17:23] \ miconda: don't know, but I will say just the
ones that use openssl
[17:23] \ ZogG_laptop: a backtrace would be good and
eventually the log with debug=3
[17:23] \ What is the background of the TLS module, was code
moved from the core to that?
[17:24] \ miconda: would try to get one to you thru
maillist or tracker next week
[17:24] \ linuxmaniac: that would be easier
[17:24] \ Other modules are tls, osp, stun, auth_identity
[17:24] \ Andrei reimplemented tls module
[17:24] \ nothing from old openser core was used for it
[17:24] \ I guess pdunkley has nothing against to agree for
websocket module
[17:25] \ 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] \ miconda: I can try to ask on debian-legal and
see what they say
[17:25] \ stun and auth_identity is from iptel.org guys
[17:25] \ linuxmaniac: please do it, so we know what we have
to do
[17:25] \ pdunkley has three modules to disclaim, but that should
be fine
[17:25] \ miconda: noted
[17:25] \ linuxmaniac: mention also that we package tls
module separately
[17:26] \ linphone apprantly switched from openssl to
https:polarssl.org/
[17:26] \ is not part of other package
[17:26] \ can we get agreement fron Andrei?
[17:26] \ miconda: I will send you the mail draft before
send it to them
[17:27] \ Just checked, I can remove the OpenSSL dependency
from stun with a trivial code change.
[17:27] \ but anyways we have to add the exception
[17:27] \ I am happy to disclaim my modules.
[17:27] \ oej: probably iptelorg
[17:27] \ That means websocket, stun, outbound, and
auth_ephemeral are fine.
[17:27] \ but at least we know the target, I will get in
touch if it all we need
[17:27] \ miconda: back to larry
[17:27] \ Leaves just tls, osp, and auth_identity
[17:28] \ for osp I can approach the company that developed
it
[17:28] \ Transnexus
[17:28] \ although they were not very active, I guess they
have nothing against
[17:28] \ oej: yes
[17:28] \ but not sure how many users that module has
[17:28] \ Auth_identity was a school, that should possibly be
fine if we can track someone down
[17:28] \ afaik, only that company had a solution to work
with it
[17:29] \ tls is a tough nut to crack and an important one
[17:29] \ yes, tls is the one that needs it most ...
[17:30] \ the other important one, websocket, is fine
[17:30] \ for stun, I guess we can reimplement it
[17:30] \ doesn't look that hard
[17:30] \ and is not big
[17:30] \ tls has lot of code, on the other hand
[17:30] \ Yep.
[17:31] \ ok i'm off. bye and goood luck to every one adn
thanks for help.
[17:31] \ but first let's see what linuxmaniac gets from
debian-legal and then I will see how to approach for tls + stun
[17:31] \ ZogG_laptop: thanks for joining!
[17:31] \ anything else about openssl exception?
[17:31] \ ok then
[17:32] \ 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] \ bye
[17:32] \ thanks, bye
===== github clone ===== [17:32] \ next admin stuff: github
[17:32] \ Andreas Granig secured kamailio name on github
[17:33] \ pdunkley and few others expressed the willingness
to maintain a clone of the repo there
[17:33] \ we have a mirror at sipwise
[17:33] \ Github would work best if that was the primary
repo.
[17:34] \ so, do we get enough work force to maintain a
clone
[17:34] \ Biggest advantage of Github is fork management
etc.
[17:34] \ pdunkley: from Andreas I understood is a matter of
some scripts to merge back and forth
[17:34] \ but in case of conflicts, someone has to care of
...
[17:34] \ Yes.
[17:35] \ I suppose that is true.
[17:35] \ pdunkley: but you can fork with no problem
afaik
[17:35] \ 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] \ 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] \ why did we leave sourceforge?
[17:36] \ besides the fact that github started to have issues
(e.g., availability)
[17:36] \ pdunkley: the thing is that you have to do git
am on our repo not github
[17:36] \ oej: when we merged the code, we had svn on
sourceforge and ser was cvs on berlios
[17:36] \ we needed root privileges :-)
[17:36] \ to make things fit together
[17:37] \ 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] \ Right.
[17:37] \ pdunkley: will not be a read only clone
[17:37] \ Will we end up in the same situation with github
[17:37] \ github can get updates directly there
[17:37] \ the scripts have to do sync both ways
[17:38] \ Andreas said is something they do as well for some
of their repos
[17:38] \ afaik github is just a mirror for us
[17:38] \ I guess the big question is whether enough people
think that Github provides advantages to the project.
[17:38] \ no changes from github onto our repo
[17:39] \ linuxmaniac: check sr-dev for Andreas' email on
this topic
[17:39] \ 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] \ 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] \ so, at least have to keep/try both for a while just
to see if github is good
[17:41] \ miconda: "Everytime you push something to the
internal repo, the github repo gets automatically synced and
overwritten"
[17:41] \ so no changes from github on our repo
[17:42] \ linuxmaniac: "people have the possibility to send
pull requests and everything"
[17:43] \ miconda: yes
[17:43] \ but no merge is done
[17:43] \ so I assumed they are used ...
[17:43] \ miconda: you have to use git am on the "master"
repo
[17:43] \ linuxmaniac, miconda: but does the internal repo
get sync'd and overwritten everytime the github repo is changed?
[17:44] \ pdunkley: no changes are done on github
[17:44] \ this is just "read-only"
[17:44] \ OK. That's my point.
[17:44] \ 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] \ If we don't make changes on Github, we can't use
Github push requests etc for merging.
[17:44] \ So there is no advantage to Github.
[17:45] \ 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] \ pdunkley: just a nice web interface and the
pull-request are received as mails
[17:46] \ we can use http://gitlab.org/ in our server
[17:46] \ pdunkley: maybe there are tutorials to do sync two
ways
[17:47] \ I thought Andreas said they do merge on both ways
[17:47] \ maybe was on some private conversation
[17:48] \ 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] \ miconda: he is just in front of me. No changes
from github
[17:48] \ linuxmaniac: ok
[17:48] \ i misunderstood
[17:48] \ 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] \ It's conference season :-(
[17:49] \ this comes also to another point related to
administration
===== technical administration group ===== [17:50] \ building
a tech admin group
[17:50] \ with volunteers
[17:50] \ to care of various aspects of the project
[17:50] \ including releases, sysadmin work on servers
[17:50] \ miconda: I'm still single, I have some time
free. haha
[17:50] \ typically was me, Henning and Jan
[17:50] \ linuxmaniac: great
[17:51] \ you are more than welcome to join
[17:51] \ that will be great
[17:51] \ I can help more with the web site.
[17:51] \ Would love to help out. LOD.com is also interested in
donating servers, etc.
[17:52] \ 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] \ qxork: I am willing to receive donations! Haha.
[17:52] \ miconda: sounds reasonable
[17:53] \ ok, so here we have linuxmaniac, oej, qxork and
pdunkley (as volunteered for github stuff)
[17:53] \ just as summary
[17:53] \ me and Henning will stay in as well
[17:53] \ anyone else interested to join is welcome (after
some security clearance :-D )
[17:55] \ ok then, will ask also on mailing list
[17:55] \ happy that we have a core group formed here
[17:55] \ Darn, does that mean I'm out. The security clearance?
[17:55] \ Yes, that's progress. Thanks for inviting us Miconda.
[17:55] \ web access only doesn't require the high level
:-)
[17:55] \ Oh dear. Well, it's a start :-)
[17:56] \ You can ask NSA about me… Obviously they know it all
now.
[17:56] \ :-)
[17:56] \ ok, next topic (not to get late here)
[17:56] \ oej: They have known for years!
===== Kamailio World 2014 ===== [17:57] \ 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] \ apart of obvious dates for Easter (orthodox and
catholic)
[17:58] \ and other public holidays in Germany (because all
will be closed)
[17:58] \ anyone aware of conferences, events that we should
not overlap?
[17:58] \ Possibly April Fool's day because no one will believe
what you say
[17:58] \ I only see IETF, but that's March 3-7
[17:58] \ the plan is to have it again in Berlin, being easy
with administration
[17:59] \ and good/cheap to reach from EU
[17:59] \ miconda: That's great! I'm in! :-)
[17:59] \ Berlin Works fine.
[17:59] \ oej: April 1 looks as good candidate, thoug :-)
[18:00] \ anyway, keep in mind and ping me if you discover
something
[18:00] \ let's see if I can attend :/
[18:00] \ Well, then we can easily release Kamailio 5.0 for
Windows supporting Lync
[18:00] \ ..and skype… and… WhatsApp
[18:00] \ I'll make some proposals soon, once I see
availability of locations
[18:00] \ If you're going to do a Lync release it should be
"Kamailio One" like the latest Xbox...
[18:00] \ :)
[18:01] \ Scchhh. The marketing dept wanted that to be a
secret.
===== Other world wide events ===== [18:01] \ other world
wide events?
[18:01] \ pdunkley seems already busy
[18:01] \ I will go to Astricon and most probably Fosdem, in
the near future
[18:02] \ although fosdem is next year
[18:02] \ I will be at ElastixWorld and Voip2day
[18:02] \ voip2day is in November
[18:02] \ Olympics
[18:02] \ I'm currently planning AstriCon, WebRTC Expo
(November), DevCon5 (December), and FOSDEM.
[18:02] \ so, if anyone goes to events, add news on the
website
[18:02] \ or ask us if you don't have write access
[18:02] \ Also Telecoms API conference in London in
November.
[18:02] \ Where's WebRTC expo?
[18:03] \ oej: Santa Clara. DevCon5 is in LA.
[18:03] \ We need URLs folks, send us the URLs
[18:03] \ I will be at Astricon this year from 2013-10-07 to
2013-10-10
[18:03] \ Might be some events at Google Campus London
coming up too.
[18:03] \ We should have a pre-FOSDEM meeting. ANy dates set for
Fosdem?
[18:03] \ oej: FOSDEM 14 website is up
[18:03] \ oej: the rule was first weekend in Feb
[18:04] \ I guess they didn't change
[18:04] \ Telecom APIs: http:iir-telecoms.com/
[18:05] \ WebRTC Conference:
http:
[18:05] \ DevCon5:
http:
[18:05] \ oej: 1&2 of Feb
[18:05] \ Someone from Crocodile will be at the Upperside
WebRTC conference in Paris in December too.
http:
[18:06] \ oej: URLs a plenty
[18:06] \ THank you!
[18:06] \ ok, looks like we don't miss many events out there
:-)
[18:07] \ so last on agenda
[18:07] \ next major release
[18:07] \ Actually we miss loads :-)
[18:07] \ Too many events.
[18:07] \ pdunkley: I know
[18:07] \ Anyone here going to TADS in Thailand (at the same
time as the November WebRTC conference)?
[18:07] \ even in Berlin are like 2-3 per week that look
interesting
[18:07] \ Exactly: For example FOKUS FUSECO Conference in
November (http://www.fuseco-forum.org), i will be there.
[18:08] \ pdunkley: don't think so, I got an invite, but I
can't make it, planning for some trainings instead
[18:08] \ Must be someone who can find the budget for
Thailand ;-)
[18:08] \ I need to work… Three weeks on the road in October will
be expensive.
[18:09] \ :-) maybe you get donations
===== 4.1 release planning ===== [18:09] \ back to 4.1
[18:09] \ Is that the skype/lync release?
[18:10] \ do you think we can freeze by end of september?
[18:10] \ oej: No that would be Kamailio One.
[18:10] \ any big dev plans still for it?
[18:10] \ I hope, i get the documentation ready for
IMS-Charging (Diameter-Ro).
[18:10] \ 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] \ I have some new functionality in snmp to work with. I
hope to complete it soon.
[18:10] \ Fighting with net-snmp...
[18:11] \ Any help with Kamailio NAT configuration I am
unable to send file might be NATED issue
[18:11] \ ?
[18:11] \ kethzer: We are still in the developers
meeting...
[18:11] \ kethzer: Please send e-mail to sr-users and you will
get answers. We're in the middle of a meeting
[18:12] \ ok, i have one or two modules in mind, but they can
wait if I don't have the time
[18:12] \ I'd like to address some of the issues with MSRP,
but I won't have the time.
[18:12] \ so, let's plan freezing for end of the month
[18:13] \ Okay.
[18:13] \ if need it, we can prolong a bit
[18:13] \ otherwise, is going to be time also for the 4.2
===== TLS enchancements ===== [18:13] \ oej: have you had
any success with getting your TLS enhancements.
[18:13] \ we need new features for that version too
[18:13] \ I have had no time for TLS. Just applied for funding
for working with it.
[18:13] \ Personally I got lost in the code.
[18:14] \ You wanted to be able to set conditions on whether
to use a new connection when you call t_relay()?
[18:14] \ 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] \ Something like if the connection didn't get
negotiated/validated the way you wanted you could choose not to use
it.
[18:15] \ Ah yes. That was what I suggested the xavp for. I
remember now.
[18:15] \ Need to find a friendly TLS module expert :-)
[18:15] \ Yep.
[18:15] \ At some point I would like to add DANE support
according to the draft I wrote.
[18:16] \ We do have DNSsec.
[18:16] \ oej: hmm, you wrote the draft before the code?!?!
that's not good…
[18:16] \ oej: this security stuff will never take off. NSA
and GCHQ are listening anyway.
[18:16] \ Yes, we should enable null ciphers by default.
[18:17] \ I run Kamailio through some TLS tests but could not get
it to be approved. There's updates needed somewhere.
[18:17] \ any official topic to discuss?
[18:17] \ I am happy to see interest in DMQ
[18:17] \ any other official topic to discuss?
[18:18] \ oej: yes, glad that cchance jumped in
[18:18] \ IPv6 support in all modules
[18:18] \ we will grant git access
[18:18] \ Should we try to set that as requirement for the next
release?
[18:18] \ oej: those I use have ipv6
[18:18] \ Or 4.2 at least
[18:18] \ only the provider doesn't have
[18:18] \ I noticed that json was hard coded to the IPv4 legacy
protocol
[18:19] \ I haven't reviewed the others.
[18:19] \ oej: I remember people saying IPv6 was needed
right now back when I was at university. That was 15 years ago.
[18:19] \ IPv4 still working for me ;-)
[18:19] \ 15 years ago I had ping6 working on Windows PCs!
[18:20] \ We should at least have that as a requirement for new
modules
[18:20] \ All my Amazon servers are IPv4 only. Think it'll
take a miracle to get them onto IPv6.
[18:20] \ Or just a tunnel from sixxs.net
[18:20] \ IPv6 is quite important.
[18:21] \ I will set up a Hall of shame list on the wiki.
[18:21] \ It's a big topic with german ISPs.
[18:21] \ Cool.
[18:21] \ Kamailio IMS is IPv6 ready... :-)
[18:21] \ 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] \ Oh yes, you will know the moment we nail you to that
wiki.
[18:23] \ Hey QbY how do i check by fault to see if it
happens before session progress
[18:23] \ …he said with a dark voice
[18:23] \ We're still working on Happy Eyeballs for UDP in the
SIP Forum IPv6 wg…
[18:23] \ Any other topics?
[18:23] \ --none--
===== open discussion ===== [18:24] \ ok
[18:24] \ I will follow up with some emails in the next
days
[18:24] \ about releases, and major suggestions here,
etc...
[18:24] \ miconda: Thanks for the great work & organizing
everything around Kamailio!
[18:25] \ thanks everyone for participating!
[18:25] \ I've to leave, see you guys!
[18:25] \ linuxmaniac: married?!?
[18:25] \ carstenbock: welcome!
[18:25] \ thank you everyone!
[18:25] \ miconda: see you next month :-P
[18:25] \ :-) will be fun
[18:26] \ better beer than in Alicante last winter
[18:26] \ miconda: sure
[18:26] \ Going to Astricon?
[18:26] \ oej: yes
[18:26] \ btw, free discussion now, not anymore in
transcripts :-)
[18:26] \ miconda: some are on me
[18:26] \ See you there!
[18:26] \ oej: yes
[18:26] \ — This chat room is now open for normal
questions/answers/thoughts/recommendations and SIPpy things
[18:26] \ qxork: I think I have some emails to reply
[18:26] \ Yeni is staying home this year.
[18:27] \ just got my laptop back
[18:27] \ home as in, the bakery
[18:27] \ So there will be quite a Kamailio gathering at
AstriCon.
[18:27] \ miconda: I hate timemachine, btw
[18:27] \ oej: I see you're doing a keynote
[18:27] \ Yep I am. Short one.
[18:27] \ qxork: proved to be the hdd cable
[18:27] \ so all data is intact
[18:27] \ 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] \ any suggestions on how to fix that?
[18:27] \ qxork: Say hello to Yeni!
[18:28] \ I had backups, but still would have killed lot of
time to restore
[18:28] \ oej: =)
[18:28] \ voipjedijoe: do you intercept 503 in failure
route?
[18:28] \ Ok, dinner time. See you around folks!
[18:28] \ Talk with all of you soon!
[18:28] \ cheers.
[18:29] \ no at the moment I only intercept on 500s
[18:29] \ 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] \ it's an odd problem me thinks
[18:29] \ voipjedijoe: add also 503 in the condition to
re-route in falure_route
[18:30] \ iirc, 503 should be replaced by 500 when
forwarding
[18:30] \ so you should get 503 only from fs
[18:30] \ otherwise is hard to detect
[18:30] \ unless fs adds some custom reason phrase or special
header
[18:31] \ 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] \ 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] \ you can use different failure routes for sending to
freeswitch
[18:33] \ you send to customers and then to freeswitch?
[18:33] \ or what's the routing logic
[18:34] \ invite to kam-lb --> route via dispatcher to
fs
[18:34] \ kethzer: for the nat problem, you would need to
send some network traces
[18:34] \ so you better use mailing list
[18:35] \ 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] \ so when you get other 503?
[18:36] \ 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] \ 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] \ I don't know how to do that
[18:37] \ ok but I get a 100 back from freeswitch all the
time
[18:37] \
http:kamailio.org/dokuwiki/doku.php/pseudovariables:3.1.x
[18:37] \ you shouldn't see a 100 if FS is rejecting the call
because of max sessions
[18:37] \ I am
[18:38] \ 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] \ its xrazy
[18:39] * QbY looks at something
[18:39] \ what do you mean?
[18:40] \ voipjedijoe: what do you have for
sip-options-respond-503-on-busy in sofia?
[18:41] \
http://wiki.freeswitch.org/wiki/Sofia.conf.xml#SIP_Related_options
[18:41] \ I looked at this, but it seems to only be for
option requests
[18:44] \ so I just tested that, and I still get a 503
[18:45] \ after getting a 100?
[18:47] \ yep
[18:49] \ I could change it in the c
[18:49] \ but that doesn't seem like the best idea