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

Next revision
Previous revision
devel:irc-meetings:2012a [2012/01/19 12:50]
85.178.76.61 created
devel:irc-meetings:2012a [2012/03/04 18:22] (current)
85.178.79.238 [Participants]
Line 1: Line 1:
-====== IRC Devel Meeting - 2012-XX-XX ======+====== IRC Devel Meeting - 2012-01-31 ======
  
-Proposed Dates+Date
-  * **15:00 UTC, January 26, 2012** +  * **15:00 UTC, Tuesday, January 31, 2012**
-  * **15:00 UTC, January 31, 2012**+
  
-Vote for date: +Utilities:
-  * http://www.doodle.com/qzteweb62sqax5r6 +
- +
-Utility:+
   * [[http://www.timeanddate.com/worldclock/converter.html|Time Converter]]   * [[http://www.timeanddate.com/worldclock/converter.html|Time Converter]]
 +  * IRC webchat: http://webchat.freenode.net/
 +  * IRC client apps: http://en.wikipedia.org/wiki/Internet_Relay_Chat#Clients
  
 Place: Place:
- * **#sip-router** IRC channel on **irc.freenode.net** server+  * **#sip-router** IRC channel on **irc.freenode.net** server
  
 ===== Agenda ===== ===== Agenda =====
  
 Kamailio related: Kamailio related:
-  * (dcm) kamailio 3.3.0 - roadmap to next major release+
   * (dcm) outstanding issues at this time, if any   * (dcm) outstanding issues at this time, if any
   * (dcm) packaging - ways to automate the process better   * (dcm) packaging - ways to automate the process better
   * (dcm) documentation - suggestions to improve it and attract more contributions in this field   * (dcm) documentation - suggestions to improve it and attract more contributions in this field
 +  * (dcm) 'librarization' of presence modules - is there duplicated code that fit in an internal lib?
 +  * (dcm) merging duplicated K|S modules
 +  * (dcm) unique ids for user profiles
 +  * (JP & RG) IMS branch and related modules
 +  * (dcm) kamailio 3.3.0 - roadmap to next major release
   * (dcm) ideas for new features   * (dcm) ideas for new features
   * (dcm) administration - web site, mailing lists, etc ... do we miss some good resource out there that should be added in the eco-system?   * (dcm) administration - web site, mailing lists, etc ... do we miss some good resource out there that should be added in the eco-system?
 +
  
  
 ===== Participants ===== ===== Participants =====
  
-Following developers and community members announced intention to participate (add yourself, alphabetic order):+Following developers and community members announced intention to participate (add yourself, alphabetic order, especially if you add items in the agenda):
   * Daniel-Constantin Mierla (dcm)   * Daniel-Constantin Mierla (dcm)
   * Elena-Ramona Modroiu (erm)   * Elena-Ramona Modroiu (erm)
 +  * Jason Penton
 +  * Richard Good
 +
 +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.1326973845.txt.gz · Last modified: 2012/01/19 12:50 by 85.178.76.61