[OpenSIPS-Users] Opensips as SIP Proxy and WebRTC Media Gateway

[Alex Megalokonomos]

Hello Bogdan,

First of all, thanks for your time.

Unfortunately my SIP/OpensSIPS skills are what I've managed to learn in the
last couple of days. I am a programmer but I've never had to work on SIP
stuff before.

Frankly to me, both solutions sound equally difficult since I have no idea
where to start. (And to be honest, I expected the first to be simpler)

I found this
https://blog.voipxswitch.com/2015/03/27/kamailio-basic-sip-proxy-all-requests-setup/
and tried to port the config to OpenSIPS since from what I understand
Kamailio and OpenSIPS share a common codebase to an extent but was
unsuccesful.

In your second scenario,  I am not interested in WS->WS calls so that auth
part is not an issue.

So I guess I need the uac_registrar, authorize by IP and usrloc parts.

Any relevant documentation to get me started since I'm still not clear on
what I need to change?

Best regards,
Alex

On Fri, Jun 30, 2017 at 11:29 AM, Bogdan-Andrei Iancu <bogdan at opensips.org>
wrote:

> Hi Alex,
>
> To make a kind of WS<>UDP gateway you need a complete rework of the script
> presented in the tutorial, as it is a completely different SIP scenario.
> Not sure what are your SIP/OpenSIPS skills.
>
> But, there is a simpler alternative . Instead of a GW, you can make
> OpenSIPS as a sub-server for the WS extensions:
>
> Registration handling:
>
> 1) WS extensions register only with OpenSIPS (as right now) -
> authentication is done by OpenSIPS
> 2) OpenSIPS registers the 3 extensions into OmniPCX using the
> uac_registrar
>
> By this, we simply add the uac_registration and you achieve kind of
> decoupled 2 steps registration (with a minimum change in the cfg)
>
>
> Inbound calls:
>
> 1) OmniPCX will send all the calls (from other extensions) for the WS
> extension to OpenSIPS (due the registration via uac_registrar) - this is
> default behavior , so nothing to change
> 2) In OpenSIPS, when receiving calls, you need to authorize (by IP) the
> calls from OmniPCX - and as the current script does, you will handle them
> via the local opensips usrloc -> calls are sent to WS extension
>
>
> Outbound calls:
>
> 1) when you receive a call from a WS extension, you have to check if the
> call is for a local extension (on opensips) or for an extension in OmniPCX
> 2) if call is local (WS to WS) you will do authentication for the call
> 3) if the call is to be sent to OmniPCX, simply send the call to  OmniPCX
> without auth - the auth will be done by OmniPCX as for any other extension
>
>
> Hopefully this will work for you :)
>
> Best regards,
>
> Bogdan-Andrei Iancu
>   OpenSIPS Founder and Developer
>   http://www.opensips-solutions.com
>
> OpenSIPS Bootcamp 2017, Houston, US
>   http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>
> On 06/29/2017 11:54 AM, Alex Megalokonomos wrote:
>
> Hello Bogdan,
>
> Yes, a gateway from WS to UDP (as well as DTLS-SRTP to RTP in order for it
> to work) is exactly what we're looking for.
>
> Unfortunately our Alcatel OmniPCX call center  is a proprietary system
> that only allows for a limited number of SIP extensions (served from what
> appears to be an outdated customised  Kamailio 3.2.2 from what I can tell
> from the headers.
>
> For our normal internal office use it all works fine.
>
> However we have 3 customer support lines that are currently routed to 3
> extensions via OmniPCX.
>
> We want to integrate these to our custom web-based CRM and the best way
> for us to do it is to use something like SIP js to handle and log calls,
> identify calling parties, bring up customer details etc.
>
> Since the kamailio version inside OmniPCX does not support ws/webrtc we
> are looking to set up Opensips in exactly the way you described as a
> gateway/proxy for everything in order to convert the UDP-only sip
> extensions to ws+ webRTC capable ones.
>
> I have used this tutorial http://www.opensips.org/Documentation/Tutorials-
> WebSocket-2-1 to get what I assume is half the work (for RTP proxying)
>  but I havent figured out the rest yet.
>
> Best regards,
> Alex
>
> On Thu, Jun 29, 2017 at 11:43 AM, Bogdan-Andrei Iancu <
> <bogdan at opensips.org>bogdan at opensips.org> wrote:
>
>> Hi Alex,
>>
>> First, some questions regarding the desired topology:
>>     1) the WS end-points should register in OpenSIPS or all the way into
>> Kamailio ?
>>     2) also, the calls from the WS end-points should be all the time sent
>> to Kamailio ?
>>
>> More or less, what I'm asking is : is OpenSIPS suppose to act as a
>> gateway from WS to UDP , but pass all the resulting traffic to Kamailio ?
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>>   OpenSIPS Founder and Developer
>>   http://www.opensips-solutions.com
>>
>> OpenSIPS Bootcamp 2017, Houston, US
>>   http://opensips.org/training/OpenSIPS_Bootcamp_2017.html
>>
>> On 06/28/2017 12:47 PM, Alex Megalokonomos wrote:
>>
>> Hello,
>> We have the following scenario: our office call center is an Alcatel
>> OmniPCX Office setup.
>> This handles most of our needs and also provides 4 SIP extensions.
>> These are provided by what appears to be a Kamailio SIP server v 3.2.2
>> (no webrtc or websockets support)
>> What we would like to do is set up an OpenSIPS instance to handle WebRTC
>> and proxy everything to this Kamailio SIP server.
>> The idea is to allow a web client (using sip js or something similar) to
>> register / make / receive calls as one of the Kamailio extensions.
>> I think half of the configuration is this : http://www.opensips.org/Docu
>> mentation/Tutorials-WebSocket-2-1
>> which I've already completed and indeed, clients can register to opensips
>> and chat/make calls over websockets between them.
>> How do I go about proxying registrations/invites/etc to the kamailio
>> server instead?
>> best regards
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170630/80eecbad/attachment.html>