Differences

This shows you the differences between two versions of the page.

--- devel:irc-meetings:2012a [2012/01/31 13:25] – [Agenda] 85.178.65.250
+++ devel:irc-meetings:2012a [2012/03/04 17:22] (current) – [Participants] 85.178.79.238
@@ Line 38: / Line 38: @@
 Note that participation is open to anyone, just join the IRC channel if you want to participate.
+===== Transcripts of Discussed Topics =====
+This is pretty much the unedited IRC discussion, split by topics.
+==== Existing Issues ====
+<code>
+miconda: anyone here to report any outstanding issue (code, administration, etc.) that needs to be fixed?
+richardgood: nothing to report here.
+miconda: ok if none is quick with something ... think about and eventually say during this session
+</code>
+==== Packaging ====
+<code>
+miconda: second: packaging
+miconda: we have debs and rpms
+miconda: debs provided at deb.kamailio.org are fine for nightly builds
+jasonpenton: maybe an option for Solaris packages - but I'm not too sure of the demand?
+miconda: but the release builds need some manual triggering, as I understood from Jon Bonilla
+miconda: and they stay sometimes long time behind
+miconda: for that reason I made an OpenSUSE Build Service that can be triggered via web
+miconda: I will post some details later
+osas: is there a real need for nightly pkg builds?
+miconda: rpms should be fine for now on OBS (OpenSUSE Build Service) - rpms for centos, redhat, fedora and opensuse are generated
+miconda: osas: yes, they are very useful to get fixes from stable branches
+miconda: agranig: thanks, but I was looking for a solution when many people can get access
+osas: besides for checking that the build is susscessfull, I don't see a real presure in having nightly builds for all platforms
+miconda: not for all platforms
+miconda: but actually the problem is not nightly builds
+miconda: they are done automatically
+miconda: just release builds
+agranig: miconda: sure... just as a side note: we're using jenkins to build our internal debs and generate release repos, maybe this should be considered for kamailio as well?
+miconda: which have to be done manually, since the releases happen sporadically
+agranig: i can provide some input on that if we want to go that path
+miconda: jenkins is a service or tool?
+agranig: it's a tool... a continuous integration server, which can be hooked up with a git repo, which than triggers deb builds either immediately upon commit, or on nightly intervals, or when you prepare a release
+miconda: at this moment the debs are generated on a server that would require user access to trigger release builds
+miconda: and it is hard to keep adding users to be sure someone is going to be available to trigger
+miconda: OBS does everything over web
+miconda: or a client installed on own system
+miconda: so it is convenient to allow "any" people to manage the repository and revoke later if not trusted
+agranig: ok... with jenkins, you'd have a web interface where you control it (and a jabber interface etc)... it's quite powerful in that regards... you'd still have to maintain users though
+miconda: I am not saying is the best way, that;s why I wanted to see if there are other options
+miconda: ok then, let's see if we can get something with jenkins or obs in regards to debs for releases ...
+miconda: jasonpenton: solaris would be nice
+miconda: if someone can take care of
+miconda: I am not a solaris user at all
+jasonpenton: look - we will be doing it for ourselves anyway - so we will take it on
+miconda: great, thanks!
+jasonpenton: but can't commit a time yet!
+miconda: no problem!
+agranig: there are couple of tools to maintain repos automatically, we can talk at fosdem about the details
+miconda: *BSD specs are probably old as well ...
+miconda: gentoo got quite up to date
+miconda: agranig: ok
+miconda: so, to finish this topic
+miconda: if you know tools to automatize building packages for any distro or want to maintain packaging for some distro, write to sr-dev mailing list
+</code>
+==== Documentation ====
+<code>
+miconda: next topic: documentation ...
+miconda: I saw lot of good info going though mailing lists, but nobody is digesting in some wiki pages or faqs ...
+miconda: anyone has ideas of how to attract doc writers?!?!
+osas: It should be the responsability of the one who get's help to update the wiki
+miconda: yes, but cannot be enforced
+osas: and the pone that provides help should remind the one that gets helped to update the wiki
+osas: it cannot, but if someone is reminded to do so, it will (most of the time)
+jasonpenton: users will never update/contribute to docs
+miconda: so we need to engage their willingness somehow
+jasonpenton: it will be up to devs only IMO
+osas: no
+osas: devs have a different POV
+osas: I cannot see things like a beginner
+osas: and therefor I cannot update docs from a beginner POV
+osas: I think that's the issue
+jasonpenton: true - but users are typically consumers of info and never interested in producing
+osas: from my POV, the docs are quite good
+osas: Than you get hellped onces, and that's it
+miconda: ok, so kind of bonus program ...
+jasonpenton: lol - that;s a good idea - provide doc for free consulting
+miconda: you got answers and no updates to docs, then you are delayed
+osas: I think a friendly reminder by everyone who provides help shold give the docs a boost
+miconda: osas: yes, that should be done, added as a signature
+miconda: jasonpenton: could be something like audio conference
+agranig: just curious... where would you even add interesting junks from the mailing list, e.g. config snippets for specific use cases?
+osas: and a friendly monthly e-mail about it
+jasonpenton: agranig: wiki
+jasonpenton: ?
+agranig: yeah, but where?
+miconda: aswering questions to participants and they have to write docs based on answers
+jasonpenton: what about the responders to good email questions: create a wiki page and the user needs to update on experienceand succuess, etc?
+miconda: maybe 1-2 sessions a month
+agranig: like in http://www.kamailio.org/wiki/start#tutorials or where?
+jasonpenton: and all follow up questions
+miconda: jasonpenton: sometimes I answer from a mobile or in a hurry, creating a wiki is not always easy...
+miconda: agraning: yes, that is a place, other can be created, like FAQ page
+miconda: ok, other ideas? If not, we will digest this discussion and go to mailing list for follow up
+agranig: handing off good questions to the wiki sounds interesting, but the usability is questionable... you don't get to know if/when the OP is providing infos there etc
+miconda: agraning: first is to get something, then we can review and clean up
+miconda: but how to get some writers...
+agranig: maybe a Q/A portal similar to stackoverflow could help, but then again you could just stick with the mailinglist...
+qxork: I was thinking about this hard based on the mail yesterday... problem is that without a very good understanding of SIP, the documentation simply won't make sense.
+qxork: I think what Alex wrote yesterday was amazing
+agranig: ack
+agranig: it should be taken as kind of an official project introduction
+miconda: qxork: access to web site only if answering correctly a SIP spec question?
+qxork: I do think Alex's piece might make a very good intro
+</code>
+==== Presence ====
+<code>
+miconda: next a bit about presence ... I added recently based on last mailing list activity
+miconda: is pdunkley or other presence users/devs active in the channel?
+pdunkley: I am here
+miconda: I got the impression that some code is duplicated across couple of modules
+miconda: when presence server was started, we had no internal libraries
+miconda: but now we have that
+pdunkley: There is certainly quite a bit of code duplicated within some of the modules.
+miconda: would it be the case of making an internal lib to collect such code?
+pdunkley: The only stuff I can think of that is duplicated between the modules is the pres_auth_status()/xcap_auth_status() stuff.
+miconda: so there will be no need to patch in many places, whenever is something to fix
+miconda: btw, irc, presence module has also some lib only mode
+pdunkley: I am not sure how easy it would be to write a lib for some of the stuff.  I don't think there is a huge amount duplicated between presence/presence_xml/pua/rls.
+pdunkley: There is similar (but not quite the same code) in some places.  But not a lot duplicated.
+pdunkley: I don't know about the other presence modules (for dialogs, pua_xmpp, and so on).
+miconda: ok
+miconda: wanted to double check ... when I have time I will look a bit over the code
+pdunkley: I think there could be a lot duplicated between presence_conference, presence_dialoginfo, presence_mwi, ... though
+miconda: ok
+pdunkley: A nearly identical pair of files (pidf.[ch]) is in presence_xml, presence_conference, presence_dialoginfo, and pua.
+pdunkley: and pua_xmpp
+pdunkley: So there could be something there.
+miconda: thanks for checking, maybe I have time to look over before Fosdem and update there for a decision
+miconda: anything else related to presence?
+miconda: any refactoring that should be done?
+miconda: anyone using MSRP?
+pdunkley: I am currently thinking about adding an internal API between RLS and presence.
+pdunkley: I might clean-up some bits and pieces as I do that, if I spot anything.
+pdunkley: Internal as in functions, to try and squeeze a bit more performance and dodge some of the race hazards.
+miconda: ok ... topic done?
+carstenbock: The topic of my speech at LinuxTag will be on Rich Communications with sip-router.org (if accepted)
+pdunkley: I've not tried the MSRP yet.  I was thinking a handy feature might be some sort of function interface into MSILO so that offline MSRP messages can be captured?
+miconda: offline msrp ... if the connection to target is closed, could be useful
+pdunkley: Yes, and establish a connection and send the messages when the target REGISTERs and comes online.
+miconda: pdunkley: but you have to create a dialog with INVITE first ...
+pdunkley: Can the uac module (or other modules) be used to terminate the INVITE session and create an INVITE session after REGISTER?
+miconda: uac does not have for the moment such feature
+miconda: can be enhanced
+miconda: dialog module has some feature for doing click-to-dial
+aXl: regarding pua: i still have to port the deadlock freen version from 1.5 to 3.x. I looked at it quickly a few months ago, but it will require a bit of work for which i don't have time yet.
+miconda: invite, 200ok, ack, refer, 200ok, bye, 200ok
+miconda: aXl: i think that was fixed
+miconda: was it deadlock or race in handling taffic?
+aXl: it deadlocked because it kept a lock on a hash bucket entry while waiting for a sip response
+aXl: if all sip listeners are waiting for such a lock...
+miconda: I had in mind it was fixed by some refactoring in handling the traffic
+miconda: you can doublecheck when you have the time
+aXl: ok, i haven't noticed any siginficant changes to pua in the 3.0/3.1 timeframe, so i assumed it wasn;t fixed yet
+miconda: there were lot in 3.2 and devel
+pdunkley: DB only mode and a lot of race-hazards fixed since 3.2
+miconda: anything else on presence?
+pdunkley: Nothing from me
+aXl: no
+</code>
+==== Duplicated Modules ====
+<code>
+miconda: merging duplicated modules
+miconda: long live topic
+miconda: I hope we get pdt, dispatcher and few more merged
+miconda: auth_db depends on db schema, let's see
+miconda: maybe usrloc, as I have some plans for gruu support
+jasonpenton: miconda, quick question about modules K|S - if we write a new module, where should it go? K|S|modules?
+miconda: ser version has implemented parts of gruu already
+jasonpenton: assuming brand new functinality
+miconda: should go in modules
+jasonpenton: ok
+miconda: radius modules were merged once, then reverted, don't recall the reason right now
+miconda: xlog from ser still has specifiers like '%ru' and it is used by other ser modules
+miconda: perhaps is gonna take more to get to a decision for it
+miconda: speeddial, cpl-c and permissions might be also easy ...
+miconda: just to give the current state
+miconda: other modules from modules_k/s can be just copied, they are not duplicated, just have some local dependencies
+miconda: if any dev has spare time to work on reducing duplicates, write on sr-dev to sync
+aXl: it'll probably need a dev with experience in both projects, at least with the module to be converted, i don't think there are a lot of them
+osas: there should be a wiki page dedicated to module merging
+osas: and maybe it make sense to just drop one version and keep the other one (for some modules)
+miconda: when I did it, I looked in readmes to be sure the features are not lost
+miconda: most of complexity comes from different db structure
+osas: for some
+osas: for some others, it should be relatively simple
+osas: like nathelper
+jasonpenton: I assume in a merge all we need to preserve is 1. funcionality, 2. API, 3. DBSchema? is that all?
+osas: there are some extra features in s version, but OI don't know how many are relly using those
+miconda: jasonpenton: ideally
+miconda: for db schema I try to make it compatible with both
+miconda: maybe by having some columns used by only one "mode"
+jasonpenton: miconda: implemented how? #ifdefs?
+miconda: no, modparams
+jasonpenton: ok
+osas: for some modules, maybe we need a pool to see much are those used
+miconda: I prefer no compile time switches
+jasonpenton: yeah was gonna say
+miconda: it is like with use_domain parameter
+osas: and based on that, consider dropping on version and keeping the other one
+miconda: domain column is not used if that parameter is not set
+jasonpenton: ok
+miconda: osas: yes, at some point we should get to something like that
+miconda: related to this, I added also the next topic
+miconda: adding kind of unique id in some structures
+miconda: ser uses that and might be easy to integrate
+miconda: we can make it as user@domain from existing records
+miconda: the idea showed up when I looked a bit over gruu specs
+jasonpenton: please explain a little miconda, im lost here
+jasonpenton: you are talking about location db schema?
+miconda: jasonpenton: at this moment we have (username) or (username,domain) to identify a subscriber
+jasonpenton: ahh yes - okay
+miconda: a matter of use_domain, there are conditions and conditions
+jasonpenton: we had issues with that in IMS extensions too
+jasonpenton: ok
+miconda: so it might be good to have a main SIP id the (username,domain) and unique id
+miconda: sip id can change eventually
+miconda: so it is about adding a new column in subscriber and location tables
+miconda: for auth and location services
+miconda: not sure what will be the impact
+jasonpenton: happy with that!
+miconda: wanted to see if people see benefits
+jasonpenton: def!
+miconda: the unique id target is to be used internally for references between records
+jasonpenton: well for IMS extensions, we have to have 'custom data' added to customer profile - and for backwards compat we had to use another DB table
+jasonpenton: keying with username/domain is not cool
+jasonpenton: uniqueid will be much  better
+miconda: in gruu is so called permanent address, which has to be mapped to a subscriber
+miconda: ok ... we have to see the impact anyhow, might not be for next release (or at least not across all modules)
+</code>
+==== IMS ====
+<code>
+miconda: then since you are on stage, the next topic IMS
+miconda: I added it in case someone wants to ask questions and see the status
+miconda: there are two branches, afaik
+jasonpenton: yeah - not much Daniel - we have a working prototype whcih we are testing
+miconda: carstenbock and jasonpenton
+jasonpenton: however, one thing we are puzzled over is how to integrate leveraging existing functoinality
+jasonpenton: mainly in usrloc/registrar
+carstenbock: I actually point everyone to Jason's branch.
+carstenbock: Since i think it is more advanced than my branch.
+miconda: ok
+jasonpenton: as I mentioned earlier 'custom data' for subscribers  - do you think it would be feasible to include in usrloc a 'custom field' to add anything - using some form of serialisation?
+miconda: jasonpenton: usrloc from modules_s has that functionality
+miconda: a reason i was looking to merge
+jasonpenton: ahh - i didnt notice that
+miconda: it uses avps
+jasonpenton: I have the bad misconception that k is better than s
+miconda: in many aspects
+jasonpenton: ok will look into - we really just dont want to duplicate functoinality
+miconda: k version has lot of features not in _s
+miconda: I didn't add in _k/usrloc because I wanted to merge first (and therefore get it)
+jasonpenton: ok - so our roadmap is to finish testing pretty soon and then push our stuff - so maybe ready for by the  ++next release
+miconda: ok
+jasonpenton: other than that no updates
+jasonpenton: also hoping someone could look at dialog2 for us
+miconda: to implement it?
+jasonpenton: we're not experts in TM and dialog - but dialog 2 works for us
+jasonpenton: no Richard did alot of the work already
+miconda: is it on git?
+jasonpenton: yes
+jasonpenton: in our branch
+miconda: i missed it then
+miconda: ok
+miconda: i will try to find time for it
+jasonpenton: okay no rush
+jasonpenton: so topic done
+agranig: one thing regarding usrloc from my side is the sync with db... we've talked on the sr-users list a bit about that, where we should make the write-back a bit more resilient (insert vs update, independent from the state in cache)... I couldn't come up with some generic approach yet
+carstenbock: Great
+miconda: agranig: indeed, it was a topic
+miconda: let's finish this one then
+miconda: solutions?
+miconda: someone proposed a new db mode, just for read only at startup
+miconda: and all registers will be replicated to another instance to write to db
+agranig: well, one could be to check in the update result whether rows where affected... this is just for mysql though, not sure about other modules
+miconda: it might be a contribution soon, let's see
+aXl: for mysql insert ... on duplicate key can be used it is faster than update, then insert (and racefree)
+agranig: the problem we have atm is rather that the usrloc cache thinks it's already in db, and just tries an update (no insert at all)
+aXl: above solves that, just use insert always
+aXl: but only for mysql unfortunately
+agranig: would this work with pgsql and oracle and other drivers we support?
+miconda: aXl: or anyone,  is insert ... on duplicate good in postgres?
+miconda: ok ... we have to check, I guess
+nangel: no, I don't think postgres has insert ... on duplicate... I forget the way to do it though
+ • nangel has mysql + postgresql dbs
+miconda: ok, back to next topic ... if nothing else here
+nangel: http://stackoverflow.com/questions/1109061/insert-on-duplicate-update-postgresql - create a function
+aXl: if we create a new db op like insert_or_update
+aXl: it can be solved within a transaction for every DB out there
+agranig: or some stored procedure, yes
+aXl: that requires DB magic, i'd prefer if de db module of kamailio would provide support for it
+miconda: maybe a dedicated process to detect consitency
+miconda: walk through mem records and check if in db ...
+miconda: anyhow, not easy to decide here
+miconda: let's continue on mailing lists
+</code>
+==== Roadmape to 3.3.0 ====
+<code>
+miconda: road map to next major release 3.3.3
+miconda: 3.3.0
+miconda: so we released in October, we should do it before summer
+miconda: nobody wants (I guess) to do it in holidays from the beach
+miconda: maybe looking to freeze devel after mid of march, latest on end of march
+miconda: test on april
+miconda: release in may?
+miconda: anyone having plans for major additions that require more time?
+miconda: looks like no
+miconda: so I will propose these time lines and see reaction on mailing lists
+miconda: approaching the end of this session then
+miconda: anything missing as feature in the project?
+miconda: what you would like to see added soon?
+miconda: (not saying it will be)
+aXl: i have one
+miconda: good, you have dev access
+jasonpenton: lol
+aXl: support for modifying the outgoing message _after_ DNS resolving
+aXl: like i talked with you about on fosdem
+aXl: there is a need to enable an rtpproxy for ipv6/ipv4 transistion situations
+miconda: just after dns, before printing the output buffer
+carstenbock: There was some hacks on the list recently, like using the local IP as outbound_proxy in some presence-modules...
+aXl: it would also need to be able to update avp's or record-route parameters
+carstenbock: It would be nice, if that could be avoided.
+miconda: I will look for places where we can call an event route on forward, after dns, before building output
+aXl: what would maybe work is onsend_route where this would be possibel
+miconda: onsend_route has the outgoing buffer printed
+aXl: just ned to prohibit rewriting $du
+miconda: too late for route headers
+aXl: then a new event would be needed
+miconda: the tricky part will be with dns failover
+miconda: ipv6, then fallback to ipv4
+aXl: the event should be called for every outgoing message (apart from retransmissions)
+miconda: ... then to noIP
+aXl: that;'s exactly the issue im having
+miconda: ok, understood
+aXl: mixed ipv4 and ipv6 in one dns records
+miconda: for records, tm module and forward.c are places to look at
+miconda: anything else?
+nangel: wishlist - would be handy to be able to do SRV/A/AAAA/NAPTR lookups directly from script
+aXl: somewhere between creating the transaction and adding record-route headers ?
+miconda: yes, Record-Route header is added after dns and selection of local socket to send
+pdunkley: I have a suggestion for a new feature.  Can the rtpproxy module detect when the SDP is indicating TURN/ICE support in the client and only activate when it is needed?  Or possibly add something to SDPOPs so this can be detected in config and rtpproxy not used?
+aXl: but when is the tranasction created? before or after that?
+miconda: nangel: ok
+miconda: before
+miconda: but should work for stateless mode
+miconda: with forward()
+aXl: that would be a good thing i think
+agranig: pdunkley: sounds like this will be much needed in the light of webrtc
+miconda: in tm, the code of t_relay() should be followed and dug in
+miconda: in core, forward() in forward.c
+aXl: ok, thanks
+pdunkley: agranig: I was thinking in the context of RCE/RCS-e too.  For those specifications NAT traversal in the client is mandatory - but some still don't do it.
+miconda: pdunkley: sdpops can be a good place
+pdunkley: So need to be able to cope efficiently with both types of client (good ones and bad ones :-))
+miconda: I think it is about searching for a=ice and similar
+pdunkley: It's been on my wish list to do this for a while, but I haven't had time.
+miconda: ok
+pdunkley: Yes I think is is something like looking for ice on an attribute line.
+pdunkley: Maybe a generic SDPOPs to allow someone to match an "a=" line with a reg-ex would be useful for other things too?
+miconda: search_body() does it
+miconda: from textops
+miconda: safe for sdp body only
+pdunkley: I didn't think of that.
+miconda: if it is a multi-part body, then can be conflicts a matter of content
+miconda: so an sdp_search() would be safer
+miconda: there is also a new transformation on devel
+miconda: line: http://www.kamailio.org/wiki/cookbooks/devel/transformations#line_transformations
+miconda: can be enhanced for matching on a line based
+miconda: btw, IPv6 -- how is it in your side?
+miconda: production already?
+miconda: we should be pretty safe with everything related to IPv6
+miconda: carrierroute and drouting were not checked by me so far
+pdunkley: IPv6 is required for RCE/RCS-e as it is IMS based.  Lots of people still using IPv4 at the moment though.
+miconda: from the list of routing modules
+jasonpenton: that is somethign we still need to test too (IPv6)
+agranig: our tests were pretty much fine with IPv6, but we don't use carrierroute and drouting...
+pdunkley: So haven't done much with IPv6 yet myself.
+jasonpenton: on our roadmap and we will be using cr
+jasonpenton: as well as dispatcher
+miconda: I don't use these modules as well, but from the list of modules I know the may deal with, are still in the check list
+miconda: dispatcher should be ready
+jasonpenton: great
+miconda: ok then
+agranig: at least the core, usrloc and lcr are definitely ready
+</code>
+==== Closing Remarks ====
+<code>
+miconda: last topic -- any relevant resources we are missing in the environment?
+miconda: lot of cool apps might be out and some of us are not aware
+miconda: facebook 'Love' page ;-)?
+qxork: kamailio cake.
+miconda: I know where to place the order
+agranig: native websocket-transport-support proposed by inaki
+agranig: i think he implemented it in his own server, not in kamailio
+miconda: well, to my understanding so far to websockets (some sporadic reads), it will not be something very complex
+miconda: it starts as an http
+miconda: we have that
+miconda: then there is an handshake based on some headers
+miconda: then it is pretty much tcp
+miconda: with packets to be handled based on app id or so ...
+agranig:  what's missing is the WS(S) support in vias... you usually get a client id for a websocket, so you'd need to map a message coming via "normal" sip to the correct socket on the http-side
+miconda: it is like msrp
+miconda: you have to keep the mapping of connection id
+miconda: msrp has no Via headers as well
+miconda: ok ... added to the list
+agranig: as far as i understood inakis proposal, websockets will have vias... it's intended to be another transport beside udp, tcp etc
+agranig: anyways
+miconda: not sure about Inaki's proposal
+miconda: knowing a bit about generic websocket specs
+miconda: so Inaki may have proposed some 'enhancements'
+agranig:        http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01
+miconda: anything else? otherwise looks we can close development in few days ...
+jasonpenton: cool - ciao!
+miconda: ok! then officially ending here!
+</code>