16 Mar
2007
16 Mar
'07
6:05 a.m.
Hi all,
I don't want to bother you about this problem again but I'm a little
bit stuck.
Someone can help ?
Tnx in advance
Regards
Edoardo
Edoardo Serra ha scritto:
Tnx Carsten for attention.
My openser.cfg is following
I probably contains some misconfiguration as I'm still new to OpenSER
Tnx in advance
Regards
# ----------- global configuration parameters ------------------------
check_via=yes # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
fifo="/tmp/ser_fifo"
# ------------------ 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://XXX:XXX@192.168.252.5/openser")
modparam("usrloc", "timer_interval", 120)
modparam("auth_db", "calculate_ha1", 0)
modparam("auth_db", "db_url",
"mysql://XXX:XXX@192.168.252.5/userdb")
modparam("uri_db", "db_url",
"mysql://XXX:XXX@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{
# 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");
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==111.222.333.444) || (src_ip==555.666.777.888)) {
# IPs of our PSTN gateways
if (!lookup("location")) {
sl_send_reply("486", "Busy here");
exit;
};
# forward to current uri now; use stateful forwarding; that
# works reliably even if we forward from TCP to UDP
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 the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
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");
route(1);
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");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if ((src_ip!=111.222.333.444) && (src_ip!=555.666.777.888)) {
#IPs of our PSTN Gateways
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();
};
}
Carsten Bock ha scritto:
Hi Edoardo,
Normally this would be handled by an Record-Route/Loose-Route construct.
When doing record-routing/loose-routing, the in-dialog request
"Re-INVITE" (for Music-On-Hold) should take the same route as the
initial request (following the route headers) and you should no longer
need to query the dispatcher-module for these in-dialog requests.
Maybe you could post your config, i guess then we could help a little
more.
Carsten
Am Montag, den 12.03.2007, 13:10 +0100 schrieb Edoardo Serra:
Daniel,
thanks for your interest in the problem.
I better analyzed the problem and found the point in it.
I try to describe where I guess the problem is
When one of our users receive a call from the PSTN, the PSTN Gateway
(Asterisk) sends an INVITE at username@openser, the INVITE is
correctly forwarded to the user and the call is set up without problems.
(RTP from PSTN gw to USER and SIP through OpenSER)
When the user wants to put the caller OnHold it sends an INVITE to
OpenSER but OpenSER forwards the INVITE to one of the PSTN GW using
dispatcher module.
This way, if the INVITE is not forwarded to the PSTN GW which is
handling the call a second call is generated.
Do you have any suggestion ?
Every kind of help is appreciated.
Sorry for not having sent a network capture, but is quite difficult to
prepare such a capture on our system because it's always very busy
Hoping to hear from you soon
Regards
Edoardo
Daniel-Constantin Mierla ha scritto:
Hello,
a network trace (ngrep or wireshark) will help to spot what might be
the problem, otherwise is hard to guess.
Cheers,
Daniel
On 03/04/07 17:32, Edoardo Serra wrote:
> Hi all,
> I have an OpenSER server in front of serveral Asterisk acting
> as a load balancer and registrar server.
>
> We're offering both, inbound and outbound call services.
>
> When an outbound call is made, OpenSER, through the dispatcher
> module, choose an Asterisk server to handle the media of the call.
>
> When an inbound call is received (by a PSTN GW interconnected with
> one of the Asterisks), Asterisk calls SIP/username@openser.
>
> Media flows directly from user to Asterisks without using RTPProxy
> as every Asterisk server has got a public IP Address..
>
> I have the following problem with MOH.
>
> If a user tries to put on hold an outbound call (placed by him)
> everything is OK, Asterisk start playing MOH and stops when the
> user wants to stop it.
>
> But, if a user wants to put on hold an inbound call (a call just
> answered), as soon as it press the hold button another call to the
> caller is originated and the first call is not put on hold by the
> Asterisk
>
> I guess the problem is that, in this case, the asterisk doesn't
> recognise the INVITE as a re-INVITE and originate a new call
> instead of putting the other on hold.
>
> Do you have any idea on how to solve the problem ?
> Every suggestion is appreciated.
>
> Regards
>
> Edoardo Serra
>
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users