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@hotmail.com', but registering WM to server fails: URI = 'ivan@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/
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@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@hotmail.com', but registering WM to server fails: URI = 'ivan@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@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@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
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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Thanks :-)
That fixed it!
---greg
-----Original Message----- From: serusers-admin@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@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
-- Jiri Kuthan http://iptel.org/~jiri/
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
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@hotmail.com', but registering WM to server fails: URI = 'ivan@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