Re: [OpenSIPS-Users] Feature Request - drouting

[Bogdan-Andrei Iancu]

Hi Mark,

The drouting module does prefix based routing, while your suggestion is 
about a variable part at the end of the number. If you do not like the 
idea of expanding the rule into multiple prefixes, maybe take a look at 
the dialplan module which does regexp based matching (but take care, 
this is highly inefficient for medium, large number of records, as it 
has to check all the records, one by one, there is no optimization in 
terms of searching the matching records)


Best regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS eBootcamp 2021
  https://opensips.org/training/OpenSIPS_eBootcamp_2021/

On 8/5/21 3:54 PM, Mark Farmer wrote:

Hi everyone

I am using drouting() which is working well but I am finding the 
prefix matching a little limited. It would be really useful to be able 
to match mid-range prefixes. For example, in Asterisk you can do do 
things like:


_+44123456789[2,3]
Which only matches prefixes ending 2 or 3.

Or:
_+44123456789[2-5]
Which matches prefixes ending 2,3,4 or 5

Would it be feasible to add this ability to drouting()?

Thanks and regards
Mark.


___
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

[OpenSIPS-Users] Feature Request - drouting

[Mark Farmer]

Hi everyone

I am using drouting() which is working well but I am finding the prefix
matching a little limited. It would be really useful to be able to match
mid-range prefixes. For example, in Asterisk you can do do things like:

_+44123456789[2,3]
Which only matches prefixes ending 2 or 3.

Or:
_+44123456789[2-5]
Which matches prefixes ending 2,3,4 or 5

Would it be feasible to add this ability to drouting()?

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

Re: [OpenSIPS-Users] feature request

[volga629 via Users]

  
  
Hello Răzvan,
Thank you. I added to the list.
volga629


On 3/31/20 9:23 AM, Răzvan Crainea
  wrote:

Hi,
  Volga!
  
  
  This looks like a valid feature request.
  
  Please open this feature request on our tracker[1], so we can keep
  track of them easier.
  
  
  [1] https://github.com/OpenSIPS/opensips/issues
  
  
  Best regards,
  
  
  Răzvan Crainea
  
  OpenSIPS Core Developer
  
  http://www.opensips-solutions.com
  
  
  On 3/30/20 1:31 PM, volga629 via Users wrote:
  
  Hello Everyone,


I would like request add rfc3994 to presence modules that allow
use of application/im-iscomposing+xml.



https://www.ietf.org/rfc/rfc3994.txt



Any opinion welcome.


volga629



___

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
  

  


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

Re: [OpenSIPS-Users] feature request

[Răzvan Crainea]

Hi, Volga!

This looks like a valid feature request.
Please open this feature request on our tracker[1], so we can keep track 
of them easier.


[1] https://github.com/OpenSIPS/opensips/issues

Best regards,

Răzvan Crainea
OpenSIPS Core Developer
http://www.opensips-solutions.com

On 3/30/20 1:31 PM, volga629 via Users wrote:

Hello Everyone,

I would like request add rfc3994 to presence modules that allow use of 
application/im-iscomposing+xml.



https://www.ietf.org/rfc/rfc3994.txt


Any opinion welcome.

volga629


___
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

[OpenSIPS-Users] feature request

[volga629 via Users]

  
  
Hello Everyone,
I would like request add rfc3994 to
presence modules that allow use of 
application/im-iscomposing+xml.

  https://www.ietf.org/rfc/rfc3994.txt

  
Any opinion welcome.
  
volga629 
  
  


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

Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address

[Johan De Clercq]

I am interested

Outlook voor iOS<https://aka.ms/o0ukef> downloaden


Van: Users  namens Vitalii Aleksandrov 

Verzonden: donderdag, juli 18, 2019 4:56 PM
Aan: users@lists.opensips.org
Onderwerp: Re: [OpenSIPS-Users] Feature request - pseudo-variable for 
destination IP address

Hi,

Original question was about different thing but the destination IP of a
request or reply is not hard to get. I wrote a small module which
extracts the destination uri from ru (du) for requests and from via for
replies, makes a dns resolve if it's a domain name and then detects the
outgoing interface of opensips and exports it as a PV to config. The
goal was to configure rtpengine's direction to bridge between different
interfaces. Adding just a few more lines of code will export the
destination IP as a PV. Since I use dns cache module resolve happens
only once and when t_relay() (tm module) searches for a destination it
just reuses previously resolved values from cache. I can share it if
anybody needs it.
> As far as I know, the equivalent variable to $si on the destination side is 
> either $dd, which may not always be set, or $rd. Those are not guaranteed to 
> be IP addresses, however. If DNS is being used, I don't believe OpenSIPS 
> provides the results of the DNS lookup to the script in any variable, so I 
> don't think there is a way to find the actual IP aside from doing your own 
> DNS lookup (or possibly using the dns_cache module and snooping the cache, 
> but I have had issues with this module in the past.)
>
> Ben Newlin
>
> On 6/28/19, 10:16 AM, "Users on behalf of rob.d...@telus.net" 
>  wrote:
>
> Unfortunately the address of the interface where the request was receeived is 
> private. I am using 1 to 1 NAT.
>
> - Original Message -
> From: "Ovidiu Sas" 
> To: "OpenSIPS users mailling list" 
> Sent: Thursday, June 27, 2019 3:31:34 PM
> Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for 
> destination IP address
>
> Check out the $Ri pvar:
> https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78
>
> -ovidiu
>
> On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net  wrote:
> >
> > I was looking for something similar to the $si PV but for the destination 
> > IP address. Either it doesn't exist or I am blind. I can't find things in 
> > the refrigerator either.
> >
> > The motivation.
> >
> > I have a working instance of Opensips with a basic residential 
> > configuration. I extended it to allow calling UAs on the LAN from the 
> > outside. It is a typical residential LAN without a fixed IP address. 
> > Dynamic DNS is working for me. I read the tutorial about Opensips behind 
> > NAT. Following the recommendations there I was able to setup rtpproxy, the 
> > advertised address and an alias for my Opensips. Initial testing using a 
> > softphone on a laptop using either WiFi or a mobile phone tethered to the 
> > laptop worked well. However it seems that some UAs will not accept a domain 
> > name in the SDP connection. The UAs that failed could be made to work by 
> > coding in an IP address. This is not a satisfactory solution because the 
> > router's address may chaange. There is probably some convoluted way to 
> > import the needed address into the script. A pseudo-variable representing 
> > the destination IP address of the received INVITE or 200 OK could then be 
> > passed as the advertised address to the rtpproxy module.
> >
> > Thank you for having a look.
> > Rob
> >
> > ___
> > Users mailing list
> > Users@lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
>
> ___
> 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
>
>
>
> ___
> 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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address

[Robert Dyck]

Using the ip transform to resolve the address worked for me. When I get around 
to it I should do it on opensips start up and cache the address

On Thursday, July 18, 2019 7:53:41 A.M. PDT Vitalii Aleksandrov wrote:
> Hi,
> 
> Original question was about different thing but the destination IP of a
> request or reply is not hard to get. I wrote a small module which
> extracts the destination uri from ru (du) for requests and from via for
> replies, makes a dns resolve if it's a domain name and then detects the
> outgoing interface of opensips and exports it as a PV to config. The
> goal was to configure rtpengine's direction to bridge between different
> interfaces. Adding just a few more lines of code will export the
> destination IP as a PV. Since I use dns cache module resolve happens
> only once and when t_relay() (tm module) searches for a destination it
> just reuses previously resolved values from cache. I can share it if
> anybody needs it.
> 
> > As far as I know, the equivalent variable to $si on the destination side
> > is either $dd, which may not always be set, or $rd. Those are not
> > guaranteed to be IP addresses, however. If DNS is being used, I don't
> > believe OpenSIPS provides the results of the DNS lookup to the script in
> > any variable, so I don't think there is a way to find the actual IP aside
> > from doing your own DNS lookup (or possibly using the dns_cache module
> > and snooping the cache, but I have had issues with this module in the
> > past.)
> > 
> > Ben Newlin
> > 
> > On 6/28/19, 10:16 AM, "Users on behalf of rob.d...@telus.net"  wrote:
> >  Unfortunately the address of the interface where the request was
> >  receeived is private. I am using 1 to 1 NAT.
> >  
> >  - Original Message -
> >  From: "Ovidiu Sas" 
> >  To: "OpenSIPS users mailling list" 
> >  Sent: Thursday, June 27, 2019 3:31:34 PM
> >  Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for
> >  destination IP address
> >  
> >  Check out the $Ri pvar:
> >  https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78
> >  
> >  -ovidiu
> >  
> >  On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net 
 wrote:
> >  > I was looking for something similar to the $si PV but for the
> >  > destination IP address. Either it doesn't exist or I am blind. I
> >  > can't find things in the refrigerator either.
> >  > 
> >  > The motivation.
> >  > 
> >  > I have a working instance of Opensips with a basic residential
> >  > configuration. I extended it to allow calling UAs on the LAN from
> >  > the outside. It is a typical residential LAN without a fixed IP
> >  > address. Dynamic DNS is working for me. I read the tutorial about
> >  > Opensips behind NAT. Following the recommendations there I was
> >  > able to setup rtpproxy, the advertised address and an alias for my
> >  > Opensips. Initial testing using a softphone on a laptop using
> >  > either WiFi or a mobile phone tethered to the laptop worked well.
> >  > However it seems that some UAs will not accept a domain name in
> >  > the SDP connection. The UAs that failed could be made to work by
> >  > coding in an IP address. This is not a satisfactory solution
> >  > because the router's address may chaange. There is probably some
> >  > convoluted way to import the needed address into the script.  A
> >  > pseudo-variable representing the destination IP address of the
> >  > received INVITE or 200 OK could then be passed as the advertised
> >  > address to the rtpproxy module.
> >  > 
> >  > Thank you for having a look.
> >  > Rob
> >  > 
> >  > ___
> >  > Users mailing list
> >  > Users@lists.opensips.org
> >  > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >  
> >  --
> >  VoIP Embedded, Inc.
> >  http://www.voipembedded.com
> >  
> >  ___
> >  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
> > 
> > ___
> > 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





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

Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address

[Vitalii Aleksandrov]

Hi,

Original question was about different thing but the destination IP of a 
request or reply is not hard to get. I wrote a small module which 
extracts the destination uri from ru (du) for requests and from via for 
replies, makes a dns resolve if it's a domain name and then detects the 
outgoing interface of opensips and exports it as a PV to config. The 
goal was to configure rtpengine's direction to bridge between different 
interfaces. Adding just a few more lines of code will export the 
destination IP as a PV. Since I use dns cache module resolve happens 
only once and when t_relay() (tm module) searches for a destination it 
just reuses previously resolved values from cache. I can share it if 
anybody needs it.

As far as I know, the equivalent variable to $si on the destination side is 
either $dd, which may not always be set, or $rd. Those are not guaranteed to be 
IP addresses, however. If DNS is being used, I don't believe OpenSIPS provides 
the results of the DNS lookup to the script in any variable, so I don't think 
there is a way to find the actual IP aside from doing your own DNS lookup (or 
possibly using the dns_cache module and snooping the cache, but I have had 
issues with this module in the past.)

Ben Newlin

On 6/28/19, 10:16 AM, "Users on behalf of rob.d...@telus.net" 
 wrote:

 Unfortunately the address of the interface where the request was receeived 
is private. I am using 1 to 1 NAT.
 
 - Original Message -

 From: "Ovidiu Sas" 
 To: "OpenSIPS users mailling list" 
 Sent: Thursday, June 27, 2019 3:31:34 PM
 Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for 
destination IP address
 
 Check out the $Ri pvar:

 https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78
 
 -ovidiu
 
 On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net  wrote:

 >
 > I was looking for something similar to the $si PV but for the 
destination IP address. Either it doesn't exist or I am blind. I can't find things 
in the refrigerator either.
 >
 > The motivation.
 >
 > I have a working instance of Opensips with a basic residential 
configuration. I extended it to allow calling UAs on the LAN from the outside. It 
is a typical residential LAN without a fixed IP address. Dynamic DNS is working 
for me. I read the tutorial about Opensips behind NAT. Following the 
recommendations there I was able to setup rtpproxy, the advertised address and an 
alias for my Opensips. Initial testing using a softphone on a laptop using either 
WiFi or a mobile phone tethered to the laptop worked well. However it seems that 
some UAs will not accept a domain name in the SDP connection. The UAs that failed 
could be made to work by coding in an IP address. This is not a satisfactory 
solution because the router's address may chaange. There is probably some 
convoluted way to import the needed address into the script.  A pseudo-variable 
representing the destination IP address of the received INVITE or 200 OK could 
then be passed as the advertised address to the rtpproxy module.
 >
 > Thank you for having a look.
 > Rob
 >
 > ___
 > Users mailing list
 > Users@lists.opensips.org
 > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 
 
 
 --

 VoIP Embedded, Inc.
 http://www.voipembedded.com
 
 ___

 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
 
 


___
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] Feature request - pseudo-variable for destination IP address

[Robert Dyck]

Thank you Yuri Ritvin 

{ip.resolve} transform works for me. The example given in the documentation is 
misleading. You can't use a literal string. You need to put into a var of some 
sort and then transform it.

On Thursday, June 27, 2019 3:35:37 P.M. PDT rob.d...@telus.net wrote:
> On second thought it probably isn't poosible to do in any direct way because
> the information is lost in the router. The only possible way is a DNS
> query.
> 
> - Original Message -
> From: "rob dyck" 
> To: users@lists.opensips.org
> Sent: Thursday, June 27, 2019 3:21:59 PM
> Subject: Feature request - pseudo-variable for destination IP address
> 
> I was looking for something similar to the $si PV but for the destination IP
> address. Either it doesn't exist or I am blind. I can't find things in the
> refrigerator either.
> 
> The motivation.
> 
> I have a working instance of Opensips with a basic residential
> configuration. I extended it to allow calling UAs on the LAN from the
> outside. It is a typical residential LAN without a fixed IP address.
> Dynamic DNS is working for me. I read the tutorial about Opensips behind
> NAT. Following the recommendations there I was able to setup rtpproxy, the
> advertised address and an alias for my Opensips. Initial testing using a
> softphone on a laptop using either WiFi or a mobile phone tethered to the
> laptop worked well. However it seems that some UAs will not accept a domain
> name in the SDP connection. The UAs that failed could be made to work by
> coding in an IP address. This is not a satisfactory solution because the
> router's address may chaange. There is probably some convoluted way to
> import the needed address into the script.  A pseudo-variable representing
> the destination IP address of the received INVITE or 200 OK could then be
> passed as the advertised address to the rtpproxy module.
> 
> Thank you for having a look.
> Rob
> 
> ___
> 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] Feature request - pseudo-variable for destination IP address

[Ben Newlin]

As far as I know, the equivalent variable to $si on the destination side is 
either $dd, which may not always be set, or $rd. Those are not guaranteed to be 
IP addresses, however. If DNS is being used, I don't believe OpenSIPS provides 
the results of the DNS lookup to the script in any variable, so I don't think 
there is a way to find the actual IP aside from doing your own DNS lookup (or 
possibly using the dns_cache module and snooping the cache, but I have had 
issues with this module in the past.)

Ben Newlin 

On 6/28/19, 10:16 AM, "Users on behalf of rob.d...@telus.net" 
 wrote:

Unfortunately the address of the interface where the request was receeived 
is private. I am using 1 to 1 NAT.

- Original Message -
From: "Ovidiu Sas" 
To: "OpenSIPS users mailling list" 
Sent: Thursday, June 27, 2019 3:31:34 PM
    Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for 
destination IP address

Check out the $Ri pvar:
https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78

-ovidiu

On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net  
wrote:
>
> I was looking for something similar to the $si PV but for the destination 
IP address. Either it doesn't exist or I am blind. I can't find things in the 
refrigerator either.
>
> The motivation.
>
> I have a working instance of Opensips with a basic residential 
configuration. I extended it to allow calling UAs on the LAN from the outside. 
It is a typical residential LAN without a fixed IP address. Dynamic DNS is 
working for me. I read the tutorial about Opensips behind NAT. Following the 
recommendations there I was able to setup rtpproxy, the advertised address and 
an alias for my Opensips. Initial testing using a softphone on a laptop using 
either WiFi or a mobile phone tethered to the laptop worked well. However it 
seems that some UAs will not accept a domain name in the SDP connection. The 
UAs that failed could be made to work by coding in an IP address. This is not a 
satisfactory solution because the router's address may chaange. There is 
probably some convoluted way to import the needed address into the script.  A 
pseudo-variable representing the destination IP address of the received INVITE 
or 200 OK could then be passed as the advertised address to the rtpproxy module.
>
> Thank you for having a look.
> Rob
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
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



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

Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address

[rob.d...@telus.net]

Unfortunately the address of the interface where the request was receeived is 
private. I am using 1 to 1 NAT.

- Original Message -
From: "Ovidiu Sas" 
To: "OpenSIPS users mailling list" 
Sent: Thursday, June 27, 2019 3:31:34 PM
Subject: Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination 
IP address

Check out the $Ri pvar:
https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78

-ovidiu

On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net  wrote:
>
> I was looking for something similar to the $si PV but for the destination IP 
> address. Either it doesn't exist or I am blind. I can't find things in the 
> refrigerator either.
>
> The motivation.
>
> I have a working instance of Opensips with a basic residential configuration. 
> I extended it to allow calling UAs on the LAN from the outside. It is a 
> typical residential LAN without a fixed IP address. Dynamic DNS is working 
> for me. I read the tutorial about Opensips behind NAT. Following the 
> recommendations there I was able to setup rtpproxy, the advertised address 
> and an alias for my Opensips. Initial testing using a softphone on a laptop 
> using either WiFi or a mobile phone tethered to the laptop worked well. 
> However it seems that some UAs will not accept a domain name in the SDP 
> connection. The UAs that failed could be made to work by coding in an IP 
> address. This is not a satisfactory solution because the router's address may 
> chaange. There is probably some convoluted way to import the needed address 
> into the script.  A pseudo-variable representing the destination IP address 
> of the received INVITE or 200 OK could then be passed as the advertised 
> address to the rtpproxy module.
>
> Thank you for having a look.
> Rob
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

___
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] Feature request - pseudo-variable for destination IP address

[rob.d...@telus.net]

On second thought it probably isn't poosible to do in any direct way because 
the information is lost in the router. The only possible way is a DNS query.

- Original Message -
From: "rob dyck" 
To: users@lists.opensips.org
Sent: Thursday, June 27, 2019 3:21:59 PM
Subject: Feature request - pseudo-variable for destination IP address

I was looking for something similar to the $si PV but for the destination IP 
address. Either it doesn't exist or I am blind. I can't find things in the 
refrigerator either.

The motivation.

I have a working instance of Opensips with a basic residential configuration. I 
extended it to allow calling UAs on the LAN from the outside. It is a typical 
residential LAN without a fixed IP address. Dynamic DNS is working for me. I 
read the tutorial about Opensips behind NAT. Following the recommendations 
there I was able to setup rtpproxy, the advertised address and an alias for my 
Opensips. Initial testing using a softphone on a laptop using either WiFi or a 
mobile phone tethered to the laptop worked well. However it seems that some UAs 
will not accept a domain name in the SDP connection. The UAs that failed could 
be made to work by coding in an IP address. This is not a satisfactory solution 
because the router's address may chaange. There is probably some convoluted way 
to import the needed address into the script.  A pseudo-variable representing 
the destination IP address of the received INVITE or 200 OK could then be 
passed as the advertised address to the rtpproxy module.

Thank you for having a look.
Rob

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

Re: [OpenSIPS-Users] Feature request - pseudo-variable for destination IP address

[Ovidiu Sas]

Check out the $Ri pvar:
https://www.opensips.org/Documentation/Script-CoreVar-3-0#toc78

-ovidiu

On Thu, Jun 27, 2019 at 6:23 PM rob.d...@telus.net  wrote:
>
> I was looking for something similar to the $si PV but for the destination IP 
> address. Either it doesn't exist or I am blind. I can't find things in the 
> refrigerator either.
>
> The motivation.
>
> I have a working instance of Opensips with a basic residential configuration. 
> I extended it to allow calling UAs on the LAN from the outside. It is a 
> typical residential LAN without a fixed IP address. Dynamic DNS is working 
> for me. I read the tutorial about Opensips behind NAT. Following the 
> recommendations there I was able to setup rtpproxy, the advertised address 
> and an alias for my Opensips. Initial testing using a softphone on a laptop 
> using either WiFi or a mobile phone tethered to the laptop worked well. 
> However it seems that some UAs will not accept a domain name in the SDP 
> connection. The UAs that failed could be made to work by coding in an IP 
> address. This is not a satisfactory solution because the router's address may 
> chaange. There is probably some convoluted way to import the needed address 
> into the script.  A pseudo-variable representing the destination IP address 
> of the received INVITE or 200 OK could then be passed as the advertised 
> address to the rtpproxy module.
>
> Thank you for having a look.
> Rob
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com

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

[OpenSIPS-Users] Feature request - pseudo-variable for destination IP address

[rob.d...@telus.net]

I was looking for something similar to the $si PV but for the destination IP 
address. Either it doesn't exist or I am blind. I can't find things in the 
refrigerator either.

The motivation.

I have a working instance of Opensips with a basic residential configuration. I 
extended it to allow calling UAs on the LAN from the outside. It is a typical 
residential LAN without a fixed IP address. Dynamic DNS is working for me. I 
read the tutorial about Opensips behind NAT. Following the recommendations 
there I was able to setup rtpproxy, the advertised address and an alias for my 
Opensips. Initial testing using a softphone on a laptop using either WiFi or a 
mobile phone tethered to the laptop worked well. However it seems that some UAs 
will not accept a domain name in the SDP connection. The UAs that failed could 
be made to work by coding in an IP address. This is not a satisfactory solution 
because the router's address may chaange. There is probably some convoluted way 
to import the needed address into the script.  A pseudo-variable representing 
the destination IP address of the received INVITE or 200 OK could then be 
passed as the advertised address to the rtpproxy module.

Thank you for having a look.
Rob

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

Re: [OpenSIPS-Users] Feature request? Script Var / AVP variables in route function.

[xaled]

There could be a constrain in OpenSIPS that the route name should be defined at 
the start of opensips process. Otherwise if a variable value for some reason 
does not match any defined route there will be a problem. 

 

Greetings,

xaled

 

From: Users [mailto:users-boun...@lists.opensips.org] On Behalf Of Jim DeVito
Sent: Donnerstag, 21. September 2017 14:58
To: OpenSIPS users mailling list 
Subject: Re: [OpenSIPS-Users] Feature request? Script Var / AVP variables in 
route function.

 

Hmmm. I want to use the contents of $avp(carrier_id) as the route name. So if 
$avp(carrier_id) is 25 I want it to call the routing block route[25].

 

On Thu, Sep 21, 2017 at 8:52 AM, Răzvan Crainea mailto:raz...@opensips.org> > wrote:

Hi, Jim!

You should have a name for the route, such as:

route(route_name, $avp(carrier_id));

Best regards,



Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com <http://www.opensips-solutions.com> 

On 09/21/2017 03:43 PM, Jim DeVito wrote:

Hi Razvan, 

 

So what am I doing wrong with 

 

route($avp(carrier_id));

 

It produces...

 

...line 318, column 53-54: bad routeargument

 

Thanks!!

 

On Thu, Sep 21, 2017 at 8:31 AM, Răzvan Crainea mailto:raz...@opensips.org> > wrote:

Hi, Jim!

Script variables or AVPs are PV (pseudo-variables) themselves, so you should be 
able to use them.

Best regards,



Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com <http://www.opensips-solutions.com> 

On 09/21/2017 03:14 PM, Jim DeVito wrote:

Hi All,

 

It's my understanding only PV, integers and strings can be used in the core 
route function. Is there a reason I don't understand why we can not use script 
variables or AVP's?

 

 

Thanks!!

 

- 

Jim DeVito

Mobile 216.507.9497  

 

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

 


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





 

-- 

- 

Jim DeVito

Mobile 216.507.9497  

 

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

 


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





 

-- 

-

Jim DeVito

Mobile 216.507.9497

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

Re: [OpenSIPS-Users] Feature request? Script Var / AVP variables in route function.

[Jim DeVito]

Hmmm. I want to use the contents of $avp(carrier_id) as the route name. So
if $avp(carrier_id) is 25 I want it to call the routing block route[25].

On Thu, Sep 21, 2017 at 8:52 AM, Răzvan Crainea  wrote:

> Hi, Jim!
>
> You should have a name for the route, such as:
>
> route(route_name, $avp(carrier_id));
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Developerwww.opensips-solutions.com
>
> On 09/21/2017 03:43 PM, Jim DeVito wrote:
>
> Hi Razvan,
>
> So what am I doing wrong with
>
> route($avp(carrier_id));
>
> It produces...
>
> ...line 318, column 53-54: bad routeargument
>
> Thanks!!
>
> On Thu, Sep 21, 2017 at 8:31 AM, Răzvan Crainea 
> wrote:
>
>> Hi, Jim!
>>
>> Script variables or AVPs are PV (pseudo-variables) themselves, so you
>> should be able to use them.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Developerwww.opensips-solutions.com
>>
>> On 09/21/2017 03:14 PM, Jim DeVito wrote:
>>
>> Hi All,
>>
>> It's my understanding only PV, integers and strings can be used in the
>> core route function. Is there a reason I don't understand why we can not
>> use script variables or AVP's?
>>
>>
>> Thanks!!
>>
>> -
>> Jim DeVito
>> Mobile 216.507.9497 <%28216%29%20507-9497>
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> --
> -
> Jim DeVito
> Mobile 216.507.9497 <(216)%20507-9497>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


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

Re: [OpenSIPS-Users] Feature request? Script Var / AVP variables in route function.

[Răzvan Crainea]

Hi, Jim!

You should have a name for the route, such as:

route(route_name, $avp(carrier_id));

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 09/21/2017 03:43 PM, Jim DeVito wrote:

Hi Razvan,

So what am I doing wrong with

route($avp(carrier_id));

It produces...

...line 318, column 53-54: bad routeargument

Thanks!!

On Thu, Sep 21, 2017 at 8:31 AM, Răzvan Crainea > wrote:


Hi, Jim!

Script variables or AVPs are PV (pseudo-variables) themselves, so
you should be able to use them.

Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com 

On 09/21/2017 03:14 PM, Jim DeVito wrote:

Hi All,

It's my understanding only PV, integers and strings can be used
in the core route function. Is there a reason I don't understand
why we can not use script variables or AVP's?


Thanks!!

-
Jim DeVito
Mobile 216.507.9497 


___
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





--
-
Jim DeVito
Mobile 216.507.9497


___
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] Feature request? Script Var / AVP variables in route function.

[Jim DeVito]

Hi Razvan,

So what am I doing wrong with

route($avp(carrier_id));

It produces...

...line 318, column 53-54: bad routeargument

Thanks!!

On Thu, Sep 21, 2017 at 8:31 AM, Răzvan Crainea  wrote:

> Hi, Jim!
>
> Script variables or AVPs are PV (pseudo-variables) themselves, so you
> should be able to use them.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Developerwww.opensips-solutions.com
>
> On 09/21/2017 03:14 PM, Jim DeVito wrote:
>
> Hi All,
>
> It's my understanding only PV, integers and strings can be used in the
> core route function. Is there a reason I don't understand why we can not
> use script variables or AVP's?
>
>
> Thanks!!
>
> -
> Jim DeVito
> Mobile 216.507.9497 <(216)%20507-9497>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>


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

Re: [OpenSIPS-Users] Feature request? Script Var / AVP variables in route function.

[Răzvan Crainea]

Hi, Jim!

Script variables or AVPs are PV (pseudo-variables) themselves, so you 
should be able to use them.


Best regards,

Răzvan Crainea
OpenSIPS Developer
www.opensips-solutions.com

On 09/21/2017 03:14 PM, Jim DeVito wrote:

Hi All,

It's my understanding only PV, integers and strings can be used in the 
core route function. Is there a reason I don't understand why we can 
not use script variables or AVP's?



Thanks!!

-
Jim DeVito
Mobile 216.507.9497


___
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

[OpenSIPS-Users] Feature request? Script Var / AVP variables in route function.

[Jim DeVito]

Hi All,

It's my understanding only PV, integers and strings can be used in the core
route function. Is there a reason I don't understand why we can not use
script variables or AVP's?


Thanks!!

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

Re: [OpenSIPS-Users] Feature request - automatic string to lower domains

[Daniel Goepp]

Sounds good, thanks.  I have created issue #8.


-dg


On Mon, Jun 24, 2013 at 7:18 AM, Bogdan-Andrei Iancu wrote:

> **
> Hello Daniel,
>
> What you are saying may have sense in some scenarios - could you please
> open a feature request on the tracker, so we will not forget about this.
> See:
> http://www.opensips.org/Development/Tracker
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 05/08/2013 08:03 AM, Daniel Goepp wrote:
>
> Have you considered a function or flag that automatically sets the domain
> on the RURI, From and To all lower case?
>
>  We have a work around of course, to just do this manually, but figured
> it would be good to give some feed back.
>
>  Specifically we had issues regarding auth with multi-domain support.  In
> the auth module we leave the first parameter null, which by default pulls
> from the To header.  However, if a device sends caps in the domain, it
> affect the auth (which is case-sensitive for realm).
>
>  Just a thought, with regards to compliance with DNS and domains in
> general, which are not case sensitive.
>
> -dg
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] Feature request - automatic string to lower domains

[Bogdan-Andrei Iancu]

Hello Daniel,

What you are saying may have sense in some scenarios - could you please
open a feature request on the tracker, so we will not forget about this.
See:
http://www.opensips.org/Development/Tracker

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/08/2013 08:03 AM, Daniel Goepp wrote:
> Have you considered a function or flag that automatically sets the
> domain on the RURI, From and To all lower case?
>
> We have a work around of course, to just do this manually, but figured
> it would be good to give some feed back.
>
> Specifically we had issues regarding auth with multi-domain support.
>  In the auth module we leave the first parameter null, which by
> default pulls from the To header.  However, if a device sends caps in
> the domain, it affect the auth (which is case-sensitive for realm).
>
> Just a thought, with regards to compliance with DNS and domains in
> general, which are not case sensitive.
>
> -dg
>
>
> ___
> 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

[OpenSIPS-Users] Feature request - automatic string to lower domains

[Daniel Goepp]

Have you considered a function or flag that automatically sets the domain
on the RURI, From and To all lower case?

We have a work around of course, to just do this manually, but figured it
would be good to give some feed back.

Specifically we had issues regarding auth with multi-domain support.  In
the auth module we leave the first parameter null, which by default pulls
from the To header.  However, if a device sends caps in the domain, it
affect the auth (which is case-sensitive for realm).

Just a thought, with regards to compliance with DNS and domains in general,
which are not case sensitive.

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

Re: [OpenSIPS-Users] Feature request: multiset cache interfaces and queued insertions

[Brett Nemeroff]

Right it's mostly useful for append only operations like cdr writing. Of
course you'll be able to do alot of that via the acc module, but this lets
you write all sorts of other analytics at high insertion rate as well.

Oh and speaking of append only... Couchbase does support an "append" method
that would be nice to expose to the script as well.  :)

Thanks for your time Vlad,
Brett


On Tue, Feb 12, 2013 at 10:24 AM, Vlad Paiu  wrote:

> Hi Brett,
>
> While Couchbase supports such operations, I can't see that other familiar
> NoSQL back-ends support such multiset features.
> Could you give more examples of back-ends supporting this ?
>
> Also, it might be that doing delayed inserts for cache operations would
> lead to some tricky scenarios.. Like if you want to cache some information
> from a regular DB, you will end up first loading the info and storing it in
> memory, in order to do a multiset later when more set queries have piled up.
> Then when you'd need the key again, you would not find it ( since it's
> still in mem waiting to be flushed to the back-end ) and again fetch it
> from the DB and put it into memory waiting for the multi set. So it kind of
> breaks the cache concept ( that once you put something there, you'll find
> it next time ).
>
> Regards,
>
> Vlad Paiu
> OpenSIPS Developer
> http://www.opensips-solutions.**com 
>
>
>
> On 02/10/2013 11:17 PM, Brett Nemeroff wrote:
>
>> Hey all,
>> Quick feature request. Many of the cache back ends support multisets
>> at once. I've seen tremendous speed improvements from multisets. In
>> addition, maybe complementary, I'd like to see queues cache
>> insertions. This is especially useful for using the cache interface
>> for something like acc. The idea would be that it'll queue up
>> insertions (set/add) nd maybe in a timer route or when some queued
>> message count is hit, it'd multiset all if them at once. Doing one set
>> with thousands of records is much faster than multiple connections to
>> do the same
>>
>> Thanks!
>> Brett
>>
>> -Brett
>>
>> __**_
>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Feature request: multiset cache interfaces and queued insertions

[Vlad Paiu]

Hi Brett,

While Couchbase supports such operations, I can't see that other 
familiar NoSQL back-ends support such multiset features.

Could you give more examples of back-ends supporting this ?

Also, it might be that doing delayed inserts for cache operations would 
lead to some tricky scenarios.. Like if you want to cache some 
information from a regular DB, you will end up first loading the info 
and storing it in memory, in order to do a multiset later when more set 
queries have piled up.
Then when you'd need the key again, you would not find it ( since it's 
still in mem waiting to be flushed to the back-end ) and again fetch it 
from the DB and put it into memory waiting for the multi set. So it kind 
of breaks the cache concept ( that once you put something there, you'll 
find it next time ).


Regards,

Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com


On 02/10/2013 11:17 PM, Brett Nemeroff wrote:

Hey all,
Quick feature request. Many of the cache back ends support multisets
at once. I've seen tremendous speed improvements from multisets. In
addition, maybe complementary, I'd like to see queues cache
insertions. This is especially useful for using the cache interface
for something like acc. The idea would be that it'll queue up
insertions (set/add) nd maybe in a timer route or when some queued
message count is hit, it'd multiset all if them at once. Doing one set
with thousands of records is much faster than multiple connections to
do the same

Thanks!
Brett

-Brett

___
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

[OpenSIPS-Users] Feature request: multiset cache interfaces and queued insertions

[Brett Nemeroff]

Hey all,
Quick feature request. Many of the cache back ends support multisets
at once. I've seen tremendous speed improvements from multisets. In
addition, maybe complementary, I'd like to see queues cache
insertions. This is especially useful for using the cache interface
for something like acc. The idea would be that it'll queue up
insertions (set/add) nd maybe in a timer route or when some queued
message count is hit, it'd multiset all if them at once. Doing one set
with thousands of records is much faster than multiple connections to
do the same

Thanks!
Brett

-Brett

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

Re: [OpenSIPS-Users] Feature request for OpenSIPS 1.9: support for macro definitions

[Ali Pey]

Thank you Bogdan...


On Thu, Nov 8, 2012 at 12:14 PM, Bogdan-Andrei Iancu wrote:

> **
> Hi Ali,
>
> Added on the list http://www.opensips.org/Main/Ver190#toc9 with a quite
> high priority ;).
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> On 11/08/2012 07:06 PM, Ali Pey wrote:
>
> I second this as well. Named flags would make debugging and scripting
> quite simpler.
>
>  Regards,
> Ali
>
>
>
> On Thu, Nov 8, 2012 at 11:23 AM, Bogdan-Andrei Iancu 
> wrote:
>
>> Hi Michael,
>>
>> You can already use names for the route, not only numerical IDs (without
>> the need of defining).
>>
>> For flags, you can use only numbers, indeed - usually I use M4 as text
>> preprocessor to do different complex ops over the script (like defines,
>> ifdefs, etc).
>> But maybe a built in support for names of flags will not be a big issue,
>> especially it is not a big deal.
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>>
>> On 11/08/2012 01:22 PM, Michael Renzmann wrote:
>>
>>> Hi all.
>>>
>>> I'm relatively new to OpenSIPS and still am at the very beginning of
>>> learning how to tame this wonderful beast ;-).
>>>
>>> One thing that I, personally, find pretty uncomfortable is that in
>>> various
>>> places in the opensips.cfg one needs to use plain numbers to define or
>>> modify the behaviour. That easily results in constructs like:
>>>
>>> === cut ===
>>> route {
>>>  ...
>>>  route(42);
>>>  ...
>>> }
>>>
>>> route[42] {
>>>  ...
>>>  setflag(8);
>>>  ...
>>> }
>>> === cut ===
>>>
>>> Obviously, it is possible to memorize the meaning of the different
>>> numbers
>>> depending on the context they are used in - this is what people do now
>>> when they work with OpenSIPS. But I guess things may become pretty
>>> painful
>>> when you have a complex configuration and need to urgently debug an issue
>>> in it which just has brought down a heavily loaded, productively used
>>> OpenSIPS instance...
>>>
>>> Using comments certainly helps to relieve the problem a bit, but they can
>>> not solve it. However, things would become much easier if one could use
>>> "speaking names" instead of plain numbers:
>>>
>>> === cut ===
>>> define(ROUTE_NAT_DETECTION, 42);
>>> define(FLAG_NAT_DETECTED, 8);
>>>
>>> route {
>>> ...
>>> route(ROUTE_NAT_DETECTION);
>>> ...
>>> }
>>>
>>> route[ROUTE_NAT_DETECTION] {
>>> ...
>>> setflag(FLAG_NAT_DETECTED);
>>> ...
>>> }
>>> === cut ===
>>>
>>> Yes, I am aware that this could also be achieved by using an external
>>> macro preprocessor such as M4. But that would add another dependency -
>>> one
>>> which could be avoided if OpenSIPS had built-in support for simple macro
>>> definitions like those shown in the example above.
>>>
>>> Bye, Mike
>>>
>>> ___
>>> 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
>>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://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] Feature request for OpenSIPS 1.9: support for macro definitions

[Bogdan-Andrei Iancu]

Hi Ali,

Added on the list http://www.opensips.org/Main/Ver190#toc9 with a quite 
high priority ;).


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/08/2012 07:06 PM, Ali Pey wrote:
I second this as well. Named flags would make debugging and scripting 
quite simpler.


Regards,
Ali



On Thu, Nov 8, 2012 at 11:23 AM, Bogdan-Andrei Iancu 
mailto:bog...@opensips.org>> wrote:


Hi Michael,

You can already use names for the route, not only numerical IDs
(without the need of defining).

For flags, you can use only numbers, indeed - usually I use M4 as
text preprocessor to do different complex ops over the script
(like defines, ifdefs, etc).
But maybe a built in support for names of flags will not be a big
issue, especially it is not a big deal.

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com



On 11/08/2012 01:22 PM, Michael Renzmann wrote:

Hi all.

I'm relatively new to OpenSIPS and still am at the very
beginning of
learning how to tame this wonderful beast ;-).

One thing that I, personally, find pretty uncomfortable is
that in various
places in the opensips.cfg one needs to use plain numbers to
define or
modify the behaviour. That easily results in constructs like:

=== cut ===
route {
 ...
 route(42);
 ...
}

route[42] {
 ...
 setflag(8);
 ...
}
=== cut ===

Obviously, it is possible to memorize the meaning of the
different numbers
depending on the context they are used in - this is what
people do now
when they work with OpenSIPS. But I guess things may become
pretty painful
when you have a complex configuration and need to urgently
debug an issue
in it which just has brought down a heavily loaded,
productively used
OpenSIPS instance...

Using comments certainly helps to relieve the problem a bit,
but they can
not solve it. However, things would become much easier if one
could use
"speaking names" instead of plain numbers:

=== cut ===
define(ROUTE_NAT_DETECTION, 42);
define(FLAG_NAT_DETECTED, 8);

route {
...
route(ROUTE_NAT_DETECTION);
...
}

route[ROUTE_NAT_DETECTION] {
...
setflag(FLAG_NAT_DETECTED);
...
}
=== cut ===

Yes, I am aware that this could also be achieved by using an
external
macro preprocessor such as M4. But that would add another
dependency - one
which could be avoided if OpenSIPS had built-in support for
simple macro
definitions like those shown in the example above.

Bye, Mike

___
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



___
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] Feature request for OpenSIPS 1.9: support for macro definitions

[Ali Pey]

I second this as well. Named flags would make debugging and scripting quite
simpler.

Regards,
Ali



On Thu, Nov 8, 2012 at 11:23 AM, Bogdan-Andrei Iancu wrote:

> Hi Michael,
>
> You can already use names for the route, not only numerical IDs (without
> the need of defining).
>
> For flags, you can use only numbers, indeed - usually I use M4 as text
> preprocessor to do different complex ops over the script (like defines,
> ifdefs, etc).
> But maybe a built in support for names of flags will not be a big issue,
> especially it is not a big deal.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> http://www.opensips-solutions.**com 
>
>
>
> On 11/08/2012 01:22 PM, Michael Renzmann wrote:
>
>> Hi all.
>>
>> I'm relatively new to OpenSIPS and still am at the very beginning of
>> learning how to tame this wonderful beast ;-).
>>
>> One thing that I, personally, find pretty uncomfortable is that in various
>> places in the opensips.cfg one needs to use plain numbers to define or
>> modify the behaviour. That easily results in constructs like:
>>
>> === cut ===
>> route {
>>  ...
>>  route(42);
>>  ...
>> }
>>
>> route[42] {
>>  ...
>>  setflag(8);
>>  ...
>> }
>> === cut ===
>>
>> Obviously, it is possible to memorize the meaning of the different numbers
>> depending on the context they are used in - this is what people do now
>> when they work with OpenSIPS. But I guess things may become pretty painful
>> when you have a complex configuration and need to urgently debug an issue
>> in it which just has brought down a heavily loaded, productively used
>> OpenSIPS instance...
>>
>> Using comments certainly helps to relieve the problem a bit, but they can
>> not solve it. However, things would become much easier if one could use
>> "speaking names" instead of plain numbers:
>>
>> === cut ===
>> define(ROUTE_NAT_DETECTION, 42);
>> define(FLAG_NAT_DETECTED, 8);
>>
>> route {
>> ...
>> route(ROUTE_NAT_DETECTION);
>> ...
>> }
>>
>> route[ROUTE_NAT_DETECTION] {
>> ...
>> setflag(FLAG_NAT_DETECTED);
>> ...
>> }
>> === cut ===
>>
>> Yes, I am aware that this could also be achieved by using an external
>> macro preprocessor such as M4. But that would add another dependency - one
>> which could be avoided if OpenSIPS had built-in support for simple macro
>> definitions like those shown in the example above.
>>
>> Bye, Mike
>>
>> __**_
>> 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Feature request for OpenSIPS 1.9: support for macro definitions

[Bogdan-Andrei Iancu]

Hi Michael,

You can already use names for the route, not only numerical IDs (without 
the need of defining).


For flags, you can use only numbers, indeed - usually I use M4 as text 
preprocessor to do different complex ops over the script (like defines, 
ifdefs, etc).
But maybe a built in support for names of flags will not be a big issue, 
especially it is not a big deal.


Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 11/08/2012 01:22 PM, Michael Renzmann wrote:

Hi all.

I'm relatively new to OpenSIPS and still am at the very beginning of
learning how to tame this wonderful beast ;-).

One thing that I, personally, find pretty uncomfortable is that in various
places in the opensips.cfg one needs to use plain numbers to define or
modify the behaviour. That easily results in constructs like:

=== cut ===
route {
 ...
 route(42);
 ...
}

route[42] {
 ...
 setflag(8);
 ...
}
=== cut ===

Obviously, it is possible to memorize the meaning of the different numbers
depending on the context they are used in - this is what people do now
when they work with OpenSIPS. But I guess things may become pretty painful
when you have a complex configuration and need to urgently debug an issue
in it which just has brought down a heavily loaded, productively used
OpenSIPS instance...

Using comments certainly helps to relieve the problem a bit, but they can
not solve it. However, things would become much easier if one could use
"speaking names" instead of plain numbers:

=== cut ===
define(ROUTE_NAT_DETECTION, 42);
define(FLAG_NAT_DETECTED, 8);

route {
...
route(ROUTE_NAT_DETECTION);
...
}

route[ROUTE_NAT_DETECTION] {
...
setflag(FLAG_NAT_DETECTED);
...
}
=== cut ===

Yes, I am aware that this could also be achieved by using an external
macro preprocessor such as M4. But that would add another dependency - one
which could be avoided if OpenSIPS had built-in support for simple macro
definitions like those shown in the example above.

Bye, Mike

___
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

[OpenSIPS-Users] Feature request for OpenSIPS 1.9: support for macro definitions

[Michael Renzmann]

Hi all.

I'm relatively new to OpenSIPS and still am at the very beginning of
learning how to tame this wonderful beast ;-).

One thing that I, personally, find pretty uncomfortable is that in various
places in the opensips.cfg one needs to use plain numbers to define or
modify the behaviour. That easily results in constructs like:

=== cut ===
route {
...
route(42);
...
}

route[42] {
...
setflag(8);
...
}
=== cut ===

Obviously, it is possible to memorize the meaning of the different numbers
depending on the context they are used in - this is what people do now
when they work with OpenSIPS. But I guess things may become pretty painful
when you have a complex configuration and need to urgently debug an issue
in it which just has brought down a heavily loaded, productively used
OpenSIPS instance...

Using comments certainly helps to relieve the problem a bit, but they can
not solve it. However, things would become much easier if one could use
"speaking names" instead of plain numbers:

=== cut ===
define(ROUTE_NAT_DETECTION, 42);
define(FLAG_NAT_DETECTED, 8);

route {
   ...
   route(ROUTE_NAT_DETECTION);
   ...
}

route[ROUTE_NAT_DETECTION] {
   ...
   setflag(FLAG_NAT_DETECTED);
   ...
}
=== cut ===

Yes, I am aware that this could also be achieved by using an external
macro preprocessor such as M4. But that would add another dependency - one
which could be avoided if OpenSIPS had built-in support for simple macro
definitions like those shown in the example above.

Bye, Mike

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

Re: [OpenSIPS-Users] Feature request: additional authorization conditions in auth_db

[Alexander]

  Thank you very much, Bogdan! I've forgot about load_credentials :(

> Hi Alexander,

> auth_ module simply does only the digest authentication. Whatever 
> additional check you may need can be done from the script, if auth is 
> passed. if you need some extra info from the subscriber table, you can 
> use the "load_credentials" param to fetch it in script.

> Regards,
> Bogdan

> Alexander wrote:
>>   Hello all!
>>
>>   I  have a question about authorization: is there ability to specify 
>> additional
>> conditions? For example, like it's done in postfix?
>>   We  check  only username and password in OpenSIPS, but there may be 
>> additional
>> info,  like  "status" (active, suspended, blocked, etc...). So, if 
>> name/password
>> match, but status is not "active" - authorization fails.
>>
>>   It may look like this in config file:
>>
>>   modparam("auth_db", "additional_conditions", "fiStatus = 200").
>>
>>   As   I   see,   now   this   feature  is not supported. If it's not 
>> planned to
>> develop, I can try to  implement this feature  and  provide  patch  or  
>> modified
>> source  files. Will it be useful for someone else but me? :)
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>   





-- 
С уважением,
 Alexander  mailto:goa...@gmail.com


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

Re: [OpenSIPS-Users] Feature request: additional authorization conditions in auth_db

[Bogdan-Andrei Iancu]

Hi Alexander,

auth_ module simply does only the digest authentication. Whatever 
additional check you may need can be done from the script, if auth is 
passed. if you need some extra info from the subscriber table, you can 
use the "load_credentials" param to fetch it in script.

Regards,
Bogdan

Alexander wrote:
>   Hello all!
>
>   I  have a question about authorization: is there ability to specify 
> additional
> conditions? For example, like it's done in postfix?
>   We  check  only username and password in OpenSIPS, but there may be 
> additional
> info,  like  "status" (active, suspended, blocked, etc...). So, if 
> name/password
> match, but status is not "active" - authorization fails.
>
>   It may look like this in config file:
>
>   modparam("auth_db", "additional_conditions", "fiStatus = 200").
>
>   As   I   see,   now   this   feature  is not supported. If it's not planned 
> to
> develop, I can try to  implement this feature  and  provide  patch  or  
> modified
> source  files. Will it be useful for someone else but me? :)
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro


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

Re: [OpenSIPS-Users] Feature request: additional authorization conditions in auth_db

[Raúl Alexis Betancor Santana]

On Tuesday 05 January 2010 12:59:31 Alexander wrote:
>   Hello all!
>
>   I  have a question about authorization: is there ability to specify
> additional conditions? For example, like it's done in postfix?
>   We  check  only username and password in OpenSIPS, but there may be
> additional info,  like  "status" (active, suspended, blocked, etc...). So,
> if name/password match, but status is not "active" - authorization fails.
>
>   It may look like this in config file:
>
>   modparam("auth_db", "additional_conditions", "fiStatus = 200").
>
>   As   I   see,   now   this   feature  is not supported. If it's not
> planned to develop, I can try to  implement this feature  and  provide 
> patch  or  modified source  files. Will it be useful for someone else but
> me? :)

I think that everyone off us use the group module for that task of ACL's, also 
you could use a view as the table for auth.


-- 
Raúl Alexis Betancor Santana
Dimensión Virtual

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

[OpenSIPS-Users] Feature request: additional authorization conditions in auth_db

[Alexander]

  Hello all!

  I  have a question about authorization: is there ability to specify additional
conditions? For example, like it's done in postfix?
  We  check  only username and password in OpenSIPS, but there may be additional
info,  like  "status" (active, suspended, blocked, etc...). So, if name/password
match, but status is not "active" - authorization fails.

  It may look like this in config file:

  modparam("auth_db", "additional_conditions", "fiStatus = 200").

  As   I   see,   now   this   feature  is not supported. If it's not planned to
develop, I can try to  implement this feature  and  provide  patch  or  modified
source  files. Will it be useful for someone else but me? :)


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

Re: [OpenSIPS-Users] Feature request: Loop detection

[Bogdan-Andrei Iancu]

the IPs are internally kept in a tree that assumes that the data is 
IP-only - each node can have maximum 256 sub-nodes, but with some twists 
I can do it more generic, to support any kind of data..

Regards,
Bogdan

Brett Nemeroff wrote:
>  Why is that? Does it provide rate-limiting for subnets of sending 
> traffic as well?
>
> Seems like the function needs to be redone altogether with the whole 
> tree business..
> -Brett
>
>
> On Mon, Jun 29, 2009 at 12:02 PM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> OK, let me see how difficult is to re-design the pike module, as
> so far, the way the internal data is kept is highly IP-format
> dependent.
>
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
> Yeah, that's a great idea actually, I could just concatenate
> some PVs to form a key like $si-$rU.
>
>
> On Mon, Jun 29, 2009 at 8:53 AM, Bogdan-Andrei Iancu
> mailto:bog...@voice-system.ro>
>  >> wrote:
>
>Hi Brett,
>
>This will be kind of pike but instead of using as input the
> source
>IP string, it should use a custom string you build form script,
>right ? this string will be a kind of key (logical one) to
>identify the loop.
>
>Regards,
>Bogdan
>
>Brett Nemeroff wrote:
>
>Hey All,
>I was wanting to submit a feature request for loop
> detection.
>Specifically NOT SIP loop detection, but when another
>technology / B2BUA is involved where max-forwards can't be
>used. This is for big loops.
>The idea is similar to the pike module. However, you
>bascically look at the to_did and the source IP and if
> you see
>more than X calls in Y period, begin to reject them for
> Z seconds.
>
>Simple enough. This has come up a dozen times for me
> and for
>now I have to handle it with kludge of memcache, and perl
>scripts to detect these issues in my cdr.
>
>The loops are a bit nuts and are always the results of
> someone
>doing something stupid (but hey, it does happen). The loops
>are like, my customer sends me a call to one of thier
> own DIDs
>(they've misrouted it to me) and I send it to my
> carrier, who
>sends it to the pstn, back to my customer, back to me,
> etc..
>There may be a ss7 portion in there so it keeps looking
> like a
>new call on the SIP side.
>So without anything, this can clog up my call paths pretty
>quickly, the proposed feature would blacklist the source_ip
>to_did combination for a period of time to kill the loop.
>
>Thoughts?
>-Brett
>
>  
>  
> 
>
>___
>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] Feature request: Loop detection

[Brett Nemeroff]

 Why is that? Does it provide rate-limiting for subnets of sending traffic
as well?
Seems like the function needs to be redone altogether with the whole tree
business..
-Brett


On Mon, Jun 29, 2009 at 12:02 PM, Bogdan-Andrei Iancu <
bog...@voice-system.ro> wrote:

> OK, let me see how difficult is to re-design the pike module, as so far,
> the way the internal data is kept is highly IP-format dependent.
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
>> Yeah, that's a great idea actually, I could just concatenate some PVs to
>> form a key like $si-$rU.
>>
>>
>> On Mon, Jun 29, 2009 at 8:53 AM, Bogdan-Andrei Iancu <
>> bog...@voice-system.ro > wrote:
>>
>>Hi Brett,
>>
>>This will be kind of pike but instead of using as input the source
>>IP string, it should use a custom string you build form script,
>>right ? this string will be a kind of key (logical one) to
>>identify the loop.
>>
>>Regards,
>>Bogdan
>>
>>Brett Nemeroff wrote:
>>
>>Hey All,
>>I was wanting to submit a feature request for loop detection.
>>Specifically NOT SIP loop detection, but when another
>>technology / B2BUA is involved where max-forwards can't be
>>used. This is for big loops.
>>The idea is similar to the pike module. However, you
>>bascically look at the to_did and the source IP and if you see
>>more than X calls in Y period, begin to reject them for Z seconds.
>>
>>Simple enough. This has come up a dozen times for me and for
>>now I have to handle it with kludge of memcache, and perl
>>scripts to detect these issues in my cdr.
>>
>>The loops are a bit nuts and are always the results of someone
>>doing something stupid (but hey, it does happen). The loops
>>are like, my customer sends me a call to one of thier own DIDs
>>(they've misrouted it to me) and I send it to my carrier, who
>>sends it to the pstn, back to my customer, back to me, etc..
>>There may be a ss7 portion in there so it keeps looking like a
>>new call on the SIP side.
>>So without anything, this can clog up my call paths pretty
>>quickly, the proposed feature would blacklist the source_ip
>>to_did combination for a period of time to kill the loop.
>>
>>Thoughts?
>>-Brett
>>
>>
>>  
>>
>>___
>>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] Feature request: Loop detection

[Bogdan-Andrei Iancu]

OK, let me see how difficult is to re-design the pike module, as so far, 
the way the internal data is kept is highly IP-format dependent.

Regards,
Bogdan

Brett Nemeroff wrote:
> Yeah, that's a great idea actually, I could just concatenate some PVs 
> to form a key like $si-$rU.
>
>
> On Mon, Jun 29, 2009 at 8:53 AM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Hi Brett,
>
> This will be kind of pike but instead of using as input the source
> IP string, it should use a custom string you build form script,
> right ? this string will be a kind of key (logical one) to
> identify the loop.
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
> Hey All,
> I was wanting to submit a feature request for loop detection.
> Specifically NOT SIP loop detection, but when another
> technology / B2BUA is involved where max-forwards can't be
> used. This is for big loops.
> The idea is similar to the pike module. However, you
> bascically look at the to_did and the source IP and if you see
> more than X calls in Y period, begin to reject them for Z seconds.
>
> Simple enough. This has come up a dozen times for me and for
> now I have to handle it with kludge of memcache, and perl
> scripts to detect these issues in my cdr.
>
> The loops are a bit nuts and are always the results of someone
> doing something stupid (but hey, it does happen). The loops
> are like, my customer sends me a call to one of thier own DIDs
> (they've misrouted it to me) and I send it to my carrier, who
> sends it to the pstn, back to my customer, back to me, etc..
> There may be a ss7 portion in there so it keeps looking like a
> new call on the SIP side.
> So without anything, this can clog up my call paths pretty
> quickly, the proposed feature would blacklist the source_ip
> to_did combination for a period of time to kill the loop.
>
> Thoughts?
> -Brett
>
> 
> 
>
> ___
> 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] Feature request: Loop detection

[Brett Nemeroff]

Yeah, that's a great idea actually, I could just concatenate some PVs to
form a key like $si-$rU.

On Mon, Jun 29, 2009 at 8:53 AM, Bogdan-Andrei Iancu  wrote:

> Hi Brett,
>
> This will be kind of pike but instead of using as input the source IP
> string, it should use a custom string you build form script, right ? this
> string will be a kind of key (logical one) to identify the loop.
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
>> Hey All,
>> I was wanting to submit a feature request for loop detection. Specifically
>> NOT SIP loop detection, but when another technology / B2BUA is involved
>> where max-forwards can't be used. This is for big loops.
>> The idea is similar to the pike module. However, you bascically look at
>> the to_did and the source IP and if you see more than X calls in Y period,
>> begin to reject them for Z seconds.
>>
>> Simple enough. This has come up a dozen times for me and for now I have to
>> handle it with kludge of memcache, and perl scripts to detect these issues
>> in my cdr.
>>
>> The loops are a bit nuts and are always the results of someone doing
>> something stupid (but hey, it does happen). The loops are like, my customer
>> sends me a call to one of thier own DIDs (they've misrouted it to me) and I
>> send it to my carrier, who sends it to the pstn, back to my customer, back
>> to me, etc.. There may be a ss7 portion in there so it keeps looking like a
>> new call on the SIP side.
>> So without anything, this can clog up my call paths pretty quickly, the
>> proposed feature would blacklist the source_ip to_did combination for a
>> period of time to kill the loop.
>>
>> Thoughts?
>> -Brett
>>
>> 
>>
>> ___
>> 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] Feature request: Loop detection

[Bogdan-Andrei Iancu]

Hi Brett,

This will be kind of pike but instead of using as input the source IP 
string, it should use a custom string you build form script, right ? 
this string will be a kind of key (logical one) to identify the loop.

Regards,
Bogdan

Brett Nemeroff wrote:
> Hey All,
> I was wanting to submit a feature request for loop 
> detection. Specifically NOT SIP loop detection, but when another 
> technology / B2BUA is involved where max-forwards can't be used. This 
> is for big loops. 
>
> The idea is similar to the pike module. However, you bascically look 
> at the to_did and the source IP and if you see more than X calls in Y 
> period, begin to reject them for Z seconds.
>
> Simple enough. This has come up a dozen times for me and for now I 
> have to handle it with kludge of memcache, and perl scripts to detect 
> these issues in my cdr.
>
> The loops are a bit nuts and are always the results of someone doing 
> something stupid (but hey, it does happen). The loops are like, my 
> customer sends me a call to one of thier own DIDs (they've misrouted 
> it to me) and I send it to my carrier, who sends it to the pstn, back 
> to my customer, back to me, etc.. There may be a ss7 portion in there 
> so it keeps looking like a new call on the SIP side. 
>
> So without anything, this can clog up my call paths pretty quickly, 
> the proposed feature would blacklist the source_ip to_did combination 
> for a period of time to kill the loop.
>
> Thoughts?
> -Brett
>
> 
>
> ___
> 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

[OpenSIPS-Users] Feature request: Loop detection

[Brett Nemeroff]

Hey All,I was wanting to submit a feature request for loop
detection. Specifically NOT SIP loop detection, but when another technology
/ B2BUA is involved where max-forwards can't be used. This is for big
loops.

The idea is similar to the pike module. However, you bascically look at the
to_did and the source IP and if you see more than X calls in Y period, begin
to reject them for Z seconds.

Simple enough. This has come up a dozen times for me and for now I have to
handle it with kludge of memcache, and perl scripts to detect these issues
in my cdr.

The loops are a bit nuts and are always the results of someone doing
something stupid (but hey, it does happen). The loops are like, my customer
sends me a call to one of thier own DIDs (they've misrouted it to me) and I
send it to my carrier, who sends it to the pstn, back to my customer, back
to me, etc.. There may be a ss7 portion in there so it keeps looking like a
new call on the SIP side.

So without anything, this can clog up my call paths pretty quickly, the
proposed feature would blacklist the source_ip to_did combination for a
period of time to kill the loop.

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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Bogdan-Andrei Iancu]

Thomas Gelf wrote:
> I've overseen that you already replied...
>
> Bogdan-Andrei Iancu wrote:
>   
>> ... The idea is:
>> 1) nat_traversal has more features on pinging area - can do pinging 
>> without registration, simply monitoring presence and call sessions
>> 2) to avoid code duplicity between nathelper and mediaproxy (nat 
>> tests, contact changing, etc)
>>
>> so far there was no action in this direction.
>> 
>
> IMO it would be worth to re-animate this plan, don't you think so?
>   
We can start filling in :
http://www.opensips.org/Development/Nattraversal

with a migration plan.

Regards,
Bogdan

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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Thomas Gelf]

I've overseen that you already replied...

Bogdan-Andrei Iancu wrote:
> ... The idea is:
> 1) nat_traversal has more features on pinging area - can do pinging 
> without registration, simply monitoring presence and call sessions
> 2) to avoid code duplicity between nathelper and mediaproxy (nat 
> tests, contact changing, etc)
> 
> so far there was no action in this direction.

IMO it would be worth to re-animate this plan, don't you think so?

Cheers,
Thomas


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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Thomas Gelf]

Hi Brett,

I'm responding being just a "user", so please don't trust my words too
much ;-) Afaik nat_traversal is an approach to move keepalive methods
to a single module, and let rtpproxy (currently: nathelper) and media-
proxy do what there name says: being just an RTP (media) proxy.

At the times where there was one single OpenSER project there might
also have been some personal preference regarding one or the other
module - and not everybody seemed to be amused to remove functionality
from the nathelper/rtpproxy combo.

Personally I consider nat_traversal's keep-alive mechanism far better
than the one provided with rtpproxy. I started three threads some day
ago, all of them around this topic. My intention was to initiate some
discussion / brainstorming - as the status quo is confusing, migration
in a good direction has been started a while ago, but now this movement
seems to have fallen asleep.

Imo we should figure out:

- whether there are still keepalive-features in nathelper, that are
  missing in nat_traversal (so far I found only what I mentioned in
  my thread "Comparing client_nat_test with nat_uac_test"

- if there is some k.o. criteria forbidding us to rename the nathelper
  module to "rtpproxy" and remove the keepalive functions

As told before, I'm not involved in development, just trying to make
suggestion from my position as "OpenSIP user" ;-)

Cheers,
Thomas


Brett Nemeroff wrote:
> Migration from nathelper? What's this you say?  :)
> 
> 
> Can you for us "users" out here explain the implication of a new
> "nathelper"? Is nat_traveral intended to replace nathelper?  What's new?
> Am I jumping the gun asking these questions? :)
> 
> Thanks!
> -Brett
> 
> 
> On Wed, Jun 10, 2009 at 1:07 PM, Bogdan-Andrei Iancu
>  > wrote:
> 
> Dan, what about this? this will accelerate the migration from nathelper
> to nat_tranversal module, what do you say?
> 
> As time as it is not technical nightmare (from implementation point of
> view), this feature make sense to me.
> 
> Regards,
> Bogdan


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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Bogdan-Andrei Iancu]

let's keep the guns away :D.

There is an older plan (since almost 1 year) of refurbishing the NAT 
related traversal modules:
nat_traversal module will be responsible for signalling part (ping + 
mangling)
mediaproxy and nathelper (future rtpproxy) will offer the 
interfacing to the media relays...

The idea is:
1) nat_traversal has more features on pinging area - can do pinging 
without registration, simply monitoring presence and call sessions
2) to avoid code duplicity between nathelper and mediaproxy (nat 
tests, contact changing, etc)

so far there was no action in this direction.

Regards,
Bogdan

Brett Nemeroff wrote:
> Migration from nathelper? What's this you say?  :)
>
>
> Can you for us "users" out here explain the implication of a new 
> "nathelper"? Is nat_traveral intended to replace nathelper?  What's 
> new? Am I jumping the gun asking these questions? :)
>
> Thanks!
> -Brett
>
>
> On Wed, Jun 10, 2009 at 1:07 PM, Bogdan-Andrei Iancu 
> mailto:bog...@voice-system.ro>> wrote:
>
> Dan, what about this? this will accelerate the migration from
> nathelper
> to nat_tranversal module, what do you say?
>
> As time as it is not technical nightmare (from implementation point of
> view), this feature make sense to me.
>
> Regards,
> Bogdan
>
> Thomas Gelf wrote:
> > I would also like to take occasion to propose a new feature:
> adding a
> > parameter named "keepalive_interval_avp", allowing to set individual
> > keepalive intervals for customers with special needs.
> >
> > Also "keepalive_method_avp" would be a useful addition. Both changes
> > would probably require modifications to keepalive_state_file and
> > corresponding internal structures, but I think this could be solved
> > in a backward-compatible manner.
> >
> > Best regards,
> > Thomas Gelf
> >
> >
> > ___
> > 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
>
>


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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Brett Nemeroff]

Migration from nathelper? What's this you say?  :)

Can you for us "users" out here explain the implication of a new
"nathelper"? Is nat_traveral intended to replace nathelper?  What's new? Am
I jumping the gun asking these questions? :)

Thanks!
-Brett


On Wed, Jun 10, 2009 at 1:07 PM, Bogdan-Andrei Iancu  wrote:

> Dan, what about this? this will accelerate the migration from nathelper
> to nat_tranversal module, what do you say?
>
> As time as it is not technical nightmare (from implementation point of
> view), this feature make sense to me.
>
> Regards,
> Bogdan
>
> Thomas Gelf wrote:
> > I would also like to take occasion to propose a new feature: adding a
> > parameter named "keepalive_interval_avp", allowing to set individual
> > keepalive intervals for customers with special needs.
> >
> > Also "keepalive_method_avp" would be a useful addition. Both changes
> > would probably require modifications to keepalive_state_file and
> > corresponding internal structures, but I think this could be solved
> > in a backward-compatible manner.
> >
> > Best regards,
> > Thomas Gelf
> >
> >
> > ___
> > 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
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Thomas Gelf]

Dan Pascu wrote:
> Hmm. Up to now I haven't encountered any device that doesn't reply to  
> a request. If it doesn't understand it, it should at least reply with  
> "Not supported". Having devices that completely ignore a request is  
> bad for communication, because you cannot discern between the case  
> where the device is not accessible anymore or it's just not willing to  
> reply.

Bad for communication -> it is. And I always thought the SIP universum
would be a perfect one ;-) However it was not necessarily the device's
fault - those ALG where both more than braindead :-(

> .. This is a background activity and one should not need to manually
> configure it too much or at all. It should simply work as automatically
> as possible.

Full ack!! As long as it doesn't do "everything" automatically managing
this "manually" is possible solely for small setups with just a few
thousand accounts (like ours) - of if your backoffice allows experienced
customers to manually adjust such settings, BUT:

> IMO, a better solution would be to make it adaptive. It could monitor  
> the replies and if it doesn't get a reply for a ping it can switch to  
> use the other method for that particular endpoint. For example the  
> first time the proxy has to send a ping to a newly added endpoint, it  
> should send both a NOTIFY and an OPTIONS. If it gets a reply for both,  
> it will use whatever the module is configured to use by default. If it  
> only gets a reply for one of them, it will use that no matter what the  
> module uses by default.

That would be absolutely great! It would for sure be more work for you,
but I would STRONGLY opt for this variant - great proposal!

Cheers,
Thomas Gelf


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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Dan Pascu]

On 11 Jun 2009, at 14:46, Thomas Gelf wrote:
> As you asked for real-world example for the "per-user-ping-type"
> feature request: while preparing our new VoIP platform I've switched
> to nat_traversal and configured NOTIFY, as it seemed to be the more
> elegant variant.
>
> This went well, unless I've met problems with some UACs (tested AVM,
> Snom, Grandsteam - don't remember which one had the problem) behind
> an enterprise firewall (Nokia Checkpoint or Juniper Netscreen, both
> cluster installations - don't remember even here which one it has
> been). There have no longer been no replies to my NOTIFY, I switched
> to OPTIONS and it worked.

Hmm. Up to now I haven't encountered any device that doesn't reply to  
a request. If it doesn't understand it, it should at least reply with  
"Not supported". Having devices that completely ignore a request is  
bad for communication, because you cannot discern between the case  
where the device is not accessible anymore or it's just not willing to  
reply.

> I must confess that I didn't try to find out who caused the problem
> (ALG or UAC) - I've just seen issues with NOTIFY and opted for the
> second option (OPTIONS). Nonetheless I would welcome the possibility
> to switch back to NOTIFY and use OPTIONS just where I encounter
> problems.


There are some problems I see with your proposal:

1. It adds little value to the solution, but increases a lot the need  
to provision, monitor and manage this per device. This is a background  
activity and one should not need to manually configure it too much or  
at all. It should simply work as automatically as possible.

2. Sending pings with different methods may require different headers  
to be present. So it is not enough to just specify the method. It  
should rather have a few available profiles and let you choose from  
them.


IMO, a better solution would be to make it adaptive. It could monitor  
the replies and if it doesn't get a reply for a ping it can switch to  
use the other method for that particular endpoint. For example the  
first time the proxy has to send a ping to a newly added endpoint, it  
should send both a NOTIFY and an OPTIONS. If it gets a reply for both,  
it will use whatever the module is configured to use by default. If it  
only gets a reply for one of them, it will use that no matter what the  
module uses by default.


--
Dan




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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Dan Pascu]

On 11 Jun 2009, at 14:13, Bogdan-Andrei Iancu wrote:
>> I explicitly did not implement UDP pings, because over 40% of the  
>> routers out there will not keep the NAT open if they do not receive  
>> something from inside the NAT. As a consequence UDP pings are  
>> useless with those devices and unfortunately you cannot know which  
>> work and which don't. While UDP pings are cheaper and thus more  
>> appealing, in their case it applies the rule that you get what you  
>> pay for.
>
> I agree with you - to be honest I'm using only SIP ping so  
> should we obsolete the UDP ping :) ?

I think we should.

--
Dan




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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Thomas Gelf]

Bogdan-Andrei Iancu wrote:
> I agree with you - to be honest I'm using only SIP ping so should we 
> obsolete the UDP ping :) ?

I have no concerns regarding this. IMO the additional load does not
really hurt small systems - and large systems should already be designed
to scale out ;-) Seriously: the only reason for "pings" is keeping "UDP
connections" (even if there is no such thing) alive. Most systems that
require such things need traffic from "inside" - so UDP ping is mostly
pretty useless, trash it!

>> No extra function is needed, just some extra avps.
> makes sense - if there are not so many vals to push.

In my initial feature request I mentioned keepalive_interval_avp and
keepalive_method_avp - while the naming could be subject to discussions
those should be the only two required AVPs to satisfy the proposed
enhancements.

It seems that we agree on the interval-part - this would allow to
use a not-so-frequent default interval (saving ressources) and grant
the option to make it more "aggressive" for users having issues with
the default setting.

As you asked for real-world example for the "per-user-ping-type"
feature request: while preparing our new VoIP platform I've switched
to nat_traversal and configured NOTIFY, as it seemed to be the more
elegant variant.

This went well, unless I've met problems with some UACs (tested AVM,
Snom, Grandsteam - don't remember which one had the problem) behind
an enterprise firewall (Nokia Checkpoint or Juniper Netscreen, both
cluster installations - don't remember even here which one it has
been). There have no longer been no replies to my NOTIFY, I switched
to OPTIONS and it worked.

I must confess that I didn't try to find out who caused the problem
(ALG or UAC) - I've just seen issues with NOTIFY and opted for the
second option (OPTIONS). Nonetheless I would welcome the possibility
to switch back to NOTIFY and use OPTIONS just where I encounter
problems.

Best regards,
Thomas Gelf



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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Bogdan-Andrei Iancu]

Dan Pascu wrote:
>
> On 11 Jun 2009, at 12:23, Bogdan-Andrei Iancu wrote:
>>> Anyway, I'm open to patch submissions. But first let's see if these 
>>> additions really serve real use cases that are not covered by the 
>>> existing design, or just provide suboptimal solutions that could be 
>>> achieved with the existing code. I'd like to hear some arguments and 
>>> examples of real use cases for them. I'm interested to avoid getting 
>>> in the creeping featurism zone.
>>
>> From my personal opinion , what makes sense here is:
>>   - to be able to enable/disable pinging from script (per each 
>> REGISTER  or dialog) - I guess the module already does this
>
> This already works.
>
>>
>>   - to allow custom ping interval per ping session (similar as we do 
>> with timeouts in TM - setting an AVP when enabling the ping, maybe)
>
> As I said, I can see why this could be useful.
>
>>
>>   - to allow selection of ping type (UDP versus SIP) by simply 
>> setting a flag (like we do now in nathelper - default is UDP ping and 
>> if you set an extra flag, you get SIP  ping).
>>
>
> I explicitly did not implement UDP pings, because over 40% of the 
> routers out there will not keep the NAT open if they do not receive 
> something from inside the NAT. As a consequence UDP pings are useless 
> with those devices and unfortunately you cannot know which work and 
> which don't. While UDP pings are cheaper and thus more appealing, in 
> their case it applies the rule that you get what you pay for.

I agree with you - to be honest I'm using only SIP ping so should we 
obsolete the UDP ping :) ?
>
>> So three infos: if ping or not, the interval and the type - maybe we 
>> can combine all this into an enable_ping() functions ?
>
> No extra function is needed, just some extra avps.
makes sense - if there are not so many vals to push.


Regards,
Bogdan

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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Dan Pascu]

On 11 Jun 2009, at 12:23, Bogdan-Andrei Iancu wrote:
>> Anyway, I'm open to patch submissions. But first let's see if these  
>> additions really serve real use cases that are not covered by the  
>> existing design, or just provide suboptimal solutions that could be  
>> achieved with the existing code. I'd like to hear some arguments  
>> and examples of real use cases for them. I'm interested to avoid  
>> getting in the creeping featurism zone.
>
> From my personal opinion , what makes sense here is:
>   - to be able to enable/disable pinging from script (per each  
> REGISTER  or dialog) - I guess the module already does this

This already works.

>
>   - to allow custom ping interval per ping session (similar as we do  
> with timeouts in TM - setting an AVP when enabling the ping, maybe)

As I said, I can see why this could be useful.

>
>   - to allow selection of ping type (UDP versus SIP) by simply  
> setting a flag (like we do now in nathelper - default is UDP ping  
> and if you set an extra flag, you get SIP  ping).
>

I explicitly did not implement UDP pings, because over 40% of the  
routers out there will not keep the NAT open if they do not receive  
something from inside the NAT. As a consequence UDP pings are useless  
with those devices and unfortunately you cannot know which work and  
which don't. While UDP pings are cheaper and thus more appealing, in  
their case it applies the rule that you get what you pay for.

> So three infos: if ping or not, the interval and the type - maybe we  
> can combine all this into an enable_ping() functions ?

No extra function is needed, just some extra avps.

>
>
> All these options will give you the possibility to do all the crazy  
> combinations from script. At least I think so :)


--
Dan




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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Bogdan-Andrei Iancu]

Hi Dan,

Dan Pascu wrote:
>
> On 10 Jun 2009, at 21:07, Bogdan-Andrei Iancu wrote:
>
>> Dan, what about this? this will accelerate the migration from 
>> nathelper to nat_tranversal module, what do you say?
>>
>
> I can see the benefit of having the keepalive interval customizable 
> per user, but I'm not sure what's the advantage of having the 
> keepalive method customizable per user. In my experience all devices 
> I've encountered respond to either OPTIONS or NOTIFY and in the end it 
> doesn't really matter if they give a positive or negative reply for 
> that matter. All it matters that they give a reply back. I would be 
> curious to hear how the keepalive method per user can help and in what 
> cases. If one can imagine a use case for custom keepalive methods, I 
> would rather see that on a per device basis not per SIP account basis.
>
> Anyway, I'm open to patch submissions. But first let's see if these 
> additions really serve real use cases that are not covered by the 
> existing design, or just provide suboptimal solutions that could be 
> achieved with the existing code. I'd like to hear some arguments and 
> examples of real use cases for them. I'm interested to avoid getting 
> in the creeping featurism zone.

 From my personal opinion , what makes sense here is:
- to be able to enable/disable pinging from script (per each 
REGISTER  or dialog) - I guess the module already does this
- to allow custom ping interval per ping session (similar as we do 
with timeouts in TM - setting an AVP when enabling the ping, maybe)
- to allow selection of ping type (UDP versus SIP) by simply setting 
a flag (like we do now in nathelper - default is UDP ping and if you set 
an extra flag, you get SIP  ping).

So three infos: if ping or not, the interval and the type - maybe we can 
combine all this into an enable_ping() functions ?

All these options will give you the possibility to do all the crazy 
combinations from script. At least I think so :)

Regards,
Bogdan

>
>> As time as it is not technical nightmare (from implementation point 
>> of view), this feature make sense to me.
>>
>> Regards,
>> Bogdan
>>
>> Thomas Gelf wrote:
>>> I would also like to take occasion to propose a new feature: adding a
>>> parameter named "keepalive_interval_avp", allowing to set individual
>>> keepalive intervals for customers with special needs.
>>>
>>> Also "keepalive_method_avp" would be a useful addition. Both changes
>>> would probably require modifications to keepalive_state_file and
>>> corresponding internal structures, but I think this could be solved
>>> in a backward-compatible manner.
>>>
>>> Best regards,
>>> Thomas Gelf
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>
>
> -- 
> Dan
>
>
>
>


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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Dan Pascu]

On 10 Jun 2009, at 21:07, Bogdan-Andrei Iancu wrote:

> Dan, what about this? this will accelerate the migration from  
> nathelper to nat_tranversal module, what do you say?
>

I can see the benefit of having the keepalive interval customizable  
per user, but I'm not sure what's the advantage of having the  
keepalive method customizable per user. In my experience all devices  
I've encountered respond to either OPTIONS or NOTIFY and in the end it  
doesn't really matter if they give a positive or negative reply for  
that matter. All it matters that they give a reply back. I would be  
curious to hear how the keepalive method per user can help and in what  
cases. If one can imagine a use case for custom keepalive methods, I  
would rather see that on a per device basis not per SIP account basis.

Anyway, I'm open to patch submissions. But first let's see if these  
additions really serve real use cases that are not covered by the  
existing design, or just provide suboptimal solutions that could be  
achieved with the existing code. I'd like to hear some arguments and  
examples of real use cases for them. I'm interested to avoid getting  
in the creeping featurism zone.

> As time as it is not technical nightmare (from implementation point  
> of view), this feature make sense to me.
>
> Regards,
> Bogdan
>
> Thomas Gelf wrote:
>> I would also like to take occasion to propose a new feature: adding a
>> parameter named "keepalive_interval_avp", allowing to set individual
>> keepalive intervals for customers with special needs.
>>
>> Also "keepalive_method_avp" would be a useful addition. Both changes
>> would probably require modifications to keepalive_state_file and
>> corresponding internal structures, but I think this could be solved
>> in a backward-compatible manner.
>>
>> Best regards,
>> Thomas Gelf
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>


--
Dan




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

Re: [OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Bogdan-Andrei Iancu]

Dan, what about this? this will accelerate the migration from nathelper 
to nat_tranversal module, what do you say?

As time as it is not technical nightmare (from implementation point of 
view), this feature make sense to me.

Regards,
Bogdan

Thomas Gelf wrote:
> I would also like to take occasion to propose a new feature: adding a
> parameter named "keepalive_interval_avp", allowing to set individual
> keepalive intervals for customers with special needs.
>
> Also "keepalive_method_avp" would be a useful addition. Both changes
> would probably require modifications to keepalive_state_file and
> corresponding internal structures, but I think this could be solved
> in a backward-compatible manner.
>
> Best regards,
> Thomas Gelf
>
>
> ___
> 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

[OpenSIPS-Users] Feature-request: AVPs for nat_traversal

[Thomas Gelf]

I would also like to take occasion to propose a new feature: adding a
parameter named "keepalive_interval_avp", allowing to set individual
keepalive intervals for customers with special needs.

Also "keepalive_method_avp" would be a useful addition. Both changes
would probably require modifications to keepalive_state_file and
corresponding internal structures, but I think this could be solved
in a backward-compatible manner.

Best regards,
Thomas Gelf


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

Re: [OpenSIPS-Users] feature request feedback

[Brett Nemeroff]

Well,I think for best_match, I think it's main use is routing lookups. I
could see a variant of it that can handle subnet matching as well. After
all, the whole point is to detect and rewrite, right?

So in general, I don't see best_match doing a whole lot other than routing..
I can tell you, I'd probably also use it for rating and costing in realtime.
But likewise, it'd be the kind of thing I take a dialed number or the ANI
and look for a best match pattern to retrieve the route, cost, or rate. For
ANI, you could use it for RPID pattern enforcement. I think it would be a
good addition. It would allow for the creation of a lot of applications
based on the memory caching backend.

As for using an external store, I think it's a great idea. However,
scriptwriters need to remember that memcache isn't meant to be
a reliable data store. So it's important that people write their scripts
with that in mind. In other words, you always check the cache for a value,
and if it isn't there, then load the cache with the value from the database.
It's got to be ok for the cache to be empty. Preloading the cache should
always be an option as well (especially for larger datastores with higher
cardinality).

I suppose best_match could be done in a while loop in script.. but honestly,
I think that's pretty messy. I think it would be a good addition.

Thanks for your consideration. :)
-Brett




On Tue, May 26, 2009 at 10:54 AM, Bogdan-Andrei Iancu <
bog...@voice-system.ro> wrote:

> Hi Brett,
>
> The idea of having "families / classes/ groups" for cached values is indeed
> a nice and useful one. I will love to have this in the next release.
>
> But regarding the "best_match" do you think there is any other application
> for it except the routing part?
>
> An idea that I would like to explore is how to use an external cache server
> (like memcached) during t restarts to avoid the penalty of going through the
> db (save and load) - like you restart opensips, but the memory content stays
> the same.
>
> Regards,
> Bogdan
>
> Brett Nemeroff wrote:
>
>> Hey All,
>> I just had this revelation today about a potential feature and I wanted to
>> run it by the group to see if there was any interest in it. I tried posting
>> it to the tracker, but sf.net  keeps failing (I'm getting
>> server busy messages.. grumble..)
>>
>>
>> So I had talked before about "memcache families". This is where you can
>> store data into separate memcache namespaces. This would be useful to store
>> and purge large sets for data at one time..
>>
>> Think for a minute about routes being loaded into memcache
>>
>> Say for example, if I had 10 customers. Each with their own unique route
>> table with 3 million records each. As one table, that would be 30 million
>> total routes.. Which may be slow to traverse (not sure, haven't tested).
>> However if each route table is in it's own family (ie: namespace in
>> memcache) it would only be 3 million. Which should be very fast. Also, if
>> I'm changing just one route, I wouldn't have to purge my entire memcache
>> store to update it.. just the one route table effected.. Also, I use
>> memcache to store my IP to account relationships.. so we don't need those to
>> reload either.. That's the idea of memcache families; only update the family
>> that makes sense. It would only add one additional option to the cache_store
>> and cache_fetch functions (family). And would also add a function
>> cache_family_purge, which would delete an entire family of data.
>>
>> Now building on that idea is my next feature request (which really doesn't
>> depend on memcache families, but it makes sense to combine the two):
>> This is a request for the ability to "find_best_match" in memcache family.
>> This is a function that you'd pass a memcache family to and it would take
>> the input value (say $rU for example) and keep removing a character from it
>> until it hit a match and then return the cached value. Of course, this also
>> depends on preloaded cache values. Which I'd load from an external script
>> upon startup.
>> Function usage would be like this:
>> find_best_match("","","",)
>>
>> There is a *ton* that can be done with this.. My mind is spinning. :) ie:
>> return 1.2.3.4_ Then use the transformations to pull the prefix out
>> and push it into the $rU.. Very powerful.. And you wouldn't even need custom
>> modules anymore for routing.
>>
>> So if the dialed number is 5125551212 and in memcache I have: 512555 ->
>> 1.2.3.4 It would hit memcache like this: if
>> (find_best_match("local","$avp(s:routetable)","$rU",$avp(s:routestring))) {
>> $rD = $(avp(s:routestring){s.select,0,_}); # rewrite destination $rU = $rU +
>> $(avp(s:routestring){s.select,1,_}); # add prefix if defined } else {
>> sl_send_reply("404","No Route"); exit; } 5125551212 -> No Match 512555121 ->
>> No Match 51255512 -> No Match 5125551 -> No Match 512555 -> 1.2.3.4
>>  Thanks for your consideration and feedback!!
>> -Brett
>>
>> 

Re: [OpenSIPS-Users] feature request feedback

[Bogdan-Andrei Iancu]

Hi Brett,

The idea of having "families / classes/ groups" for cached values is 
indeed a nice and useful one. I will love to have this in the next release.

But regarding the "best_match" do you think there is any other 
application for it except the routing part?

An idea that I would like to explore is how to use an external cache 
server (like memcached) during t restarts to avoid the penalty of going 
through the db (save and load) - like you restart opensips, but the 
memory content stays the same.

Regards,
Bogdan

Brett Nemeroff wrote:
> Hey All,
> I just had this revelation today about a potential feature and I 
> wanted to run it by the group to see if there was any interest in it. 
> I tried posting it to the tracker, but sf.net  keeps 
> failing (I'm getting server busy messages.. grumble..)
>
> So I had talked before about "memcache families". This is where you 
> can store data into separate memcache namespaces. This would be useful 
> to store and purge large sets for data at one time..
>
> Think for a minute about routes being loaded into memcache
>
> Say for example, if I had 10 customers. Each with their own unique 
> route table with 3 million records each. As one table, that would be 
> 30 million total routes.. Which may be slow to traverse (not sure, 
> haven't tested). However if each route table is in it's own family 
> (ie: namespace in memcache) it would only be 3 million. Which should 
> be very fast. Also, if I'm changing just one route, I wouldn't have to 
> purge my entire memcache store to update it.. just the one route table 
> effected.. Also, I use memcache to store my IP to account 
> relationships.. so we don't need those to reload either.. That's the 
> idea of memcache families; only update the family that makes sense. It 
> would only add one additional option to the cache_store and 
> cache_fetch functions (family). And would also add a function 
> cache_family_purge, which would delete an entire family of data.
>
> Now building on that idea is my next feature request (which really 
> doesn't depend on memcache families, but it makes sense to combine the 
> two):
> This is a request for the ability to "find_best_match" in memcache 
> family. This is a function that you'd pass a memcache family to and it 
> would take the input value (say $rU for example) and keep removing a 
> character from it until it hit a match and then return the cached 
> value. Of course, this also depends on preloaded cache values. Which 
> I'd load from an external script upon startup.
> Function usage would be like this: 
> find_best_match("","","",)
>  
>
> There is a *ton* that can be done with this.. My mind is spinning. :) 
> ie: return 1.2.3.4_ Then use the transformations to pull the 
> prefix out and push it into the $rU.. Very powerful.. And you wouldn't 
> even need custom modules anymore for routing.
>
> So if the dialed number is 5125551212 and in memcache I have: 512555 
> -> 1.2.3.4 It would hit memcache like this: if 
> (find_best_match("local","$avp(s:routetable)","$rU",$avp(s:routestring))) 
> { $rD = $(avp(s:routestring){s.select,0,_}); # rewrite destination $rU 
> = $rU + $(avp(s:routestring){s.select,1,_}); # add prefix if defined } 
> else { sl_send_reply("404","No Route"); exit; } 5125551212 -> No Match 
> 512555121 -> No Match 51255512 -> No Match 5125551 -> No Match 512555 
> -> 1.2.3.4
>  
> Thanks for your consideration and feedback!!
> -Brett
>
> 
>
> ___
> 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

[OpenSIPS-Users] feature request feedback

[Brett Nemeroff]

Hey All,I just had this revelation today about a potential feature and I
wanted to run it by the group to see if there was any interest in it. I
tried posting it to the tracker, but sf.net keeps failing (I'm getting
server busy messages.. grumble..)

So I had talked before about "memcache families". This is where you can
store data into separate memcache namespaces. This would be useful to store
and purge large sets for data at one time..

Think for a minute about routes being loaded into memcache

Say for example, if I had 10 customers. Each with their own unique route
table with 3 million records each. As one table, that would be 30 million
total routes.. Which may be slow to traverse (not sure, haven't tested).
However if each route table is in it's own family (ie: namespace in
memcache) it would only be 3 million. Which should be very fast. Also, if
I'm changing just one route, I wouldn't have to purge my entire memcache
store to update it.. just the one route table effected.. Also, I use
memcache to store my IP to account relationships.. so we don't need those to
reload either.. That's the idea of memcache families; only update the family
that makes sense. It would only add one additional option to the cache_store
and cache_fetch functions (family). And would also add a function
cache_family_purge, which would delete an entire family of data.

Now building on that idea is my next feature request (which really doesn't
depend on memcache families, but it makes sense to combine the two):
This is a request for the ability to "find_best_match" in memcache family.
This is a function that you'd pass a memcache family to and it would take
the input value (say $rU for example) and keep removing a character from it
until it hit a match and then return the cached value. Of course, this also
depends on preloaded cache values. Which I'd load from an external script
upon startup.
 Function usage would be like this:
find_best_match("","","",)

There is a *ton* that can be done with this.. My mind is spinning. :) ie:
return 1.2.3.4_ Then use the transformations to pull the prefix out
and push it into the $rU.. Very powerful.. And you wouldn't even need custom
modules anymore for routing.
So if the dialed number is 5125551212 and in memcache I have: 512555 ->
1.2.3.4 It would hit memcache like this: if
(find_best_match("local","$avp(s:routetable)","$rU",$avp(s:routestring))) {
$rD = $(avp(s:routestring){s.select,0,_}); # rewrite destination $rU = $rU +
$(avp(s:routestring){s.select,1,_}); # add prefix if defined } else {
sl_send_reply("404","No Route"); exit; } 5125551212 -> No Match 512555121 ->
No Match 51255512 -> No Match 5125551 -> No Match 512555 -> 1.2.3.4
Thanks for your consideration and feedback!!
-Brett
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users