Hola como estan. Acabo de inscribirme, soy nueva en la lista. tengo muchas dudas con respecto a openser, espero me ayuden, Antes comentare del trabajo que estoy encaminando.
Estoy trabajando en un proyecto para implementar Telefonia IP para una empresa, que me permita hacer llamadas dentro de la empresa(red local) y desde internet.
La red de esta empresa cuenta con 35 VLANs, un firewall que controla las conexiones salientes y entrantes de las VLANs (permisos) hacia el Internet,
teniendo algunas referencias de la plataforma a utilizar para este proyecto hemos elegido Linux por cierto Debian y Openser version 1.2. luego de leer la documentacion de openser comence a instalar y probar. la Autenticacion me funciona, las llamadas de igual manera pero solo en una VLAN, estoy utilizando el X-Lite. cuando hago la autenticacion de una VLAN diferente los mensajes de señalizacion no llegan a mi servidor, de igual manera desde el internet, en mi servidor estoy monitorizando con NGREP los mensajes SIP, mi servidor cuenta con una IP publica y tambien esta instalado el rtpproxy para cuestiones de NAT, En el firewall me han dado todos los permisos, estan habilitados todos los protocolos y sus puertos(principalmente TCP y UDP), permite conexiones entrantes y salientes desde el internet a las VLANs y viciversa.
lo primero que puse a correr es el RTPProxy(la que utilizo es rtpproxy-cvs-latest.tgz)
rtpproxy -l 200.58.82.46 -s udp:127.0.0.1:7890 -F
luego Openser.
cuando hago llamadas en el mismo VLANs como mencione anteriormente me funcionan correctamente pero de una VLAN diferente no, tampoco de internet. la configuracion de mi openser.cfg es la siguiente
#
# sample config file to be used with nathelper/rtpproxy
#
# ----------- global configuration parameters ------------------------
debug=7 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=yes # (cmd line: -E)
listen=200.58.82.46
/* Uncomment these lines to enter debugging mode
fork=no
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
# --- module loading
mpath="//lib/openser/modules/"
loadmodule "mysql.so"
loadmodule "sl.so"
loadmodule "tm.so"
loadmodule "rr.so"
loadmodule "maxfwd.so"
loadmodule "usrloc.so"
loadmodule "registrar.so"
loadmodule "textops.so"
loadmodule "nathelper.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "mi_fifo.so"
loadmodule "xlog.so"
# --- setting module parameters
# -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
modparam("usrloc|auth_db","db_url","mysql://openser:openserrw@localhost/openser")
# -- usrloc params --
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "nat_bflag", 6)
# -- registrar params --
modparam("registrar|nathelper", "received_avp", "$avp(i:42)")
# -- auth params --
#modparam("auth_db", "calculate_ha1", no)
#modparam("auth_db", "password_column", "ha1")
#modparam("auth_db", "password_column_2", "ha1b")
modparam("auth_db", "calculate_ha1", yes)
modparam("auth_db", "password_column", "password")
# -- rr params --
modparam("rr", "enable_full_lr", 1)
# -- nathelper params ---
modparam("nathelper", "rtpproxy_sock", "udp:127.0.0.1:7890")
modparam("nathelper", "natping_interval", 30)
modparam("nathelper", "ping_nated_only", 1)
modparam("nathelper", "sipping_bflag", 7)
modparam("nathelper", "sipping_from", "sip:200.58.82.46")
# --- main routing logic
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
exit;
};
if (msg:len>= 2048 ) {
sl_send_reply("513", "Message too big");
exit;
};
# NAT detection
route(2);
if (!method=="REGISTER")
record_route();
if (loose_route()) {
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (!uri==myself) {
append_hf("P-hint: outbound\r\n");
route(1);
};
if (uri==myself) {
if (method=="REGISTER") {
if (!www_authorize("", "subscriber")) {
www_challenge("", "0");
exit;
};
if (isflagset(5)) {
# set branch flag -- when someone will call this user
# the INVITE will have branch flag 6 set after lookup("location")
setbflag(6);
# if you want OPTIONS natpings uncomment next
# setbflag(7);
};
save("location");
exit;
};
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
exit;
};
append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
route[1] {
if (subst_uri('/(sip:.*);nat=yes/\1/')){
setbflag(6);
};
if (isflagset(5)||isbflagset(6)) {
route(3);
}
if (!t_relay()) {
sl_reply_error();
};
exit;
}
route[2]{
force_rport();
if (nat_uac_test("19")) {
if (method=="REGISTER") {
fix_nated_register();
} else {
fix_nated_contact();
};
setflag(5);
};
}
route[3] {
if (is_method("BYE|CANCEL")) {
unforce_rtp_proxy();
} else if (is_method("INVITE")){
force_rtp_proxy();
t_on_failure("2");
};
if (isflagset(5))
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
t_on_reply("1");
}
failure_route[2] {
if (isbflagset(6) || isflagset(5)) {
unforce_rtp_proxy();
}
}
onreply_route[1] {
if ((isflagset(5) || isbflagset(6)) && status=~"(183)|(2[0-9][0-9])") {
force_rtp_proxy();
}
search_append('Contact:.*sip:[^>[:cntrl:]]*', ';nat=yes');
if (isbflagset(6)) {
fix_nated_contact();
}
exit;
}
Derrepente me falte dar algun permiso en mi Servidor? o esta mal mi configuracion de openser.cfg. espero podeis ayudar.
Saludos
Mariam
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
Hola, ¿existe algún caso en el que un gateway nos envíe un re-INVITE?
O sea, si el lado oscuro (PSTN, GSM...) nos pone en espera entiendo yo que eso
no se llega a reflejar nunca en el lado SIP, ¿no?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola, supongamos un UAC tras NAT sin nada para arreglarlo (ni STUN ni ALG's ni
redirecciones de puertos...) y sin registrarse en su proxy.
Al no registrarse en el proxy, toda la historia del ping para keepalive desde
el proxy se va al garete, ya que si el UAC no se registra no hay "bflag"
posible y por lo tanto no se envía un ping/OPTIONS periódico.
El problema es que si ese UAC llama, se autentica, y pasan X segundos sin
tráfico SIP, su router liberará la "conexión" UDP y si cuelga el llamado no
le llegará el BYE al UAC.
¿Debo asumir que es necesario el registro para solucionar este problema?
Por ejemplo, he notado que cierto proveedor con su galardonado producto de
VoIP (al que para mantener en el anonimato llamaremos "0ig@@") te envía un
OPTIONS **perpetuo**, incluso aunque te hayas de-registrado correctamente
desde tu UAC tras NAT.
Esa técnica, la del OPTIONS "de por vida" podría ser una solución a mi
problema, aunque me pregunto... ¿cómo de "ético" es mantener a la fuerza una
conexión UDP que yo como usuario he decidido cerrar con mi proveedor? XD
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola a todos,
esto es normal?? Tantos mensajes iguales.. digo
2(4608) receive_msg: cleaning up
2(4608) SIP Reply (status):
2(4608) version: <SIP/2.0>
2(4608) status: <408>
2(4608) reason: <Request Timeout>
2(4608) parse_headers: flags=2
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.0b5b6ba4.0>; state=6
2(4608) Found param type 235, <rport> = <5060>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=2
2(4608) parse_headers: this is the first via
2(4608) After parse_msg...
2(4608) DEBUG:forward_reply: found module nathelper, passing reply to it
2(4608) parse_headers: flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.fa5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) parse_headers: this is the second via
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.ea5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.da5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.ca5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.ba5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.aa5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.9a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.8a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.7a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.6a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.5a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.4a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.3a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.2a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.1a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.0a5b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 235, <rport> = <5060>; state=6
2(4608) Found param type 232, <branch> = <z9hG4bK8a11.f95b6ba4.0>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) Found param type 232, <branch> = <z9hG4bK-fb9bab01>; state=6
2(4608) Found param type 235, <rport> = <5061>; state=16
2(4608) end of header reached, state=5
2(4608) parse_headers: Via found, flags=20
2(4608) DEBUG: add_param: tag=9c37e3272d64c03ecd3b414dc8bfa515-25e6
2(4608) DEBUG:parse_to:end of header reached, state=29
2(4608) DBUG:parse_to: display={}, ruri={sip:SIP.PARALLAMAR.NET}
2(4608) DEBUG: get_hdr_field: <To> [68]; uri=[sip:SIP.domain.NET]
2(4608) DEBUG: to body [<sip:SIP.domain.NET>]
2(4608) get_hdr_field: cseq <CSeq>: <9751> <NOTIFY>
2(4608) DEBUG:forward_reply: found module tm, passing reply to it
2(4608) DEBUG: t_check: start=0xffffffff
2(4608) parse_headers: flags=22
Bien .. ahora que tengo el t_replicate funcionando ok, gracias chicos
por las indicaciones ... viene el problema de un INVITE que entra por
el openser2 y que vá con destino a un usuario TRAS UN NAT, que se
registró en el openser1.
Antes de usar t_replicate(), yo tenía montada una pequeña "ñapa",
consistente en que no replicaba los REGISTER, sino que cuando al hacer
un lookup() no encontraba un usuario, añadía una cabecera
SBC-Internal-Jump y hacía un rewritehost hacia el otro openser, en
este ejecutaba el guión con normalidad y la llamada funcionaba
(porculeando un poco con mediaproxy .. pero bueno).
Ahora que tengo el t_replicate() andando bien .. ¿cual es la solución
adecuada para que el INVITE llegue al UAC que está detrás de un NAT y
que se registró mediante el openser1? ¿usar el módulo path?
Saludos.
--
Raúl Alexis Betancor Santana
Dimensión Virtual S.L.
Mi duda viene de si el OPENSER envía los INVITE a partir de la cabecera
TO o a partir de la sipURI que va en la request line. En teoría creo que
debería ser a partir de la que va en la request line, pero en la
práctica no estoy tan seguro. De hecho con otros proxys he comprobado
que lo hace a partir del TO. Si alguien me pudiera solventar la duda le
estaré muy agradecido. Un saludo.
Hola, he instalado OpenSER, he agregado tres usuarios con openserctlrc
y todo bien. Pero ahora quiero hacer pruebas locales. Instale el
x-Lite y se conecta bien. ¿como me doy cuenta que numero se le asigno
a cada uno de los usuarios agregados? hay que hacerlo por separado?...
--
Ronmel Jiron Sandres
hola a todos..
he instalado openser con Soporte Mysql y lo hice bien. al momento de
agregar usuarios el primero lo acepta, cuando agrego por segunda vez
me sale el siguiente error.
# openserctl add ronmel ronmel ronmel@localhost
database engine 'MYSQL' loaded
Control engine 'FIFO' loaded
is_user: user counter=0
check_db_alias: alias counter=0
ERROR 1062 (23000) at line 1: Duplicate entry '' for key 3
ERROR: introducing the new user 'ronmel1' to the database failed
Creo que tiene que ver con Primary Key pero no soy muy bueno en
MySQL, asi que por favor ayuda
--
Ronmel Jiron Sandres
Hola, en llamadas con número oculto el Nortel CS2000 me envía un From así:
From: <sip:NULL@NULL.invalid:5060>
Me gustaría saber cuál es el estándar (y si existe/se usa) para referirse a un
SIP URI anónimo. Tenía esperanzas en que fuese:
From: "Anonymous" <sip:anonymous@anonymous.invalid>
Pero veo que cada uno manda lo que le da la gana. ¿Es así con otros gateways?
Gracias.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es