|
|
@@ -1,8 +1,13 @@
|
|
|
$Id$
|
|
|
|
|
|
|
|
|
-Installation Notes
|
|
|
-===================
|
|
|
+ ===========================================
|
|
|
+
|
|
|
+ SIP Express Router (ser) Installation Notes
|
|
|
+
|
|
|
+ http://www.iptel.org/ser/
|
|
|
+
|
|
|
+ ===========================================
|
|
|
|
|
|
TOC
|
|
|
|
|
|
@@ -13,7 +18,7 @@ TOC
|
|
|
B) Disclaimers
|
|
|
C) Quick Start
|
|
|
D) ser with Persistent Data Storage
|
|
|
- E) Troubleshooting
|
|
|
+4. Troubleshooting
|
|
|
|
|
|
|
|
|
|
|
|
@@ -241,7 +246,7 @@ Solaris:
|
|
|
|
|
|
|
|
|
D) ser with Persistent Data Storage
|
|
|
-----------------------------------------------
|
|
|
+
|
|
|
The default configuration is very simple and features many simplifications.
|
|
|
In particular, it does not authenticate users and loses User Location
|
|
|
database on reboot. To provide persistency, keep user credentials and remember
|
|
|
@@ -291,3 +296,30 @@ proceed, you need to make sure MySQL is installed on your box.
|
|
|
b) try to login with your SIP client as user 'admin' with password 'heslo'
|
|
|
c) try adding new users using
|
|
|
'serctl add <name> <password> <email>'
|
|
|
+
|
|
|
+4. Troubleshooting
|
|
|
+------------------
|
|
|
+
|
|
|
+Q: Windows Messenger authentication fails.
|
|
|
+
|
|
|
+A: The most likely reason for this problem is a bug in Windows Messenger.
|
|
|
+WM only authenticates if server name in request URI equals authentication
|
|
|
+realm. After a challenge is sent by SIP server, WM does not resubmit the
|
|
|
+challenged request at all and pops up authentication window again. If you
|
|
|
+want to authenticate WM, you need to set up your realm value to equal server
|
|
|
+name. If your server has no name, IP address can be used as realm too.
|
|
|
+
|
|
|
+Q: SIP requests are replied by ser with "483 Too Many Hops" or
|
|
|
+ "513 Message Too Large"
|
|
|
+
|
|
|
+A: In both cases, the reason is probably an error in request routing script
|
|
|
+ which caused an infinite loop. You can easily verify whether this happens
|
|
|
+ by watching SIP traffic on loopback interface. A typical reason for misrouting
|
|
|
+ is a failure to match local domain correctly. If a server fails to recognize
|
|
|
+ a request for itself, it will try to forward it to current URI in believe it
|
|
|
+ would forward them to a foreign domain. Alas, it forwards the request to itself
|
|
|
+ again. This continues to happen until value of max_forwards header field reaches
|
|
|
+ zero or the request grows too big. Solutions is easy: make sure that domain matching
|
|
|
+ is correctly configured. A quick way to achieve that is to introduce a config
|
|
|
+ option to ser.cfg: alias=domainname, where domainname shall be replaced with
|
|
|
+ name of domain, which you wish to server and which appears in request-URIs.
|
Jiri Kuthan