Hello
does openSER uses the host identificayion in any way to authenticate its
costumers?
Because I re-installed my server and thats the only difference from the
previous instalation (its even in the same machine).
Thanks
regards
Joao pereira
Hello,
with openser 1.0 I have this
if ( avp_db_load("$low_c_service/username","i:/serviceLowCoastredirect"))
and for openser 1.2 I try to do this
if (
avp_db_load("$avp(low_c_service)/username","i:/serviceLowCoastredirect"))
or
if (
avp_db_load("$avp($low_c_service)/username","i:/serviceLowCoastredirect"))
low_c_service is an alias
avp_aliases="low_c_service=i:500"
but I have always an error.
0(0) ERROR:avops:parse_avp_db:: error - bad avp flags
0(0) ERROR:avpops:fixup_db_avp: parse failed
0(0) ERROR: fix_actions: fixing failed (code=-1) at cfg line 633
0(0) ERROR: fix_expr : fix_actions error
I think the key message for problem analysis, client's ACK, is missing. This is the setting,
right:?
.100/UAC -----NAT/.248----> SER outbound @ .246 -----> UAS @ .239
The ACK in your message dump is only that one sent from proxy (246) to UAS
(.239). The ACK which can possibly mismatch and produce the error message
you mentioned must come from upstream. To be properly formatted, it must
have Via identical to that of initial INVITE
( Via: SIP/2.0/UDP 192.168.1.100:5060;rport=46127;received=100.100.100.248;branch=z9hG4bK2893084087)
-jiri
At 17:50 27/03/2007, Ricardo Martinez wrote:
No. Time Source Destination Protocol Info
> 14 6.102719 100.100.100.239 100.100.100.246 SIP Status: 487 Request Terminated
>Session Initiation Protocol
> Status-Line: SIP/2.0 487 Request Terminated
> Status-Code: 487
> Resent Packet: False
> Message Header
> Via: SIP/2.0/UDP 100.100.100.246;branch=z9hG4bK895c.a98d35.0
> Via: SIP/2.0/UDP 192.168.1.100:5060;rport=46127;received=100.100.100.248;branch=z9hG4bK2893084087
>No. Time Source Destination Protocol Info
> 15 6.103011 100.100.100.246 100.100.100.239 SIP Request: ACK sip:005622408196@100.100.100.239
>Session Initiation Protocol
> Request-Line: ACK sip:005622408196@100.100.100.239 SIP/2.0
> Method: ACK
> Resent Packet: False
> Message Header
> Via: SIP/2.0/UDP 100.100.100.246;branch=z9hG4bK895c.a98d35.0
> f: "cl" <sip:cl@sipvoiss.desa.redvoiss.net>;tag=1587516403
> SIP Display info: "cl"
> SIP from address: sip:cl@sipvoiss.desa.redvoiss.net
> SIP tag: 1587516403
> i: <mailto:e94a98aa177e8579e5242a2091c0ac5f@192.168.1.100>e94a98aa177e8579e5242a2091c0ac5f(a)192.168.1.100
> To: <sip:0299005622408196@sipvoiss.desa.redvoiss.net>;tag=9146c297a4
>Thanks
>
>Ricardo.-
>_______________________________________________
>Serusers mailing list
>Serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
Hi all!
Can somebody explain me how I can fill response with my useful headers?
For example, I need to send 305 "Use proxy" response with Contact
headers. Is it possible? If so, how can I populate it?
Thanks!
--
CU,
Victor Gamov
I experienced the same problem with the SNMPstats module. If you run openser in foreground mode (fork=no), the module doesn't initialize. Running in background mode fixes the problem.
Hello!
Thanks for your answer. I'm using the standard config file
(http://ftp.iptel.org/pub/ser/presence/cfg/full-no-failover.cfg),
with a little modification, because I'm using radius
authentication, accounting and media proxy.
loadmodule "/opt/lib/ser/modules/acc_radius.so"
loadmodule "/opt/lib/ser/modules/mediaproxy.so"
loadmodule "/opt/lib/ser/modules/auth_radius.so"
modparam("acc_radius","radius_config","/etc/radiusclient-ng/radiusclient.conf")
modparam("acc_radius", "log_flag", 1)
modparam("acc_radius", "log_missed_flag", 2)
modparam("rls", "db_url",
"mysql://yyyyyyy:xxxxxx@10.22.1.222/ser_pa")
modparam("domain|uri_db|auth_db|usrloc|msilo", "db_url",
"mysql://yyyyyyy:xxxxxx@10.22.1.222/ser_pa")
if ((method=="INVITE") or (method=="BYE") or (method=="CANCEL"))
{
setflag(1);
}
if (!radius_www_authorize("test.intra")) {
www_challenge("test.intra", "0");
break;
};
handle_rls_subscription("1");
route[1]
{
if (method=="INVITE")
{
t_on_reply("1");
t_on_failure("1");
use_media_proxy();
}
else if (method=="BYE|CANCEL") {
end_media_session();
}
# send it out now; use stateful forwarding as it works
reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
};
}
onreply_route[1]
{
if (status=~"(183)|2[0-9][0-9]") {
use_media_proxy();
};
if (status=~"[3-6]0[0-9]") {
end_media_session();
break;
}
}
failure_route[1]
{
# forwarding failed -- check if the request was a MESSAGE
if (!method=="MESSAGE") { break; };
log(1, "MSILO: MESSAGE forward failed - storing it\n");
# we have changed the R-URI with the contact address,
ignore it now
if (m_store("0", "")) {
t_reply("202", "Accepted");
} else {
log(1, "MSILO: offline message NOT stored\n");
t_reply("503", "Service Unavailable");
};
end_media_session();
}
-----------------
I made a capture with Ethereal, and I can see that eyeBeam
sent the "Supported: eventlist" field.
I inserted the lists of both type:
Global-list:
Message Header
Via: SIP/2.0/UDP
10.22.2.134:9510;branch=z9hG4bK-d87543-dd118615e6316f41-1--d87543-
Max-Forwards: 70
Contact: <sip:12345@10.22.2.134:9510>
To: <sip:bartaj-list@test.intra>
SIP to address: sip:bartaj-list@test.intra
From: "12345"<sip:12345@test.intra>;tag=0a48df34
SIP Display info: "12345"
SIP from address: sip:12345@test.intra
SIP tag: 0a48df34
Call-ID:
ee79a62abd227204@S2FhbGlhLXhwLndlc3RlbC53ZXN0ZWw5MDAuaHU.
CSeq: 1 SUBSCRIBE
Expires: 60
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
NOTIFY, MESSAGE, SUBSCRIBE, INFO
Supported: eventlist
User-Agent: CounterPath eyeBeam
Event: presence
Content-Length: 0
User-list:
Message Header
Via: SIP/2.0/UDP
10.22.2.134:9510;branch=z9hG4bK-d87543-6300f275d049656e-1--d87543-
Max-Forwards: 70
Contact: <sip:12345@10.22.2.134:9510>
To: <sip:12345@test.intra>
SIP to address: sip:12345@test.intra
From: "12345"<sip:12345@test.intra>;tag=cb3e2c5c
SIP Display info: "12345"
SIP from address: sip:12345@test.intra
SIP tag: cb3e2c5c
Call-ID:
a46e4b35e4754144@S2FhbGlhLXhwLndlc3RlbC53ZXN0ZWw5MDAuaHU.
CSeq: 1 SUBSCRIBE
Expires: 3600
Accept: message/external-body
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
NOTIFY, MESSAGE, SUBSCRIBE, INFO
Supported: eventlist
User-Agent: CounterPath eyeBeam
Event:
sip-profile;profile-type=application;app-id=resource-lists
Content-Length: 0
The second case is working, but the first one is not.
Is this maybe an EyeBeam problem? Which version of EyeBeam
works fine (or which other client can I test it with)?
And I have another question.
What can I do with those clients, that does not support the
presence information (can I do something anyway?).
For example:
I have a "Cisco Call Manager Express" box, and some Cisco IP
Phones, that reach other PC clients through the SER.
The Cisco makes the registration (and reregistration) with
the phone's identifiers too into the SER (but the presence
information is not handled by the Cisco), and therefore if a
PC client would like to add the Cisco phone into his buddy
list, the presence won't be working.
...Record(0x405cc588)...
domain: 'location'
aor : '101$'
~~~Contact(0x405cc5c8)~~~
domain : 'location'
aor : '101$'
Contact : 'sip:101$@10.22.2.233:5060'
Expires : Expired
q :
Call-ID : '9C5717E5-D7D211DB-804EA958-71810899'
CSeq : 4103
User-Agent: 'Cisco-SIPGateway/IOS-12.x'
received : ''
State : CS_SYNC
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
.../Record...
...Record(0x405cc698)...
domain: 'location'
aor : '100$'
~~~Contact(0x405cc6d8)~~~
domain : 'location'
aor : '100$'
Contact : 'sip:100$@10.22.2.233:5060'
Expires : Expired
q :
Call-ID : '9C5717E5-D7D211DB-804DA958-71810899'
CSeq : 1364
User-Agent: 'Cisco-SIPGateway/IOS-12.x'
received : ''
State : CS_SYNC
Flags : 0
next : (nil)
prev : (nil)
~~~/Contact~~~~
.../Record...
Is it possible, that the SER (in these cases) simulates a
presence client (if the user registration is active, then
the user is online, anyway offline)?
Thanks,
Jani
-----Original Message-----
From: Vaclav Kubart [mailto:vaclav.kubart@iptel.org]
Sent: Wednesday, March 28, 2007 3:46 PM
To: Barta János
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] global contact list
Hi,
please can you send here your config file?
By the way, in some EyeBeam versions was not possible to use
"Subscribe to contact list" feature because in such cases
EyeBeam didn't send header "Supported: eventlist".
Vaclav
On Tue, Mar 27, 2007 at 08:54:15AM +0200, Barta János wrote:
> Hello!
>
> I have a little problem with the (global) contact list
subscription
> of the presence, please help me.
> I installed the presence server (0.10.99-dev35-pa-4.1),
and it works
> without any problems.
> But I can not use the "Subscribe to contact list" of the
eyeBeam. (The
> user subscribe list works fine.) I typed the next content
into this
> field (of the eyeBeam):
>
> sip:bartaj-list@test.intra
>
>
> and my config file contains:
>
> sip:/var/xcap-root/rls-services/global# cat ./index <?xml
> version="1.0" encoding="UTF-8"?> <rls-services>
>
> <service uri="sip:bartaj-list@test.intra">
> <list name="Human resources">
> <entry uri="sip:test1@test.intra">
>
> <display-name>bartaj</display-name>
> </entry>
> <entry uri="sip:test2@test.intra">
>
> <display-name>12345</display-name>
> </entry>
> </list>
> <packages>
> <package>presence</package>
> </packages>
> </service>
>
> </rls-services>
>
> But I can see only the user subscribe list, and can't see
the global
> one.
> Why?
> Can anybody help me?
> Thx,
> Jani
>
_____________________________________________________________________________________________________
Jean Michel Jarre: Téo és Téa, az új, ünnepi album 1990 Forintért, kizárólag a T-Online Zeneáruházban! http://zenearuhaz.t-online.hu/index.php?m=info&albumid=30593&sp=1&sty=21
Hello
The dialog module checks SIP messages only if the OpenSER in on
record-route header in function dlg_onroute().
When the callee in registered on another SIP Server and the callee sends
BYE, the OpenSER is not on record-route header. In this case, the dialog
module doesn't detect end of call.
Is there a way to callback the dlg_onroute() function not only in case
of record-route?
The configuration is as following:
- Tel 101 registered to 192.168.13.8 (siproxd) (URI: 101(a)192.168.13.8)
(IP: 192.168.13.101)
- Tel 155 registered to 192.168.13.86 (OpenSER) (URI: 155(a)192.168.13.86)
(IP: 192.168.13.155)
- 155 is the caller and 101 is the callee.
Attached, message capture (ethereal) when the callee (101) terminate the
call.
Thanks.
Regards,
Michel.
