18 Apr
2008
18 Apr
'08
4:42 p.m.
Hola,
No consigo configurar OpenSER correctamente. Mi intención es hacer que los clientes se
registren con Openser usando un dominio virtual privado que es
"sipserver.apt.local"
# ----------- global configuration parameters ------------------------
debug=5 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=no # (cmd line: -E)
children=4
log_facility=LOG_LOCAL7
# Uncomment these lines to enter debugging mode
#fork=no
#log_stderror=yes
#
port=5060
listen=udp:192.168.100.244:5060
listen=udp:sipserver.apt.local:5060
alias="sipserver.apt.local:5060"
sip_warning=yes
# uncomment the following lines for TLS support
#disable_tls = 0
#listen = tls:your_IP:5061
#tls_verify_server = 1
#tls_verify_client = 1
#tls_require_client_certificate = 0
#tls_method = TLSv1
#tls_certificate = "/etc/openser/tls/user/user-cert.pem"
#tls_private_key = "/etc/openser/tls/user/user-privkey.pem"
#tls_ca_list = "/etc/openser/tls/user/user-calist.pem"
# ------------------ module loading ----------------------------------
#set module path
mpath="/usr/lib/openser/modules/"
# Uncomment this if you want to use SQL database
#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 "mi_fifo.so"
loadmodule "xlog.so"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
#loadmodule "auth.so"
#loadmodule "auth_db.so"
# ----------------- setting module-specific parameters ---------------
# -- mi_fifo params --
modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo")
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
#modparam("usrloc", "db_mode", 2)
# -- auth params --
# Uncomment if you are using auth module
#
#modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
#
#modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 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;
};
# 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
if (!method=="REGISTER")
record_route();
# subsequent messages withing a dialog should take the
# path determined by record-routing
if (loose_route()) {
# mark routing logic in request
append_hf("P-hint: rr-enforced\r\n");
route(1);
};
if (!uri==myself) {
# mark routing logic in request
append_hf("P-hint: outbound\r\n");
# if you have some interdomain connections via TLS
#if(uri=~"(a)tls_domain1.net") {
# t_relay("tls:domain1.net");
# exit;
#} else if(uri=~"(a)tls_domain2.net") {
# t_relay("tls:domain2.net");
# exit;
#}
route(1);
};
# 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 (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest
authentication
#if
(!www_authorize("openser.org", "subscriber")) {
#
www_challenge("openser.org", "0");
# exit;
#};
xlog("L_INFO","[ACHTUNG]
saved $ru");
save("location");
exit;
};
xlog("L_INFO","[ACHTUNG]request from $ru");
#lookup("aliases");
#if (!uri==myself) {
# append_hf("P-hint: outbound
alias\r\n");
# route(1);
#};
# native SIP destinations are handled using our USRLOC DB
#if (!lookup("location")) {
# sl_send_reply("404", "Not
Found");
# exit;
#};
#append_hf("P-hint: usrloc applied\r\n");
};
route(1);
}
route[1] {
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
exit;
}
Los clientes se registran correctamente, sin embargo, al enviar un invite, OpenSER lo
reenvia internamente constantemente hasta que el max_fw llega a 0 y contesta con un
"too many hops".
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: [ACHTUNG] saved sip:192.168.100.244
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=8000000
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: build_contact(): Created Contact HF:
Contact: <sip:oslo_2_Route_1@sipserver.apt.local:5060>;expires=3600^M
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: check_via_address(192.168.100.238,
sipserver.apt.local, 0)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: DEBUG:destroy_avp_list: destroying list
(nil)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5022]: receive_msg: cleaning up
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: SIP Request:
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: method: <INVITE>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: uri:
<sip:oslo@sipserver.apt.local>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: version: <SIP/2.0>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=2
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: Found param type 232, <branch> =
<z9hG4bK4211644481>; state=16
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: end of header reached, state=5
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: Via found, flags=2
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: this is the first via
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: After parse_msg...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: preparing to run routing scripts...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=100
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:parse_to:end of header reached,
state=10
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBUG:parse_to: display={},
ruri={sip:oslo@sipserver.apt.local}
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: get_hdr_field: <t> [32];
uri=[sip:oslo@sipserver.apt.local]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: to body
[<sip:oslo@sipserver.apt.local>^M ]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_hdr_field: cseq <CSeq>:
<985859914> <INVITE>
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:maxfwd:is_maxfwd_present: value =
70
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_param: tag=3326383385
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:parse_to:end of header reached,
state=29
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBUG:parse_to: display={},
ruri={sip:oslo_2_Route_1@sipserver.apt.local}
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=200
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: get_hdr_body :
content_length=202
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: found end of header
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: find_first_route: No Route headers
found
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: loose_route: There is no Route HF
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us:
19==15 && [sipserver.apt.local] == [192.168.100.244]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060
matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us:
19==19 && [sipserver.apt.local] == [sipserver.apt.local]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060
matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us:
19==15 && [sipserver.apt.local] == [192.168.100.244]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060
matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if host==us:
19==19 && [sipserver.apt.local] == [sipserver.apt.local]
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: grep_sock_info - checking if port 5060
matches port 5060
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: [ACHTUNG]request from
sip:oslo@sipserver.apt.local
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: t_newtran: T on
entrance=0xffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=78
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: t_lookup_request: start searching:
hash=45820, isACK=0
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: RFC3261 transaction matching
failed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: t_lookup_request: no transaction
found
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: parse_headers: flags=ffffffffffffffff
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: check_via_address(192.168.100.238,
sipserver.apt.local, 0)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: WARNING:vqm_resize: resize(0) called
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:_reply_light: reply sent out.
buf=0x813efd8: SIP/2.0 1..., shmem=0xb3e5d980: SIP/2.0 1
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:_reply_light: finished
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: mk_proxy: doing DNS lookup...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no port, no
proto -> do NAPTR lookup!
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_record: lookup(sipserver.apt.local,
35) failed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no valid NAPTR
record found for sipserver.apt.local, trying direct SRV lookup...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: get_record:
lookup(_sip._udp.sipserver.apt.local, 33) failed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:sip_resolvehost2: no valid SRV
record found for _sip._udp.sipserver.apt.local, trying A record lookup...
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: check_via_address(192.168.100.238,
sipserver.apt.local, 0)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DBG:check_against_rule_list: using list
dns
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:set_timer: relative timeout is
500000
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_to_tail_of_timer[4]:
0xb4091bac (104400000)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:set_timer: relative timeout is
30
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG: add_to_tail_of_timer[0]:
0xb4091bc8 (133)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:t_relay_to: new transaction
fwd'ed
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:tm:UNREF_UNSAFE: after is 0
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: DEBUG:destroy_avp_list: destroying list
(nil)
Apr 18 15:36:16 barcelona /usr/sbin/openser[5024]: receive_msg: cleaning up
Que es necesario hacer para que el invite se envie al cliente al que esta destinado en vez
de renviarlo??
18 Apr
18 Apr
4:50 p.m.
New subject: [OpenSER-Users-ES] Configuracion basica OpenSER. Re-enviar INVITES a un UA
El Friday 18 April 2008 14:42:43 Eloi Pecharroman escribió:
Los clientes se registran correctamente, sin embargo,
al enviar un invite,
OpenSER lo reenvia internamente constantemente hasta que el max_fw llega a
0 y contesta con un “too many hops”.
Es normal, tienes comentado la parte del 'lookup("location")', ¿cómo
esperas
que funcione si cuando llaman a un usuario OpenSer no consulta la tabla
location para ver si dicho usuario está registrado y en caso afirmativo
cambiar el RURI para rutar el mensaje a él?
Lo que está pasando es muy muy sencillo: OpenSer recibe un INVITE a:
sip:user@sipserver.apt.local"
y como no transformas ese RURI OpenSer lo suelta y por DNS vuelve a él, de
pura lógica. Si no cambias el destino de un mensaje (bien cambiando el RURI o
vía cabecera Route) es normal que el paquete vuelva.
¿Tienes bien claro estos conceptos?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:01 p.m.
New subject: [OpenSER-Users-ES] Configuracion basica OpenSER. Re-enviarINVITES a un UA
Hola,
-----Original Message-----
From: users-es-bounces(a)lists.openser.org [mailto:users-es-
bounces(a)lists.openser.org] On Behalf Of Iñaki Baz Castillo
Sent: 18 April 2008 15:51
To: users-es(a)lists.openser.org
Subject: Re: [OpenSER-Users-ES] Configuracion basica OpenSER. Re-
enviarINVITES a un UA
El Friday 18 April 2008 14:42:43 Eloi Pecharroman escribió:
Ok, comente el lookup en pura desesperacion, la verdad. No tengo particularmente claros
los conceptos. Todo este mundo me es bastante nuevo.
Sin embargo, no veo que lookup modifique el mensaje.
Lo voy a probar ahora mismo, pero creo que el comportamiento de OpenSER es el mismo.
Gracias por la respuesta.
Eloi.
Los clientes se registran correctamente, sin
embargo, al enviar un
invite,
OpenSER lo reenvia internamente constantemente
hasta que el max_fw
llega a
0 y contesta con un “too many hops”.
Es normal, tienes comentado la parte del 'lookup("location")', ¿cómo
esperas
que funcione si cuando llaman a un usuario OpenSer no consulta la tabla
location para ver si dicho usuario está registrado y en caso afirmativo
cambiar el RURI para rutar el mensaje a él?
Lo que está pasando es muy muy sencillo: OpenSer recibe un INVITE a:
sip:user@sipserver.apt.local"
y como no transformas ese RURI OpenSer lo suelta y por DNS vuelve a él,
de
pura lógica. Si no cambias el destino de un mensaje (bien cambiando el
RURI o
vía cabecera Route) es normal que el paquete vuelva.
¿Tienes bien claro estos conceptos?
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
5:12 p.m.
New subject: [OpenSER-Users-ES] Configuracion basica OpenSER. Re-enviarINVITES a un UA
El Friday 18 April 2008 15:01:51 Eloi Pecharroman escribió:
Ok, comente el lookup en pura desesperacion, la
verdad. No tengo
particularmente claros los conceptos. Todo este mundo me es bastante nuevo.
Pues entonces lo vas a tener muy difícil. No intentes poner a funcionar esto
sin entenderlo, de verdad. Si lo haces acabarás abandonándolo puesto que cada
problema será insolventable sin los conceptos claros.
Sin embargo, no veo que lookup modifique el mensaje.
Eso es que no está entontrando a ese usuario en la tabla "location". Si un
usuario se registra debe figurar en esa tabla.
Añade un:
xlog("L_INFO", "------- RURI = $ru ---------\n");
antes y después del "lookup(location)" para ver si efectivamente lo ha
encontrado o no.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:23 p.m.
New subject: [OpenSER-Users-ES] Configuracion basica OpenSER.Re-enviarINVITES a un UA
Hola,
Tienes razon,
Apr 18 16:05:49 barcelona /usr/sbin/openser[5095]: lookup(): 'oslo' Not found in
usrloc
Lo que no entiendo es pq.
No es algo que save("location"); hace? Eso pone en la doc.
Funciona esto sin activar el uso de la base de datos??
-----Original Message-----
From: users-es-bounces(a)lists.openser.org [mailto:users-es-
bounces(a)lists.openser.org] On Behalf Of Iñaki Baz Castillo
Sent: 18 April 2008 16:12
To: users-es(a)lists.openser.org
Subject: Re: [OpenSER-Users-ES] Configuracion basica OpenSER.Re-
enviarINVITES a un UA
El Friday 18 April 2008 15:01:51 Eloi Pecharroman escribió:
En eso estamos. Leyendo la documentacion de los modulos, y los tutoriales del wiki.
Si tienes algún link que consideres especialmente relevante, agradecería lo
compartieras.
Ok, comente el lookup en pura desesperacion, la
verdad. No tengo
particularmente claros los conceptos. Todo este mundo me es bastante
nuevo.
Pues entonces lo vas a tener muy difícil. No intentes poner a funcionar
esto
sin entenderlo, de verdad. Si lo haces acabarás abandonándolo puesto
que cada
problema será insolventable sin los conceptos claros.
Sin embargo, no veo que lookup modifique el
mensaje.
Eso es que no está entontrando a ese usuario en la tabla "location". Si
un
usuario se registra debe figurar en esa tabla.
Añade un:
xlog("L_INFO", "------- RURI = $ru ---------\n");
antes y después del "lookup(location)" para ver si efectivamente lo ha
encontrado o no.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
5:40 p.m.
New subject: [OpenSER-Users-ES] Configuracion basica OpenSER.Re-enviarINVITES a un UA
El Friday 18 April 2008 15:23:26 Eloi Pecharroman escribió:
Sí, mira le módulo "registrar" y el "usrloc". Su puede usar memoria
RAM en vez
DB. Si usas memoria el comando "openserctl ul show" te enseñará quienes están
registrados.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Hola,
Por supuesto:
- Tutorial un poco viejo de SER (no OpenSer). Han cambiado muchas cosas pero
la base es la misma:
ttp://siprouter.onsip.org/doc/gettingstarted
- CookBook:
http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.3.x
- Pseudo-variables:
http://www.openser.org/dokuwiki/doku.php/pseudovariables:1.3.x
Pseudo-variables]
- Módulos:
http://www.openser.org/docs/modules/1.3.x
- Transformaciones:
http://www.openser.org/dokuwiki/doku.php/transformations:1.3.x
- Tablas BD:
http://www.openser.org/docs/db-tables/openser-db-devel.html
- Un post que hice sobre SIP y NAT:
http://blog.aliax.net/2007/08/aclarando-sip-y-nat.html
Y por supuesto una buena lectura del RFC 3261 y alguno más:
RFC 3261 -- SIP: Session Initiation Protocol
RFC 3581 -- An Extension to SIP for Symmetric Response Routing (rport)
RFC 3263 -- Locating SIP Servers
-----Original Message-----
From: users-es-bounces(a)lists.openser.org [mailto:users-es-
bounces(a)lists.openser.org] On Behalf Of Iñaki Baz Castillo
Sent: 18 April 2008 16:12
To: users-es(a)lists.openser.org
Subject: Re: [OpenSER-Users-ES] Configuracion basica OpenSER.Re-
enviarINVITES a un UA
El Friday 18 April 2008 15:01:51 Eloi Pecharroman escribió:
En eso estamos. Leyendo la documentacion de los modulos, y los tutoriales
del wiki. Si tienes algún link que consideres especialmente relevante,
agradecería lo compartieras. Ok, comente el lookup en pura desesperacion, la
verdad. No tengo
particularmente claros los conceptos. Todo este mundo me es bastante
nuevo.
Pues entonces lo vas a tener muy difícil. No intentes poner a funcionar
esto
sin entenderlo, de verdad. Si lo haces acabarás abandonándolo puesto
que cada
problema será insolventable sin los conceptos claros. Eso es que no
está entontrando a ese usuario en la tabla "location". Si
un
usuario se registra debe figurar en esa tabla.
Tienes razon,
Apr 18 16:05:49 barcelona /usr/sbin/openser[5095]: lookup(): 'oslo' Not
found in usrloc Lo que no entiendo es pq.
No es algo que save("location"); hace? Eso pone en la doc.
Funciona esto sin activar el uso de la base de datos??
6:16 p.m.
New subject: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re-enviarINVITES a un UA
> Eso es
que no está entontrando a ese usuario en la tabla
"location". Si
un
usuario se registra debe figurar en esa tabla.
Tienes razon,
Apr 18 16:05:49 barcelona /usr/sbin/openser[5095]: lookup(): 'oslo' found in usrloc Lo que no entiendo es pq.
No es algo que save("location"); hace? Eso pone en la doc.
Funciona esto sin activar el uso de la base de datos??
Sí, mira le módulo "registrar" y el "usrloc". Su puede usar memoria
RAM
en vez
DB. Si usas memoria el comando "openserctl ul show" te enseñará quienes
están
registrados.
8:48 p.m.
New subject: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re-enviarINVITES a un UA
El Viernes, 18 de Abril de 2008, Eloi Pecharroman escribió:
AOR:: oslo
Contact:: sip:oslo@sipserver.apt.local:5060 Q=
Expires:: 3594
Callid:: 1578954088(a)sipserver.apt.local
Cseq:: 1003541875
User-agent:: n/a
State:: CS_NEW
Flags:: 0
Cflag:: 0
Socket:: udp:192.168.100.244:5060
Methods:: 4294967295
Sin embargo, la función lookup() devuelve:
Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: ------- RURI =
sip:oslo@sipserver.apt.local --------- Apr 18 17:12:32 barcelona
/usr/sbin/openser[5722]: rewrite_uri: Rewriting Request-URI with
'sip:oslo@sipserver.apt.local:5060' Apr 18 17:12:32 barcelona
/usr/sbin/openser[5722]: ------- RURI = sip:oslo@sipserver.apt.local:5060
---------
¿Cómo es posible que el "Contact" sea "(a)sipserver.apt.local" ???
El "Contact" debe ser la IP del teléfono (o softphone), incluso aunque sea
privada (para eso está el campo "received").
¿Qué cliente estás usando? ¿has configurado algo raro en el cliente?
--
Iñaki Baz Castillo
21 Apr
21 Apr
2:16 p.m.
New subject: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re-enviarINVITESa un UA
Hola Iñaki,
Antes de nada, muchísimas gracias por la ayuda.
Ahora funciona!!!! :)
-----Original Message-----
From: users-es-bounces(a)lists.openser.org [mailto:users-es-
bounces(a)lists.openser.org] On Behalf Of Iñaki Baz Castillo
Sent: 18 April 2008 19:49
To: users-es(a)lists.openser.org
Subject: Re: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re-
enviarINVITESa un UA
El Viernes, 18 de Abril de 2008, Eloi Pecharroman escribió:
El cliente es mi propio software en el que estoy implmentando SIP. Estoy confundido, ya
que en la RFC especifica lo siguiente:
The Contact header field values of the request typically consist of
SIP or SIPS URIs that identify particular SIP endpoints (for example,
"sip:carol@cube2214a.chicago.com"), but they MAY use any URI scheme.
En la seccion 2.10:Contact
Da como ejemplo las DOS formas:
Examples:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
Deduje que ambas formas eran validas. No es cierto? Sin embargo OpenSER exige una de
ellas.
AOR:: oslo
Contact:: sip:oslo@sipserver.apt.local:5060 Q=
Expires:: 3594
Callid:: 1578954088(a)sipserver.apt.local
Cseq:: 1003541875
User-agent:: n/a
State:: CS_NEW
Flags:: 0
Cflag:: 0
Socket:: udp:192.168.100.244:5060
Methods:: 4294967295
Sin embargo, la función lookup() devuelve:
Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: ------- RURI =
sip:oslo@sipserver.apt.local --------- Apr 18 17:12:32 barcelona
/usr/sbin/openser[5722]: rewrite_uri: Rewriting Request-URI with
'sip:oslo@sipserver.apt.local:5060' Apr 18 17:12:32 barcelona
/usr/sbin/openser[5722]: ------- RURI =
sip:oslo@sipserver.apt.local:5060
---------
¿Cómo es posible que el "Contact" sea "(a)sipserver.apt.local" ???
El "Contact" debe ser la IP del teléfono (o softphone), incluso aunque
sea
privada (para eso está el campo "received").
¿Qué cliente estás usando? ¿has configurado algo raro en el cliente?
--
Iñaki Baz Castillo
_______________________________________________
Users-es mailing list
Users-es(a)lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
2:33 p.m.
New subject: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re-enviarINVITESa un UA
El Monday 21 April 2008 12:16:33 Eloi Pecharroman escribió:
En la seccion 2.10:Contact
Da como ejemplo las DOS formas:
Examples:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
Deduje que ambas formas eran validas. No es cierto? Sin embargo OpenSER
exige una de ellas.
¿Puedes por favor indicar las dos cabeceras Contact con las que has probado
(la que funiona y la que no)? pero no cambies nada de ellas.
Yo creo que tu error es que ponías como dominio en el Contact el dominio del
proxy.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
3:19 p.m.
New subject: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re-enviarINVITESa un UA
El Monday 21 April 2008 12:33:36 Iñaki Baz Castillo escribió:
El Monday 21 April 2008 12:16:33 Eloi Pecharroman
escribió:
Hola, lo acabo de comprobar y por supuesto que OpenSer permite la forma
abreviada de la cabecera "Contact" ("m"). El error, insisto, es que tú
habías
puesto como dominio en el Contact el dominio de tu cuenta SIP cuando lo que
tendrías que poner es la IP de tu ordenador/tfno o bien un dominio que apunte
a dicha IP (pero NO el dominio de tu cuenta SIp que obviamente apunta al
proxy, y ahí No está tu dispositivo escuchando).
Saludos.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
En la seccion 2.10:Contact
Da como ejemplo las DOS formas:
Examples:
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
;q=0.7; expires=3600,
"Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
m: <sips:bob@192.0.2.4>;expires=60
Deduje que ambas formas eran validas. No es cierto? Sin embargo OpenSER
exige una de ellas.
¿Puedes por favor indicar las dos cabeceras Contact con las que has probado
(la que funiona y la que no)? pero no cambies nada de ellas.
Yo creo que tu error es que ponías como dominio en el Contact el dominio
del proxy.
3:32 p.m.
New subject: [OpenSER-Users-ES] ConfiguracionbasicaOpenSER.Re-enviarINVITESa un UA
-----Original Message-----
From: users-es-bounces(a)lists.openser.org [mailto:users-es-
bounces(a)lists.openser.org] On Behalf Of Iñaki Baz Castillo
Sent: 21 April 2008 14:20
To: users-es(a)lists.openser.org
Subject: Re: [OpenSER-Users-ES] ConfiguracionbasicaOpenSER.Re-
enviarINVITESa un UA
El Monday 21 April 2008 12:33:36 Iñaki Baz Castillo escribió:
probado
Funciona:
m: <sip:oslo@192.168.100.238:5060>
NO funciona:
m: <sip:oslo@sipserver.apt.local:5060>
El Monday 21 April 2008 12:16:33 Eloi Pecharroman
escribió:
> En la seccion 2.10:Contact
> Da como ejemplo las DOS formas:
> Examples:
>
> Contact: "Mr. Watson" <sip:watson@worcester.bell-
telephone.com>
> ;q=0.7; expires=3600,
> "Mr. Watson" <mailto:watson@bell-telephone.com> ;q=0.1
> m: <sips:bob@192.0.2.4>;expires=60
>
> Deduje que ambas formas eran validas. No es cierto? Sin embargo
OpenSER
exige una
de ellas.
¿Puedes por favor indicar las dos cabeceras Contact con las que has (la que funiona y la que no)? pero no cambies
nada de ellas.
Yo creo que tu error es que ponías como dominio en el Contact el
dominio
del proxy.
Hola, lo acabo de comprobar y por supuesto que OpenSer
permite la forma
abreviada de la cabecera "Contact" ("m"). El error, insisto, es que
tú
habías
puesto como dominio en el Contact el dominio de tu cuenta SIP cuando lo
que
tendrías que poner es la IP de tu ordenador/tfno o bien un dominio que
apunte
a dicha IP (pero NO el dominio de tu cuenta SIp que obviamente apunta
al
proxy, y ahí No está tu dispositivo escuchando).
Si, la forma abreviada o no no influye, a eso no me referia. Lo que yo me refería es que
en la RFC da a entender que ambas formas (@dominio y @IP) son compatibles. De ahí mi
deducción de que el proxy/server las guardaría independientemente. No se si me explico.
Esta claro que el problema es la forma como se registran mis clientes.
Repito, muchas gracias y saludos!
Eloi.
3:50 p.m.
New subject: [OpenSER-Users-ES] ConfiguracionbasicaOpenSER.Re-enviarINVITESa un UA
El Monday 21 April 2008 13:32:06 Eloi Pecharroman escribió:
Funciona:
m: <sip:oslo@192.168.100.238:5060>
NO funciona:
m: <sip:oslo@sipserver.apt.local:5060>
Si, la forma abreviada o no no influye, a eso no me
referia. Lo que yo me
refería es que en la RFC da a entender que ambas formas (@dominio y @IP)
son compatibles. De ahí mi deducción de que el proxy/server las guardaría
independientemente. No se si me explico.
Y así es, te garantizo que así funciona.
Pero insisto una vez más, ¿¿¿por qué pones el dominio del server en
el "Contact" del cliente??? **ESO** es lo que te produce el loop.
Díme, a qué IP apunta el dominio sipserver.apt.local? ¿verdad que apunta a la
IP del servidor OpenSer en vez de a la IP de tu cliente? pues ahí está el
fallo.
Esta claro que el problema es la forma como se
registran mis clientes.
El problema es que has puesto el dominio del proxy en el "Contact", nada más.
PD: Un consejo creo que fruto de la experiencia: cuando creas que has
encontrado un fallo en OpenSer en cuestiones básicas como registro, call
forking, etc etc... la mayoría de las veces el fallo es tuyo, OpenSer ahce
estas cosas maravillosamente bien ;)
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5848
days inactive
5851
days old
sr-users-es@lists.kamailio.org
12 comments
3 participants
participants (3)
-
Eloi Pecharroman -
Iñaki Baz Castillo -
Iñaki Baz Castillo