Hi!
I'm running ser-0.9.6, on FreeBSD 6.1-stable, database backend
is postgresql version 8.1.3.
Today I got errors in logfiles, saying:
messages.2.bz2:May 29 14:35:03 <XXX> /usr/local/sbin/ser[51448]:
ERROR:avpops:dbrow2avp: dbrow contains NULL fields
The similar problem reported in:
http://lists.iptel.org/pipermail/serusers/2005-May/019681.html
with much more detailed description of error, database contents
and config samples.
Patch is trivial, and looks more like a fix to copy'n'paste error:
in mysql/val.c function str2val states:
if (!_s) {
memset(_v, 0, sizeof(db_val_t));
VAL_TYPE(_v) = _t;
VAL_NULL(_v) = 1;
return 0;
}
VAL_NULL(_v) = 0;
and the last line mentions that 'well, that's value is not NULL'.
In postgresql/db_val.c, line 182, function str2valp, the same statement is the:
if (!_s) {
DLOG("str2valp", "got a null value");
VAL_TYPE(_v) = _t;
VAL_NULL(_v) = 1;
return 0;
}
without explicit notification that this is not-NULL value.
More than, nowhere else in this function VAL_NULL(_v) not set to 0.
So, if a value _v.val contained anyting but 0 at the function start,
resulting value will be threated as NULL despite the fact, that _s is NOT NULL.
Patch is obvious, just add VAL_NULL(_v)=0; after cited block (line 188) and
everyting will be ok.
At least for me it's ok for some hours :)
Hi ,
I tried to call from one nokia sip (E61 and other models )phone to another nokia sip phone. The call works fine. The problem comes only when I call from Phone A to Phone B and then immediately cancel the call(from Phone A). The Phone A will hangup the call as it sent CANCEL but the SER will ignore this CANCEL and still send INVITE to Phone B resulting in a ghost call situation.
I tried to capture a log of message and found that Phone A "CANCEL" message is received on SER even before any provisional response from Phone B. Therefor SER doesnot relay this CANCEL request to Phone B. I even checked RFC which clearly says that UAC should not send CANCEL untill it receives any provisional response. I talked to Nokia expert and they said the 100 Trying message from your server is considered as provisional response, therefor behaviour of client is absolutely correct.
Is there any way I can stop 100 Trying message and still run statefull SER, so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards,
Abdul Qadir
---------------------------------
Don't be flakey. Get Yahoo! Mail for Mobile and
always stay connected to friends.
Guys,
thanks to your support (both Bogdan and Daniel), I found out that
there was nothing wrong with the server and t_onreply handling, but
the INVITE was taking another routing three than the one I was
checking and therefore never hit the t_on_reply section I wanted.
This being said, I consider this issue resolved.
Cheers,
Dan
Hi!
i wonder if there is a timer which controls the timeout for provisional
replies.
E.g. I want to cancel an INVITE and retry another gateway if the gateway
does not respond with 100 (or 180) in a certain time.
regards
klaus
--
Klaus Darilion
nic.at
Hi,
openser 1.1.1 is now available in binary format for several embedded patforms:
- Linksys NSLU
- Synology DS-101(g+)
- Iomega NAS 100d
- Freecom FSG-3
- Qnap TurboStation
...
and all routers supported by the oleg or dd-wrt distributions.
Check out http://www.nslu2-linux.org
Regards,
Ovidiu Sas
Hi, all.
I know this is a little bit out off Topic. I'm trying to install
CDRTool for CDR normalization and billing with SER. I get the things allmost
working (freeradius + MySQL + SER) But i can't get the CDRs normalized with
price. Can anybody please help me or post a CDRTool global.inc working file?
.
Thanks a lot in advance any help will be highly apreciated!
Guys,
I'm wondering what solutions there are to this problem. We have some
NATed clients making outgoing calls. The NAT traversal is done using
mediaproxy and works fine. However, we have a problem with 183 responses
and early media ringing sounds.
The problem is that before the NATed client starts sending out RTP data,
mediaproxy doesn't know which IP and port to send the RTP traffic to.
Some of the NETed clients don't start sending out RTP traffic until the
call is connected, therefore none of the early media (ringing sounds)
reaches the user - making it sound like dead air.
Any ideas?
Jeff
Hi everybody,
OpenSER 1.2.0 has now the capability to do DNS based failover, according
to RFC3263 (http://www.ietf.org/rfc/rfc3263.txt).
The SIP resolver was enhanced to to be able to save and resume later the
DNS queries in order to get all possible IP destinations. The resolving
process is step-by-step done (get next IP only on demand) to minimize
the total number of DNS queries. So having this support does not imply,
in normal processing, more load on the DNS server. Additional queries
are done only when needed (after failure detected).
The scanning for new IP destinations is done by the SIP resolver on all
DNS levels: NAPTR, SRV, A.
Both core and TM are using this new feature.
In core, the stateless forwarding can do only DNS-based failover at
transport level (if no egress interface found or send operation
failed due whatever reason).
In TM, the DNS-based failover is extended to transaction level. If the
transaction completes with 503 or 408 with no reply, automatically, a
new branch will be fork if any destination IP can be found by the DNS
resolver.
Read more here http://www.openser.org/docs/modules/1.2.x/tm.html#AEN103
For controlling this feature use:
- newly added core parameter "disable_dns_failover" - use to
generally disable the DNS-based failover. By default is false.
- in TM, t_relay() take a new flag for turning off the DNS-based
failover. This setting is per transaction. By default, the failover is done.
Any feedback is appreciated.
regards,
Bogdan
Hi!
I thought setting the tcp_connection_lifetime to 0 should keep them open
endlessly, but in my case the proxy closes the TCP connection ~10
seconds after the last SIP message.
What am I doing wrong?
regards
klaus
--
Klaus Darilion
nic.at
Hi everybody,
OpenSER 1.2.0 has new feature - IP Blacklist support. This is a low
level filtering engine for the outgoing requests; low level, because the
filtering is done based on IP, protocol, port, etc.
Its primary purposes will be to prevent sending requests to critical IPs
(like GWs) due DNS or to avoid sending to destinations that are known to
be unavailable (temporary or permanent).
Because of flexibility concerns, the filtering rules can be groups
inside multiple lists.
A rule:
- matches based on IP/mask, proto, port and text pattern criteria
- can be reversed applied
A list:
- can be read-only - it does not change during execution
- have timeout per elements - elements expires after a configured timeout.
How to use:
===========
currently there are 2 ways of using the blacklists:
1) statically defining list in the configuration file and selecting
which ones should be used for each request.
You can define blacklists as follow:
# filter out requests going to ips of my gws
dst_blacklist = gw:{( tcp , 192.168.2.100 , 5060 , "" ),( any ,
192.168.2.101 , 0 , "" )}
# block requests going to "evil" networks
dst_blacklist = net_filter:{ ( any , 192.168.1.100/255.255.255.0 , 0
, "" )}
# block message requests with nasty words
dst_blacklist = msg_filter:{ ( any , 192.168.20.0/255.255.255.0 , 0
, "MESSAGE*ugly_word" )}
# block requests not going to a specific subnet
dst_blacklist = net_filter2:{ !( any , 192.168.30.0/255.255.255.0 ,
0 , "" )}
a rule is defined by:
protocol : TCP, UDP, TLS or "any" for anything
port : number or 0 for any
ip/mask
test patter - is a filename like matching (see "man 3 fnmatch")
applied on the outgoing request buffer (first_line+hdrs+body)
From routing script, you can use the use_blacklist("name") function to
select what blacklist to be applied for the current request. More than
one list can be selected.
If the destination address matches on of the selected rules, the send
will fail.
2) via DNS
The DNS resolver, when configured with failover, can automatically store
in a temporary blacklist the failed destinations. This will prevent (for
a limited period of time) openser to send requests to destination known
as failed.
So, the blacklist can be used as a memory for the DNS resolver.
To use it, you have to enabled it - the rest is done automatically.
disable_dns_blacklist = no
By default is enabled. The temporary blacklist created by DNS resolver
is named "dns" and it is by default selected for usage (no need use the
use_blacklist() function. The rules from this list have a life time of 4
minutes - you can change it at compile time, from blacklists.h .
To give you an internal snapshot, a new MI function - "list_blacklists"
- was added to print all existent blacklists and their rules.
Any suggestions/reports are welcome!
regards,
bogdan