User Tools

Site Tools


devel:irc-meetings:2012a

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
devel:irc-meetings:2012a [2012/01/31 14:25]
85.178.65.250 [Agenda]
devel:irc-meetings:2012a [2012/03/04 18:22] (current)
85.178.79.238 [Participants]
Line 38: Line 38:
  
 Note that participation is open to anyone, just join the IRC channel if you want to participate. 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>
devel/irc-meetings/2012a.txt · Last modified: 2012/03/04 18:22 by 85.178.79.238