Login | Register

Community

Community -> PublicMeetings -> 13th of April 2011


Topics & Conclusions

1) 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).
Also, Ovidiu suggested to start collecting such reports from mailing list as there is much more traffic / subscribers there.

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).
The merging discussion will be moved on the "devel" mailing list in order to get feedback and input from all developers.

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.
The plan is to remove this parameter and the underlaying stuff (end2end ACK matching in TM) in the next release.

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.
The plan is to add SIP-wise URI matching in the next release.


IRC Logs

17: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&#65533;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

Page last modified on May 09, 2013, at 11:00 AM