Login | Register

Community

Community -> PublicMeetings -> 29th of October 2014

When

  • Wednesday, 29th of October 2014, at 17:00 EET (link here)
  • IRC, #opensips channel on Freennode

Topics

WebRTC integration in OpenSIPS

  • The current solution for using WebRTC with OpenSIPS is by using a gateway between them, such as OverSIP
  • The goal of the discussion is to enlist and evaluate the advantages and disadvantages of integrating WebRTC in OpenSIPS
  • At the end of the meeting we should determine whether the current approach offers a complete solution for WebRTC, or we should integrate it directly in OpenSIPS.

Conclusions

TODO


IRC Logs

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