James,
We have found with out users that some of them put the phones on public
IP's. If the default password is not changed, no matter how hard the
password is they will get in. Also try using characters like @:^# in your
passwords.
Regards,
Dovid
_
From:
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,
Hello,
I¹m having a bit of a problem with the presence mechanism provided by the
OpenSIPS server. From one device I send information with a PUBLISH and the
pidf xml looks like this:
?xml version='1.0' encoding='UTF-8'?
presence xmlns:rpid=urn:ietf:params:xml:ns:pidf:rpid
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,
I'm using Opensips to dispatch to 2 servers - serverA, serverB. When one of the
servers is down, Opensips is dispatching to the active one correctly. However,
when both of them are Active, it's picking only one of them and ignoring the
other; e.g.,
when serverB is down, dispatches to
Hi, Matt!
Are you sure you are not using the same hashing value all the time?
If yes, can you increase your debugging level to 6 and provide more
information? I would be looking in the opensips log for lines that
contain the following strings: ds_hash_pvar: Hashing and
ds_select_dst: alg
Hi Răzvan,
Yes, I'm using the same hashing values - the values I assign to the PV are also
passed to the ds_select_dst correctly as far as I can see. Here is a typical
debug output:
DBG:dispatcher:ds_hash_pvar: Hashing 061002!
DBG:dispatcher:ds_select_dst: alg hash [1], id [1]
Hi, Matt!
So for different hashed strings like:
DBG:dispatcher:ds_hash_pvar: Hashing 061002!
you always get the same output:
DBG:dispatcher:ds_select_dst: alg hash [1], id [1]
Also, are you assigning different weights for any of the Asterisk?
Regards,
--
Ra(zvan Crainea
OpenSIPS Developer
Hi Răzvan,
I don't assign any weights, and I use the dispatcher.list file:
1 sip:x.x.x.11:5060
1 sip:x.x.x.12:5060
1 sip:x.x.x.13:5060
When there are only 2 servers in that file, I always get:
DBG:dispatcher:ds_select_dst: alg hash [1], id [1] and dispatcher selects the
2nd entry.
When there
13 matches
Mail list logo
