|
Community |
Community -> PublicMeetings -> 29th of October 2014WhenTopicsWebRTC integration in OpenSIPS
ConclusionsTODO IRC Logs17:02 < razvanc>| Hi all! 17:02 < eric_onsip>| hey razvanc 17:02 < razvanc>| hi eric_onsip 17:02 <@ bogdan_vs>| Hello all 17:02 < Sparky-UK>| Hi all 17:02 < eric_onsip>| hi bogdan_vs 17:03 < eric_onsip>| bogdan_vs, you guys should look at sip.js for your test client vs. sipml5 17:03 < eric_onsip>| ;) 17:03 < eric_onsip>| http://sipjs.com/ 17:03 < razvanc>| thanks for the info eric_onsip 17:03 < eric_onsip>| so does any one else here currently do WebRTC stuff? 17:03 <@ bogdan_vs>| eric_onsip: I do not remember what client we are using right now on opensips.org.... vlad-paiu know more on that :) 17:03 < eric_onsip>| we have production deployment of oversip->opensips+mediaproxy 17:04 <@ bogdan_vs>| ok, so let's start :) ....with webrtc 17:04 <@ bogdan_vs>| we so on opensips.org SIP service.... 17:04 <@ bogdan_vs>| s/so/do 17:05 <@ bogdan_vs>| first I guess we need to see where opensips stands from webrtc perspective 17:05 <@ bogdan_vs>| and then to see where we want to get, right ? :) 17:05 < eric_onsip>| sure 17:06 <@ bogdan_vs>| vlad-paiu did the webrtc tutorial on opensips... 17:06 < alipey>| Where does opensips stand right now? 17:06 < eric_onsip>| so at the moment, opensips is capable of parsing websocket .invalid via headers etc. 17:06 <@ bogdan_vs>| he can give more details on where we are now... 17:06 < eric_onsip>| so it can handle traffic from webrtc clients, just not directly because it lacks support for the transport protocol, websocket/websocket secure 17:07 < eric_onsip>| seem like a reasonable summary bogdan_vs ? 17:08 < alipey>| How about media? 17:08 <@ bogdan_vs>| the main question is what the reason for not heaving the websockets support in opensips.... 17:08 < p3k4y>| is there a reason for not having it ? 17:08 < eric_onsip>| alipey, mediaproxy is capable of doing ICE/stun 17:08 < eric_onsip>| so - websockets are conneciton based 17:09 < eric_onsip>| and like tcp, could be blocking if not done async 17:09 < p3k4y>| opensips has other "non RFC" but more business/product oriented modules like b2bua and call_center so why not websockets 17:09 < eric_onsip>| p3k4y, that is not a relevant argument - websockets are a RFC 17:09 < alipey>| how about rtpproxy? Can that do media for WebRTC? 17:10 < vlad-paiu>| The current approach that we took is to keep the WEBRTC at the border of a SIP platform , and deploy OverSIP at the edge , taking care of converting from websockets to regular UDP 17:10 < eric_onsip>| https://tools.ietf.org/html/rfc6455 17:10 < eric_onsip>| alipey, no - rtpproxy is not ICE aware 17:10 < eric_onsip>| vlad-paiu, right - that is what we have done too 17:10 < eric_onsip>| but 17:10 < vlad-paiu>| basically, a short tutorial is available at http://www.opensips.org/Documentation/Tutorials-WebSocket - OpenSIPS is able to route traffic that is WEBRTC at one / both of the end-points 17:10 < p3k4y>| eric_onsip: it is valid argument… I mean it is not a SIP RFC 17:10 < eric_onsip>| we would love to have opensips do BOTH 17:11 < alipey>| I agree, I don’t see why opensips shouldn’t do websocket 17:11 < eric_onsip>| we are interested in keeping the same architecture 17:11 < eric_onsip>| an edge 17:11 < eric_onsip>| and a more "core" 17:11 < alipey>| Native webRTC support would be a great addition to opensips. 17:12 < eric_onsip>| and have the edge handle the connection to clients - udp, tcp, and ws 17:12 < vlad-paiu>| for handling the media side, in case we want to terminate WEBRTC traffic to a legacy equipment ( eg. PSTN ) available options are either using the webrtc2sip framework ( http://webrtc2sip.org ) or the RTPENGINE rtp proxy ( there is a module that allows OpenSIPS to control that ) 17:13 < alipey>| Can RTPENGINE do NAT? 17:13 < eric_onsip>| we are also very interested in the rtpengine project 17:13 < razvanc>| so basically as you guys pointed this out, we have to split the problem in two 17:13 < MaxMue>| I am not sure but doesn't kamailio already support webrtc (natively) maybe opensips should support it also so people dont choose kamailio instead... :) 17:13 < eric_onsip>| alipey, no rtp relay does "nat" 17:13 < razvanc>| signalling and media 17:13 < alipey>| I also hear RTPENGINE crashes frequently 17:13 < rrevels>| is webrtc2sip still maintained? 17:13 < eric_onsip>| alipey, nat is handled by opensips 17:13 < eric_onsip>| alipey, mediaproxy, and rtpengine are ice capable, and thus work with webrtc 17:14 < razvanc>| let's first take the signaling side, since this should be handled by OpenSIPS 17:14 < alipey>| eric_onsip, both rtpproxy and mediaproxy do nat for media. 17:14 < razvanc>| let's see the advantages and disadvantages of having this in OpenSIPS 17:15 < alipey>| Let’s start with disadvantages? 17:15 < razvanc>| as you wish 17:15 < razvanc>| yes 17:15 < eric_onsip>| the only disadvantage that I see is the same as with TCP ... its a potentially blocking if not done async 17:15 < razvanc>| eric_onsip: true 17:16 < alipey>| Can it not time out? 17:16 < alipey>| It doesn’t have to be blocking? 17:16 < eric_onsip>| it can time out 17:16 < razvanc>| yes, it can 17:17 < vlad-paiu>| in the current ( 1.x ) OpenSIPS architecture, TCP and eventually websocket traffic would be fully blocking 17:17 < alipey>| opensips does TCP, so why not websocket? 17:17 < rrevels>| the webrtc signaling has a requirement to use TLS as well? 17:17 < vlad-paiu>| the future release will handle these things much better, since it will have fully async capabilities in the core 17:17 < eric_onsip>| vlad-paiu, fully blocking? ... i thought that there was some async TCP support in opensips currently? 17:18 < vlad-paiu>| eric_onsip : yes, there currently is support for async tcp ( async_tcp = 1 ) , but it's something exclusively related to tcp, there is no full capabilities of performing whatever other async ops 17:19 < eric_onsip>| right - i know that async ops was some thing discussed in the last meeting 17:20 < razvanc>| another disadvantage I can see is that wr 17:20 < eric_onsip>| wr? 17:20 < razvanc>| I'm continuing mi sentence now ;) 17:20 < eric_onsip>| oh 17:20 < razvanc>| *my 17:21 < razvanc>| another disadvantage I can see is that we need to do a mapping between webrtc protocol and SIP 17:21 < eric_onsip>| im not sure i follow 17:22 < eric_onsip>| webrtc specifies no "protocol" ... so you choose to do SIP ... and you work with opensips 17:22 < eric_onsip>| or ... you choose some custom protocol and go do some thing else 17:22 < joseph-onsi>| razvanc, eric_onsip: https://tools.ietf.org/html/rfc7118 17:23 < eric_onsip>| razvanc, can you elaborate? 17:23 < eric_onsip>| or are you talking about the interop details as covered in the rfc draft that joseph-onsip posted 17:23 < razvanc>| no, I was thinking more on the internal stuff 17:24 < p3k4y>| wss <> udp ? 17:24 < razvanc>| so for now we support mainly TCP, TLS and UDP 17:25 < razvanc>| we'd also have to add support for Websockets 17:25 < alipey>| Let’s look at it in a different way: 17:25 < alipey>| What would need to be done in opensips to support webrtc? 17:25 < alipey>| Let’s make a list for that 17:25 < eric_onsip>| alipey,lets finish this existing discussion 17:26 < eric_onsip>| razvanc, so after the ws/wss transport is added, what other internals need to be updated 17:26 < razvanc>| we first need an HTTP parser 17:27 < razvanc>| implement the Websocket transport as eric_onsip said 17:27 < razvanc>| update current code to handle this new transport method 17:28 < razvanc>| I am thinking of force_send_socket() functions & co 17:28 < MaxMue>| Have a nice day/evening, i am leaving now. 17:29 < vlad-paiu>| we have GRUU support in the registrar / usrloc modules, we'd also have to implement the outbound support ( as per RFC 5626 ) 17:30 < eric_onsip>| vlad-paiu, right for tracking the connections to clients 17:32 < vlad-paiu>| eric_onsip : right. also some tinkering needed with the PATH module and across all the places where transport is involved in the OpenSIPS code.. what we've just listed here would be the biggest things, I think 17:32 < eric_onsip>| but ... it could be said that RFC5626 should be on for TCP as well no? 17:33 < eric_onsip>| vlad-paiu, yea .. path ... usrloc / registrar 17:33 < eric_onsip>| so yes - clearly it is a non-trivial amount of work 17:34 < vlad-paiu>| eric_onsip : true, but RFC 7118 is the first place where it's explicitly mentioned as mandatory, since HTTP clients impose their limits of not being able to tell any IP at all 17:34 < eric_onsip>| vlad-paiu, gotcha 17:34 < eric_onsip>| i know there are concerns that opensips as a project does not want to become a "frankenstein" 17:35 < eric_onsip>| after enumerating the general changes that think need to be done - just to add WS/WSS transport ... does it "feel" like it can be done cleanly 17:35 < eric_onsip>| so that it is just another transport protocol 17:35 < eric_onsip>| without otherwise ... making things messy? 17:36 < eric_onsip>| and ... does it make sense to do before async operations 17:36 < razvanc>| yes, it seems to map to "traditional" transport protocol 17:36 < eric_onsip>| ok - that much is good at least 17:36 < razvanc>| more or less these two independente 17:37 < eric_onsip>| well i was suggesting that ... having blocking websockets might not be useful 17:37 < eric_onsip>| i am not sure that we could actually use a blocking websocket implementation 17:38 < eric_onsip>| we'd have to have edge proxies with a ton of processes to protect against blocking issues 17:38 < razvanc>| yes, having them done asynchronous would definitely be better 17:39 < eric_onsip>| so ... in the scope of the opensips project planning... are async ops "under development" ... or is that left to the 2.1 series ? 17:39 < razvanc>| eric_onsip: yes, they are under develpment 17:40 < eric_onsip>| so ... is it worth it to work on WS in a blocking implementation currently? would that work be easily portable to the async ops? 17:40 < razvanc>| and they are developed in the 2.1 branch 17:40 < razvanc>| which is the next release 17:40 < eric_onsip>| right 17:41 < razvanc>| probably porting it to async ops would not make sense 17:41 < razvanc>| we should do it right from the begining :) 17:41 < eric_onsip>| ok - that is what i was getting at 17:42 < eric_onsip>| ... is it possible to do it async in the current opensips implemenation ? 17:42 < eric_onsip>| or would it have to wait till async ops are "done" then developed on top of that frame work 17:42 < eric_onsip>| b/c ... i would also advocate doing "it right from the beginning" 17:43 < razvanc>| that's what I was saying 17:43 < eric_onsip>| ok 17:43 < eric_onsip>| cool 17:43 < razvanc>| we should do them after the async operations are "done" 17:43 < razvanc>| ok, moving on, let's see what are the advantages of implementing WebRTC in OpenSIPS 17:44 < razvanc>| probably the first one is that we will have everything unified 17:44 < eric_onsip>| yeah 17:44 < eric_onsip>| well we LOVE using opensips as our registrar, and for all our UDP stuff 17:45 < eric_onsip>| and we would really like to be able to have all our endpoints running through the same "infrastructure" 17:45 < eric_onsip>| opensips edge proxies to handle all user agents would be great 17:46 < razvanc>| well, yes, that is something we agree 17:46 < eric_onsip>| i think ... from a project perspective it will keep opensips relevant and on the forefront 17:47 < p3k4y>| it will open up opensips to a wider audience, if "WebRTC" is supported natively it will attract people to look at it for their solution instead of putting together something less elegant 17:47 < p3k4y>| and as eric_onsip says WebRTC does seem to be the thing everyone keeps talking about for the last few years 17:48 < razvanc>| that's also true 17:49 < rrevels>| that would seem to be a key point. its one thing to talk about it a lot (because it seems useful) and another to really have it take off as a communication method. 17:49 < eric_onsip>| the last year has been huge for webrtc 17:49 < eric_onsip>| the browsers have really gotten going 17:49 < eric_onsip>| and the support is really there now 17:49 < rrevels>| so far, test calls, call centers, and google hangouts use it a lot. 17:50 < rrevels>| when people get ready to REALLY make a call though, they still pick up a handset or cell phone 17:50 < p3k4y>| … and we all know opensips has a call_center module, right :) 17:50 < razvanc>| indeed we do :) 17:51 < eric_onsip>| rrevels, webrtc is still a very "new" technology and is in the "Early adopter" stage 17:51 < eric_onsip>| that said - its a technology that is maturing, and growing 17:51 < eric_onsip>| its in the native webview for android 17:51 < jarrod>| errr 17:51 < eric_onsip>| its going to have more mobile presence 17:51 < jarrod>| what happened to lirakis 17:51 < eric_onsip>| jarrod, ? 17:52 < eric_onsip>| i am lirakis 17:52 < p3k4y>| tbh people are finding ways round opensips not having webrtc. Who would have heard of oversip if it was not used for wss <> udp, so I think there is demand for this as I hear about oversip so much - but only in the context of a front for opensips 17:52 < jarrod>| who is this imposter with a different nick 17:52 < jarrod>| ;) 17:52 < eric_onsip>| jarrod, heh - just like people to know who i am for the meeting/discussion 17:52 < jarrod>| oh, the meeting, *backs away slowly* 17:53 < eric_onsip>| so yeah ... i think the biggest argument for having webrtc in opensips is actually keeping the project relevant, and attractive to more people 17:53 < eric_onsip>| i mean - we would love to have async WS/WSS support for our own purposes at onsip 17:54 < razvanc>| well, we could do that by focusing our resources on other interesting features, like async stuff 17:54 < razvanc>| but let's continue with our topic now :) 17:54 < razvanc>| so it would be nice to have Websockets transport in OpenSIPS 17:54 < alipey>| Please also consider that this will take a while to be implemented, tested and debugged in opensips, so if WebRTC happens to be a thing, you wouldn’t want to be left behind. 17:55 < razvanc>| but in order to keep things unified 17:55 < rrevels>| well and maybe having a configuration / routing model you are used to working with to implement webtrc might be a good thing too. having to know a lot about a lot of different software applications to make calls work kinda sucks. 17:55 < razvanc>| we also need to find a solution for the media 17:55 < eric_onsip>| right - so ... we currently use mediaproxy 17:55 < eric_onsip>| and it "works" 17:55 < p3k4y>| is that "works" or *works* 17:55 < eric_onsip>| i believe rtpengine is more the "future" 17:56 < eric_onsip>| p3k4y, it works, but it is not full featured 17:56 < eric_onsip>| its like a bare minimum implemenation 17:56 < p3k4y>| ah 17:56 < vlad-paiu>| eric_onsip : mediaproxy @ ag projects ? does it currently support SRTP ? 17:57 < eric_onsip>| vlad-paiu, http://mediaproxy.ag-projects.com/ 17:57 < eric_onsip>| we use the mediaproxy module to inject ICE candidates with low priority 17:57 < eric_onsip>| it does the ice/stun "handshake" 17:58 < eric_onsip>| dtls/srtp is negotiated between endpoints 17:58 < vlad-paiu>| eric_onsip : ok, I understand 17:58 < eric_onsip>| vlad-paiu, it does NOT do dtls/srtp decryption 17:58 < eric_onsip>| we use freeswitch for that 17:58 < eric_onsip>| if we need to connect to a non-dtls capable endpoint 17:59 < vlad-paiu>| ok. so now we have oversip + opensips + mediaproxy + freeswitch :) that's a complex architecture 17:59 < eric_onsip>| yea 17:59 < eric_onsip>| heh 17:59 < eric_onsip>| especially when you throw parallel forking in 17:59 < eric_onsip>| ;) 17:59 < p3k4y>| I need to leave unfortunately, enjoy the rest of the meeting 18:00 < eric_onsip>| razvanc, so what "solution" are you looking for as far as media is concerned 18:00 < razvanc>| ok, thanks for attendin p3k4y 18:00 < eric_onsip>| i ask b/c webrtc <-> webrtc user agents media is supported currently with mediaproxy as i said 18:00 < razvanc>| eric_onsip: well I was thinking of 3 different directions 18:00 < eric_onsip>| are you thinking of a dtls-srtp decrypting rtp proxy to interop with legacy / non-dtls uas 18:01 < eric_onsip>| *ua 18:01 < razvanc>| all of them need extra devel 18:01 < razvanc>| 1. add SRTP support in media proxy 18:01 < razvanc>| 2. add SRTP + ICE in rtpproxy 18:01 < eric_onsip>| so when you say ... add srtp support 18:01 < razvanc>| 3. use rtpengine :) 18:02 < eric_onsip>| lol 18:02 < eric_onsip>| i vote #3 18:02 < eric_onsip>| well i say that - i havent used it yet 18:02 < eric_onsip>| but mediaproxy is the bare minimum 18:02 < razvanc>| well, me neither, but as they advertised, it seems it can handle this 18:03 < Sparky-UK>| I vote RTP Engine, I use it on a cluster of 10 and its reasonably stable 18:03 < eric_onsip>| Sparky-UK, do you use it to decrypt DLTS-SRTP and relay plain RTP ? 18:03 < eric_onsip>| i am very interested in that functionality 18:03 < Sparky-UK>| just plain RTP at present 18:03 < vlad-paiu>| eric_onsip : well, currently we have experience with RTPProxy and Mediaproxy, they are very fast and stable. so I would choose one of them *if* they were to get SRTP support 18:03 < eric_onsip>| so there would be some module work 18:04 < eric_onsip>| vlad-paiu, i agree - we use both, previously rtpproxy 18:04 < eric_onsip>| now mediaproxy 18:04 < eric_onsip>| but 18:04 < vlad-paiu>| maybe saghul can give is more inside info about plans on mediaproxy 18:04 < eric_onsip>| mediaproxy has a very minimal ice implemenation 18:04 < vlad-paiu>| *give us 18:04 < eric_onsip>| but yes if saghul can let us know if there are any plans for mediaproxy that would be good for this discussion 18:05 < saghul>| sorry, I just entered the channel :-/ plans for what? 18:05 < eric_onsip>| mediaproxy and SRTP (SDES & DTLS ) 18:05 < eric_onsip>| for further WebRTC capability 18:07 < eric_onsip>| does the current opensips rtpengine module implement the ability to do SRTP with rtpengine? 18:07 < saghul>| yes, it's in the roadmap, though I cannot give an ETA :-/ 18:07 < SylkServer>| Adrian G <sip:ag@sip2sip.info>: <p style="margin: 0.0px 0.0px 0.0px 0.0px"><font face="Helvetica" size="3" style="font: 12.0px Helvetica">/\</font></p> 18:08 < eric_onsip>| so .. back to the topic of ... a "media solution" 18:08 < eric_onsip>| lets assume rtpengine does what it says 18:08 < vlad-paiu>| eric_onsip : http://www.opensips.org/html/docs/modules/1.12.x/rtpengine.html#rtpengine.f.rtpengine_offer , see the RTP, SRTP, AVP, AVPF , so yes, that's possible 18:08 < eric_onsip>| does opensips need to do any further development to make it "work" completely 18:09 < eric_onsip>| ah i see 18:09 < eric_onsip>| and it has the same API offer/ answer etc 18:09 < eric_onsip>| i like that better than the mediaproxy "engage" mechanism 18:09 < eric_onsip>| which provides less control 18:12 < razvanc>| does any of you have experience with rtpengine doing DLTS-SRTP to RTP transcoding? 18:13 * | eric_onsip knows what ill be working on this weekend 18:13 < razvanc>| :) 18:14 < razvanc>| so nobody can confirm this actually works as advertised? 18:14 < vlad-paiu>| Sparky-UK mentioned it above 18:15 < razvanc>| I am asking this because the module was not ported by us 18:15 < eric_onsip>| i was going to ask ... who wrote the module 18:15 < eric_onsip>| lol 18:15 < alipey>| RTPENGINE works but it crashes time to time 18:15 < razvanc>| and those guys don't really offered to support the module :) 18:15 < Sparky-UK>| I use standard RTP through it, performs much better than RTP Proxy 18:15 < razvanc>| alipey: the module or the media rely 18:15 < razvanc>| *relay? 18:16 < alipey>| the media relay 18:16 < Sparky-UK>| the module was ported by Peter Lemenkov and the rtp engine was Richard Fuchs 18:16 < razvanc>| Sparky-UK: just out of curiosity, have you done some tests? 18:16 < Sparky-UK>| I have it running in production right now 18:16 < eric_onsip>| i assume its doing the kernel level ip forwarding 18:16 < razvanc>| I mean do you have some numbers :)? 18:17 < eric_onsip>| yeah thats what its doing - similar to mediaproxy 18:17 < Sparky-UK>| at peak I have about 500 channels per rtpengine box 18:17 < eric_onsip>| im guessing it can do TONS of traffic in that way 18:17 < eric_onsip>| bandwidth will likely be your limit rather than what rtpengine (or mediaprox) is capable of really 18:17 < eric_onsip>| if you use the kernel ipforwarding 18:18 < Sparky-UK>| yes, I am sure it can do more, I want to run at low utilisation for performance reasons though 18:18 < rrevels>| i dont think that allows for transcoding 18:19 < eric_onsip>| no - not if you are doing pure ipforwarding 18:19 < eric_onsip>| i was saying if you are just running plain "rtp" 18:19 < Sparky-UK>| No it does not do transcoding, but you couldnt really do that kernal level either, so you have for your performance / functionality trade off 18:19 < eric_onsip>| which is all we can compare with rtpproxy 18:19 < rrevels>| it will be much slower and resource intensive if it supports transcoding and will break the .. right break the ipforwarding at kernel level stuff 18:20 < eric_onsip>| ok - so real take away here 18:20 < eric_onsip>| we dont know what rtpengine can really do 18:20 < eric_onsip>| and we should find out 18:20 < eric_onsip>| if it can do what it says it can 18:20 < rrevels>| im really interested in looking at it in the near future though. thanks for bringing it to my attention. 18:21 < eric_onsip>| its a near complete solution for webrtc media with opensips 18:21 <@ bogdan_vs>| at some point, something useful will be have a comparison as feature set and as performance 18:21 < vlad-paiu>| eric_onsip : agreed, let's all look more into it 18:21 < Sparky-UK>| https://github.com/sipwise/rtpengine/ - features 18:21 <@ bogdan_vs>| between the 3 candidates 18:23 <@ bogdan_vs>| it looks like the most important things were addressed ... 18:24 <@ bogdan_vs>| what I personally wanted to see is what is other people opinion on webrtc 18:24 <@ bogdan_vs>| the community input ;) 18:24 < eric_onsip>| well - you got our opinions ... what is yours and the other devs ? 18:24 < eric_onsip>| haha 18:25 <@ bogdan_vs>| somewhere in the middle....like doing or not webrtc directly in opensips 18:25 < Sparky-UK>| I think that its something that should be developed "at some point", but I dont know if its the highest priority, I am saying this without really knowing what is on the development list. 18:25 <@ bogdan_vs>| at the end of the day everything is about the balance between resources and what to do 18:25 < eric_onsip>| yep 18:26 < joseph-onsi>| as someone who's primary work has been with webrtc endpoints for sip, it feels like it has the potential to get quite big 18:26 <@ bogdan_vs>| Sparky-UK: true 18:26 < eric_onsip>| there are things that need to happen before webrtc can happen any way - primarily async ops 18:26 < joseph-onsi>| having it in the major browsers is a huge plus 18:26 < Sparky-UK>| Quick question, how difficult is it to use 3rd party solutions to accomplish this? 18:26 < eric_onsip>| Sparky-UK, 3rd party solutions? like oversip -> opensips to get WS/WSS support 18:26 <@ bogdan_vs>| Sparky-UK: using oversip -> you can do it now 18:27 < eric_onsip>| it really depends on the complexity of your network and usecase 18:27 < Sparky-UK>| yes, but is it an easy lightweight thing that provides a complete solution? 18:27 < eric_onsip>| no 18:27 < eric_onsip>| its at least 3 pieces of software 18:27 < eric_onsip>| if not 4 18:27 <@ bogdan_vs>| for a core system, webrtc is not on the top of the list. but we need to consider the large usage of OpenSIPS in the edge systems 18:28 < eric_onsip>| yeah thats really all im thinking of - but currently opensips is not usable as an edge for anything but UDP 18:28 < Sparky-UK>| how many people have a requirement for WebRTC right now? 18:28 < eric_onsip>| because it lacks REAL async tcp 18:28 <@ bogdan_vs>| eric_onsip: also TCP, TLS or IPV6 ;) 18:29 < eric_onsip>| but - we would love to get full async tcp and use it as an edge for that even 18:29 <@ bogdan_vs>| eric_onsip: true by at a certain point 18:29 < eric_onsip>| right now we have to pump our TCP/TLS connections through oversip 18:29 < eric_onsip>| same as with websocket 18:30 < rrevels>| i did see one real world application that sparked my interest enough to try it out the other day ; an email that said blah blah blah - im at my desk if you want to discuss hit the link to be connected to my phone. 18:30 < eric_onsip>| so to your point bogdan_vs - thinking about the large usage of opensips in the edge 18:30 < eric_onsip>| i think that the async support is much more important 18:30 <@ bogdan_vs>| eric_onsip: if you have any issues with the TLS/TCP stuff (aside async), I will be glad to get into details .. 18:30 <@ bogdan_vs>| (off this discussion, of course) 18:30 < eric_onsip>| bogdan_vs, no issues - just the blocking 18:30 < rrevels>| I hit the link just because I could and we got connected and spoke more. 18:31 <@ bogdan_vs>| rrevels: the old approach is the web click to call.... 18:31 < alipey>| bogdan_vs, WebRTC might be in to becoming something, you don’t want opensips to fall behind 18:31 < Sparky-UK>| rrevels: nice :) 18:31 <@ bogdan_vs>| it works, but you need your sip phone somewhere 18:32 <@ bogdan_vs>| alipey: true 18:32 < rrevels>| : > 18:32 < alipey>| I have seen people moving to Kamailio just for the websocket support 18:32 < eric_onsip>| how "Real" is the support for websocket in kamailio? ... 18:33 <@ bogdan_vs>| :( 18:33 < eric_onsip>| and i agree with that 18:33 < eric_onsip>| i mean 18:33 < alipey>| It is possible to get to work with oversip and other things, but most people would rather to have everything in one place 18:33 < eric_onsip>| we wont do that 18:33 < eric_onsip>| ha ha 18:33 <@ bogdan_vs>| to be honest, I was afraid of doing some ugly hack into OpenSIPS (the Frankenstein stuff), just to claim you have webrtc 18:34 < eric_onsip>| bogdan_vs, and im glad you didnt dot that! 18:34 < eric_onsip>| i was under the impression that is what kamailio did 18:34 <@ bogdan_vs>| without a proper approach, better drop it... 18:34 < alipey>| bogdan_vs, I agree. You’d want to do it right 18:34 < eric_onsip>| this is why we use opensips 18:34 < eric_onsip>| heh 18:34 <@ bogdan_vs>| but with the 2.1 we have the best foundation for that 18:34 <@ bogdan_vs>| thank you eric_onsip 18:35 < eric_onsip>| yeah - i think that is the "right" approach ... lay the solid foundation 18:35 < alipey>| 2.1 will be in 2015, right? 18:36 < razvanc>| alipey: it's not scheculed yet 18:36 < razvanc>| but probably that's when it will be released 18:36 < razvanc>| because it will take a few months to devel, a few more to test 18:36 < Sparky-UK>| is the 1.11.X or 1.1X branch going to be continued for a bit, or is all development focusing on 2.1 now? 18:37 <@ bogdan_vs>| 1.11 is LTS, so it will be out for at least 2 years 18:37 <@ bogdan_vs>| fixed and maintained, but not developed any more 18:37 <@ bogdan_vs>| 2.1 stable is scheduled for feb 2015 18:38 < eric_onsip>| exciting :) 18:38 < Sparky-UK>| how much script compatibility is there going to be when moving to 2.1, as I am expecting alot to change. 18:38 <@ bogdan_vs>| if things are going according to plans ;) 18:39 <@ bogdan_vs>| Sparky-UK: from scripting perspective, the backward compatibility will be highly preserve (maybe 10% changes) 18:39 < Sparky-UK>| ok thats good :) 18:39 <@ bogdan_vs>| ok, so we can declare the meeting closed...... 18:40 < rrevels>| Have a good one everyone. I learned a lot. 18:40 <@ bogdan_vs>| it was a good discussion...thank you for everyone who contributed on this 18:40 < razvanc>| thank you guys 18:40 < eric_onsip>| thanks to all the devs! 18:40 <@ bogdan_vs>| just keep close for the news 18:40 < eric_onsip>| will do hehe 18:40 <@ bogdan_vs>| there are many things to be released for 2.1 ;) 18:40 < joseph-onsi>| thanks everyone, was nice to see progress on this 18:41 < Sparky-UK>| thank you 18:41 < alipey>| Thanks you everyone. Good meeting 18:41 < razvanc>| we'll parse again the entire meeting logs and let you know when we reach a conclusion for this 18:41 < eric_onsip>| if i get time to test rtpengine - i will let you guys know what i find 18:41 <@ bogdan_vs>| sure ERic 18:41 < alipey>| Maybe we can have a meeting for rtp/media proxy solutions one time 18:41 < razvanc>| yes, please run some tests and let us see the numbers :) 18:41 <@ bogdan_vs>| alipey - that will be interesting 18:41 < eric_onsip>| razvanc, im moslty interested in whether or not it can do DTLS-SRTP - > RTP 18:41 < eric_onsip>| less about how much it can do 18:42 < eric_onsip>| since it can operate with a pool of servers 18:43 <@ bogdan_vs>| just as a note : it will be a follow-up email about this meeting 18:43 <@ bogdan_vs>| for everyone to know what was discussed here 18:43 <@ bogdan_vs>| have a nice rest of the day ;) |
Page last modified on October 29, 2014, at 06:50 PM