Re: [OpenSIPS-Users] Forking Non-INVITE Requests

[Bogdan-Andrei Iancu]

Hi Chad,

I would say the t_replicate() is what you are looking for :
http://www.opensips.org/html/docs/modules/2.3.x/tm.html#treplicate

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 07:31 PM, Chad Attermann wrote:

Hi All,

I would like to be able to “broadcast” some non-INVITE requests (like 
NOTIFY and MESSAGE) to multiple registered endpoints.  The problem 
with using parallel forking is that the request is not reliably 
delivered to all registered endpoints since retransmission of the 
request stops after the first success response is received.  What I 
need is some hybrid of parallel and serial forking, where requests to 
all registered are sent at once, but each is treated as a separate 
transaction so that the message is sent (or at least attempted) 
reliably to each endpoint.


This sort of situation is mentioned in the docs for the TM module…

"UAC--it is a very simplistic code which allows you to generate your 
own transactions. Particularly useful for things like NOTIFYs or 
IM gateways.”


… but there is no mention of *how* to use it.  I’m sure there is 
probably a simple script for this, but I haven’t had any success 
searching the mailing list or the Internet at large for details.  I 
would appreciate if anybody could provide details or a sample script 
demonstrating how to create a separate transaction for each branch.


Thanks!


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[Bogdan-Andrei Iancu]

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 
mailto:bog...@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/Documentation/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 list
Users@lists.opensips.org 
http://list

Re: [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 
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 <
> bog...@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 

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

[Bogdan-Andrei Iancu]

I checked the script you mentioned and it does not help you - it has 
only UDP (no WS), it is really basic and it does not handle any REGISTER 
stuff, which is the trickiest - see

https://blog.opensips.org/2016/12/13/how-to-proxy-sip-registrations/
or
https://blog.opensips.org/2016/12/20/mid-registrar-scalable-registration-and-call-forking/

Maybe you can start with handling REGISTERs - what you need (on top of 
the script from the WSS tutorial) is to add this uac_registrant, to have 
the WS extensions registered into OmniPCX with a contact URI pointing 
back to OpenSIPS IP:

http://www.opensips.org/html/docs/modules/2.3.x/uac_registrant.html

Let me know if you get stuck in this first step.

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/30/2017 12:22 PM, Alex Megalokonomos wrote:

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 
mailto:bog...@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 

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

[Alex Megalokonomos]

I think I set up uac_registrant correctly.

I can dial out from a ws client and the ws extension rings from outside
calls.

However:
 a) on incoming calls, when ws client accepts, there is no sound and the
line is dropped after 30 secs or so
b) on outgoing calls, when the called extension accepts the ws client
immediately responds with 401 Unauthorised and then BYE

b) I believe is what you mentioned here "In OpenSIPS, when receiving calls,
you need to authorize (by IP) the calls from OmniPCX "

How do I do this?

and a) seems to be rtp proxy related since I see the following errors in
the logs¨

ERROR:rtpengine:rtpe_function_call: proxy replied with error: Unknown
call-id

and

no matching transaction

On Fri, Jun 30, 2017 at 2:27 PM, Bogdan-Andrei Iancu 
wrote:

> I checked the script you mentioned and it does not help you - it has only
> UDP (no WS), it is really basic and it does not handle any REGISTER stuff,
> which is the trickiest - see
>  https://blog.opensips.org/2016/12/13/how-to-proxy-sip-registrations/
> or
>  https://blog.opensips.org/2016/12/20/mid-registrar-
> scalable-registration-and-call-forking/
>
> Maybe you can start with handling REGISTERs - what you need (on top of the
> script from the WSS tutorial) is to add this uac_registrant, to have the WS
> extensions registered into OmniPCX with a contact URI pointing back to
> OpenSIPS IP:
> http://www.opensips.org/html/docs/modules/2.3.x/uac_registrant.html
>
> Let me know if you get stuck in this first step.
>
> 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/30/2017 12:22 PM, Alex Megalokonomos wrote:
>
> 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 <
> bog...@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
>> ap

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

[Bogdan-Andrei Iancu]

Good, there is some progress :).

On the incoming calls, if the WS get's the call, we can park the part 
with the auth (it seems your opensips script is accepting calls from 
unknown sources...we can address this security hole later.


So, if a call drop after 30 secs it usually means there is no ACK. Can 
you make a mgrep capture on OpenSIPS to grab the whole call flow ? (grab 
5060 and 80 ports)


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/30/2017 04:52 PM, Alex Megalokonomos wrote:

I think I set up uac_registrant correctly.

I can dial out from a ws client and the ws extension rings from 
outside calls.


However:
 a) on incoming calls, when ws client accepts, there is no sound and 
the line is dropped after 30 secs or so
b) on outgoing calls, when the called extension accepts the ws client 
immediately responds with 401 Unauthorised and then BYE


b) I believe is what you mentioned here "In OpenSIPS, when receiving 
calls, you need to authorize (by IP) the calls from OmniPCX "


How do I do this?

and a) seems to be rtp proxy related since I see the following errors 
in the logs¨


ERROR:rtpengine:rtpe_function_call: proxy replied with error: Unknown 
call-id


and

no matching transaction

On Fri, Jun 30, 2017 at 2:27 PM, Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


I checked the script you mentioned and it does not help you - it
has only UDP (no WS), it is really basic and it does not handle
any REGISTER stuff, which is the trickiest - see
https://blog.opensips.org/2016/12/13/how-to-proxy-sip-registrations/

or

https://blog.opensips.org/2016/12/20/mid-registrar-scalable-registration-and-call-forking/



Maybe you can start with handling REGISTERs - what you need (on
top of the script from the WSS tutorial) is to add this
uac_registrant, to have the WS extensions registered into OmniPCX
with a contact URI pointing back to OpenSIPS IP:
http://www.opensips.org/html/docs/modules/2.3.x/uac_registrant.html


Let me know if you get stuck in this first step.

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/30/2017 12:22 PM, Alex Megalokonomos wrote:

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
mailto:bog...@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 

Re: [OpenSIPS-Users] SIP URI User Parameters

[Ben Newlin]

Bogdan,

Sorry for the delayed response, I am having some trouble reproducing this in a 
local test environment. Currently it is only occurring in our live environment. 
I do have some clarifications and answers to your questions:


· The npdi parameter is not present in $ru in the failure route when 
the response is 500. It is present when the response is 503 or 408. I haven’t 
tested any other responses. This is not terribly important to my issue, simply 
an observation.


· We are sometimes using do_routing to populate a list of carriers, but 
other times we get the list from our own DB query. We use route_to_carrier to 
send the call to each carrier in sequence. This is because we don’t always use 
do_routing, but also because we wish to skip to the next carrier, not just the 
next gateway, on certain response codes and the normal do_routing mechanism 
doesn’t allow that.


· The issue actually does not happen when use_next_gw is called. I was 
wrong about that. You were right that seems to be a straight URI copy. The 
issue occurs when we skip use_next_gw or there are no gateways left and we call 
route_to_carrier for the next carrier with the parameter present in $ru.


· I printed out the dr_ruri avp after the call to route_to_carrier and 
it shows the npdi parameter moved to the end, not after the user:
“sip:+1551...@gw2.com;npdi=yes”

Also, I should have mentioned that we are running 1.11.11. I’m still working to 
try to reproduce locally.

Ben Newlin

From: Bogdan-Andrei Iancu 
Date: Thursday, June 29, 2017 at 4:38 AM
To: OpenSIPS users mailling list , Ben Newlin 

Subject: Re: [OpenSIPS-Users] SIP URI User Parameters

Hello Ben

I understand you add the npdi useraname parameter after performing the initial 
do_routing() - if you do it in request or branch route is not relevant (for 
RURI changes) as RURI is anyhow a per-branch value.
In failure route, when resuming, you will get the RURI of the winning branch ( 
the one which was selected to be sent back to caller), so you see the npdi 
param.

So far so good. And now you do use_next_gw() in failure route and you get 
"sip:+1551...@gw2.com;npdi" directly, without any another npdi addition ? 
I'm asking, as use_next_gw() does a full RURI replacement (it doesn;t care what 
is the existing RURI).

Could you also do an
xlog("DR ruris are <$(avp(___dr_ruri__)[*])>\n");
right after do_routing() ?

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 11:41 PM, Ben Newlin wrote:
Hi,

We have run into an issue with OpenSIPs’ handling of user parameters in SIP 
URIs with Dynamic Routing module. When a parameter is added to a SIP URI user 
part, any subsequent modification of the URI by DR module results in the 
parameter being moved to be a URI parameter.

For example, starting with $ru of “sip:+1551...@gw1.com”, if we modify it 
this way:

$rU = $rU + “;npdi”;

then we get a new $ru of “sip:+1551212;n...@gw1.com”.

We send this call out and if it returns an error we want to use the next 
available gateway.

The Request URI in the failure route is still “sip:+1551212;n...@gw1.com”.

Note: this is the case even when the “;npdi” parameter was added in a branch 
route, which I didn’t expect. I thought changes made in a branch route were 
isolated to that branch.

Now from the failure route when we call use_next_gw the npdi parameter is moved 
and the URI is now “sip:+1551...@gw2.com;npdi”. This is not correct.

Is there some other way to properly manipulate SIP URI user parameters or is 
this a bug?


Thanks,

Ben Newlin




___

Users mailing list

Users@lists.opensips.org

http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Pending OpenSIPS minor releases: Last minute bug fixes!

[Bogdan-Andrei Iancu]

As next week we will release the OpenSIPS Control Panel version related 
to OpenSIPS 2.3 , we will also change the versioning policy for OpenSIPS 
Control Panel


Why? we what to create a tight and direct relation between the version 
of OpenSIPS Control Panel and the corresponding version of OpenSIPS.


Right now, OpenSIPS Control Panel 6.2 matches OpenSIPS 2.2and as you 
can see, this is not so obvious when looking at the version numbers  - 
unless you go and look into README files.


So, from now on, the OpenSIPS X.Y will match the OpenSIPS Control Panel 
N.X.Y , where N is a major version specific to Control Panel.


Shortly, OpenSIPS 2.3 will have OCP 7.2.3 ; and future OpenSIPS 2.4 will 
have OCP 7.2.4; and if we come up with some improvements in OCP and we 
need to bust the release, we will have 8.2.4 (OCP version 8 matching 
OpenSIPS 2.4)


So, expect OpenSIPS Control Panel 7.2.3 to be the next release on 
Wednesday ;)


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/28/2017 07:09 PM, Liviu Chircu wrote:

Hi, all!

We have planned an OpenSIPS minor release bump for 2.2 and 2.3 - due 
next week, July 5th.The headline of this release, however, is the 
long-awaited 2.3-compatible release for the OpenSIPS Control Panel!


If you have any pending GitHub issues / mailing list bug threads 
concerning OpenSIPS 2.2+ or the Control Panel which are yet to be 
resolved, this would be a good time to bump them!


Best regards,




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [Blog] Traffic balancing – load, weights, round robin ??

[Mundkowsky, Robert]

Yeah, saw that. Looks real good.

Robert Mundkowsky

-Original Message-
From: Bogdan-Andrei Iancu [mailto:bog...@opensips.org]
Sent: Wednesday, June 28, 2017 3:43 PM
To: Mundkowsky, Robert ; OpenSIPS devel mailling list 
; OpenSIPS users mailling list 

Cc: busin...@lists.opensips.org; n...@lists.opensips.org
Subject: Re: [OpenSIPS-Users] [Blog] Traffic balancing – load, weights, round 
robin ??

Hi Robert,

See the new blog post about how a balancer should be inserted into the SIP flow:

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fblog.opensips.org%2F2017%2F06%2F28%2Ftraffic-balancing-the-insertion-into-the-sip-flow%2F&data=02%7C01%7Crmundkowsky%40ets.org%7C82012f772567476f77a308d4be5ddf7d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C63634275029125&sdata=xseFlfBeoa0hoS1sp01WsrFIeO71etgACzp9BPj6KcY%3D&reserved=0

Thanks for the idea of the post ;)

Bogdan-Andrei Iancu
   OpenSIPS Founder and Developer
   
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.opensips-solutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7C82012f772567476f77a308d4be5ddf7d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C63634275029125&sdata=SfQLAan3rPA%2FfN%2Ftyr8c0WfvFKQ%2BAv1P2rGvQLlYig0%3D&reserved=0

OpenSIPS Bootcamp 2017, Houston, US
   
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopensips.org%2Ftraining%2FOpenSIPS_Bootcamp_2017.html&data=02%7C01%7Crmundkowsky%40ets.org%7C82012f772567476f77a308d4be5ddf7d%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C63634275029125&sdata=M6Ms4t4ks5P3Ex228Ye6iDagl%2BT7%2FrfnG%2Fg4BM5xD8c%3D&reserved=0

On 06/16/2017 07:52 PM, Mundkowsky, Robert wrote:
> Thanks.
>
> FYI, the main reason we decided to use openSIPS is that is a lot more 
> documentation than other solutions.
>
> Anyways, I have read lot of the books ("Building Telephony..2nd and 1.6"), 
> some of the website (modules, how to, ); and the major missing things are:
> 1 - Need a "openSIPS CookBook of recipes" that has more route examples
> (e.g. how to setup user authentication, how to do HA, security (drop
> ghost calls, ...), setup to work with RTP proxies,  ...)
> 2 - module documentation needs better details on how to pass in and pass out 
> values. For example, some modules do not expand variables, so it is really 
> hard to pass in values.
>
>
>
> Robert Mundkowsky
>
> -Original Message-
> From: Devel [mailto:devel-boun...@lists.opensips.org] On Behalf Of
> Bogdan-Andrei Iancu
> Sent: Friday, June 16, 2017 10:47 AM
> To: OpenSIPS users mailling list 
> Cc: busin...@lists.opensips.org; n...@lists.opensips.org; OpenSIPS
> devel mailling list 
> Subject: Re: [OpenSIPS-Devel] [OpenSIPS-Users] [Blog] Traffic balancing – 
> load, weights, round robin ??
>
> Hi Robert,
>
> All the time there is space for more :). This blog post is the first from a 
> set of docs trying to explain the routing with OpenSIPS.
>
> Including some feedback from you, I can draft as following chapters:
>   1) how to insert a balancer in your SIP traffic - like dialog statefull 
> proxy, transaction statefull proxy, stateless proxy, etc
>   2) routing modules in opensips, like dispatcher versus drouting versus 
> load-balancer..
>
>
> In your classification, I noticed many missing features for Dynamic Routing:
>   - in memory matching with prefix-tree - O(prefix_len)
>   - has gui in Control Panel
>   - destination pinging, failover, re-enable
>   - clustering capabilities for the state of the GW/destinations
>   - rule fallback (on matching)
>   ..
>
> Again, any feedback is more the welcome as it will give us some ideas about 
> the hot topics from the user perspective.
>
> Best regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.op
> ensips-solutions.com&data=02%7C01%7Crmundkowsky%40ets.org%7Ccb9609d327
> 0b4091081108d4b4c6c079%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C63
> 6332213102517343&sdata=ejvSuDmud%2FPcsYLuGhCjfEX3Zug1WSCwBmWblGUTcus%3
> D&reserved=0
>
> OpenSIPS Bootcamp 2017, Houston, US
>
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopensi
> ps.org%2Ftraining%2FOpenSIPS_Bootcamp_2017.html&data=02%7C01%7Crmundko
> wsky%40ets.org%7Ccb9609d3270b4091081108d4b4c6c079%7C0ba6e9b760b34fae92
> f37e6ddd9e9b65%7C0%7C0%7C636332213102517343&sdata=30yqvccNVQZmoeGjEWkj
> WQC2n7CZ7KgzccZxoRtPBek%3D&reserved=0
>
> On 06/15/2017 09:36 PM, Mundkowsky, Robert wrote:
>> This is helpful. But would like a little more details there. Such as:
>>
>> 1) openSIPS when it actions as a Load Balancer is always a SIP proxy during 
>> the complete dialog. In other words, the caller RTP is direct connected 
>> backend gateway, but openSIPS is always between them for the SIP traffic.
>> 2) Some information for the traffic distributions modules is stored
>> in the database, but some info is only in memory (e.g. which gateway
>> is enabled, count