Resources.IRCmeeting20110309 History

Hide minor edits - Show changes to output

April 24, 2013, at 01:15 PM by 109.99.235.212 -
Changed lines 1-447 from:
!! Resources -> [[Resources.PublicMeetings | 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 04: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&#322;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 12:23 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, ... (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 12:22 PM by bogdan -
Changed line 12 from:
to:
----
March 10, 2011, at 12:21 PM 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 12:14 PM 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
#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 12:07 PM by bogdan -
Changed lines 4-9 from:
!!! Topics
%blue%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 04:14 PM by osas -
Added line 14:
* Race condition in presence module while handling PUBLISH (1) (osas)
March 09, 2011, at 01: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 10:48 AM by bogdan -
Changed line 1 from:
!! Resources -> [[Resources.PublicMeetings | PublicMeetings]] -> 08th of March 2011
to:
!! Resources -> [[Resources.PublicMeetings | PublicMeetings]] -> 09th of March 2011
March 04, 2011, at 04: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 05: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 04:22 PM by edekkers -
Added line 12:
* Tutorial on NAT + RTPProxy with examples and detailed description (1) (wvds-nl)
March 01, 2011, at 12:19 PM 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 07: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 10:11 PM by bogdan -
Changed lines 5-7 from:
----
%blue%
Rules:\\
to:
%blue%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 10:10 PM by bogdan -
Added lines 3-14:

!!! Topics
----
%blue%
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 07:30 PM by bogdan -
Changed line 1 from:
!! Resources -> [[Resources.PublicMeetings | PublicMeetings] -> 08th of March 2011
to:
!! Resources -> [[Resources.PublicMeetings | PublicMeetings]] -> 08th of March 2011
February 23, 2011, at 07:30 PM by bogdan -
Added lines 1-3:
!! Resources -> [[Resources.PublicMeetings | PublicMeetings] -> 08th of March 2011
----

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