[Users] Re: Dropped calls with OpenSER 1.1.x and Asterisk >= 1.2.14
Edoardo Serra
edoardo.serra at webrainstorm.it
Sat May 19 18:54:32 CEST 2007
Hi Bogdan, and sorry for my stupid question :)
Let's try to describe the complete scenario
We're a VoIP provider using OpenSER as registrar server and load
balancer (with dispatcher module) for a cluster of Asterisk servers
We're now talking of received calls from our users perspective.
One of our Asterisks originate an INVITE for someuser at openser,
OpenSER does a lookup in the location table and forward the INVITE
statefully.
When the user answer the call sends a 200 OK to OpenSER which is
forwarded to Asterisk, Asterisk sends back an ACK which is not forwarded
back to the user.
The user retries to send the OK but after a while it drops the call
because it's considering that a critical error
Here is a dump of what I mean
ASTERISK -> OPENSER - SIP/SDP Request: INVITE -
SIP:sorsatrav at 213.92.79.131, with session description
OPENSER -> ASTERISK - SIP Status: 100 trying -- your call is important to us
OPENSER -> USER - SIP/SDP Request: INVITE - SIP:s at 81.196.154.44:5060,
with session description
OPENSER -> USER - SIP/SDP Request: INVITE - SIP:s at 81.196.154.44:5060,
with session description
USER -> OPENSER - SIP Status: 100 Trying
USER -> OPENSER - SIP/SDP Status: 200 OK, with session description
OPENSER -> ASTERISK - SIP/SDP Status: 200 OK, with session description
ASTERISK -> OPENSER - SIP Request: ACK - SIP:s at 192.168.0.251
(this packet is not forwarded to user so client retries to send the OK)
USER -> OPENSER - SIP/SDP Status: 200 OK, with session description
OPENSER -> ASTERISK - SIP/SDP Status: 200 OK, with session description
ASTERISK -> OPENSER - SIP Request: ACK - SIP:s at 192.168.0.251
In this case the USER is an Asterisk, I tried the same tests with an
XLite as user and the packet is forwarded correctly.
Here are the details of the ACK packet
Request-Line: ACK sip:s at 192.168.0.251 SIP/2.0
Message Header
Via: SIP/2.0/UDP 213.92.79.138:5060;branch=z9hG4bK5a1555e7;rport
Route: <sip:213.92.79.131;lr=on;ftag=as3b66b2ad>
From: "Unknown" <sip:Unknown at 213.92.79.138>;tag=as3b66b2ad
To: <sip:sorsatrav at 213.92.79.131>;tag=as4b185fcc
Contact: <sip:Unknown at 213.92.79.138>
Call-ID: 6c21caa9503939325dc45a343434e8dc at 213.92.79.138
CSeq: 102 ACK
User-Agent: Exsorsa
Max-Forwards: 70
Content-Length: 0
Tnx in advance for you help
Regards
Edoardo
P.S.: Here is my openser.cfg
# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
# ----------- global configuration parameters ------------------------
check_via=yes # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
fifo="/tmp/ser_fifo"
#uid=nobody
#gid=nobody
# ------------------ module loading ----------------------------------
loadmodule "/usr/lib/openser/modules/sl.so"
loadmodule "/usr/lib/openser/modules/tm.so"
loadmodule "/usr/lib/openser/modules/rr.so"
loadmodule "/usr/lib/openser/modules/maxfwd.so"
loadmodule "/usr/lib/openser/modules/usrloc.so"
loadmodule "/usr/lib/openser/modules/registrar.so"
loadmodule "/usr/lib/openser/modules/nathelper.so"
loadmodule "/usr/lib/openser/modules/textops.so"
loadmodule "/usr/lib/openser/modules/exec.so"
loadmodule "/usr/lib/openser/modules/uri.so"
loadmodule "/usr/lib/openser/modules/uri_db.so"
loadmodule "/usr/lib/openser/modules/dispatcher.so"
loadmodule "/usr/lib/openser/modules/mysql.so"
loadmodule "/usr/lib/openser/modules/auth.so"
loadmodule "/usr/lib/openser/modules/auth_db.so"
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "db_url", "mysql://user:pass@192.168.252.5/openser")
modparam("usrloc", "timer_interval", 120)
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "db_url", "mysql://user:pass@192.168.252.5/db")
modparam("uri_db", "db_url", "mysql://user:pass@192.168.252.5/openser")
modparam("rr", "enable_full_lr", 1)
modparam("registrar", "nat_flag", 6)
modparam("registrar", "max_expires", 3600)
modparam("registrar", "min_expires", 60)
modparam("registrar", "append_branches", 0)
modparam("registrar", "desc_time_order", 1)
modparam("nathelper", "natping_interval", 20) # Ping interval 20 s
modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT
modparam("dispatcher", "force_dst", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if ( msg:len > max_len ) {
sl_send_reply("513", "Message too big");
exit;
};
if ( (method=="OPTIONS") || (method=="SUBSCRIBE") ||
(method=="NOTIFY") ) {
sl_send_reply("405", "Method Not Allowed");
exit;
}
if (!method=="REGISTER") {
record_route();
};
if ((src_ip==ip.of.asterisk.1) || (src_ip==ip.of.asterisk.1)) {
if (!lookup("location")) {
sl_send_reply("486", "Busy here");
exit;
};
if (!t_relay()) {
sl_reply_error();
};
exit;
};
if (nat_uac_test("3")) {
if ((method=="REGISTER") || (method=="INVITE") ||
(method=="OPTIONS")) {
fix_nated_contact();
force_rport();
setflag(6); # Mark as NATed
}
}
if (method=="REGISTER") {
if (!proxy_authorize("exorsa", "openser_view")) {
proxy_challenge("exorsa", "0");
exit;
}
if (!check_to()) {
sl_send_reply("403", "Digest username and URI
username do NOT match! Stay away!");
exit;
}
save("location");
exit;
};
if (method=="INVITE") {
if (!proxy_authorize("exorsa", "openser_view")) {
proxy_challenge("exorsa", "0");
exit;
}
if (!check_from()) {
sl_send_reply("403", "Digest username and URI username do NOT match!
Stay away!");
exit;
}
}
# loose-route processing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
t_relay();
exit;
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
route(1);
exit;
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# !! Nathelper
if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)"
&& !search("^Route:")){
sl_send_reply("479", "We don't forward to private IP
addresses");
exit;
};
# NAT processing of replies; apply to all transactions (for
example,
# re-INVITEs from public to private UA are hard to identify as
# NATed at the moment of request processing); look at replies
t_on_reply("1");
if ((src_ip!=ip.of.asterisk.1) && (src_ip!=ip.of.asterisk.2)) {
ds_select_dst("1", "0");
}
if (!t_relay()) {
sl_reply_error();
};
}
# !! Nathelper
onreply_route[1] {
# NATed transaction ?
if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
fix_nated_contact();
# otherwise, is it a transaction behind a NAT and we did not
# know at time of request processing ? (RFC1918 contacts)
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
Bogdan-Andrei Iancu ha scritto:
> Hi Edoardo,
>
> the ACK for 200 OK is generated by the call originator (caller) - it is
> an end-to-end request ; so you have to check if the caller sent an ACK,
> if it got to openser and if it contained proper route information in
> order to be sent to Asterisk.
>
> regards,
> bogdan
>
> Edoardo Serra wrote:
>> Hi guys,
>> I'm having a problem about asterisk dropping calls received from
>> OpenSER
>>
>> The problems was spotted at Asterisk users mailing lists
>> http://lists.digium.com/pipermail/asterisk-users/2007-April/184875.html
>>
>> Asterisk complains about an ACK not received and drops the calls.
>> It expects OpenSER to send an ACK back to its '200 OK' when the call
>> is set up
>>
>> Is that a problem OpenSER should solve ???
>>
>> Tnx in advance
>>
>> Regards
>>
>> Edoardo Serra
>> WeBRainstorm S.r.l.
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>
>
More information about the Users
mailing list