Resources.IRCmeeting20110309 History

Hide minor edits - Show changes to markup

April 24, 2013, at 12:15 PM by 109.99.235.212 -
Changed lines 1-447 from:

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


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
to:

(:redirect Community.IRCmeeting20110309 quiet=1:)

March 10, 2011, at 03:34 PM by bogdan -
Changed lines 6-10 from:
  • 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
to:

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

March 10, 2011, at 11:23 AM by bogdan -
Changed lines 6-10 from:
  • 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)
  • Discussion on a new "Event Interface" and on an extension on error handling in script (error route) (2) (bogdan)
  • Tutorial on NAT + RTPProxy with examples and detailed description (1) (wvds-nl)
  • Proper hooks for received/sent messages in b2b mode (1) (osas)
  • Race condition in presence module while handling PUBLISH (1) (osas)
to:
  • 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
March 10, 2011, at 11:22 AM by bogdan -
Changed line 12 from:
to:

March 10, 2011, at 11:21 AM by bogdan -
Changed lines 309-310 from:

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

to:

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

March 10, 2011, at 11:14 AM by bogdan -
Changed lines 16-17 from:

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

to:

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

 progress
Changed lines 20-21 from:

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

to:

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

Changed lines 23-24 from:

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)

to:

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)

Changed lines 28-29 from:

17:03 <@bogdan_vs> regarding the Event Interface, the concept is described here http://www.opensips.org/Development/EventNotification

to:

17:03 <@bogdan_vs> regarding the Event Interface, the concept is described here http://www.opensips.org/Development/EventNotification

Changed lines 31-33 from:

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?

to:

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?

Changed lines 38-39 from:

17:06 <@bogdan_vs> osas: for example you cannot fire a notification when a registration / subscription times out

to:

17:06 <@bogdan_vs> osas: for example you cannot fire a notification when a registration / subscription times out

Changed lines 42-44 from:

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

to:

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

Changed lines 52-55 from:

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

to:

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

Changed lines 62-63 from:

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

to:

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

Changed lines 66-67 from:

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

to:

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

Changed lines 71-72 from:

17:14 < brettnem> hey all, is there some sort of secret decoder for numerical dialog state indicators? :D

to:

17:14 < brettnem> hey all, is there some sort of secret decoder for numerical dialog state indicators? :D

Changed lines 76-77 from:

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

to:

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

Changed lines 81-82 from:

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

to:

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

Changed lines 85-86 from:

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

to:

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

Changed lines 88-89 from:

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

to:

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

Changed lines 93-97 from:

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?

to:

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?

Changed lines 105-106 from:

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

to:

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

Changed lines 112-113 from:

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

to:

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

Changed lines 115-116 from:

17:22 <@bogdan_vs> a much clear approach was the "error_route" - which is triggered for all parsing errors

to:

17:22 <@bogdan_vs> a much clear approach was the "error_route" - which is triggered for all parsing errors

Changed lines 118-119 from:

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

to:

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

Changed lines 128-129 from:

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

to:

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

Changed lines 131-133 from:

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

to:

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

Changed lines 140-142 from:

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 {}; "

to:

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 {}; "

Changed lines 149-150 from:

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

to:

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

Changed lines 155-157 from:

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..

to:

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..

Changed lines 167-168 from:

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

to:

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

Changed lines 183-184 from:

17:34 <@bogdan_vs> so, let;s try to divert (as new classes) the memeory and DB errors

to:

17:34 <@bogdan_vs> so, let;s try to divert (as new classes) the memeory and DB errors

Changed lines 188-189 from:

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

to:

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

Changed lines 194-199 from:

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]

to:

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]

Changed lines 209-210 from:

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 ?

to:

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 ?

Changed lines 220-221 from:

17:40 < viraptor> that would probably also need a compilation option to remove it completely for the speed freaks ;)

to:

17:40 < viraptor> that would probably also need a compilation option to remove it completely for the speed freaks ;)

Changed lines 223-224 from:

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

to:

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

Changed lines 230-234 from:

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

to:

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

Changed lines 245-246 from:

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...

to:

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...

Changed lines 251-252 from:

17:46 <@bogdan_vs> viraptor: regarding the benchmarking, can you start on the SandBox section some ideas on how this should work?

to:

17:46 <@bogdan_vs> viraptor: regarding the benchmarking, can you start on the SandBox section some ideas on how this should work?

Changed lines 266-267 from:

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

to:

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

Changed lines 269-270 from:

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

to:

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

Changed lines 272-273 from:

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

to:

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

Changed lines 279-280 from:

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

to:

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

Changed lines 284-285 from:

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 ?

to:

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 ?

Changed lines 293-294 from:

17:55 <@bogdan_vs> Tutorial on NAT + RTPProxy with examples and detailed description (1) (wvds-nl)

to:

17:55 <@bogdan_vs> Tutorial on NAT + RTPProxy with examples and detailed description (1) (wvds-nl)

Changed lines 297-298 from:

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

to:

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

Changed lines 307-308 from:

17:57 < wvds-nl> osa: i don't think it's handy for me to do that, cause im a noob on this topic

to:

17:57 < wvds-nl> osa: i don't think it's handy for me to do that, cause im a noob on this topic

Changed lines 314-317 from:

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

to:

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

Changed lines 324-328 from:

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

to:

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

Changed lines 335-337 from:

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

to:

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

Changed lines 343-344 from:

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

to:

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

Changed lines 349-350 from:

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

to:

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

Changed lines 354-355 from:

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

to:

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

Changed lines 359-360 from:

18:03 -!- lftsy [~lftsy@pul-lav-fw-so-01-x1.vtxnet.net] has quit [Ping timeout: 276 seconds]

to:

18:03 -!- lftsy [~lftsy@pul-lav-fw-so-01-x1.vtxnet.net] has quit [Ping timeout: 276 seconds]

Changed lines 362-363 from:

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

to:

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

Changed lines 365-366 from:

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

to:

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

Changed lines 371-372 from:

18:04 < jaxyeh> both callers behind nat, but communicate through multiple SIP Proxy

to:

18:04 < jaxyeh> both callers behind nat, but communicate through multiple SIP Proxy

Changed lines 377-378 from:

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

to:

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

Changed lines 386-387 from:

18:06 <@bogdan_vs> Race condition in presence module while handling PUBLISH (1) (osas)

to:

18:06 <@bogdan_vs> Race condition in presence module while handling PUBLISH (1) (osas)

Changed lines 392-393 from:

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

to:

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

Changed lines 395-396 from:

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

to:

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

Changed lines 401-402 from:

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

to:

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

Changed lines 406-407 from:

18:09 < wvds-nl> let's discuss the new track of jennifer lopez - on the floor. i think it's a pretty good song :)

to:

18:09 < wvds-nl> let's discuss the new track of jennifer lopez - on the floor. i think it's a pretty good song :)

Changed lines 409-410 from:

18:11 -!- haloha [73489cee@gateway/web/freenode/ip.115.72.156.238] has quit [Ping timeout: 244 seconds]

to:

18:11 -!- haloha [73489cee@gateway/web/freenode/ip.115.72.156.238] has quit [Ping timeout: 244 seconds]

Changed lines 417-418 from:

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

to:

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

  1. opensips
Changed lines 423-424 from:

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

to:

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

March 10, 2011, at 11:07 AM by bogdan -
Changed lines 4-9 from:

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)
to:

Topics & Conclusions

Changed lines 10-305 from:
  • Race condition in presence module while handling PUBLISH (1) (osas)
to:
  • 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
March 09, 2011, at 03:14 PM by osas -
Added line 14:
  • Race condition in presence module while handling PUBLISH (1) (osas)
March 09, 2011, at 12:55 PM by ivaxer - voted for "event interface" topic
Changed line 11 from:
  • Discussion on a new "Event Interface" and on an extension on error handling in script (error route) (1) (bogdan)
to:
  • Discussion on a new "Event Interface" and on an extension on error handling in script (error route) (2) (bogdan)
March 08, 2011, at 09:48 AM by bogdan -
Changed line 1 from:

Resources -> PublicMeetings -> 08th of March 2011

to:

Resources -> PublicMeetings -> 09th of March 2011

March 04, 2011, at 03:58 PM by osas - Proper hooks for received/sent messages in b2b mode
Changed line 13 from:
to:
  • Proper hooks for received/sent messages in b2b mode (1) (osas)
March 03, 2011, at 04:19 PM by viraptor -
Changed line 10 from:
  • 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)
to:
  • 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)
March 03, 2011, at 03:22 PM by edekkers -
Added line 12:
  • Tutorial on NAT + RTPProxy with examples and detailed description (1) (wvds-nl)
March 01, 2011, at 11:19 AM by bogdan -
Changed line 11 from:
to:
  • Discussion on a new "Event Interface" and on an extension on error handling in script (error route) (1) (bogdan)
February 24, 2011, at 06:16 PM by viraptor -
Changed line 10 from:
to:
  • 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)
February 23, 2011, at 09:11 PM by bogdan -
Changed lines 5-7 from:

Rules:\\

to:

Rules:\\

Changed lines 7-8 from:
 Please add a new topic or vote (increase the counter) an existing topic
to:
 Please add a new topic or vote (increase the counter) an existing topic
February 23, 2011, at 09:10 PM by bogdan -
Added lines 3-14:

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)
February 23, 2011, at 06:30 PM by bogdan -
Changed line 1 from:

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

to:

Resources -> PublicMeetings -> 08th of March 2011

February 23, 2011, at 06:30 PM by bogdan -
Added lines 1-3:

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



Page last modified on April 24, 2013, at 12:15 PM