en many carriers do this.
>>
>>
>>
>> Ben Newlin
>>
>>
>>
>> *From: *Users on behalf of Mark
>> Farmer
>> *Reply-To: *OpenSIPS users mailling list
>> *Date: *Friday, April 26, 2019 at 8:59 AM
>> *To: *OpenSIPS users mailling
8:59 AM
> *To: *OpenSIPS users mailling list
> *Subject: *Re: [OpenSIPS-Users] check_source_address()
>
>
>
> Thank you, that makes sense now. I will keep that in mind for the future.
>
> In the meantime I have raised a query with our provider.
>
>
>
> Additionally, I
Farmer
Reply-To: OpenSIPS users mailling list
Date: Friday, April 26, 2019 at 8:59 AM
To: OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] check_source_address()
Thank you, that makes sense now. I will keep that in mind for the future.
In the meantime I have raised a query with our
Thank you, that makes sense now. I will keep that in mind for the future.
In the meantime I have raised a query with our provider.
Additionally, I realised this morning that at our request, our provider is
sending calls to us via a domain name instead of an IP. Would that likely
cause the issue
On 25.04.2019 17:11, Mark Farmer wrote:
Thanks so much for helping with this.
I have applied the suggested config but the result is the same.
OpenSIPS routes the RE-INVITE to itself and it never gets routed back
to the Asterisk box.
If the 2nd Route header in the RE-INVITE is the IP of the
Thanks so much for helping with this.
I have applied the suggested config but the result is the same. OpenSIPS
routes the RE-INVITE to itself and it never gets routed back to the
Asterisk box.
If the 2nd Route header in the RE-INVITE is the IP of the other interface -
will that not always be the
On 24.04.2019 20:10, Mark Farmer wrote:
Sure, I'll send the pcap off list.
It seems you are performing an interface switching operation when
routing out,
which leads to a double Record-Route header. While this is completely fine,
you should be aware that OpenSIPS handles a double RR'ed
Sure, I'll send the pcap off list.
TIA
Mark.
On Wed, 24 Apr 2019 at 17:47, Liviu Chircu wrote:
> From what I understand, your OpenSIPS ends up routing those mid-dialog
> requests to itself! This is definitely bogus, unless there is some
> spiraling logic involved, which I doubt to be the
From what I understand, your OpenSIPS ends up routing those mid-dialog
requests to itself! This is definitely bogus, unless there is some
spiraling logic involved, which I doubt to be the case. Can you upload
text file or pcap with a network capture of your call attempt, so we can
figure out
Hi, thanks for the reply.
I added the xlog which told me that it was trying to find permissions for
itself - this is an mhomed server. That seems a bit odd to me but I added
the permissions and the 403 responses stopped. - Is this the correct thing
to do?
The issue I have now is that the
Hi, Mark!
The best way to proceed is to add an xlog("checking $si:$sp\n") before
check_source_address(), then some useful xlog() messages on each if
branch, so we can confirm the theory that this is an OpenSIPS issue, and
not a problem specific to your setup.
Liviu Chircu
OpenSIPS Developer
Should've added I'm running OpenSIPS 2.4.4
Mark.
On Tue, 23 Apr 2019 at 12:10, Mark Farmer wrote:
> Hi everyone,
>
> I'm seeing some odd behaviour in tha initial requests are allowed but
> RE-INVITES are resulting in 403. From my logging I can see the INVITE
> coming in so I think it must be
Hello,
I see the logs saying :
DBG:permissions:match_subnet_table: match found in the subnet table
Have you checked the return code of the function, at script level ? it
is true or false ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On
Hi Bogdan, here snippet of used code:
*if(!check_source_address(0)){
xlog(LOG: Controllo dell'IP sorgente!\n );
if (!proxy_authorize(, subscriber)) {
proxy_challenge(, 0);
Hello,
I'm a bit confused, as what you are claiming is a bit of a nonces - you
say that is with NOT or without, for the same src IP, you end up in the
if() block all the time ?!?!
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04/12/2013
Hi all, i would arise this post because it's happening same thing to me.
Opensips v. : OpenSIPS (1.9.0-notls (i386/linux))
Database entries:
mysql select * from address;
++-+---+--+--+---+-+--+
| id | grp | ip| mask | port | proto
Răzvan has fixed this issue with the latest trunk. I have tested and all
is good now.
Thanks Razvan and Ovidiu.
On Thu, Feb 2, 2012 at 1:03 PM, duane.lar...@gmail.com wrote:
I talked a little with Ovidiu offline so I went ahead and opened a bug
ticket.
Ticket is
3483337
I will chime into say that I ran into the same issue when attempting
to upgrade to the latest trunk. I just have not had time to open a bug
and get a test setup to do in-depth trouble shooting.
On Thu, Feb 2, 2012 at 8:38 AM, duane.lar...@gmail.com wrote:
I just upgraded my b2bua opensips
Hmmm. That would suck if its a bug. Just to follow up on my last email
here is what I see when I start OpenSIPS. You can see that OpenSIPS grabs
all the info from the address table
Feb 2 10:39:32 proxy01 /usr/local/sbin/opensips[14584]:
DBG:permissions:reload_address_table: number of rows in
Check the in memory cache:
http://www.opensips.org/html/docs/modules/devel/permissions.html#id293903
See address_dump and subnet_dump.
At start up, opensips will cache everything in memory.
Regards,
Ovidiu Sas
--
VoIP Embedded, Inc.
http://www.voipembedded.com
On Thu, Feb 2, 2012 at 11:38 AM,
This is what I see
Proxy01:/var/log# opensipsctl fifo address_dump
15 173.XXX.XXX.XXX,3, 5060, 0, NULL, NULL
20 216.82.224.202,2, 5060, 0, NULL, NULL
34 64.2.142.15,4, 5060, 0, NULL, NULL
50 216.82.225.202,2, 5060, 0, NULL, NULL
63 173.XXX.XXX.XXX,10, 5060, 0, NULL, NULL
85
Yeah. It is the first one in the list (Number 15 in the dump). Like I
said this worked before I upgraded.
On Thu, Feb 2, 2012 at 10:56 AM, Ovidiu Sas o...@voipembedded.com wrote:
The subnet is empty because you don't have any subnets (the mask is
set to 32 and therefore you have full IP
I talked a little with Ovidiu offline so I went ahead and opened a bug
ticket.
Ticket is
3483337 check_source_address broken in latest trunk Open 2012-02-02 nobody
duanelarson123 None 5
Thanks for the help Ovidiu.
On , Duane Larson duane.lar...@gmail.com wrote:
Yeah. It is the first
Hi Jeff,
There was a problem with the check_address_source function. It has been
fixed starting with rev 6262. Please update and let me know if you find any
other problems.
Thank you!
Irina Stanescu
On Wed, Oct 14, 2009 at 1:19 AM, Brad Bendy brad.be...@benganetworks.comwrote:
I know on mine
Hi Irina,
The update seems to have taken care of the problem. Thanks. I’m noticing an
issue with check_address I’ll put in a separate message.
- Jeff
On 10/14/09 10:05 AM, Irina Stanescu ironmi...@gmail.com wrote:
Hi Jeff,
There was a problem with the check_address_source function. It
I know on mine I had to set port to 5060 (5068 in your case) or whatever
you want, otherwise it would not work for me.
Im sure you can use a * for any port number as well, but I have not
tried that.
Jeff Pyle wrote:
Hello,
A request arrives at Opensips 1.6 from address 175.88.228.19:5068 on
26 matches
Mail list logo
