31 Jan
2003
31 Jan
'03
2:30 p.m.
Hi,
I have successfully (I think that) installed SER server with ser-mysql
package.
I have set the environment variable 'SIP_DOMAIN="192.168.11.237"' (that
is
server IP address).
I have succesfully added a user to subscriber table: 'serctl add ivan
ivanpswd ivan(a)hotmail.com'#39;, but registering WM to server fails:
URI = 'ivan(a)192.168.11.237'
Passwowd = 'ivanpswd'
User = 'ivan'
This is my ser.cfg file:
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=yes # (cmd line: -E)
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
loadmodule "//usr/lib/ser/modules/mysql.so"
loadmodule "//usr/lib/ser/modules/sl.so"
loadmodule "//usr/lib/ser/modules/tm.so"
loadmodule "//usr/lib/ser/modules/rr.so"
loadmodule "//usr/lib/ser/modules/maxfwd.so"
loadmodule "//usr/lib/ser/modules/usrloc.so"
loadmodule "//usr/lib/ser/modules/registrar.so"
loadmodule "//usr/lib/ser/modules/auth.so"
# ----------------- setting module-specific parameters ---------------
modparam("usrloc", "db_mode", 2)
modparam("auth", "db_url", "sql://ser:heslo@localhost/ser")
modparam("auth", "calculate_ha1", yes)
modparam("auth", "password_column", "password")
# ------------------------- request routing logic -------------------
alias="engiweb.com"
alias="sip.engiweb.com"
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (len_gt( max_len )) {
sl_send_reply("513", "Message too big");
break;
};
rewriteFromRoute();
if (uri=~"^sip:(.+@)?(192\.168\.11\.237|(sip\.)?engiweb\.com)([:;\?].*)?$")
{
if (method=="REGISTER") {
if (!www_authorize("192.168.11.237", "subscriber")) {
if (!proxy_authorize("192.168.11.237", "subscriber")) {
www_challenge("engiweb.org", "0");
break;
};
save("location");
break;
};
lookup("aliases");
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
if (!t_relay()) {
sl_reply_error();
};
}
What could be the problem?
Best regards.
Ivan Vignola.
_________________________________________________________________
MSN Extra Storage: piena libertà di esprimersi e comunicare
http://www.msn.it/msnservizi/es/extra_storage_tag/
31 Jan
31 Jan
3:36 p.m.
Hi Ivan,
the problem with WM is that the address of the server have to be the same as
the domain part of the URI (which is not RFC conform). For example you have
to add ivan(a)192.168.11.237 to the subscriber table and also use this account
within your WM to get authentication working.
Regards
Nils Ohlmeier
On Friday 31 January 2003 13:30, Ivan Vignola wrote:
Hi,
I have successfully (I think that) installed SER server with ser-mysql
package.
I have set the environment variable 'SIP_DOMAIN="192.168.11.237"' (that
is
server IP address).
I have succesfully added a user to subscriber table: 'serctl add ivan
ivanpswd ivan(a)hotmail.com'#39;, but registering WM to server fails:
URI = 'ivan(a)192.168.11.237'
Passwowd = 'ivanpswd'
User = 'ivan'
This is my ser.cfg file:
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd)
fork=yes
log_stderror=yes # (cmd line: -E)
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
loadmodule "//usr/lib/ser/modules/mysql.so"
loadmodule "//usr/lib/ser/modules/sl.so"
loadmodule "//usr/lib/ser/modules/tm.so"
loadmodule "//usr/lib/ser/modules/rr.so"
loadmodule "//usr/lib/ser/modules/maxfwd.so"
loadmodule "//usr/lib/ser/modules/usrloc.so"
loadmodule "//usr/lib/ser/modules/registrar.so"
loadmodule "//usr/lib/ser/modules/auth.so"
# ----------------- setting module-specific parameters ---------------
modparam("usrloc", "db_mode", 2)
modparam("auth", "db_url",
"sql://ser:heslo@localhost/ser")
modparam("auth", "calculate_ha1", yes)
modparam("auth", "password_column", "password")
# ------------------------- request routing logic -------------------
alias="engiweb.com"
alias="sip.engiweb.com"
route{
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if (len_gt( max_len )) {
sl_send_reply("513", "Message too big");
break;
};
rewriteFromRoute();
if
(uri=~"^sip:(.+@)?(192\.168\.11\.237|(sip\.)?engiweb\.com)([:;\?].*)?$") {
if (method=="REGISTER") {
if (!www_authorize("192.168.11.237", "subscriber")) {
if (!proxy_authorize("192.168.11.237", "subscriber")) {
www_challenge("engiweb.org", "0");
break;
};
save("location");
break;
};
lookup("aliases");
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
if (!t_relay()) {
sl_reply_error();
};
}
What could be the problem?
Best regards.
Ivan Vignola.
_________________________________________________________________
MSN Extra Storage: piena libertà di esprimersi e comunicare
http://www.msn.it/msnservizi/es/extra_storage_tag/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
gpg-key: http://www.ohlmeier.org/public_key.asc
6:58 p.m.
New subject: [Serusers] Consume_credentials failing?
I'm still working on debugging communication between
my SER server and nikotel's. One of the engineers there
did a very thorough disection of the INVITE packet.
I notice a '5' sneaking in...it must be introduced by the
SER server.
Here is the packet:
#
U 64.90.42.25:5060 -> 63.214.186.6:5060
INVITE sip:12143357976@63.214.186.6:5060 SIP/2.0.
Max-Forwards: 10.
Record-Route: <sip:12143357976@64.90.42.25;branch=0>.
Via: SIP/2.0/UDP 64.90.42.25;branch=z9hG4bK974c.7b992247.0.
Via: SIP/2.0/UDP
216.87.128.66:5060;branch=d759600326ab4b8723b14f7018c275ed.0.
Session-Expires: 3600.
From: <sip:2427747@192.168.100.240>
;tag=c0a864f0-13c4-3e3aa732-18c475-66c8.
To: <sip:12143357976@augustvoice.net> ;user=phone.
Call-ID: 5ac028-c0a864f0-13c4-3e3aa732-18c470-4b6b(a)192.168.100.240.
CSeq: 2 INVITE.
Contact:
<sip:k8ex0OqvaIVP67HyZebtvBXspeGgTWCbIdRmeKFadF3mjX4ihSIWQ7SZB5J94eb6@21
6.87.128.66>.
5.
User-Agent: FXS_GW (4asipfxs.101.BIN).
Content-Type: application/SDP.
Content-Length: 238.
.
v=0.
o=FXS_GW 12367 0 IN IP4 216.87.128.66.
s=Audio Session.
i=Audio Session.
c=IN IP4 216.87.128.66.
t=0 0.
m=audio 38002 RTP/AVP 18 0 4 8.
a=rtpmap:18 G729/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:4 G723/8000/1.
a=rtpmap:8 PCMA/8000/1.
Here is the packet, before the relay:
#
U 216.87.128.66:5060 -> 64.90.42.25:5060
INVITE sip:12143357976@augustvoice.net SIP/2.0.
Via: SIP/2.0/UDP
216.87.128.66:5060;branch=d759600326ab4b8723b14f7018c275ed.0.
Session-Expires: 3600.
From: <sip:2427747@192.168.100.240>
;tag=c0a864f0-13c4-3e3aa732-18c475-66c8.
To: <sip:12143357976@augustvoice.net> ;user=phone.
Call-ID: 5ac028-c0a864f0-13c4-3e3aa732-18c470-4b6b(a)192.168.100.240.
CSeq: 2 INVITE.
Contact:
<sip:k8ex0OqvaIVP67HyZebtvBXspeGgTWCbIdRmeKFadF3mjX4ihSIWQ7SZB5J94eb6@21
6.87.128.66>.
Authorization: Digest username="2427747", realm="augustvoice.net",
nonce="3e3aa86100000000d30d21f53b86fc0a5d1937a886aa2cdf",
uri="sip:12143357976@augustvoice.net",
response="287dd5ea9fc510acf7f7413dd711a928", algorithm=MD5.
User-Agent: FXS_GW (4asipfxs.101.BIN).
Content-Type: application/SDP.
Content-Length: 238.
.
v=0.
o=FXS_GW 12367 0 IN IP4 216.87.128.66.
s=Audio Session.
i=Audio Session.
c=IN IP4 216.87.128.66.
t=0 0.
m=audio 38002 RTP/AVP 18 0 4 8.
a=rtpmap:18 G729/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:4 G723/8000/1.
a=rtpmap:8 PCMA/8000/1.
If I was guessing, I'd say that the 'consume credentials' was leaving
the last two characters
of the Authorization line. That is, the 5 and the \r (somehow the \n
is removed).
I'm running version 0.8.10.
---greg
Greg Fausak
August.Net Services, LLC
11:38 p.m.
New subject: [Serusers] Consume_credentials failing?
Greg,
you are right, that is a ser bug -- we experienced and fixed it at
our iptel.org site but have not released a patch. Feel free to download
source code for the auth module in use at iptel
http://www.iptel.org/~jiri/ser/auth.tar.gz
That should hopefuly help. If you problem persists, let us know.
-jiri
At 05:58 PM 1/31/2003, Greg Fausak wrote:
I'm still working on debugging communication
between
my SER server and nikotel's. One of the engineers there
did a very thorough disection of the INVITE packet.
I notice a '5' sneaking in...it must be introduced by the
SER server.
Here is the packet:
#
U 64.90.42.25:5060 -> 63.214.186.6:5060
INVITE sip:12143357976@63.214.186.6:5060 SIP/2.0.
Max-Forwards: 10.
Record-Route: <sip:12143357976@64.90.42.25;branch=0>.
Via: SIP/2.0/UDP 64.90.42.25;branch=z9hG4bK974c.7b992247.0.
Via: SIP/2.0/UDP
216.87.128.66:5060;branch=d759600326ab4b8723b14f7018c275ed.0.
Session-Expires: 3600.
From: <sip:2427747@192.168.100.240>
;tag=c0a864f0-13c4-3e3aa732-18c475-66c8.
To: <sip:12143357976@augustvoice.net> ;user=phone.
Call-ID: 5ac028-c0a864f0-13c4-3e3aa732-18c470-4b6b(a)192.168.100.240.
CSeq: 2 INVITE.
Contact:
<sip:k8ex0OqvaIVP67HyZebtvBXspeGgTWCbIdRmeKFadF3mjX4ihSIWQ7SZB5J94eb6@21
6.87.128.66>.
5.
User-Agent: FXS_GW (4asipfxs.101.BIN).
Content-Type: application/SDP.
Content-Length: 238.
.
v=0.
o=FXS_GW 12367 0 IN IP4 216.87.128.66.
s=Audio Session.
i=Audio Session.
c=IN IP4 216.87.128.66.
t=0 0.
m=audio 38002 RTP/AVP 18 0 4 8.
a=rtpmap:18 G729/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:4 G723/8000/1.
a=rtpmap:8 PCMA/8000/1.
Here is the packet, before the relay:
#
U 216.87.128.66:5060 -> 64.90.42.25:5060
INVITE sip:12143357976@augustvoice.net SIP/2.0.
Via: SIP/2.0/UDP
216.87.128.66:5060;branch=d759600326ab4b8723b14f7018c275ed.0.
Session-Expires: 3600.
From: <sip:2427747@192.168.100.240>
;tag=c0a864f0-13c4-3e3aa732-18c475-66c8.
To: <sip:12143357976@augustvoice.net> ;user=phone.
Call-ID: 5ac028-c0a864f0-13c4-3e3aa732-18c470-4b6b(a)192.168.100.240.
CSeq: 2 INVITE.
Contact:
<sip:k8ex0OqvaIVP67HyZebtvBXspeGgTWCbIdRmeKFadF3mjX4ihSIWQ7SZB5J94eb6@21
6.87.128.66>.
Authorization: Digest username="2427747", realm="augustvoice.net",
nonce="3e3aa86100000000d30d21f53b86fc0a5d1937a886aa2cdf",
uri="sip:12143357976@augustvoice.net",
response="287dd5ea9fc510acf7f7413dd711a928", algorithm=MD5.
User-Agent: FXS_GW (4asipfxs.101.BIN).
Content-Type: application/SDP.
Content-Length: 238.
.
v=0.
o=FXS_GW 12367 0 IN IP4 216.87.128.66.
s=Audio Session.
i=Audio Session.
c=IN IP4 216.87.128.66.
t=0 0.
m=audio 38002 RTP/AVP 18 0 4 8.
a=rtpmap:18 G729/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:4 G723/8000/1.
a=rtpmap:8 PCMA/8000/1.
If I was guessing, I'd say that the 'consume credentials' was leaving
the last two characters
of the Authorization line. That is, the 5 and the \r (somehow the \n
is removed).
I'm running version 0.8.10.
---greg
Greg Fausak
August.Net Services, LLC
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
1 Feb
1 Feb
1:56 a.m.
New subject: [Serusers] Consume_credentials failing?
Thanks :-)
That fixed it!
---greg
-----Original Message-----
From: serusers-admin(a)lists.iptel.org
[mailto:serusers-admin@lists.iptel.org] On Behalf Of Jiri Kuthan
Sent: Friday, January 31, 2003 3:38 PM
To: Greg Fausak; serusers(a)lists.iptel.org
Subject: Re: [Serusers] Consume_credentials failing?
Greg,
you are right, that is a ser bug -- we experienced and fixed it at
our iptel.org site but have not released a patch. Feel free
to download
source code for the auth module in use at iptel
http://www.iptel.org/~jiri/ser/auth.tar.gz
That should hopefuly help. If you problem persists, let us know.
-jiri
At 05:58 PM 1/31/2003, Greg Fausak wrote:
I'm still working on debugging communication
between
my SER server and nikotel's. One of the engineers there
did a very thorough disection of the INVITE packet.
I notice a '5' sneaking in...it must be introduced by the
SER server.
Here is the packet:
#
U 64.90.42.25:5060 -> 63.214.186.6:5060
INVITE sip:12143357976@63.214.186.6:5060 SIP/2.0.
Max-Forwards: 10.
Record-Route: <sip:12143357976@64.90.42.25;branch=0>.
Via: SIP/2.0/UDP 64.90.42.25;branch=z9hG4bK974c.7b992247.0.
Via: SIP/2.0/UDP
216.87.128.66:5060;branch=d759600326ab4b8723b14f7018c275ed.0.
Session-Expires: 3600.
From: <sip:2427747@192.168.100.240>
;tag=c0a864f0-13c4-3e3aa732-18c475-66c8.
To: <sip:12143357976@augustvoice.net> ;user=phone.
Call-ID: 5ac028-c0a864f0-13c4-3e3aa732-18c470-4b6b(a)192.168.100.240.
CSeq: 2 INVITE.
Contact:
<sip:k8ex0OqvaIVP67HyZebtvBXspeGgTWCbIdRmeKFadF3mjX4ihSIWQ7SZ
B5J94eb6@21
6.87.128.66>.
5.
User-Agent: FXS_GW (4asipfxs.101.BIN).
Content-Type: application/SDP.
Content-Length: 238.
.
v=0.
o=FXS_GW 12367 0 IN IP4 216.87.128.66.
s=Audio Session.
i=Audio Session.
c=IN IP4 216.87.128.66.
t=0 0.
m=audio 38002 RTP/AVP 18 0 4 8.
a=rtpmap:18 G729/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:4 G723/8000/1.
a=rtpmap:8 PCMA/8000/1.
Here is the packet, before the relay:
#
U 216.87.128.66:5060 -> 64.90.42.25:5060
INVITE sip:12143357976@augustvoice.net SIP/2.0.
Via: SIP/2.0/UDP
216.87.128.66:5060;branch=d759600326ab4b8723b14f7018c275ed.0.
Session-Expires: 3600.
From: <sip:2427747@192.168.100.240>
;tag=c0a864f0-13c4-3e3aa732-18c475-66c8.
To: <sip:12143357976@augustvoice.net> ;user=phone.
Call-ID: 5ac028-c0a864f0-13c4-3e3aa732-18c470-4b6b(a)192.168.100.240.
CSeq: 2 INVITE.
Contact:
<sip:k8ex0OqvaIVP67HyZebtvBXspeGgTWCbIdRmeKFadF3mjX4ihSIWQ7SZ
B5J94eb6@21
6.87.128.66>.
Authorization: Digest username="2427747", realm="augustvoice.net",
nonce="3e3aa86100000000d30d21f53b86fc0a5d1937a886aa2cdf",
uri="sip:12143357976@augustvoice.net",
response="287dd5ea9fc510acf7f7413dd711a928", algorithm=MD5.
User-Agent: FXS_GW (4asipfxs.101.BIN).
Content-Type: application/SDP.
Content-Length: 238.
.
v=0.
o=FXS_GW 12367 0 IN IP4 216.87.128.66.
s=Audio Session.
i=Audio Session.
c=IN IP4 216.87.128.66.
t=0 0.
m=audio 38002 RTP/AVP 18 0 4 8.
a=rtpmap:18 G729/8000/1.
a=rtpmap:0 PCMU/8000/1.
a=rtpmap:4 G723/8000/1.
a=rtpmap:8 PCMA/8000/1.
If I was guessing, I'd say that the 'consume credentials' was leaving
the last two characters
of the Authorization line. That is, the 5 and the \r
(somehow the \n
is removed).
I'm running version 0.8.10.
---greg
Greg Fausak
August.Net Services, LLC
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
midnight
At 01:30 PM 1/31/2003, Ivan Vignola wrote:
Hi,
I have successfully (I think that) installed SER server with ser-mysql package.
I have set the environment variable 'SIP_DOMAIN="192.168.11.237"' (that
is server IP address).
I have succesfully added a user to subscriber table: 'serctl add ivan ivanpswd
ivan(a)hotmail.com'#39;, but registering WM to server fails:
URI = 'ivan(a)192.168.11.237'
Passwowd = 'ivanpswd'
User = 'ivan'
This is my ser.cfg file:
if (!www_authorize("192.168.11.237",
"subscriber")) {
if (!proxy_authorize("192.168.11.237",
"subscriber")) {
www_challenge("engiweb.org", "0");
break;
};
this is probably where the trouble lives. I'm too coffeinized now to see quickly what
is
the exaxct problem reason but two things seem strange to me:
- you challenge with a different realm ("engiweb") than you verify
("192...")
- the way how you compose ser actions is not easy to understand ... www_authorize's
'{' is matched by '}' behind save and before lookup. I guess that if
www_authorize
returns true (credentials are ok) a REGISTER is not saved but looked up, which is
what you probably do not want to do.
-jiri
7996
days inactive
7996
days old
5 comments
4 participants
participants (4)
-
Greg Fausak -
Ivan Vignola -
Jiri Kuthan -
Nils Ohlmeier