Hi,
how do I run ser/openser on multiple ports. ?
I've configured my ser with two listen stat.
listen = ip:5060
listen = ip:5070
UA:5070 -------> Cisco (Blocked 5060) --------> SER -------------> UB:5060
UA is able to call UB, but UB is not able to call UA, I know 5060 is blocked
but it should goto 5070 ? please guide on this ?
Thanks,
Arun
Hi Lazer,
>i need a simple config that achieves the following (w/ out a db)
>
>if a user is not registered then all calls should go to a default gw
>192.168.10.1
>
>the default gw will only respond w/ a 302 or a 404
>
>if a 302 is received then openser should forward the call on to the
>new gw listed in the reply
>
>if a 404 is received the call should be forwarded to a different gw
172.16.20.1
>
>if the send gw is done then the call should die.
Try with somehting like this (not tested):
if (!lookup("location")) {
route(5);
exit;
}
route[5] {
rewritehostport("192.168.10.1:5060");
t_on_failure("1");
route(1);
exit;
}
route[1] {
if (!t_relay()) {
sl_reply_error();
};
exit;
}
failure_route[1] {
if (t_check_status("404")) {
rewritehostport("172.16.20.1:5060");
append_branch();
t_relay();
} else {
get_redirects("*");
t_relay();
}
}
Saludos
JesusR.
>here is what i was thinking of but as a newbie i may be off my rocker
>i seem to get an error
>
> ERROR: t_check_status: cannot check status for a reply which has no
>T-state established
>
>but again my whole approach may be wrong.
>
>
> if (!lookup("location")) {
>
>rewritehostport ("192.168.10.1:5060");
>if (t_check_status("(404)|(480)")) {
> log("404 or 480 negative reply\n");
>rewritehostport ("172.16.20.1:5060");
>}
>else{
>t_on_failure("1");
> t_relay();
>}
>
>
> failure_route[1] {
>
> get_redirects("*");
> t_relay();
>}
> }
Saludos
JesusR.
------------------------------------
Jesus Rodriguez
VozTelecom Sistemas, S.L.
jesusr(a)voztele.com
http://www.voztele.com
Tel. 902360305
-------------------------------------
Hi, I use "uac_replace_from" with:
modparam("uac","from_restore_mode","auto")
modparam("uac","rr_store_param","vsf")
So when a call arrives and must be sent to an Asterisk voicemail server I
change the From:
Linksys PAP -> OpenSer
INVITE sip:*500@openser.ilimit.es SIP/2.0
Via: SIP/2.0/UDP 192.168.1.109:5061;branch=z9hG4bK-91c6d79a
From: PAP809 <sip:809@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>
Call-ID: 148834d2-a640054a(a)192.168.1.109
OpenSer -> Asterisk
INVITE sip:*500@80.94.0.111 SIP/2.0
Record-Route: <sip:80.94.0.110;lr=on;ftag=bd9af3255e5ce6ao1;vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw-->
Via: SIP/2.0/UDP 80.94.0.110;branch=z9hG4bKb114.2e2e6ca5.0
Via: SIP/2.0/UDP 192.168.1.109:5061;rport=5061;received=212.121.235.18;branch=z9hG4bK-91c6d79a
From: PAP809 <sip:809_openser.ilimit.es@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>
Call-ID: 148834d2-a640054a(a)192.168.1.109
Asterisk -> OpenSer
SIP/2.0 200 OK
Via: SIP/2.0/UDP 80.94.0.110;branch=z9hG4bKb114.2e2e6ca5.0;received=80.94.0.110
Via: SIP/2.0/UDP 192.168.1.109:5061;rport=5061;received=212.121.235.18;branch=z9hG4bK-91c6d79a
Record-Route: <sip:80.94.0.110;lr=on;ftag=bd9af3255e5ce6ao1;vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw-->
From: PAP809 <sip:809_openser.ilimit.es@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>;tag=as32a464eb
Call-ID: 148834d2-a640054a(a)192.168.1.109
OpenSer -> Linksys PAP
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.109:5061;rport=5061;received=212.121.235.18;branch=z9hG4bK-91c6d79a
Record-Route: <sip:80.94.0.110;lr=on;ftag=bd9af3255e5ce6ao1;vsf=AAAAAAAAAB8AAAAAAAAAAAAAAAAAAAAAAEBvcGVuc2VyLmlsaW1pdC5lcw-->
From: PAP809 <sip:809@openser.ilimit.es>;tag=bd9af3255e5ce6ao1
To: <sip:*500@openser.ilimit.es>;tag=as32a464eb
Call-ID: 148834d2-a640054a(a)192.168.1.109
The problem is that this "200 OK" from OpenSer to Linksys PAP is not recognized by Linksys PAP
who doesn't reply with an ACK (just ignores the "200 OK"), so the "200 OK" is resent again
and again by Asterisk.
This issue just occurs with the Linksys PAP:
Product Name: PAP2-NA
Software Version: 2.0.12(LS) Hardware Version: 0.03.4
There is no NAT problem and if I set:
modparam("uac","from_restore_mode","none")
then the problem dissapeares, so the problem is the existence of "vsf" parameter in Record-Route.
If this parameter doesn't exist the problem doesn't occur.
Again I repeat that this issue doesn't occur with others phones. Any idea of why this occurs
with Linksys PAP? Thanks for any suggestion.
PD: Changing the parameter name does solve nothing.
PPD: What about if I don't restore the From in the replies? According to RFC3261 the only important is the
matching of From_tag, To_tag and Call-id, so, maybe I just should set:
modparam("uac","from_restore_mode","none")
and forget this issue?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hi,
is it possible to run openser with digest auth on an openwrt router *without* mysql?
If yes can someone please provide me a hint/link?
Did try loading "/usr/lib/openser/module/auth.so" without great success, since
my box lacks a mysql server version!
Thanks in advance
Michaek
I am using OpenSER to front some Cisco AS5300s. The way the trunk groups
on those are set up, a prefix of #755 is required to dial out, so I
transform the URI in OpenSER:
$rU = "#755" + $rU;
The problem is, certain messages never get acknowledged because OpenSER
reformats the URI to use escaped sequences. I am not sure if this is RFC
compliant.
For instance, a 200 OK comes from the media gateway, and the ACK that
OpenSER sends back has this for the URI scheme:
ACK sip:%237557069999999@ip.address:5060
This is in response to an initial INVITE to:
sip:#7557069999999@ip.address:5060
... what should I make of this?
Thanks!
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : +1-678-954-0670
Direct : +1-678-954-0671
On Friday 04 January 2008, Michael Bradley Jr wrote:
> Hi Henning,
>
> I'm running openser on an openwrt (whiterussion 0.9) box and I'm quite new
> to openser.
> I did install openser and would like to quickly add a domain and some users
> that could digest auth on my box.
> I know RTFM but can you tell me the direction to go for this quick setup?
Hi,
look at http://www.openser.org/docs/modules/1.3.x/ for the modules docs.
Basically you need to load a database driver of your choice and the db_auth
module. Take a look at the docs for this module for the available functions
for authentification, in the example config there are also some hints.
I don't have experience with OpenSER on the openWRT, unfortunally, so i don't
can give you more detailed hints about this special setup.
You need to specify your database type in the /etc/openser/openserctlrc file,
and then you could use the openserdbctl tool to create a new database. After
that you could add a new user with the openserctl tool, and authentification
should work. It it don't, increase the debug level to get some hints about
the problems.
Run this tools without any command to get some help, there is also some
documentation about the installation on the wiki.
Hope this helps - cheers,
Henning
So, is there a legitimate way to retrieve multiple rows using
avp_db_query() and iterate through them with a loop structure?
Does AVP support the notion of an "array" construction?
And if not, how do I get OpenSER to apply a set of rules
codified in custom database structures?
--
Alex Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : +1-678-954-0670
Direct : +1-678-954-0671
I need some help and guidance here as I am fairly new
to openser but have made some progress....
Can some one throw some light on this issue. I am
using a standard openser script from sipwise.com. I
have several ATA or UAC registered with
openser-1.1.1-tls. THe registration process works just
fine. I can make calls etc. no issues. I am using
Mediaproxy for nat traversal and no issues there too.
Since I am using the internet (not private LAN) to
connect these devices, I have set my register
expiration time to 1200 seconds.
Now after a few hours of operation, I see that some of
the ATA or UAC (HT486) deregister. I have used "ngrep"
and I can see:
1. UAC sends REGISTER request
2. openser responds by saying "100" "Trying"
2. Openser generates a 401 unauthorized
3. UAC once again generates REGISTER request
and this goes on. The only way to correct this issue
is to reboot the ATA by powering it off and on. Any
ideas why this may happen?
When I run the same devices using Asterisk I dont see
the devices deregister but I would like to use
Asterisk only a PSTN gateway.
I have included a trace of this below
Thanks in advance
Raju
====================================================
From: <sip:88@lmnopq.com>;tag=ed8cb29199123c47.
To: <sip:88@lmnopq.com>.
Contact: <sip:88@YY.YYY.YYY.YY:50826>.
Supported: replaces, timer.
Call-ID: a679dcef0eebdbec(a)192.168.1.5.
CSeq: 100 REGISTER.
Expires: 60.
User-Agent: TigerNetCom 1.02.12.0.9.11.
Max-Forwards: 70.
Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE.
Content-Length: 0.
.
U 2008/01/03 13:42:29.518524 XXX.XX.XXX.XXX:5060 ->
YY.YYY.YYY.YY:50825
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP
YY.YYY.YYY.YY:50826;branch=z9hG4bK0826bc66f89e21de;rport=50825.
From: <sip:88@lmnopq.com>;tag=ed8cb29199123c47.
To: <sip:88@lmnopq.com>.
Call-ID: a679dcef0eebdbec(a)192.168.1.5.
CSeq: 100 REGISTER.
Server: OpenSer (1.1.1-tls (i386/linux)).
Content-Length: 0.
.
U 2008/01/03 13:42:29.518566 XXX.XX.XXX.XXX:5060 ->
YY.YYY.YYY.YY:50825
SIP/2.0 401 Unauthorized.
Via: SIP/2.0/UDP
YY.YYY.YYY.YY:50826;branch=z9hG4bK0826bc66f89e21de;rport=50825.
From: <sip:88@lmnopq.com>;tag=ed8cb29199123c47.
To:<sip:88@lmnopq.com>;tag=5cc123387d097550f225581b658b043b.4f69.
Call-ID: a679dcef0eebdbec(a)192.168.1.5.
CSeq: 100 REGISTER.
WWW-Authenticate: Digest realm="lmnopq.com",
nonce="477d57f148e6dc9dd21502b6c60d4bfe9d061657".
Server: OpenSer (1.1.1-tls (i386/linux)).
Content-Length: 0.
After this the register with same cseq shows up and
the device does not register....
Hi,
I have recently downloaded SER & SEMS and configured them for early_announce application as described in the early_announce module documentation. I am using SIPp to generate an incoming call to test the setup. Upon receiving ACK for some reason SER fails to match it to the previous INVITE and tries to forward it to the destination statelessly and picks it up again and forwards it. It continues to do this until the max forward limit is reached.
I cannot figure out what is wrong. Any help is really appreciated.
Here is the Route section from ser-sems.cfg file that I am using
# ------------------------- request routing logic -------------------
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if ( msg:len > max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
# loose-route processing
if (loose_route()) {
t_relay();
break;
};
if (uri==myself) {
# filter unsupported requests
if (!(method=="REGISTER" || method=="ACK" || method=="INVITE" ||
method=="BYE" || method=="CANCEL" )) {
sl_send_reply("501", "method not understood here");
break;
}
if (method=="REGISTER") {
# make UAs which want to register unhappy
sl_send_reply("501","registration couldn't be accepted");
break;
};
if (!t_newtran()){
sl_send_reply("500","could not create transaction");
break;
};
if (method == "INVITE") {
avp_write("Final-Reply-Code=405;Final-Reply-Reason=Prohiboted",
"$sess_params");
if(!t_write_unix("/tmp/sems_sock","early_announce/early_headers")){
log("could not contact early_announce\n");
t_reply("404","not found");
};
break;
} else if (method=="BYE" || method=="CANCEL") {
if(!t_write_unix("/tmp/sems_sock","bye")) {
t_reply("500","error contacting sems");
};
break;
} else if (method=="ACK"){
# absorb ACKs
t_relay();
break;
};
break;
}
if (!t_relay()) {
sl_reply_error();
};
}
Debug logs from SER
0(27347) SIP Request:
0(27347) method: <ACK>
0(27347) uri: <sip:service@10.107.2.246>
0(27347) version: <SIP/2.0>
0(27347) parse_headers: flags=1
0(27347) Found param type 232, <branch> = <0>; state=16
0(27347) end of header reached, state=5
0(27347) parse_headers: Via found, flags=1
0(27347) parse_headers: this is the first via
0(27347) After parse_msg...
0(27347) preparing to run routing scripts...
0(27347) DEBUG : sl_filter_ACK: to late to be a local ACK!
0(27347) parse_headers: flags=128
0(27347) Found param type 232, <branch> = <0>; state=16
0(27347) end of header reached, state=5
0(27347) parse_headers: Via found, flags=128
0(27347) parse_headers: this is the second via
0(27347) Found param type 232, <branch> = <z9hG4bK-27351-1-3>; state=16
0(27347) end of header reached, state=5
0(27347) parse_headers: Via found, flags=128
0(27347) DEBUG: add_param: tag=79EBE47B-477CE4230002578E-B7F6D6C0
0(27347) end of header reached, state=29
0(27347) DEBUG: get_hdr_field: <To> [76]; uri=[sip:service@10.107.2.246:5060]<mailto:[sip:service@10.107.2.246:5060]>
0(27347) DEBUG: to body [sut <sip:service@10.107.2.246:5060>]
0(27347) get_hdr_field: cseq <CSeq>: <1> <ACK>
0(27347) DEBUG:maxfwd:is_maxfwd_present: value = 15
0(27347) DEBUG: add_param: tag=27351SIPpTag001
0(27347) end of header reached, state=29
0(27347) parse_headers: flags=256
0(27347) DEBUG: get_hdr_body : content_length=0
0(27347) found end of header
0(27347) find_first_route: No Route headers found
0(27347) loose_route: There is no Route HF
0(27347) grep_sock_info - checking if host==us: 12==12 && [10.107.2.246] == [10.107.2.246]
0(27347) grep_sock_info - checking if port 5060 matches port 5060
0(27347) DEBUG: t_newtran: msg id=4 , global msg id=3 , T on entrance=(nil)
0(27347) parse_headers: flags=-1
0(27347) parse_headers: flags=60
0(27347) t_lookup_request: start searching: hash=30348, isACK=1
0(27347) DEBUG: proceeding to pre-RFC3261 transaction matching
0(27347) DEBUG: t_lookup_request: no transaction found
0(27347) DEBUG: t_newtran: msg id=4 , global msg id=4 , T on entrance=(nil)
0(27347) parse_headers: flags=-1
0(27347) parse_headers: flags=60
0(27347) t_lookup_request: start searching: hash=30348, isACK=1
0(27347) DEBUG: proceeding to pre-RFC3261 transaction matching
0(27347) DEBUG: t_lookup_request: no transaction found
0(27347) SER: forwarding ACK statelessly
0(27347) DEBUG: mk_proxy: doing DNS lookup...
0(27347) check_via_address(10.107.2.246, 10.107.2.246, 0)
0(27347) Sending:
ACK sip:service@10.107.2.246 SIP/2.0
Record-Route: <sip:10.107.2.246;ftag=27351SIPpTag001;lr=on>
Record-Route: <sip:10.107.2.246;ftag=27351SIPpTag001;lr=on>
Record-Route: <sip:10.107.2.246;ftag=27351SIPpTag001;lr=on>
Via: SIP/2.0/UDP 10.107.2.246;branch=0
Via: SIP/2.0/UDP 10.107.2.246;branch=0
Via: SIP/2.0/UDP 10.107.2.246;branch=0
Via: SIP/2.0/UDP 10.107.2.246:5061;branch=z9hG4bK-27351-1-3
From: sipp <sip:sipp@10.107.2.246:5061>;tag=27351SIPpTag001
To: sut <sip:service@10.107.2.246:5060>;tag=79EBE47B-477CE4230002578E-B7F6D6C0
Call-ID: 1-27351(a)10.107.2.246<mailto:1-27351@10.107.2.246>
CSeq: 1 ACK
Contact: sip:sipp@10.107.2.246:5061
Max-Forwards: 14
Subject: Performance Test
Content-Length: 0
--Srinivas Kotamarti
Hi,
I have recently downloaded SER & SEMS and configured them for early_announce application as described in the early_announce module documentation. I am using SIPp to generate an incoming call to test the setup. Upon receiving ACK for some reason SER fails to match it to the previous INVITE and tries to forward it to the destination statelessly and picks it up again and forwards it. It continues to do this until the max forward limit is reached.
I cannot figure out what is wrong. Any help is really appreciated.
Here is the Route section from ser-sems.cfg file that I am using
# ------------------------- request routing logic -------------------
# main routing logic
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if ( msg:len > max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
# loose-route processing
if (loose_route()) {
t_relay();
break;
};
if (uri==myself) {
# filter unsupported requests
if (!(method=="REGISTER" || method=="ACK" || method=="INVITE" ||
method=="BYE" || method=="CANCEL" )) {
sl_send_reply("501", "method not understood here");
break;
}
if (method=="REGISTER") {
# make UAs which want to register unhappy
sl_send_reply("501","registration couldn't be accepted");
break;
};
if (!t_newtran()){
sl_send_reply("500","could not create transaction");
break;
};
if (method == "INVITE") {
avp_write("Final-Reply-Code=405;Final-Reply-Reason=Prohiboted",
"$sess_params");
if(!t_write_unix("/tmp/sems_sock","early_announce/early_headers")){
log("could not contact early_announce\n");
t_reply("404","not found");
};
break;
} else if (method=="BYE" || method=="CANCEL") {
if(!t_write_unix("/tmp/sems_sock","bye")) {
t_reply("500","error contacting sems");
};
break;
} else if (method=="ACK"){
# absorb ACKs
t_relay();
break;
};
break;
}
if (!t_relay()) {
sl_reply_error();
};
}
Debug logs from SER
0(27347) SIP Request:
0(27347) method: <ACK>
0(27347) uri: <sip:service@10.107.2.246>
0(27347) version: <SIP/2.0>
0(27347) parse_headers: flags=1
0(27347) Found param type 232, <branch> = <0>; state=16
0(27347) end of header reached, state=5
0(27347) parse_headers: Via found, flags=1
0(27347) parse_headers: this is the first via
0(27347) After parse_msg...
0(27347) preparing to run routing scripts...
0(27347) DEBUG : sl_filter_ACK: to late to be a local ACK!
0(27347) parse_headers: flags=128
0(27347) Found param type 232, <branch> = <0>; state=16
0(27347) end of header reached, state=5
0(27347) parse_headers: Via found, flags=128
0(27347) parse_headers: this is the second via
0(27347) Found param type 232, <branch> = <z9hG4bK-27351-1-3>; state=16
0(27347) end of header reached, state=5
0(27347) parse_headers: Via found, flags=128
0(27347) DEBUG: add_param: tag=79EBE47B-477CE4230002578E-B7F6D6C0
0(27347) end of header reached, state=29
0(27347) DEBUG: get_hdr_field: <To> [76]; uri=[sip:service@10.107.2.246:5060]<mailto:[sip:service@10.107.2.246:5060]>
0(27347) DEBUG: to body [sut <sip:service@10.107.2.246:5060>]
0(27347) get_hdr_field: cseq <CSeq>: <1> <ACK>
0(27347) DEBUG:maxfwd:is_maxfwd_present: value = 15
0(27347) DEBUG: add_param: tag=27351SIPpTag001
0(27347) end of header reached, state=29
0(27347) parse_headers: flags=256
0(27347) DEBUG: get_hdr_body : content_length=0
0(27347) found end of header
0(27347) find_first_route: No Route headers found
0(27347) loose_route: There is no Route HF
0(27347) grep_sock_info - checking if host==us: 12==12 && [10.107.2.246] == [10.107.2.246]
0(27347) grep_sock_info - checking if port 5060 matches port 5060
0(27347) DEBUG: t_newtran: msg id=4 , global msg id=3 , T on entrance=(nil)
0(27347) parse_headers: flags=-1
0(27347) parse_headers: flags=60
0(27347) t_lookup_request: start searching: hash=30348, isACK=1
0(27347) DEBUG: proceeding to pre-RFC3261 transaction matching
0(27347) DEBUG: t_lookup_request: no transaction found
0(27347) DEBUG: t_newtran: msg id=4 , global msg id=4 , T on entrance=(nil)
0(27347) parse_headers: flags=-1
0(27347) parse_headers: flags=60
0(27347) t_lookup_request: start searching: hash=30348, isACK=1
0(27347) DEBUG: proceeding to pre-RFC3261 transaction matching
0(27347) DEBUG: t_lookup_request: no transaction found
0(27347) SER: forwarding ACK statelessly
0(27347) DEBUG: mk_proxy: doing DNS lookup...
0(27347) check_via_address(10.107.2.246, 10.107.2.246, 0)
0(27347) Sending:
ACK sip:service@10.107.2.246 SIP/2.0
Record-Route: <sip:10.107.2.246;ftag=27351SIPpTag001;lr=on>
Record-Route: <sip:10.107.2.246;ftag=27351SIPpTag001;lr=on>
Record-Route: <sip:10.107.2.246;ftag=27351SIPpTag001;lr=on>
Via: SIP/2.0/UDP 10.107.2.246;branch=0
Via: SIP/2.0/UDP 10.107.2.246;branch=0
Via: SIP/2.0/UDP 10.107.2.246;branch=0
Via: SIP/2.0/UDP 10.107.2.246:5061;branch=z9hG4bK-27351-1-3
From: sipp <sip:sipp@10.107.2.246:5061>;tag=27351SIPpTag001
To: sut <sip:service@10.107.2.246:5060>;tag=79EBE47B-477CE4230002578E-B7F6D6C0
Call-ID: 1-27351(a)10.107.2.246<mailto:1-27351@10.107.2.246>
CSeq: 1 ACK
Contact: sip:sipp@10.107.2.246:5061
Max-Forwards: 14
Subject: Performance Test
Content-Length: 0
--Srinivas Kotamarti