|
Community |
Community -> PublicMeetings -> 26th of November 2014WhenTopicsSimplify OpenSIPS Experience The goal of this session is to simplify the OpenSIPS usage. Durinig this meeting we plan to detect the things that you, as either a newbie or an experienced user, find difficult and annoying to deal with when using OpenSIPS. We will narrow down a few ideas and try to find solutions for them. ConclusionsTODO IRC Logs
17:06 < razvanc>| Hello all!
17:10 < razvanc>| The schedule for today is to discuss about things you find annoying and difficult when using OpenSIPS
17:10 < t_dot_zilla>| haha
17:10 <t_dot_zilla> | razvanc: can we talk about modules?
17:10 < razvanc>| sure
17:10 < t_dot_zilla>| dispatcher... it's great but then again i think it's missing some things
17:10 < t_dot_zilla>| and also it does too much
17:11 < t_dot_zilla>| i needed a "slimmed" down version
17:12 < t_dot_zilla>| with more features, like optionally using same protocol (UDP,TCP,or TLS) in the $du
17:12 < t_dot_zilla>| i also wanted it to check the $si against other lists
17:12 < razvanc>| so you think that the dispatcher module is hard to use?
17:13 < razvanc>| or just that it provides a lot of functions, that you don't necessary need
17:13 < t_dot_zilla>| i think it's over-complicated
17:13 < t_dot_zilla>| that too
17:13 < razvanc>| could you describe a bit how you would like to use it?
17:13 < t_dot_zilla>| i wrote a module (based on dispatcher) ... it's not complete yet
17:14 < t_dot_zilla>| that does the things i need and removes all the extra stuff (there was a LOT of extra features i didn't need)
17:14 < t_dot_zilla>| I wanted a module to "distribute" calls to FS
17:14 < t_dot_zilla>| but it needed to be more "aware"
17:15 < t_dot_zilla>| my module distributes calls to FS cluster simply in this fashion:
17:15 < t_dot_zilla>| 1. randomly
17:15 < t_dot_zilla>| 2. based on active calls
17:16 < t_dot_zilla>| if the caller's sip username and sip domain match an active call (using a database query), it sends the call to that box
17:16 < t_dot_zilla>| it also auto-caches the $du using the call-id as a key
17:17 < t_dot_zilla>| if another INVITE comes in matching the call-id it can use the $du from a hashtable
17:17 < razvanc>| but can you elaborate a bit what you find difficult
17:17 < t_dot_zilla>| using the hash cache mechanism, I was able to have FS auth INVITE AND REGISTER requests... is this making sense so far?
17:18 < razvanc>| yes, it definitely make sense
17:18 < t_dot_zilla>| 1. dispatcher does NOT optionally put the protocol in the $du
17:19 < t_dot_zilla>| i found that problematic as I had to write extra lines in my cfg script to force the protocol
17:19 < t_dot_zilla>| if a SIP call is TCP, I want it sent to FS as TCP, if it's TLS, i want it sent as TLS, etc.
17:19 < t_dot_zilla>| same goes for SIP port
17:20 < t_dot_zilla>| 2. dispatcher does not optionally put the port in the $du, it's hard coded in the database
17:20 < vlad-paiu>| t_dot_zilla : if you provision the database to have the destination field as sip:IP:PORT;transport=tcp , the call will go out via TCP
17:20 < t_dot_zilla>| vlad-paiu: yes i understand that
17:20 < vlad-paiu>| on the specified PORT
17:20 < lirakis>| t_dot_zilla, so detect if the transport of the call was tcp/udp/tls whatever
17:20 < t_dot_zilla>| but i want dispatcher to optionally be "smart" and auto set those things. so you can just have sip:IP in dest field of db
17:20 < lirakis>| and have a "group"
17:20 < lirakis>| defined
17:20 < lirakis>| that ONLY has tcp
17:21 < lirakis>| a group defined that ONLY has tls
17:21 < lirakis>| etc
17:21 < t_dot_zilla>| i understand there are work-arounds
17:21 < lirakis>| and load_balance("tls")
17:21 < lirakis>| which will pick the $du WITH the port, and it will work dynamic per call
17:21 < t_dot_zilla>| but these options would make your cfg script so much easier
17:21 < lirakis>| i understand you want a more sophisticated module
17:21 < lirakis>| but it doesnt exist
17:21 < razvanc>| t_dot_zilla: I don't think that's actually correct
17:21 < lirakis>| detect the transport
17:22 < t_dot_zilla>| the module i wrote, can optionally use the same port and protocol that the SIP request came to proxy on
17:22 < razvanc>| the idea of the dispatcher is that you provision the destinations in the database
17:22 < t_dot_zilla>| i understand that
17:22 < t_dot_zilla>| but it forces you to also provision the protocol and port
17:22 < razvanc>| yes
17:23 < razvanc>| I understand your point
17:23 < lirakis>| so do it 3 times group:tls, ip:port;transport=tls .... group:udp,ipport,transport=udp .... group:tcp,ip:port;transport=tcp
17:23 < t_dot_zilla>| the idea of a module should be to make your cfg script easier. i can write a perl script that can do the things i want
17:23 < lirakis>| (shrug)
17:24 < lirakis>| its literally a one line thing in the config
17:25 < lirakis>| load_balance("$oP");
17:25 < t_dot_zilla>| also after looking at all the code in dispatcher, i noticed it was way more than i ever would need
17:25 < razvanc>| yes, but to be honest, is the first time I've heard/used dispatcher used in this manner
17:25 < lirakis>| t_dot_zilla, does my suggestion make sense to you?
17:25 < t_dot_zilla>| lirakis: yes
17:25 < lirakis>| it should not complicate your script
17:26 < t_dot_zilla>| it doesn't "complicate" it but it adds many lines which i think should be built into a module
17:26 < lirakis>| ...?
17:26 < lirakis>| it is a single line
17:26 < lirakis>| use the $oP as the group
17:26 < lirakis>| and pass it as the group parameter
17:26 < t_dot_zilla>| ohh i see what youre saying
17:27 < t_dot_zilla>| ... does not address the port the
17:27 < lirakis>| i mean .. if you are looking to map sequesntial requests
17:27 < lirakis>| you do have to do tracking
17:27 < lirakis>| we do what you have said - tracking based on callid fromtag
17:27 < lirakis>| with the previously selected $du
17:28 < t_dot_zilla>| lirakis: using htable?
17:28 < lirakis>| we just do it in memory cache
17:28 < lirakis>| cache_store, cache_fetch
17:28 < t_dot_zilla>| i see.
17:28 < razvanc>| t_dot_zilla: so your point is that the dispatcher module should be more "smarter" and "flexible" to allow one to preserve the protocol of the request
17:28 < t_dot_zilla>| yes, protocol and port
17:28 < t_dot_zilla>| only as an option
17:29 < lirakis>| i dont understand the port part
17:29 < p3k4y>| I can't see why the port would be preserved?
17:29 < lirakis>| why do you need to keep the port the same .. your FS boxes will have your own profiles with ports defined
17:29 < t_dot_zilla>| sometimes (with FS) you have multiple SIPprofiles
17:29 < lirakis>| right
17:29 < t_dot_zilla>| if you configure a UA to use one of those sip profiles, it needs to be specified by the port
17:29 < lirakis>| so ... you are preselecting a profile based on port ... then "distributing" again ?
17:29 < t_dot_zilla>| no
17:30 < razvanc>| t_dot_zilla: please add a feature request for this
17:30 < razvanc>| guys, let's stick to the subject
17:30 < lirakis>| oh .. is there a meeting going on
17:30 < lirakis>| sorry
17:30 < t_dot_zilla>| im saying dispatcher should say, "this call came to me on port 5068, let's dispatch it to FS at port 5068"
17:30 < lirakis> | razvanc, sorry i didnt know there was a meeting
17:30 < p3k4y> | OK razvanc - my 2p - it would be useful to have an approved set of cookbooks for different scenarios, which moved beyond just some paragraphs and a scripting example (as in the existing tutorials). e.g. step by step instructions with breakpoints so you can check and test what is going on
17:30 < razvanc>| lirakis: no problem
17:31 < lirakis>| t_dot_zilla, can it till later ;)
17:31 < t_dot_zilla>| okay sorry
17:31 < razvanc>| p3k4y: that's actually something interesting
17:31 <t_dot_zilla> | razvanc: asked if anyone found anything annoying ..
17:32 < razvanc>| t_dot_zilla: no, your point is valid
17:32 < razvanc>| I was just trying to gather as much info as possible
17:32 < t_dot_zilla>| anyway i want to refine my module and publish it. probably as distribute module
17:32 < razvanc>| the solutions can be discussed afterwards
17:32 < p3k4y> | razvanc: for example I recently did some presence stuff which is fairly new to me. There are some tutorials but still it needed some head scratching on my part and I had to cherry pick parts to see my own progress.
17:32 < t_dot_zilla>| perhaps people like dispatcher as it is and another module is needed to address my needs
17:32 < p3k4y>| it would be nice to see a kind of "now you are at this stage and if you do X you should see result Y"
17:33 < lirakis>| hmm ... what do i find annoying about opensips ....
17:33 < razvanc>| p3k4y: so basically you want some tutorials that guide you step by step
17:33 < razvanc>| to build a specific platform
17:33 < lirakis>| ... i think that opensips is well documented - but as p3k4y mentioned many of the concepts are fairly abstracted
17:33 < lirakis>| and it can make it difficult to "connect the dots"
17:34 < p3k4y> | razvanc: no I don't think so… more like I said approved recipes for scenarios with instructions on how they are built
17:34 < lirakis>| and see how a "feature" works completely
17:34 < lirakis>| presence is a great example
17:34 < lirakis>| because there are so many "pieces"
17:35 < t_dot_zilla>| i agree, presence is like a jigsaw puzzle
17:35 < lirakis>| thats a good way to put it
17:35 < p3k4y>| maybe a list could be created and community members could write them and have such recipes approved and moderated by the project guys
17:36 < razvanc>| p3k4y: that would be great
17:37 < p3k4y>| around abstract concepts.. e.g. topology hiding. "What is it, why do I need it, why would I use it, and how do I do it"
17:37 < p3k4y>| "tcp vs udp"
17:37 < razvanc>| I will open a thread on the mailing list to gather the "topics" that require attention
17:37 < p3k4y>| "Handling NAT traversal"
17:38 < p3k4y>| I think they should be more abstract than just module overviews
17:39 < p3k4y>| "How do I load balance a call to multiple boxes" etc. Which could discuss some why's and wherefore's and options and show alternatives
17:40 < p3k4y>| "What on earth is this b2bua and how do I use it"
17:40 < razvanc>| :D
17:42 < razvanc>| I get it, so basically you want these topics detailed and what is the OpenSIPS' aproach to solve different issues
17:43 < razvanc>| as I said, I will open up a thread to gather topics
17:43 < p3k4y>| yes., I think it would be very useful. Especially with breakpoints so people can check their configs and see a result
17:44 < razvanc>| I'm not sure I get this
17:44 < razvanc>| how to do see these "breakpoints"?
17:44 < p3k4y>| :D OK…
17:44 < p3k4y>| so for example if there is a topic to handle NAT traversal.
17:46 < p3k4y>| It may be that the uac_check functions are discussed on the INVITE, and then the user is invited to then run opensips and check they see the log entry saying the check passed or failed, or after the SDP has been changed by rtpproxy, they are invited to inspect and check it happened
17:46 < p3k4y>| so it introduces understanding as to what should be happening and why it happens
17:46 < razvanc>| oh, I understand now
17:47 < p3k4y>| cool :) I would be happy to contribute if required
17:48 < razvanc>| sure, we'll keep you posted
17:48 < razvanc>| let's continue this on the mailing list
17:48 < razvanc>| what about other ideas?
17:48 < p3k4y>| I have to dash off now… Have a good meeting!
17:48 < razvanc>| how would you simplify a user's expierience
17:48 < razvanc>| thanks p3k4y!
17:49 < razvanc>| come on guys, don't be shy :)
17:49 < razvanc>| think about stuff you found hard to understand or deploy when you started to use OpenSIPS
17:55 < razvanc>| anyone?
17:58 < razvanc>| ok then, thank you very much for patricipating
17:58 < razvanc>| and see you all next month
17:59 < alipey>| Thanks Razvan
18:07 < brettnem>| hey all
18:08 < brettnem>| (facepalm) DST grrr
18:10 < razvanc>| brettnem: if you have anything to add, feel free :)
18:11 < brettnem>| is there a transcript yet?
18:11 < brettnem>| I’m on a strong push for async
18:11 < brettnem>| that and maybe some better event handling and rabbit integration :)
18:11 < razvanc>| :)
18:11 < razvanc>| the async is under development
18:12 < razvanc>| I think the last commit made was yesterday
18:12 < razvanc>| yes
18:16 < brettnem>| how close is it? I’d be really excited to test itout
18:18 < razvanc>| I think it's a matter of about two weeks until we'll have the first async command
18:18 < razvanc>| a full functional one
18:18 < razvanc>| because afaik, exec can now be fully async
18:19 < razvanc>| I'll have to check with Bogdan about that, he's working on it
18:28 < brettnem>| does each command need to be re-written as async?
18:29 < razvanc>| brettnem: yes
18:29 < brettnem>| can you do something like add it to db_virtual and bam, async exec for all db backends? :D
18:30 < brettnem>| or what about kam’s implementation where you kind of background the runtime until a call back where you restore the transaction
18:31 < razvanc>| It's not that simple, only to modify the interface and everything will work
18:32 < razvanc>| because each backend has it's own drivers, that have to support async operations
18:32 < razvanc>| some will, some probably not
18:32 < razvanc>| but the way it will work is something similar to what you said
18:32 < razvanc>| we'll start the processing and a callback will be triggered when data is available
18:33 < brettnem>| makes sense
|
Page last modified on January 23, 2015, at 03:59 PM