Hi Shane,
please post the network trace from the the server and the full debug log
of openser (use debug=9).
regards,
bogdan
Shane Burrell wrote:
> I used that as an example. On the sip side I see the 302 come back and the
> openser ack it. Then I never see the new call go out. The user gets a busy
> or not avaible message from the switch. In openser I have some logging and
> it seems to start a new route after the ACK but bombs somewhere.
>
> -----Original Message-----
> From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
> Sent: Wednesday, February 28, 2007 12:54 PM
> To: Shane Burrell; users openser.org
> Subject: Re: [Users] 3xx requests and t_relay
>
> Hi Shane,
>
> have you followed this ex:
> http://www.openser.org/docs/modules/1.2.x/uac_redirect.html#AEN251
>
> can you be more specific about the errors you see?
>
> regards,
> bogdan
>
> Shane Burrell wrote:
>
>> I am calling the t_relay after getting the contacts. However internally I
>> see in openser it makes it back to the route and then dies in loose route.
>> I assumed there was something I need to check to allow the new call to be
>> processed.
>>
>> -----Original Message-----
>> From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro]
>> Sent: Wednesday, February 28, 2007 12:26 PM
>> To: Shane Burrell
>> Cc: users(a)openser.org
>> Subject: Re: [Users] 3xx requests and t_relay
>>
>> Hi,
>>
>> let me see if I get it right...you get a 3xx reply and try to generate
>> INVITE to the new contacts? if so, take a look at the uac_redirect module.
>>
>> regards,
>> bogdan
>>
>> Shane Burrell wrote:
>>
>>
>>> I have this working to the point it tries to relay the call but I see
>>> that internally openser is not making the new call. I assume t_relay
>>> calls a new route but how to I make sure that all relays get
>>> forwarded. Some of my logic else where seems to be killing the
>>> rerouted call and I need any 302 routed calls to be accepted and routed.
>>>
>>>
>>>
>>> TIA,
>>>
>>>
>>>
>>> Shane
>>>
>>>
>>> ***************************************************************
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users(a)openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>>
>>
>>
>
>
>
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
Hi, Scott Yagel,
you could find some clues in the file scenario.cpp of sipp project.
there were some embeded scenario scripts in sipp, stored in char* default_scenario[],
you can sent a register sip message by doing this:
" <send retrans=\"500\">\n"
" <![CDATA[\n"
"\n"
" REGISTER sip:CA.cym.com SIP/2.0\n"
" Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]\n"
" From: ua1 <sip:ua1@nnl.cym:[local_port]>;tag=[pid]SIPpTag07[call_number]\n"
" To: ua1 <sip:ua1@nnl.cym:[local_port]>\n"
" Call-ID: [call_id]\n"
" CSeq: 1 REGISTER\n"
" Contact: sip:ua1@[local_ip]:[local_port]\n"
" Content-Length: 0\n"
" Expires: 300\n"
"\n"
" ]]>\n"
" </send>\n"
regards.
Yan Lin
pre_auth(): Credentials with given realm not found
After looking around google it seems to be based on the fact that the
first sip: value doesn't contain the userid (if I understand correctly...)
I can't figure out exactly why the RURI is coming in this fashion..
Should I be changing something in the clients, or my config??
These worked on an older config, now with this section, they just don't
get accepted. I've tried it with and without sipserver.mobilia.it in the
realm.
I've also tried it with the server generating ha1 and static ha1 (from
the ha1 and ha1b fields in the db), no difference.
I have use domain 1 in registrar and auth_db, and strip "sipserver."
sl_send_reply("100", "Trying");
if(!www_authorize("", "subscriber"))
{
xlog("L_INFO", "Register authentication failed - M=$rm RURI=$ru F=$fu
T=$tu IP=$si ID=$ci\n");
www_challenge("", "1");
exit;
}
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: New request -
M=REGISTER RURI=sip:mobilia.it F=sip:rice@mobilia.it
T=sip:rice@mobilia.it IP=x.x.x.105 ID=fmq-17240(a)x.x.x.105
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: parse_headers:
flags=100
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: get_hdr_field:
cseq <CSeq>: <100> <REGISTER>
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]:
DEBUG:maxfwd:is_maxfwd_present: value = 70
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: parse_headers:
flags=200
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: DEBUG:
get_hdr_body : content_length=0
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: found end of
header
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]:
find_first_route: No Route headers found
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: loose_route:
There is no Route HF
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: parse_headers:
flags=ffffffffffffffff
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]:
check_via_address(x.x.x.105, x.x.x.105, 0)
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: parse_headers:
flags=4000
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: pre_auth():
Credentials with given realm not found
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]: Register
authentication failed - M=REGISTER RURI=sip:mobilia.it
F=sip:rice@mobilia.it T=sip:rice@mobilia.it IP=x.x.x.105
ID=fmq-17240(a)x.x.x.105
Mar 29 12:07:40 sipserver /usr/local/sbin/openser[22732]:
build_auth_hf(): 'WWW-Authenticate: Digest realm="mobilia.it",
nonce="460b9118a6a044d8837a01f924be2a9a3b7e0271", qop="auth"^M '
Hello,
We wrote a simple xcap emulator to be able to manage the XCAP
documents used by OpenSER presence agent, by using PHP scripts in
combination with Apache web server.
I have tested it against OpenSER with MySQL and Eyebeam for Apple.
Klaus Darilion has tested it against Postgress and Eyebeam for Windows.
The software can be downloaded from:
http://download.dns-hosting.info/XCAP/xcap-0.5.tar.gz
Regards,
Adrian
Hi,
I am using nathelper and because I have an CISCO router in front of the SER I don't need to use RTP Proxy.
Whenever I start SER I get the following errors:
Apr 2 09:13:33 sen ser[3442]: ERROR: send_rtpp_command: can't connect to RTP proxy
Apr 2 09:13:33 sen ser[3442]: send_rtpp_command(): proxy <unix:/var/run/rtpproxy.sock> does not responding, disable it
Apr 2 09:13:33 sen ser[3442]: WARNING: rtpp_test: can't get version of the RTP proxy
Apr 2 09:13:33 sen ser[3442]: WARNING: rtpp_test: support for RTP proxy <unix:/var/run/rtpproxy.sock>has been disabled temporarily
Apr 2 09:13:33 sen ser[3444]: ERROR: send_rtpp_command: can't connect to RTP proxy
Is there a way to disable this trials through ser.cfg by nathelper mod parameter in order not to get those errors?
Cheers
Tomasz
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I try to use WeSIP C2C with UACs registered to freeswitch. freeswitch
never answeres the INVITEs for caller (that INVITE with no SDP and
from=to=caller's sip address). So my question is, is it because
freeswitch maybe doesn't support rfc 3725? If so, is there any C2C
proven SIP-PBX I can use instead?
Helmut
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFF7s8L4tZeNddg3dwRArGjAKCRJ+Kqi4FqdE2J9S/Q6t8L3VEVzwCgncCc
G2rxVs9s3fqs+XgUXnsefRs=
=RqW7
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Newbe question:
Can someone explain what causes a match when lookup() and
does_uri_exist() is used? Does it look at the least significant
characters is the URI? Does it drop certain leading numbers like '1'?
Stu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFGDs0BK69Y+xPZrWYRAg5XAJ9kL3FNuImfu6wasPZ9z32uDYmoGwCfWKhW
5al96b0dhkmFNYnwBzyHmoY=
=mNnn
-----END PGP SIGNATURE-----
