Community -> PublicMeetings -> 09th of March 2011

Topics & Conclusions

1) How to find biggest script performance issues? How can future opensips updates help? - builtin benchmark channels, upstream provided systemtap sets, standard performance checklist, ...

Stanisław Pitucha put together a page for that:

         http://www.opensips.org/Documentation/TroubleShooting-FindPerfPb

2) Discussion on a new "Event Interface" and on an extension on error handling in script (error route)

The work will follow the description from http://www.opensips.org/Development/EventNotification for the Event Manager (in core). The idea is have a first working version that can be evaluated and improved.

3) Tutorial on NAT + RTPProxy with examples and detailed description

We agreed on this need. Bogdan Iancu will take care in generating a tutorial with the nat traversal logic and the description of the OpenSIPS implementation.

4) Proper hooks for received/sent messages in b2b mode

Ovidiu Sas will push this item on the devel mailing list to see (1) what is the need for that and (2) how to do it, technically speaking.

5) Race condition in presence module while handling PUBLISH

Ovidiu Sas will push this item on the devel mailing list

IRC Logs

17:00 -!- bogdan_vs changed the topic of #opensips to: OpenSIPS meeting in
 progress
17:00 <@bogdan_vs> Hi all
17:00 < viraptor> afternoon :)
17:01 <@bogdan_vs> the topics for today are available under 
http://www.opensips.org/Resources/IRCmeeting20110309
17:01 <@bogdan_vs> just to be sure that we all are aware on what to talk about :)
17:02 <@bogdan_vs> I would suggest to start with the topics in the order of 
interest (higher numbers first)
17:02 <@bogdan_vs> So first topic : Discussion on a new "Event Interface" and on 
an extension on error handling in script (error route)
17:03 -!- karthik [~chatzilla@183.83.32.255] has joined #opensips
17:03 <@bogdan_vs> regarding the Event Interface, the concept is described here 
http://www.opensips.org/Development/EventNotification
17:04 <@bogdan_vs> The question is if anybody has any comments or ideas on that
17:04 <@bogdan_vs> as it is still in design stage, any feedback/contributions are 
welcome
17:05 < osas> The use cases described there can be implemented today using the 
exec() function
17:06 < viraptor> so the whole subscription scenario is not defined yet, right? 
it might be SIP pub/sub, as well as some event queue?
17:06 <@bogdan_vs> osas: not all
17:06 <@bogdan_vs> osas: for example you cannot fire a notification when a 
registration / subscription times out
17:07 < osas> wethat's true (but it's not under "Use cases" :)
17:07 -!- wvds-away [~wvds@178-230-045-062.dynamic.caiway.nl] has joined #opensips
17:08 <@bogdan_vs> viraptor: what is described is an interface (like the MI 
interface ). Transport will be implemented in different modules (like mi_xmlrpc, 
etc)
17:08 < viraptor> also, what's the layer this is going to be plugged into? is it 
supposed to be completely external, or something like 
"on_event_blah_route(route_name)" with new commands for doing the actual 
notifications?
17:08 <@bogdan_vs> osas: those are some examples...and the idea is to avoid exec 
as the penalty is too high
17:08 < osas> yup
17:08 <@bogdan_vs> the interface will fire an event, does not have to wait to be 
handled by external app
17:09 < osas> I think the ideea is good and as soon as the framework is 
available, more ideas and user imput will come
17:10 <@bogdan_vs> viraptor: the idea is to have the event manager (in core) that 
will allow modules to register events (like usrloc module will provide the 
CONTACT_UPLOADED event)
17:10 < osas> It will be good to have two transport interfaces: one for module to 
event notification manager
17:10 < osas> and another one for event notification manager to external app
17:10 <@bogdan_vs> on other hand, via different transport means, external apps 
will subscribe to the Event Manager to get notifications when the event is fired
17:11 <@bogdan_vs> osas: 2 interface, for 2 different purposes
17:11 < osas> yup
17:12 <@bogdan_vs> this Event Manager will make possible (or simplify) the 
integration work
17:14 < osas> It seems that a proof of concept needs to be available so ppl can 
start play with it
17:14 < osas> after that, enhancement will come for sure :)
17:14 < brettnem> hey all, is there some sort of secret decoder for numerical 
dialog state indicators? :D
17:15 < osas> brettnem: there's a meeting going on
17:15 < osas> pls stick to the agenda
17:15 < brettnem> OH! whoops, sorry, I forgot about it.. My apologies!
17:15 <@bogdan_vs> osas: yes, we can start with a POC based on the current 
description
17:15 < osas> yup
17:15 <@bogdan_vs> and let's see how it will evolve :)
17:16 <@bogdan_vs> next part: error handling in script
17:16 < osas> and after that, we need to come up with a transcoding (internal 
event to external notification)
17:16 <@bogdan_vs> that's a bit of a painful issue :(
17:16 < osas> :)
17:17 <@bogdan_vs> osas: yes - the event syntax - we have it on TODO list, we 
will update as soon as we come up with a proposal
17:17 <@bogdan_vs> so, about the errors in script
17:17 <@bogdan_vs> the idea is how to simply the script and to be able to catch 
all internal errors generated by various script function
17:17 <@bogdan_vs> like memory errors, DB errors, etc
17:18 < osas> maybe the proposed event notification mechanism will help here
17:18 < osas> every time when we have a memory issue, we can trigger an event
17:18 <@bogdan_vs> there were several threads on mailing list on that - people 
requesting different return codes (for functions) to differentiate an error 
versus a negative response
17:19 -!- p3k4y [~pete@82-68-96-110.dsl.in-addr.zen.co.uk] has quit [Quit: 
Leaving.]
17:19 <@bogdan_vs> osas: ex: lookup(location) returns false if the user is not 
registered and also false if there was some error
17:19 < osas> for this kind of errors, if the doc (README file) is up to date, I 
see no issues here
17:20 < viraptor> maybe I'm missing some information, but what more than a list 
of -N error codes is needed here?
17:20 <@bogdan_vs> viraptor - for usrloc() that's the case, it is true
17:21 < osas> so, if aal the functions have proper return codes, then it is up to 
the scripter to figure out what's going on
17:21 <@bogdan_vs> but I see 2 problems with this approach : each script function 
must be re-worked to return the internal errors as returns code and second, in 
script, all functions will be followed by big "switch" to handle all return code
17:22 <@bogdan_vs> IMO, this does not scale and it is not feasible
17:22 < osas> what is the alternative?
17:22 < brettnem> I don't really see a problem with the swtich statement, but 
enumerated return codes might be nice..make the code more readable
17:22 -!- sekil [~sekil@80.93.247.26] has quit [Quit: Leaving.]
17:22 <@bogdan_vs> a much clear approach was the "error_route" - which is 
triggered for all parsing errors
17:23 < osas> but then you have a disconnect in script
17:23 <@bogdan_vs> if your script functions generates a parsing error, the 
error_route will be triggered automatically
17:23 < osas> and yu move all the ugliness to a big error_route
17:23 <@bogdan_vs> we can have classes of errors....
17:24 <@bogdan_vs> so you can handle classes
17:24 < osas> from my point of view, it is ok as it it is now ...
17:24 < osas> sometimes it can be agly, but it's manageable ...
17:24 < osas> s/agly/ugly/
17:24 <@bogdan_vs> like in error_route:
17:25 <@bogdan_vs> if ($(err.class) == "parsing") send_reply("400","Bad request);
17:25 <@bogdan_vs> if ($(err.class) == "memory") send_reply("500","Internal 
Server Error");
17:26 < osas> this are generic errors
17:26 < osas> but if you plan to move an error there from a function that can be 
used multiple times (let's say a dialplan function)
17:26 < viraptor> looks nice :) so what would be included? err.class, err.code 
(specific documented ccode), err.message?
17:26 <@bogdan_vs> brettnem: right now we have different retcodes only for some 
functions and you are not abel to detect the internal errors from all functions
17:26 < osas> then it is difficult to know which one generated the error
17:27 <@bogdan_vs> osas: does it matter ?
17:27 < osas> well, it may
17:27 < brettnem> having the big error_route seems like it'll take a lot of the 
linear flow out of the script
17:27 < osas> cause sometimes I don't care about it and I might choose to ignore 
it
17:27 <@bogdan_vs> another crazy idea is to use an existing concept, like 
"try{...}catch {}; "
17:28 < osas> parsing an memory are pretty straigh forward
17:28 <@bogdan_vs> to through errors in error route only from parts of the script
17:28 < brettnem> if (lookup() !=  FOUND_USER) ?
17:29 <@bogdan_vs> osas: more or less I'm looking for a way to globally handle 
the general types of errors :)
17:29 < osas> adding memory errors to the error route should be simple and 
straight forward
17:29 < osas> but trying to handle all the errors, is a big task
17:29 < osas> and I don't know if the return of investment is worth it
17:29 < brettnem> but there are two big types of errors.. internal system errors, 
like parsing errors, db errors, memory errors.. then there are call flow errors, 
like user offline, not found.. etc..
17:30 < brettnem> not sure if it makes sense to group them together?
17:30 < osas> yup
17:30 < osas> general errors can go to error_route
17:30 -!- saghul [~saghul@ip3e830637.speed.planet.nl] has joined #opensips
17:30 < osas> but "call flow" errors I like to have them in script
17:30 <@bogdan_vs> brettnem: I;m talking only about internal errors
17:31 <@bogdan_vs> it is not about the "call flow "
17:31 < osas> so lookup should stay as it is
17:31 <@bogdan_vs> more or less errors relate to DB, mem, parsing....
17:31 < brettnem> right.. but you might want to force a call flow based on either 
an internal error OR a regular return code.. so if a lookup returns a memory 
error, we should be able to control the return code as well as a user not found..
17:32 <@bogdan_vs> yes, it will stay - it will return false to script if the user 
is not registered
17:32 < osas> right now we have some parsing errors redirected to error_route
17:32 < osas> we can add memory errors
17:32 < osas> and db errors
17:33 < osas> it is just like a notification (something is wrong)
17:33 < osas> that's ok, and I can see this related to the event manager stuff
17:33 < osas> which can be notified via an event
17:33 < osas> and then trigger some external actions
17:33 <@bogdan_vs> yes, we can interconnect them
17:34 <@bogdan_vs> as kind of the alerting system
17:34 < osas> those kind of errors are ok to land in error_route
17:34 < osas> but not other types
17:34 <@bogdan_vs> so, let;s try to divert (as new classes) the memeory and DB 
errors
17:34 < osas> yup
17:34 -!- UnixDev__ [~UnixDev@unaffiliated/unixdev] has joined #opensips
17:35 <@bogdan_vs> ok  cool
17:35 < osas> if we have mem errors, the error route should have a safe way to 
deal with those
17:35 < osas> like it's own private memory
17:35 < osas> otherwise, it's useless
17:36 <@bogdan_vs> ok, should we move to next topic ?
17:36 < osas> sure ...
17:36 <@bogdan_vs> How to find biggest script performance issues? How can future 
opensips updates help? - builtin benchmark channels, upstream provided systemtap 
sets, standard performance checklist, ... (1) (viraptor)
17:37 < viraptor> someone seems to have started tackling those with the "limit" 
settings for various operations already ;)
17:37 < viraptor> but I meant something more universal - there's the benchmark 
module with the api
17:38 < viraptor> unfortunately nothing uses it by default - why not stick some 
"upstream" benchmarks around stuff that would be useful in typical situations
17:38 <@bogdan_vs> viraptor: yes, we ran into some problems with a production 
system and we were looking for a way to troubleshoot the blocking of some 
processes
17:38 -!- UnixDev [~UnixDev@unaffiliated/unixdev] has quit [Ping timeout: 246 
seconds]
17:38 -!- UnixDev__ is now known as UnixDev
17:38 < viraptor> like message parsing time, dns query time, sql query, specific 
lookups / longer processing operations
17:39 <@bogdan_vs> viraptor: maybe checking exec time for each function triggered 
from script ?
17:39 < viraptor> dialog lookup which takes place behind the sceenes really
17:39 <@bogdan_vs> this will be automatic
17:39 < viraptor> hmm... wasn't going to go that far... but why not? :)
17:40 <@bogdan_vs> well, we started this work targeting the blocking IOs :)
17:40 <@bogdan_vs> and focused on DNS, DB and some TCP stuff
17:40 < UnixDev_> :D
17:40 < UnixDev_> removing blocking ios is GREAT
17:40 < viraptor> that would probably also need a compilation option to remove it 
completely for the speed freaks ;)
17:41 <@bogdan_vs> right :)
17:41 -!- wvds-away [~wvds@178-230-045-062.dynamic.caiway.nl] has quit [Quit: 
changing computers]
17:41 < UnixDev_> bogdan_vs: that bug we discussed the other day, its also 
present in 1.7.x svn branch, i ran into it last night during testing
17:41 <@bogdan_vs> UnixDev_: let's talk after the meeting...
17:41 < UnixDev_> ahh, ok
17:42 < UnixDev_> meeting is about 2.0?
17:42 < viraptor> also, I tried to browse the docs, but couldn't find a checklist 
of stuff that is typically mentioned when people are asking "I can't go over X cps, why?"
17:42 <@bogdan_vs> UnixDev_: no, topics are http://www.opensips.org/Resources
/IRCmeeting20110309
17:43 <@bogdan_vs> viraptor: true....maybe such document will help in 
troubleshooting
17:43 < viraptor> maybe I just missed it, but if not, could we create standard 
page for that on the wiki? like - check your sql access times, check your 
storage, watch out for waiting acc, too high debug level, etc. etc.
17:44 <@bogdan_vs> there was even today such an email in response to the 
Performance Tests we did
17:44 <@bogdan_vs> viraptor: like http://www.opensips.org/Resources/DocsTipsFaqs ?
17:44 <@bogdan_vs> or http://www.opensips.org/Resources/Documentation#toc3
17:45 <@bogdan_vs> anyone with an wiki account can create and edit those pages
17:45 < viraptor> yeah :) something like that
17:45 < UnixDev_> got it, definitely one of the biggest problems facing 1.6.x 
branch for us is db blocking...it would be great with async...
17:45 < viraptor> ah, right... didn't realise that :)
17:45 <@bogdan_vs> viraptor: so you can start a page on that :)
17:45 -!- wvds-nl [~erik@178-230-045-062.dynamic.caiway.nl] has joined #opensips
17:46 <@bogdan_vs> UnixDev_: hold on a sec - we will get to that topic soon :)
17:46 <@bogdan_vs> viraptor: regarding the benchmarking, can you start on the 
SandBox section some ideas on how this should work?
17:47 < viraptor> ok, will do... maybe tonight
17:47 <@bogdan_vs> take the time - think more, write less ;)
17:48 <@bogdan_vs> http://www.opensips.org/Development/SandBox
17:48 <@bogdan_vs> ok, let;s follow this up in the next meetings
17:49 <@bogdan_vs> moving forward ?
17:49 <@bogdan_vs> next topic ?
17:49 < osas> sure ... :)
17:49 < viraptor> yeah :)
17:50 <@bogdan_vs> ok
17:50 <@bogdan_vs> Proper hooks for received/sent messages in b2b mode (1) (osas)
17:50 < osas> right now, the b2b mode is very embedded :)
17:50 <@bogdan_vs> b2b_entities?
17:50 <@bogdan_vs> or b2b_logic ?
17:50 < osas> once it is engaged, there's very litle insight about what's going 
on (from a script perspective)
17:51 < osas> well ... both
17:51 <@bogdan_vs> so you are looking for a kind of callbac system as the dialog 
module has ?
17:51 < jaxyeh> did we skip discussion about NAT stuff on the list?
17:51 < osas> we have the hooks for received responses, but we don't know 
anything about sent responses
17:51 < osas> jaxyeh: I don't think the order i relevant
17:52 < osas> everything will be discussed
17:52 < jaxyeh> k
17:52 <@bogdan_vs> jaxyeh: we haven;t skipped - we go by the votes :)
17:52 < osas> back to the topic
17:52 < osas> It would be good if every message (sent or received) can be traced 
in config
17:52 < osas> via a route
17:52 <@bogdan_vs> osas: yeah, opensips itself does not provide such a mechanism
17:53 <@bogdan_vs> that's an idea...
17:53 < osas> I think it would be good to have a full array of hooks for all 
received/sent messages belongign to a b2b call
17:54 <@bogdan_vs> osas: as this is higly technical, what about taking this 
discussion on the devel mailing list ?
17:54 < osas> sure
17:54 < osas> I wanted to know if there's enough traction on this topic
17:54 <@bogdan_vs> so, please open a new thread on that..
17:54 < osas> ok
17:54 < osas> next topic?
17:55 <@bogdan_vs> Tutorial on NAT + RTPProxy with examples and detailed 
description (1) (wvds-nl)
17:55 < wvds-nl> YEAH!
17:55 < wvds-nl> :)
17:55 < wvds-nl> the idea is to provide a document with some explanation for 
beginners like me
17:56 <@bogdan_vs> wvds-nl: what we have right now is a runing example - the 
opensips VM
17:56 <@bogdan_vs> but I agree it is not explained :)
17:56 < wvds-nl> bogdan: that one is very clear. but it's not on the website
17:56 < osas> and there are config examples in the source tree
17:56 < osas> wvds-nl: the website is a wiki
17:56 < osas> you can add everything that you need there
17:57 < brettnem> is the config for the vm available on the website?
17:57 < wvds-nl> osa: i don't think it's handy for me to do that, cause im a noob 
on this topic
17:57 <@bogdan_vs> osas: to be honest, some examples in the source tree are 
trivially simple, completely useless
17:57 < wvds-nl> but you're right, if i have some more knowledge i could do that
17:57 < osas> well. I started with those
17:57 < osas> and were good, because were simple
17:57 < osas> :)
17:58 <@bogdan_vs> brettnem: not on web, but you can have it if you download the 
VM image
17:58 < wvds-nl> bogdan: maybe it's enough to just put the VM config on the 
website
17:58 <@bogdan_vs> osas: the problem with NAT traversal is not about the 
function, but the big picture - how nat traversal should be done, theoretically 
speacking
17:58 < wvds-nl> the config itself is quite clear and gives good understanding on 
how opensips is working
17:59 < osas> rtpproxy is one thing and nat traversal is a different thing
17:59 < wvds-nl> learning from examples is imho the best way cause you can see 
immediatly how it's working
17:59 -!- gosha [~gosha@92.62.99.217] has quit [Read error: Connection reset by 
peer]
17:59 <@bogdan_vs> to be honest, I'm playing for some time with the idea of 
making an comprehensive NAT traversal tutorial
17:59 < osas> it is true that rtpproxy is used for nat traversal, but it is not 
the only application
17:59 -!- soulofmischief76 [~IceChat77@corp-fw-1-1-npv.glowpoint.net] has quit 
[Quit: Say What?]
17:59 -!- gosha [~gosha@92.62.99.217] has joined #opensips
18:00 <@bogdan_vs> wvds-nl: first is is important what are the problems 
introduced by NAT and how this problems can be addressed from network point of 
view
18:00 < wvds-nl> bogdan: maybe it's an idea to just put examples per explanation. 
one example tells more then 10000 words
18:01 < wvds-nl> bogdan_vs: my problem is more on 'how to do that in opensips' 
than the technology itself
18:01 <@bogdan_vs> agreed ...
18:01 < osas> well ... if you don't understand the technology, how are you going 
to troubleshoot issues?
18:01 <@bogdan_vs> wvds-nl: but to solve a problem with opensips, you first must 
to understand the problem ;)
18:01 < wvds-nl> true
18:01 < wvds-nl> true
18:02 <@bogdan_vs> it is like trying to do SIP routing with OpenSIPS without 
understanding SIP :P
18:02 < wvds-nl> what i said, i don't think the technology itself is the problem, 
but more on how to do XX or how to do YY on opensips
18:02 <@bogdan_vs> bottom line, I will try to put together a document on that
18:02 < wvds-nl> e.g. i can do things with freeswitch, but totally don't know on 
how to make the same in opensips
18:03 < osas> same here, but the other way around ;)
18:03 <@bogdan_vs> :D
18:03 < wvds-nl> :)
18:03 -!- lftsy [~lftsy@pul-lav-fw-so-01-x1.vtxnet.net] has quit [Ping timeout: 
276 seconds]
18:03 <@bogdan_vs> ok, we have a direction for this issue, ok ?
18:03 < wvds-nl> the freeswitch wiki puts quite a lot a example under the 
function description on how to do it
18:03 < wvds-nl> yeah, great bogdan!
18:03 < jaxyeh> If possible, I would like seeing some examples of NAT Traversal 
not limited from UAC, but also proxy from another UAS who already does NAT as well
18:03 < jaxyeh> those kind of thing gets more tricky
18:04 <@bogdan_vs> jaxyeh: like opensips behid NAT ?
18:04 -!- lftsy [~lftsy@pul-lav-fw-so-01-x1.vtxnet.net] has joined #opensips
18:04 <@bogdan_vs> or both caller and callee behind NAT ?
18:04 < jaxyeh> both callers behind nat, but communicate through multiple SIP 
Proxy
18:05 <@bogdan_vs> aha
18:05 -!- DuaneLarson [~duane@12.37.251.126] has joined #opensips
18:05 <@bogdan_vs> ok
18:05 <@bogdan_vs> should we move on ?
18:05 < jaxyeh> I don't think opensips can go behind NAT, according to RTPProxy 
must be on public IP
18:05 < wvds-nl> damn, cooking and chatting isnt a good combination. my meat is 
burned :)
18:05 < medve> bogdan_vs: a tutorial would be nice when I got 488
18:05 < jaxyeh> wvds-nl: let's call it well-done!
18:06 <@bogdan_vs> :)
18:06 < jaxyeh> bogdan_vs: yes, u can move on
18:06 <@bogdan_vs> next topic:
18:06 <@bogdan_vs> Race condition in presence module while handling PUBLISH (1) 
(osas)
18:06 <@bogdan_vs> osas: ?
18:06 < osas> I already started to discuss this issue with Anca
18:06 < osas> I will open an issue on the tracker ...
18:07 < osas> the issue is related to two consecutive PUBLISH request
18:07 -!- gosha [~gosha@92.62.99.217] has quit [Read error: Connection reset by 
peer]
18:07 <@bogdan_vs> ok, so something really tech
18:07 < osas> and in the race, the second PUBLISH may generate a NOTIFY before 
the first PUBLISH
18:07 < osas> yup
18:07 < osas> :)
18:07 <@bogdan_vs> ah......I see. :)
18:07 < osas> I think we are done :)
18:08 <@bogdan_vs> well, we have one more topic, but because of time, let's keep 
it for next time
18:08 <@bogdan_vs> I think the most important and urgent things were addressed
18:09 <@bogdan_vs> everybody happy ? :) some last comments ?
18:09 < osas> all good here :)
18:09 < wvds-nl> let's discuss the new track of jennifer lopez - on the floor. i 
think it's a pretty good song :)
18:09 < wvds-nl> haha
18:11 -!- haloha [73489cee@gateway/web/freenode/ip.115.72.156.238] has quit [Ping 
timeout: 244 seconds]
18:11 <@bogdan_vs> :)....I;m in a different kind of music ;)
18:11 <@bogdan_vs> ok - so we are done for today
18:11 < wvds-nl> ypu
18:11 < wvds-nl> yup
18:11 <@bogdan_vs> I will upload the logs and the conclusions on the wiki
18:12 <@bogdan_vs> guess tomorrow ;)
18:12 -!- STenyaK [~quassel@66.Red-80-25-84.staticIP.rima-tde.net] has joined 
#opensips
18:12 < wvds-nl> nice
18:12 < wvds-nl> really cool these IRC meetings
18:12 <@bogdan_vs> so - Thanks to all of you for contributing !
18:12 < wvds-nl> you too bogdan
18:14 -!- bogdan_vs changed the topic of #opensips to: OpenSIPS Stress Tests - 
http://www.opensips.org/Resources/StressTests