Community -> PublicMeetings -> 26th of November 2014
Simplify 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.
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