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=~"@tls_domain1.net") {
# t_relay("tls:domain1.net");
# exit;
#} else if(uri=~"@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??
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?
Hola,
-----Original Message----- From: users-es-bounces@lists.openser.org [mailto:users-es- bounces@lists.openser.org] On Behalf Of Iñaki Baz Castillo Sent: 18 April 2008 15:51 To: users-es@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ó:
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?
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.
-- Iñaki Baz Castillo ibc@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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.
Hola,
-----Original Message----- From: users-es-bounces@lists.openser.org [mailto:users-es- bounces@lists.openser.org] On Behalf Of Iñaki Baz Castillo Sent: 18 April 2008 16:12 To: users-es@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ó:
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.
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.
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.
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??
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@in.ilimit.es
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
El Friday 18 April 2008 15:23:26 Eloi Pecharroman escribió:
Hola,
-----Original Message----- From: users-es-bounces@lists.openser.org [mailto:users-es- bounces@lists.openser.org] On Behalf Of Iñaki Baz Castillo Sent: 18 April 2008 16:12 To: users-es@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ó:
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.
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.
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
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??
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.
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??
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.
Ok,
Al registrar un usuario y hacer $ sudo openserctl ul show Parece que funciona correctamente: 200 OK Domain:: location table=512 records=0 max_slot=0 Domain:: aliases table=512 records=1 max_slot=1 AOR:: oslo Contact:: sip:oslo@sipserver.apt.local:5060 Q= Expires:: 3594 Callid:: 1578954088@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 --------- Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: grep_sock_info - checking if host==us: 19==15 && [sipserver.apt.local] == [192.168.100.244] Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: grep_sock_info - checking if port 5060 matches port 5060 Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: grep_sock_info - checking if host==us: 19==19 && [sipserver.apt.local] == [sipserver.apt.local] Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: grep_sock_info - checking if port 5060 matches port 5060 Apr 18 17:12:32 barcelona /usr/sbin/openser[5722]: lookup(): 'oslo' Not found in usrloc
El Viernes, 18 de Abril de 2008, Eloi Pecharroman escribió:
AOR:: oslo Contact:: sip:oslo@sipserver.apt.local:5060 Q= Expires:: 3594 Callid:: 1578954088@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 "@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?
Hola Iñaki,
Antes de nada, muchísimas gracias por la ayuda.
Ahora funciona!!!! :)
-----Original Message----- From: users-es-bounces@lists.openser.org [mailto:users-es- bounces@lists.openser.org] On Behalf Of Iñaki Baz Castillo Sent: 18 April 2008 19:49 To: users-es@lists.openser.org Subject: Re: [OpenSER-Users-ES] Configuracion basicaOpenSER.Re- enviarINVITESa 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@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 "@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?
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.
-- Iñaki Baz Castillo
Users-es mailing list Users-es@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users-es
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=60Deduje 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.
El Monday 21 April 2008 12:33:36 Iñaki Baz Castillo escribió:
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=60Deduje 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.
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.
-----Original Message----- From: users-es-bounces@lists.openser.org [mailto:users-es- bounces@lists.openser.org] On Behalf Of Iñaki Baz Castillo Sent: 21 April 2008 14:20 To: users-es@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ó:
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=60Deduje 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.
Funciona: m: sip:oslo@192.168.100.238:5060 NO funciona: m: sip:oslo@sipserver.apt.local:5060
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.
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 ;)
sr-users-es@lists.kamailio.org
-
Eloi Pecharroman -
Iñaki Baz Castillo -
Iñaki Baz Castillo