|
Community |
Community -> PublicMeetings -> 13th of April 2011Topics & Conclusions1) What are the biggest problems/issues right now in real-life operations with OpenSIPS 1.6.x It seams most of the complains / requests are DIALOG support related, like a better handling of the ghost calls (how to detect them asap), sharing dialog information between several instances of OpenSIPS (for HA purposes or scaling a Load-Balancer). 2) Nathelper and nat_traversal modules integration (after splitting the rtpproxy module) On reorganizing the NAT related module, after moving out the RTPPROXY module from NATHELPER module, next step will be to merge NAT_TRAVERSAL and NATHELPER into a new module (while keeping the old module for a while). This approach will give more flexibility (creating a new module from scratch) rather than merging NATHELPER into NAT_TRAVERSAL (as initially planned). A second idea was to be rework the module to use the SDP parser from core, instead of using their own internal SDP pseudo-parsers. 3) should we drop the "report_ack" ACC parameter? - to get rid of inefficient ACK matching in TM There was an agreement that this feature is an "ugly" hack that it is not used (may sporadically). This feature also breaks the logic on TM (dialog matching in TM :P) and slows down TM on ACK matching - so the penalties do not pay off. 4) moving on with the SIP-wise URI matching ? There is an increasing need for the SIP-wise URI matching in different modules - usrloc, nat_traversal, dialog. It is not only about being 100% RFC compliant, but more on fixing some real-life scenarios. For example, this lack of SIP-wise URI matching breaks the validating and fixing of dialogs. IRC Logs17:01 <@bogdan_vs> Hello and welcome all ! 17:01 <@bogdan_vs> to the monthly OpenSIPS meeting 17:01 <@bogdan_vs> the agenda for today is http://www.opensips.org/Resources/IRCmeeting20110413 17:03 <@bogdan_vs> So starting from the beginning, top down :) 17:03 -!- vlad_paiu [~vlad@109.99.2.142] has joined #opensips 17:03 <@bogdan_vs> 1) what are the biggest problems/issues right now in real-life operations with OpenSIPS 1.6.x 17:04 <@bogdan_vs> waiting for input from you guys 17:06 <@bogdan_vs> nothing ? 17:06 < osas> It seems that most of the issues are listed on the mailing list 17:06 < osas> more activity there ... 17:06 <@bogdan_vs> I mean none of you are operating and facing problems with OpenSIPS ? 17:06 <@bogdan_vs> I was more looking for generic "problems", not bug reporting :) 17:06 -!- medve [~medve@2E6B2469.catv.pool.telekom.hu] has quit [Quit: T�ozom] 17:07 < hmmhesays> other than my dialog problem, I don't use it for much 17:07 <@bogdan_vs> like - I hate that my opensips is slow because it has to wait for the ACC queries 17:08 <@bogdan_vs> or because the script is too complicated...to automatic parts in script, too much things to be done by hand... 17:08 -!- alerios [~alerios@190.249.193.202] has joined #opensips 17:08 <@bogdan_vs> or other things like that .... 17:08 < osas> and it doesn't do 100% accurate accounting even is I don't have a BYE :) 17:08 < hmmhesays> some user editable documentation might be nice 17:08 < andrew_p> are there any problems? :) i'm running a couple of systems here, wholesale/routing, sort of ip pbx replacement + forwarding, used presence + xcap a while ago, even dialog - it does nicely what it's designed for 17:09 < hmmhesays> andrew_p, I'm having some ghost calls, I haven't tried dlg_match_mode 1 yet though 17:09 <@bogdan_vs> hmmhesays: all docs on web site are user editable - you need a wiki account 17:09 < andrew_p> yep, supporting complex forwarding and voice setups (e.g. nested forwarding lists) can get daunting at times but it's not exactly what it has been designed for :) 17:10 < hmmhesays> bogdan_vs, I did not know that 17:10 < andrew_p> hmmhesays: happened to me too when i was having some sinaling problems.. sorry can't add much to what's been already said 17:10 <@bogdan_vs> osas: you mean the new dialog based accouting ? 17:11 < hmmhesays> andrew_p, when I take opensips out of the patch and just got freeswitch->gateway everything matches up 17:11 < hmmhesays> no ghosts 17:11 < osas> bogdan_vs: I was just trying to give some examples ... 17:11 <@bogdan_vs> ahhh :) 17:11 < osas> maybe we should attack the agenda 17:11 < osas> :) 17:12 <@bogdan_vs> well, this was the first point on the agenda - if users have some issue to report on opensips usage..... 17:13 < osas> Most of the issues are reported on mailing list 17:13 < osas> and not of the users are on irc ... 17:13 < osas> s/of/all/ 17:13 <@bogdan_vs> ok, the let's move with the next topic 17:14 <@bogdan_vs> hmmhesays: you can take your problem to the mailing list 17:14 < hmmhesays> bogdan_vs, okay 17:14 <@bogdan_vs> next topic: 17:14 <@bogdan_vs> nathelper and nat_traversal modules integration (after splitting the rtpproxy module) 17:14 < andrew_p> re 1st topic: just an idea, i can imagine some framework for keeping transaction/modules state in db would be useful. that way opensips can be load balanced so any given opensips box can serve a request at any moment of time 17:15 < andrew_p> or is b2b/dialog-everything already stored in the db? 17:15 <@bogdan_vs> andrew_p: that is actually a good point... 17:16 <@bogdan_vs> buy is it not about the transaction state, rather about the dialog state 17:16 -!- razvancrainea [~razvan@109.99.2.142] has joined #opensips 17:16 < andrew_p> yep 17:16 < anca_vamanu> andrew_p: for b2b the storage in db is not real time, but on a timer 17:16 <@bogdan_vs> I know many people trying to do a distributed load-balancer 17:16 <@bogdan_vs> 2 load-balancers balancing over the same set of destination 17:17 <@bogdan_vs> so that means to share load/dialog state between 2 opensips 17:17 <@bogdan_vs> that will be interesting, to achieve horizontal scalability 17:18 < hmmhesays> I think your method of dialog storage would be more tricky than anything there 17:19 < andrew_p> bogdan_vs: ok.. thank you for your comments. that needs some background thinking 17:19 <@bogdan_vs> dialogs are stored in DB, but only stored - they are not read from DB at runtime, but only at startup 17:20 <@bogdan_vs> ok - let;s keep this idea and move it on mailing list to a more detailed description 17:20 <@bogdan_vs> so moving with the item 2 17:21 <@bogdan_vs> 2) nathelper and nat_traversal modules integration (after splitting the rtpproxy module) 17:21 < osas> that will be a tricky one ... 17:22 <@bogdan_vs> there is work to split the current nathelper module into rtpproxy (only for communication to RTPproxy), the rest has to be integrated into nat_traversal module 17:22 < osas> both modules ofer some similar base functionality, but the underlaying implementation is quite different 17:22 <@bogdan_vs> at least that's the plan 17:22 <@bogdan_vs> osas: I'm a bit afraid of the SIP pinging part 17:22 < osas> the split was already done in trunk 17:22 <@bogdan_vs> indeed the implementations are a bit different 17:22 < osas> yep, that's what I'm talking about 17:23 < osas> I tested the nat_traversal module the other day in order to get myself familiar with it's underlaying implementation 17:23 < osas> comming from nathelper, it was quite different 17:24 < osas> my suggestion for this merge would be to create a new module 17:24 < osas> and combine everything there 17:24 <@bogdan_vs> to be honest I haven;t looked yet inside the nat_traversal module 17:24 < osas> and a configurable way of dealing with NAT pings 17:25 < osas> the detection on NATed subscribers is quite similar (no issues here) 17:25 <@bogdan_vs> I know nat_traversal has a smarter way of keeping the pinholes to ping 17:25 < osas> as for pings, it's quite different 17:25 < osas> nathelper is using usrloc 17:25 <@bogdan_vs> natraversal is registration based, while nat_traversal is dialog, registration, subscription based 17:25 <@bogdan_vs> it is smarter ;) 17:25 < osas> nat_traversal is creating it's own list of pings 17:25 <@bogdan_vs> right 17:25 < osas> each one has advantages and disadvantages 17:26 <@bogdan_vs> this parallel list is more efficient in handling - less CPU, more mem 17:26 < osas> for instance, with nat_traversal is not that easy to do a failover (as far as I looked into it) 17:26 <@bogdan_vs> nathelper is fetching the entire list from usrloc, each time 17:26 <@bogdan_vs> failover for ? 17:26 < dr__> what does rtpproxy module do except talking to rtpproxy ? how is it different than mediaproxy module ? 17:26 < osas> the list of NATed pings are saved on a file on sutdown 17:27 < osas> on a crash, it might be lost 17:27 < osas> so ... I think it would be good to keep both ways 17:27 <@bogdan_vs> osas: it should have a DB backend.... 17:27 < osas> and make it configurable 17:27 <@bogdan_vs> dr__: nothing - just controlls the rtpproxy 17:28 <@bogdan_vs> osas: could be 17:28 < osas> but it is not right now (re: DB backend) 17:28 <@bogdan_vs> osas: so action point is to evaluate the pinging approach on both modules and to see if they can be merged 17:28 < osas> so merging nathelper into nat_traversal will create a lot of confusion 17:28 <@bogdan_vs> keeping the advantages of both 17:28 < osas> I would be in favor of creating a new module 17:29 < osas> with proper documentation 17:29 <@bogdan_vs> osas: so you suggest merging them both into a new module ? 17:29 < osas> yes, while keeping the existing modules at least for one release 17:29 <@bogdan_vs> and keeping in parallel the old modules ? 17:29 <@bogdan_vs> right 17:29 <@bogdan_vs> seams a nice idea.... 17:29 < osas> otherwise, the mailing list will be flooded witn questions about this issues :) 17:30 < osas> we should start a topic on the dev list and get imput from Dan too 17:30 <@bogdan_vs> such a pity that the guys from AG do not visit IRC :) 17:30 < osas> I don't think he's here 17:30 <@bogdan_vs> right :) 17:30 <@bogdan_vs> you read my mind 17:30 < osas> another thing would be to integrate the sdp parser into this new module 17:31 <@bogdan_vs> ok, so let's move this on dev mailing list 17:31 <@bogdan_vs> why? the parsing code is usually in core 17:31 <@bogdan_vs> why in this module? 17:31 <@bogdan_vs> the textops module is also using the SDP parser for the codec ops 17:32 < osas> yes, but once the sdp is parsed, the structure is availbale 17:32 < osas> and there's no need to reparse the whole buffer 17:33 < osas> srry, I meant using the sdp parser API 17:33 < osas> not moving the parser itself into the module 17:33 <@bogdan_vs> ahh.... 17:33 <@bogdan_vs> AFAIK the nathelper is using it 17:34 < osas> right now, rtpproxy, nathelper and nat_traversal are using their own parsing methods 17:34 < osas> no, not really 17:34 < osas> it is using only a little part of it 17:34 <@bogdan_vs> hmm.....could be...... 17:34 < osas> the main parsing is done by local methods 17:35 <@bogdan_vs> anyhow, what you say is correct - they should use the SDP parser 17:35 < osas> right 17:36 <@bogdan_vs> ok, so action here : email on merging nat_traversal and nathelper into a new module + SDP parser to be used in rtpproxy module 17:38 -!- aidanna [~aidanna@c-24-30-9-224.hsd1.ga.comcast.net] has joined #opensips 17:38 <@bogdan_vs> ok, if this is agreed, moving on? 17:39 < osas> yup 17:39 <@bogdan_vs> 3) should we drop the "report_ack" ACC parameter? - to get rid of inefficient ACK matching in TM 17:39 <@bogdan_vs> here the story is like that 17:40 <@bogdan_vs> because of historical reason, the TM module (transaction module) tries to match the end2end ACKs (for 200OK) to the INVITE transaction 17:40 <@bogdan_vs> this is BS because this is not transaction matching, but dialog matching (ACK to 200ok is a different transaction) 17:40 <@bogdan_vs> and it is also really slow.... 17:41 < markmaster> returned :) 17:41 <@bogdan_vs> and because of this, a lot of people complained about slow ACK - an ACK being processed slower than an re-INVITE, swapping the order 17:42 < osas> I never accounted ack, so works for me ... 17:42 < osas> and if it makes the code faster and cleaner, even better 17:42 < viraptor> is there a known usecase for accounting ack at all? 17:43 <@bogdan_vs> yeah, this ACK matching in TM is only used by ACC module for this "report_ack" param 17:43 <@bogdan_vs> personally I never needed it..... 17:44 < osas> here's one thing that we could do: enbrace the code in ifdefs and don't compile it by default 17:44 < osas> if someone needs it they can compile with specific ifdefs 17:44 <@bogdan_vs> osas: that will impact TM and ACC module..... 17:44 < osas> yup 17:45 < osas> and if we hear nothing for a while, we can drop the code completly 17:45 <@bogdan_vs> hehe, you can do simple test - remove the param from ACC module and see who will complain :D 17:45 < osas> or that :) 17:46 <@bogdan_vs> while reviewing the TM code for 2.0 implementation, I remember about this - also talked with Jeff Pyle on this at ITEXPO 17:46 <@bogdan_vs> he complained about this 17:47 < osas> let's see if he's still complaining ... 17:47 < osas> the ifdef approach will work here 17:47 < osas> users who really want it, can compile their own version 17:47 <@bogdan_vs> I sent him a patch to disable that....haven;t received any feedback yet 17:47 <@bogdan_vs> on the speed issue 17:47 < osas> ah ... 17:47 < osas> ok 17:48 < osas> let's disable the param then 17:49 <@bogdan_vs> ok, let's to that - I will try to ping Jeff on this 17:49 -!- andrew_p [~andrew@lesnik-nat.portaone.com] has quit [Quit: leaving] 17:49 <@bogdan_vs> to see if the change pays off :) 17:49 <@bogdan_vs> ok, solved...... 17:49 <@bogdan_vs> I have one more topic :) 17:49 <@bogdan_vs> a fresh one 17:49 -!- razvancrainea [~razvan@109.99.2.142] has quit [Quit: Leaving.] 17:50 <@bogdan_vs> popped up from the mailling list 17:50 <@bogdan_vs> about the SIP-wise uri matching 17:50 < osas> hehe 17:50 <@bogdan_vs> osas, you mentioned something on that :D 17:50 < osas> nat_traversal suffers from the same issue 17:50 < osas> yup 17:50 < osas> it's a tricky one 17:50 <@bogdan_vs> yes, we have the problem on dialog module, when validating the route hdr 17:51 < osas> it seems that we will need to implement it 17:51 <@bogdan_vs> some creepy US changing the order of the URI params :P 17:51 < osas> I think it is related to the underlaying implementation on far end SIP UA 17:51 <@bogdan_vs> we considered it some time ago...so I can ask Vlad to do this... 17:52 < osas> parse the URI and save the params in a list 17:52 < osas> add them to the topof the list as you find them 17:52 <@bogdan_vs> not sure if you did any work in this direction 17:52 < osas> and when you send it back, instead of doing a copy, the params are recreated from the list (first to last) and there you have the order switched 17:53 < osas> I had a tought on how to light implement this 17:53 < osas> we can talk off list or on the dev-list about it 17:53 <@bogdan_vs> ok , sure....trying to identify the need for that 17:54 < osas> there are several modules that might benefit from it ... 17:54 <@bogdan_vs> agree... 17:54 < osas> nat_traversal, dialog and maybe registrar 17:54 < osas> for aor matching 17:55 <@bogdan_vs> AOR does not have params....maybe contact URI 17:55 < osas> yes :) 17:56 -!- vlad_paiu [~vlad@109.99.2.142] has quit [Quit: Leaving.] 17:56 <@bogdan_vs> ok - let's talk off line about sharing the work on this 17:56 < osas> well, I think that's it for today ... 17:56 < osas> sure 17:56 <@bogdan_vs> right..... 17:56 <@bogdan_vs> done for today 17:57 <@bogdan_vs> thanks all for being here and for your input 17:57 < osas> thank you 17:57 <@bogdan_vs> the logs and actions will be published on the web, as usual 18:04 -!- bogdan_vs changed the topic of #opensips to: New OpenSIPS eBootcamp training session - 2nd of May 2011 |