[15:00:08] <henningw> ok.. lets begin. [15:00:39] <henningw> Hello everybody! [15:00:53] <toady> hello henningw [15:01:11] <Marquis42> Hello [15:01:27] <henningw> bogdan, are you there? i don't find your nick. Daniel? [15:01:39] <_Bilbo_> ←- partly participating ;) [15:02:18] <agranig> daniel=miconda, bogdan=? [15:02:27] <henningw> bogdan_vs, normally [15:02:57] <henningw> miconda: is Bogdan available? [15:03:09] <henningw> ah

[15:03:40] <henningw> hello Bogdan! Ok, lets begin with the first point of the agenda.. Release planning [15:04:18] <henningw> The last (1.2.1) release was in may, should we do another 1.2 branch release? [15:05:09] <miconda> might be a good idea [15:06:03] <Marquis42> I think so. Tagged releases are zero-cost in subversion, and a lot of users are nervous about using a direct-from-svn checkout. [15:06:28] <bogdan_vs> Hi Henning [15:06:41] <henningw> hello bogdan [15:07:05] <henningw> ok, no other opionion on this? Daniel, do you suggest a date? [15:07:54] <miconda> are there any outstanding bugs anybody aware of in 1.2.1? [15:08:18] <toady> henningw: trunk is 1.4.x ? [15:08:23] <marcush> path memleak [15:08:36] <henningw> toady: trunk is 1.3 [15:08:45] <toady> ok [15:09:16] <henningw> 30 are on the tracker, but some of them are outdated probably [15:09:20] <Marquis42> I'm not sure (I haven't filed a bug because I'm trying to determine if it is one), but I'm having a problem with pulling contacts from 3xx responses that have maddr parameters. Could be user-error (see message in -Users) [15:10:08] <henningw> there are some segfault with config (modparam, vlan), but there should not so hard to fix [15:10:47] <agranig> regarding path-memleak: the guys at inode are taking marush's patch live tomorrow, so there should be some results at end of the week… [15:10:58] <agranig> sorry, marcush's patch ;) [15:11:16] <miconda> August 2 should be ok? [15:11:49] <miconda> about 2 weeks to fix and test existing and discovered meanwhile [15:12:08] <henningw> if the bugs are not a problem, then its ok for me. I can do this changelog stuff again, and some backporting if necessary [15:12:31] <miconda> ok [15:12:56] <agranig> one thing that should be cleared before another release: there's the dbtext-lcr-problem (in >=1.2)… juha wants to fix it in dbtext, but I think for the 1.2-branch there should be a fix in lcr, and for 1.3, dbtext should be extended [15:13:24] <miconda> let's have that date as reference, but not fixed by now [15:13:49] <vitspec> hi all [15:14:17] <henningw> ok, lets say, the first week of august? [15:14:28] <miconda> some work has been done with dbtext in devel [15:14:56] <henningw> agranig: do you mean the STR/ STRING issue? [15:15:46] <agranig> henningw, yes… if dbtext can return string, it's ok, but in 1.2 it can only handle str… miconda, can it handle str in 1.3? [15:16:08] <agranig> miconda, handle string is what I meant [15:16:09] <miconda> I think that was fixed … I have to check the logs [15:16:14] <vitspec> henning: is it possible to approve small patch for MySQL (db_mysql_fetch_result() instead db_mysql_store_result()? we use it in two installations without problems [15:16:14] <agranig> fine [15:16:42] <henningw> vitspec: sorry for the delay. I wanted to integrate it with some other changes. [15:16:50] <miconda> agranig: hope we talk about the same issue [15:16:56] <miconda> with returning type … [15:17:22] <agranig> miconda, I think so… in 1.2, dbtext only returns str, but lcr relies on string… [15:18:33] <miconda> ok [15:18:48] <miconda> I will check that – it is same as was talking about [15:18:58] <miconda> we can move forward

[15:19:08] <henningw> ok, good. So next point → major release.. [15:20:11] <henningw> here we need a little bit more time.. [15:20:26] <vitspec> henningw: me too I want to rewrite my old MySQL-PreparedStatements patch for current mysql-module state. [15:20:33] <toady> henningw: the first autotoolized release ? :) [15:20:53] <miconda> :) – any volunteer? [15:21:28] <bogdan_vs> henningw: whay is the reason for this? do we really need it? [15:21:54] <henningw> its a contribution from toady [15:22:35] <toady> that will help maintaining makefiles, not add much overhead [15:23:01] <toady> simplify the building process and help towards libification [15:23:27] <bogdan_vs> toady: I had some experience with auto-tool with a smaller project and it was not a positive one [15:23:34] <toady> autotools usually scares people :) [15:23:36] <miconda> henningw: on the tracker? [15:23:51] <agranig> I think the most useful scenario is cross-compiling [15:23:53] <henningw> miconda: not yet released, i did some reviews in the past [15:24:01] <miconda> ok [15:24:06] <toady> bogdan_vs: it is as simple as adding things in configure.ac instead of Make.rules [15:24:11] <miconda> I thought I missed it [15:24:16] <bogdan_vs> toady: it is not about scaring, it is about the effort in maintaining it versus benefits [15:24:41] <henningw> ok. I suggest that we try to find a date, and then adopt our roadmap, feature to this. [15:25:03] <henningw> Otherwise we'll release next year, i think.. [15:25:11] <bogdan_vs> personally I like to have thinks as simple as necessary - if they do they job, it's perfect [15:25:27] <toady> bogdan_vs: To me, this is mainly to ease the separation of openser components in libraries [15:26:08] <toady> bogdan_vs: and regarding this, own written makefiles can be harder [15:27:21] <henningw> bodgan_vs: i'm also not a autotool friend, but its no massive change, only a few files. [15:28:19] <henningw> But lets try to find a date.. Bodgan, what are you're suggestions? This year? Beginning of next year? [15:28:35] <bogdan_vs> henningw: we can take a look on it - what I want to avoid is to loose flexibility (read - to do what you really want to do) due automatic tools [15:28:50] <toady> bogdan_vs: I totaly agree [15:28:53] <henningw> bogdan_vs: this is also my concern [15:29:46] <toady> bogdan_vs: you can even have autotools files on side of regular makefiles [15:29:46] <henningw> for the last major release there was two month testing period? [15:29:59] <bogdan_vs> toady: currently there are a lot of tricks and tunes for different cases - maybe autotools will simplify some or make other impossible [15:30:06] <miconda> henningw: following our release planning we should start preparing major release about October … [15:30:10] <toady> bogdan_vs: I saw that ;) [15:30:23] <toady> bogdan_vs: if you look at http://www.wallinfire.net/files/openser-autotools_1.patch [15:30:48] <henningw> toady: lets discuss the technical details later, ok? [15:30:50] <toady> bogdan_vs: instead of being gmake checks they are bash [15:30:54] <toady> henningw: sure [15:31:51] <henningw> bogdan_vs: release in october? so the testing period starts now? [15:32:22] <miconda> I said, to think about releasing [15:32:54] <miconda> … preparing meaning, to enter in testing phase [15:33:16] <henningw> miconda: sorry, ok. i don't understand you exactly [15:33:34] <miconda> sorry [15:33:59] <bogdan_vs> henningw: it might be too short [15:34:17] <henningw> yes, i think the same.. [15:34:20] <bogdan_vs> I have on my TODO some thinks that I think they should be in 1.3 [15:35:09] <henningw> i have also some stuff there [15:35:30] <miconda> that was the past experiences [15:35:34] <miconda> it can be delayed [15:35:48] <henningw> around christmas not a good time for a release, so november would be possible [15:36:11] <miconda> if we enter november in testing, then release will be after christmas for sure [15:36:33] <henningw> yes. We need more month [15:36:37] <bogdan_vs> henningw: what about a release at the end of November - this means testing starting at the end of September [15:36:49] <bogdan_vs> so we should have 2 more months [15:37:25] <henningw> fine for me, its a compromise [15:37:56] <bogdan_vs> or should we re-evaluate the situation in 1 month? [15:38:15] <henningw> hm, i guess in one month we would delay it further.. [15:39:03] <bogdan_vs> henningw: you want a sooner or later release? just to know: ) [15:39:39] <henningw> no, september is fine for me. Then i can do some db work in this month, this should be ok. [15:40:41] <henningw> does anybody have other suggestions, need more time for features? [15:41:01] <henningw> toady, vitspec? [15:41:33] <toady> it depends of features [15:41:34] <miconda> ok, so we start freezing with october :)

[15:41:49] <toady> ok I have a suggestion actualy [15:42:00] <henningw> toady: speak up [15:42:09] <henningw> miconda: [15:42:11] <toady> I like projects that are time based [15:42:18] <toady> such as 6 months major release [15:42:23] <toady> let me explain it a little bit [15:42:47] <toady> if we do time based release, it means we are prepared to have the software out at a regular time [15:42:54] <toady> and all plannings are around it [15:42:57] <toady> freezing etc.. [15:43:09] <henningw> toady: i know this discussion. But for a six month release is unfortunaly already to late [15:43:26] <toady> ok, but how about starting it after the next major release ? [15:44:00] <bogdan_vs> toady: the bigest problem with this model is that the time is not uniform - in summer you have a lot of vacation, less work [15:44:01] <toady> we should break existing project management, but go towards something such as time base to improve the overall quality [15:44:33] <toady> bogdan_vs: same for each project ;) but you wait a few months for further integration [15:44:43] <toady> and it helps people to organize themselves [15:44:51] <roeles> hm [15:45:01] <henningw> hm, i'm not complete confident, that time based releases increase quality. Sometimes you simply need to do more work, have to much bugs.. [15:45:05] <toady> bogdan_vs: we are actually in the same situation now, if you say we can start freezing in late september [15:45:41] <toady> henningw: anyway that was just an idea that is quite positive on projects that work like that [15:46:31] <henningw> in my opionion this project is quite good regarding the release policy. Two major releases a year its not bad. [15:46:42] <toady> henningw: ok then [15:47:08] <henningw> toady: for 1.4 you could suggest it in time, perhaps its fits then, we will see [15:47:17] <toady> ok

[15:47:58] <henningw> good. then we could move to the roadmap, and cut all this stuff away that we don't manage for this release [15:48:28] <henningw> bodgan_vs, or miconda, you already did some changes to the document? [15:49:24] <miconda> I updated a bit, with the status to some items [15:49:38] <henningw> is klaus darilion present? [15:49:59] <henningw> miconda: ah, ok. [15:51:58] <henningw> whats with the xmpp integration? Who suggested this? [15:53:14] <henningw> ok, no one.. so guess this is not finished [15:54:34] <miconda> it is about removing the address mapping between sip and xmpp which is now in use, Juha asked on mailing lists [15:54:37] <miconda> not in place [15:55:24] <henningw> ok, thanks. whats with the dialog stuff? [15:56:06] <henningw> vitspec and bogdan, you suggested this [15:56:23] <miconda> just to have the link here: http://www.openser.org/dokuwiki/doku.php/roadmap:1.3.x [15:58:33] <henningw> gnuTLS (Julien Blanche) and unit Test infrastructure (Elias Baixas) will probably not implemented for 1.3 [15:58:35] <vitspec> henningw: sorry? [15:59:04] <henningw> vitspec: i noted your name for this item, sorry if this was wrong [15:59:17] <miconda> I am waiting a response email from Julien, I will update as soon as I have it [15:59:29] <henningw> ok, nice to hear! [16:01:33] <miconda> we can move to next, I think … [16:01:58] <henningw> ok. osas is not here, diameter support [16:03:38] <henningw> daniel: do you have any informations from klaus about the security/ stability improvements (XVIII) [16:03:44] <henningw> ? [16:04:51] <agranig> bogdan_vs, you mentioned improved dialog-support (e.g. call termination)… is this planned for 1.3? [16:05:44] <miconda> no update about klaus' stuff [16:06:02] <miconda> at least about the part with non-blocking [16:06:09] <henningw> hm.. more scalable TCP would be nice [16:06:32] <bogdan_vs> agranig: we made a lot of work in that direction [16:06:48] <bogdan_vs> agranig: it could be - not sure - depending of the available resources [16:08:59] <henningw> ok, next poin: SIP S URL support. [16:11:15] <henningw> no informations about this? [16:12:04] <miconda> none from my side :) [16:12:35] <miconda> how high priority should have? [16:12:37] <clona> sipS sucks :) [16:13:09] <miconda> not sure how much is hardcoded in the code … [16:13:20] <henningw> that is the question [16:13:57] <miconda> I think there are some modules that creates a new uri and use sip [16:14:38] <miconda> there are not so many, otherwise, I do not think the proto is changed [16:15:52] <miconda> if we decide to be high priority thing, the review of source code should be possible before release [16:17:00] <henningw> SIPS is not in the short term planning for us, i think. Anybody need SIPS for 1.3? [16:17:40] <henningw> but the review of the modules and providing of a patch should be a perfect “junior job” [16:18:48] <henningw> ok. it seems that SIPS really sucks [16:18:51] <agranig> if you want to scare them away, it'd be fine ;) [16:18:56] <henningw> hehe [16:19:34] <henningw> for gnuTLS we're waiting for information from Julien [16:19:54] <henningw> bogdan_vs: do you want this assembler stuff for 1.3? [16:19:56] <christian[1]> I don't know of anyone using SIPS in production … maybe some research projects [16:20:25] <bogdan_vs> henningw: I think the time is not enough and have other priorities [16:20:29] <henningw> christian[1]: yes, performance.. [16:20:59] <henningw> ok. toady: regarding the autoconf stuff, core is ok, and modules still missing? [16:21:55] <henningw> for openSER lib we're needing first the autoconf infrastructure [16:22:53] <toady> yes [16:23:36] <toady> for technical details, current is a copycat from what was available in Makefiles [16:23:52] <essobi> Morning peoples. [16:24:04] <toady> this is not perfectly autotoolized, but thus we preserve the current Makefile state [16:24:15] <toady> no changed appear in compiling [16:25:09] <toady> I think it would be reasonable to have autotools for the next major, so that the next-next major can start being libified [16:25:17] <toady> and things go smooth [16:26:19] <henningw> ok, good. sounds resonable. point X, the log system? Bodan_vs, i guess the modules must ported to the new infrastructure? [16:27:34] <toady> I would just like to mention that from now on, any changes in Makefiles concerning compile flags should be reflected in configure.ac as long as autotools has not replace the current building process [16:29:40] <vitspec> some words about release planning: RP may be not only time based but time and feature based. i.e. we can take two ot three main features and says that it will be aim for next major release. but such release must be created not later then next six mounths. such features must not fix bugs but extends openser functionality or change some basics [16:30:47] <vitspec> so new log system or re-read config at runtine may be features for major relase while new functions for some modules are for minor releases [16:30:52] <henningw> vitspec: i think we're actually using quite similar system at the moment [16:31:15] <miconda> no new functionality is added to minor release [16:31:20] <miconda> just bugs fixes [16:31:44] <henningw> miconda: do you now the status from the log enchancement? [16:32:53] <miconda> so far, we have several new modules, related to presence (xmpp, bla, mwi), ldap, mi_datagram, perlvdb [16:33:07] <miconda> and cfgutils [16:33:31] <miconda> I think the core was not altered too much [16:34:14] <henningw> regarding point XII, database stuff: i try to provide a module for application level database clustering for 1.3, for more is probably not enough time. [16:34:31] <miconda> there was committed a new system for logging messages, still to do stuff, I guess [16:34:56] <miconda> as for db, if the time allows. I will like to add at least failover support [16:35:19] <miconda> and maybe some ability to divert read/write operations to different servers … [16:35:26] <miconda> to increase the scalability [16:37:14] <henningw> nice.. OpenSER live config reload (XIII) will be probably not be finished for 1.3, i guess? [16:37:49] <miconda> guess not [16:38:09] <miconda> it is quite delicate item [16:38:24] <miconda> we discussed on paris, maybe partial reloading would be possible [16:38:53] <henningw> we have at least now a runtime changeable logging setting [16:39:56] <toady> miconda: what is the technical limitation ? [16:40:22] <miconda> lot of global and static varibles, with reference from different strucutured [16:41:03] <miconda> … structures … [16:42:25] <toady> miconda: would dbus help ? [16:43:49] <miconda> don't know, never looked at … [16:44:00] <henningw> i think for the other points we need some input of the implementors that are not present at the moment. Points still from 1.2 can be assigned to the roadmap for 1.4 [16:44:05] <henningw> I'll update the roadmap page later with the results of this discussion. [16:44:13] <miconda> ok [16:45:04] <henningw> any other points from the roadmap that needs to discussed? [16:46:53] <henningw> ok, it seems that everybody is a little bit exausted from this document.. Then we could move to the next point..

[16:48:13] <henningw> i have a question regarding the database schema stuff: should we stay with this to a plain openser tool, or its ok to extend this to generate more SQL, not only needed for openser? [16:48:47] <miconda> like? [16:49:14] <miconda> anything particular in mind? [16:49:17] <henningw> e.g. TIMESTAMP for mysql, CONSTRAINTS and such stuff [16:49:55] <henningw> i would like to stay with the stuff for needed for openser, as i'd like to move to another task.. [16:50:08] <henningw> on my TODO list .-) [16:50:11] <miconda> I am for the same decision [16:50:14] <miconda> :) ok [16:50:40] <henningw> good. [16:51:19] <henningw> Regarding you database stuff: how do you plan to implement the failover support? with timers? [16:52:31] <miconda> timeouts on connect and failover to next available, in the list [16:52:44] <miconda> the internal desing for db drivers have to be change [16:53:09] <miconda> maybe we can have a private discussion to put things together, if you are interested in it [16:53:26] <henningw> ok, good suggestion. [16:53:40] <miconda> I cannot offer too many details right now – I have to analyze first [16:54:19] <henningw> ok, no problem. [16:56:33] <vitspec> sorry, is such comle stuff really needed in DB clients like openser ? If customer needs failover it can use Db cluster, proxy, CARP or othr stuffs [16:57:38] <miconda> yes, can be done that way as well, another task is to distribute the traffic [16:57:59] <miconda> which can be big if using only one connection [16:58:59] <henningw> hm.. distribution of read/ writes to different dbs is really usefull [16:59:12] <henningw> for load balancing purposes [16:59:19] <miconda> yes [16:59:28] <henningw> for failover you could use clustering, i agree [16:59:54] <miconda> failove will come as additional stuff, should be easy if we go for dispatching the traffic [17:00:24] <vitspec> something like MySQL proxy may be usefull [17:00:31] <miconda> I agree with cluster as well, but not all are very stable, and sometime are hard to maintain [17:01:16] <miconda> is there anything similar for postgres and unixodbc? [17:01:30] <henningw> yes, thats an issue. But we must take care that the db interface stays flexible, e.g. for dbtext we don't need all this stuff. [17:02:10] <henningw> for postgresql yes, and for e.g. mssql i guess too [17:02:13] <miconda> might be a case with dbs via nfs … [17:02:30] <henningw> NFS sucks [17:02:51] <vitspec> i don't know but it may be more right to write such program for postgres (if idea behind such proxy is really correct) [17:02:51] <miconda> however, this needs to be discussed anyhow, maybe we discover that existing tools are enough [17:03:47] <miconda> it would be really hard for us [17:04:07] <miconda> the db api in openser is a limited set of sql, and easy to make a dispatcher [17:04:45] <miconda> actually the dispatcher will be before converting to sql, will be at the db api abstraction level [17:05:24] <henningw> we implemented this the same way. i'll send you some examples per mail. [17:05:39] <miconda> ok [17:05:46] <essobi> How's everyone doing this morning? [17:05:54] <henningw> essobi: fine, thank you! [17:06:14] <essobi> And yes.. NFS does suck. Heh. [17:06:23] <essobi> Depending on your application for it.. [17:06:28] <essobi> and the server.. [17:06:42] <henningw> essobi: yes

[17:07:15] <henningw> marcush: do you want to discuss about your approach to the MTU problem? [17:07:24] <essobi> Hmm.. I think I'm going to move my attempts to hack in a ENUM lookup to AVP module over to 1.2.. No sense in spinning my wheels on 1.1.. [17:08:37] <essobi> Hmm.. Is there any support in 1.2 for pointing your enum resolver at a specific IP as opposed to using resolv.conf's defs? [17:10:00] <henningw> hm.. the meeting last already two hours.. So does have anybody a topic left that he wants to discuss here? [17:10:24] <dominei> are we a problem? :( [17:10:29] <essobi> Oh.. This is a meeting? Sorry to interrupt, gents. [17:10:36] <marcush> henningw: sure [17:10:46] <henningw> essobi: no problem [17:11:32] <henningw> marcush: what are you waiting for? [17:11:38] <marcush> http://sourceforge.net/tracker/index.php?func=detail&aid=1755402&group_id=139143&atid=743022 [17:11:46] <marcush> anybody already seen this? [17:12:36] <marcush> actually i have the problem, that invites, which ran through a lot of hops were bigger than the mtu before reaching the uac [17:12:50] <henningw> how many hops? [17:13:00] <marcush> something like 4 [17:13:21] <henningw> hm. thats not really that much. [17:13:25] <marcush> recordroutes and vias blow up the packet [17:13:47] <marcush> and if there's a large sdp-header, you can get above those 1500 byte [17:14:22] <henningw> and you compress the VIAs to get around this limit [17:14:34] <marcush> thats the idea [17:14:54] <marcush> i am afraid of touching the record-routes too [17:15:08] <marcush> i guess it's possible, but a lot more complicated [17:16:13] <marcush> i can paste an example, if you have a minute [17:16:23] <essobi> Hmm. Talking out of place.. But isn't there also a short-hand/compressed SIP? [17:16:33] <bogdan_vs> marcush: I had same topic with …don't remember who :(…about having a function to compact the message (using short header names, compact the hdr with same name, etc) [17:16:55] <NirS> anyone here with FreeRadius + rlm_perl experience ? [17:17:02] <bogdan_vs> the problems were, of course, the lumps, and the idea was put on hold until a better lump approach [17:17:15] <henningw> NirS: we're in a meeting, please ask again later! Thank you [17:17:29] <marcush> bogdan_vs: that's way i implemented it as some kind of 'filter' in udp_server [17:17:38] <NirS> oh, shit, I barged on the developer's meeting - sorry [17:19:23] <henningw> essobi: compressed SIP, i think i have read about this.. [17:20:44] <tele> essobi: sigcomp is used for compress signalling [17:21:06] <marcush> tele: i read something about that too [17:21:23] <marcush> but i dont known anything about compatibility [17:21:24] <essobi> Yea, I read about it.. Two of my primary endpoints don't support it, so I never explored it, but I did read the spec.. [17:22:01] <essobi> Essentially I believe it boils down to, the headers are represented by 1 character followed by a = for a delimeter, and the rest is the same.. [17:22:06] <henningw> there is a RFC for this, SigComp, 3485 [17:23:14] <essobi> Sorry to interject.. I've got quite a bit of background in SIP, but not OpenSER. [17:23:31] <essobi> Please, continue your discussions. [17:26:00] <marcush> http://nopaste.info/a8ea9342ee.html [17:26:16] <marcush> that's what's done by the patch [17:27:58] <marcush> so 3 of the 4 vias are compressed and appended to the first via [17:28:59] <marcush> which saves 82 bytes [17:32:25] <henningw> hm.. and you have no other means to shrink the package? [17:32:56] <henningw> s/package/packet [17:33:33] <marcush> there are some, sure [17:33:38] <marcush> like short hf-names [17:33:52] <marcush> maybe stripping the user-agent [17:34:04] <marcush> reducing the number of codecs [17:35:26] <marcush> i guess all of them have draw-backs [17:37:04] <henningw> yes, probably. But embedding binary data in a via hf is also not exactly RFC conform, i guess.. [17:37:16] <marcush> it's not binary [17:37:29] <marcush> it's nearly base64 [17:37:35] <henningw> ok, sorry [17:38:11] <marcush> and the uac must keep the branch-parameter anyway [17:38:47] <marcush> i am not sure, if there are limitations in line-length [17:39:36] <marcush> or if some uac would need the compressed lines for something [17:40:05] <vitspec> using compact form is not bad idea. and compress (temporarily) unnecessary headers too. may be it must be included into core as config param? [17:41:28] <marcush> there is a compress_via core-config-param [17:41:30] <marcush> [17:42:50] <Pazzo> http://openser.org/dokuwiki/doku.php?do=search&id=compress_via&fulltext=Search ?? [17:42:58] <Pazzo> “there is” or “there will be”? [17:43:08] <marcush> Pazzo: it's in the patch on the tracker [17:43:27] <Pazzo> (sorry for jumping in, I've been quite busy right now) [17:43:43] <Pazzo> marcush: I would really like such a feature [17:43:47] <henningw> compact form is ok for me, but i personally don't think that compression is the right answer to the problem [17:45:54] <Pazzo> We are a small ISP, offering also VoIP to our customers. Calls to PSTN are “routed” to a large tcom player, making intensive use of uac_auth(). SIP packets are not seldom getting bigger than 1500 [17:46:07] <marcush> henningw: why? [17:47:38] <marcush> sure it's additional complexity and it's obfuscating the packets [17:48:34] <marcush> but if it's not breaking anything, it should be ok, shouldnt it? [17:50:25] <Pazzo> marcush: I would prefer a per-subscriber, avp-configurable or in some other way dynamic solution - giving me the possibility to enable / disable “compression” for certain users, uacs… [17:51:58] <henningw> its more a matter of taste, i really like clear text protocols . And this complexity issues are also on my mind. But if daniel or bodgan says, its ok.. I would like see a RFC solution, e.g. sigcomp. But this is not supported for msg generation in openser at the moment. [17:52:42] <marcush> but that would break compatibility [17:53:07] <Pazzo> btw: Is there somewhere a livelog of this irc meeting to be found? I joined at 16:38 GMT :( [17:54:03] <henningw> Pazzo: i post the minutes later on the wiki, no live log, unfortunally [17:54:22] <Pazzo> np, thnx! [17:55:28] <marcush> henningw: i agree, that this is not a perfectly clean concept [17:55:46] <miconda> rather than sigcomp I would prefer any other solution, that is a nightmare [17:56:05] <miconda> it is with state machines, algorithm transfer … etc [17:56:37] <Pazzo> marcush: in a perfect world, >1500 byte SIP UDP packets should be fragmented and not cause any problems; is this correct? [17:56:47] <henningw> miconda: i have not looked more closely to it. [17:56:49] <vitspec> hennengw: i think that problem in SIP. too verbose [17:57:07] <marcush> Pazzo: that would be great [17:57:33] <marcush> Pazzo: but it seems that some nat-gateways are dropping fragmented packets [17:57:39] <Pazzo> yup [17:57:44] <miconda> well, I think devices makes it too verbose, otherwise you can have quite small sip packages [17:58:24] <Pazzo> marcush: Linksys for example *grrr* we have a lot of problems with customers using them [17:59:30] <Pazzo> (and unfortunately many of them bought them from us some year ago - so we can't even say: “hey, you've got a #*%#& router” :o) [18:00:01] <miconda> :) [18:00:26] <osas> Do you experience this issue only for request coming from the server to the client behind NAT? [18:00:43] <osas> if yes, try to remove some headers from the request [18:00:46] <Pazzo> osas: yes [18:01:10] <osas> I experienced this issue with some softswitches [18:01:21] <osas> it all depends how the firewall is configured [18:01:37] <osas> I managed to circumvent the issue by removing some headers [18:02:08] <marcush> osas: i guess the worst-case is a sip2sip call [18:02:18] <Pazzo> osas: for example? most part of the header is occupied by via and rr lines [18:02:37] <marcush> where you are not generating the invite yourself [18:02:42] <osas> yes … and it all depends on how many proxies you have in between [18:02:55] <osas> but sometimes dropping a few headers will solve the issue [18:03:52] <Pazzo> we told some customers with such problems (most of them have no problem at all) to disable some codec in their client's config [18:04:42] <Pazzo> but there are not so many other things remaining in such a sip packet [18:05:27] <Pazzo> 4 “Via” lines, 3 “Record-Route”'s… [18:05:40] <osas> try to drop the useragent header, priority header, organization header [18:05:54] <osas> take a look at the rfc for all the headers [18:06:04] <osas> and drop whatever is not mandatory [18:06:41] <Pazzo> Call-ID, Supported, CSeq, Max-Forwards, Contace, Expires, Content-Type and Content-Length have to remain there [18:06:56] <Pazzo> I could remove Remote-Party-ID [18:07:29] <osas> if you have the proper from, and the ATA is able to deal with it, yes, you can do it [18:07:47] <osas> again, it is on a case by case [18:08:40] <Pazzo> yeah, I found one: “Server: Cisco…” :o) [18:08:46] <osas> heh [18:09:11] <osas> so … I missed a few lines from my irc logs … :( Is the the meeting? It started? [18:09:28] <henningw> Ok, i'm now away. thank you for all your input! I'll provide the edited meeting minutes and update the wiki pages tomorow morning. See you! [18:09:39] <osas> ok [18:09:41] <Pazzo> bye henningw! [18:09:44] <marcush> bye henningw

[18:10:02] <Pazzo> btw: will someone of you be at VON Italy? [18:10:15] <osas> bogdan_vs: have you had a chance to look at the in-dialog requests bug? [18:10:25] <osas> and the patch that I submitted? [18:13:02] <bogdan_vs> osas: not yet, but I will try in the next days [18:13:07] <osas> k [18:14:24] <agranig> just a question, now that all are here ;o) [18:15:58] <agranig> anyone ever tried wengophone? seems like it sends a route-header with every request… it's no problem if you set an alias for every domain…. but in multi-domain-setups you usually don't want that… so how do you tell loose_route that it's a local request? [18:16:33] <marcush> agranig: i think nokia's are doing this too [18:17:18] <agranig> an additional loose_route_db() call would make sense, where the domain-table is queried instead of looking at aliases [18:17:29] <agranig> like is_domain_local() does… [18:20:36] <agranig> currently I use m4 to maintain a list of aliases, but I want to get rid of the server-restarts each time I add another domain [18:36:01] <miconda> you can give the $dd as parameter to is_domain_local() after loose_route(), if dst uri is set [18:42:18] <agranig> miconda, the problem is that loose_route doesn't know that it's a local request if i don't set every domain as alias [18:43:38] <agranig> e.g. my domain is mydomain.org, then the phone sends a register or invite with Route: <sip:mydomain.org;lr> and then the request loops in my proxy since it's relayed in my loose-route-section [18:44:59] <miconda> understood that, but after a loose_route() call you get the duri set, so you can check and stop processing via your loose route section [18:45:16] <miconda> just reset the duri and continue as usual [18:45:44] <miconda> this is the workarount that should work by now [18:46:06] <miconda> real solution is to add domains list to myself list [18:46:24] <miconda> there were some discussions on the mailing list, if i am not wrong [18:46:58] <agranig> miconda, ah, ok, understand… thanks alot… [18:47:53] <miconda> welome [18:50:12] <agranig> miconda, so it's something like “if($du != null && is_domain_local($dd)) { $du = null; } else { /* do loose-routing stuff */ } [19:04:37] <agranig> miconda, works like charm… [19:05:02] <miconda> great