(:redirect Community.IRCmeeting20110309 quiet=1:)

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/Resources/DocsTsPerf

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

• How to find biggest script performance issues? How can future opensips updates help? - builtin benchmark channels, upstream provided systemtap sets, standard performance checklist, ...
• Discussion on a new "Event Interface" and on an extension on error handling in script (error route)
• Tutorial on NAT + RTPProxy with examples and detailed description
• Proper hooks for received/sent messages in b2b mode
• Race condition in presence module while handling PUBLISH

17:57 <@bogdan_vs> osas: to be honest, some examples in the source tree are trivially simple, completely useless

17:00 -!- bogdan_vs changed the topic of #opensips to: OpenSIPS meeting in

 progress

17:01 <@bogdan_vs> the topics for today are available under http://www.opensips.org/Resources/IRCmeeting20110309

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 <@bogdan_vs> regarding the Event Interface, the concept is described here http://www.opensips.org/Development/EventNotification

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: for example you cannot fire a notification when a registration / subscription times out

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 <@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 <@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: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 < brettnem> hey all, is there some sort of secret decoder for numerical dialog state indicators? :D

17:15 <@bogdan_vs> osas: yes, we can start with a POC based on the current description

17:16 < osas> and after that, we need to come up with a transcoding (internal event to external notification)

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> the idea is how to simply the script and to be able to catch all internal errors generated by various script function

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: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 < 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 <@bogdan_vs> a much clear approach was the "error_route" - which is triggered for all parsing errors

17:23 <@bogdan_vs> if your script functions generates a parsing error, the error_route will be triggered automatically

17:25 <@bogdan_vs> if ($(err.class) == "memory") send_reply("500","Internal Server Error");

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: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: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 < 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: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:34 <@bogdan_vs> so, let;s try to divert (as new classes) the memeory and DB errors

17:35 < osas> if we have mem errors, the error route should have a safe way to deal with those

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 < 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:40 < viraptor> that would probably also need a compilation option to remove it completely for the speed freaks ;)

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: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: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:46 <@bogdan_vs> viraptor: regarding the benchmarking, can you start on the SandBox section some ideas on how this should work?

17:50 < osas> once it is engaged, there's very litle insight about what's going on (from a script perspective)

17:51 <@bogdan_vs> so you are looking for a kind of callbac system as the dialog module has ?

17:51 < osas> we have the hooks for received responses, but we don't know anything about sent responses

17:52 < osas> It would be good if every message (sent or received) can be traced in config

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:55 <@bogdan_vs> Tutorial on NAT + RTPProxy with examples and detailed description (1) (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:57 < wvds-nl> osa: i don't think it's handy for me to do that, cause im a noob on this topic

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 < 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?]

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 < 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: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 < 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 -!- lftsy [~lftsy@pul-lav-fw-so-01-x1.vtxnet.net] has quit [Ping timeout: 276 seconds]

18:03 < wvds-nl> the freeswitch wiki puts quite a lot a example under the function description on how to do it

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:04 < jaxyeh> both callers behind nat, but communicate through multiple SIP Proxy

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:06 <@bogdan_vs> Race condition in presence module while handling PUBLISH (1) (osas)

18:07 -!- gosha [~gosha@92.62.99.217] has quit [Read error: Connection reset by peer]

18:07 < osas> and in the race, the second PUBLISH may generate a NOTIFY before the first PUBLISH

18:08 <@bogdan_vs> well, we have one more topic, but because of time, let's keep it for next time

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:11 -!- haloha [73489cee@gateway/web/freenode/ip.115.72.156.238] has quit [Ping timeout: 244 seconds]

18:12 -!- STenyaK [~quassel@66.Red-80-25-84.staticIP.rima-tde.net] has joined

1. opensips

18:14 -!- bogdan_vs changed the topic of #opensips to: OpenSIPS Stress Tests - http://www.opensips.org/Resources/StressTests

Topics & Conclusions

• Race condition in presence module while handling PUBLISH (1) (osas)

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

• Race condition in presence module while handling PUBLISH (1) (osas)

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

Resources -> PublicMeetings -> 09th of March 2011

• Proper hooks for received/sent messages in b2b mode (1) (osas)

• 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)

• Tutorial on NAT + RTPProxy with examples and detailed description (1) (wvds-nl)

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

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

Rules:\\

 Please add a new topic or vote (increase the counter) an existing topic

Topics

Rules:
Format (per line): * topic description (N) (submitter name) where N is a counter starting from 1.
Please add a new topic or vote (increase the counter) an existing topic

• what are the biggest problems/issues right now in real-life operations with OpenSIPS 1.6.x (1) (bogdan)

Resources -> PublicMeetings -> 08th of March 2011

Resources -> [[Resources.PublicMeetings | PublicMeetings] -> 08th of March 2011