Browse code

troubleshooting section added

Jiri Kuthan authored on 05/01/2003 21:10:46
Showing 1 changed files
... ...
@@ -1,8 +1,13 @@
1 1
 $Id$
2 2
 
3 3
 
4
-Installation Notes
5
-===================
4
+     ===========================================
5
+
6
+     SIP Express Router (ser) Installation Notes
7
+
8
+             http://www.iptel.org/ser/
9
+
10
+     ===========================================
6 11
 
7 12
 TOC
8 13
 
... ...
@@ -13,7 +18,7 @@ TOC
13 13
    B) Disclaimers
14 14
    C) Quick Start
15 15
    D) ser with Persistent Data Storage
16
-   E) Troubleshooting
16
+4. Troubleshooting
17 17
 
18 18
 
19 19
 
... ...
@@ -241,7 +246,7 @@ Solaris:
241 241
 
242 242
 
243 243
 D) ser with Persistent Data Storage
244
+
244 245
 The default configuration is very simple and features many simplifications. 
245 246
 In particular, it does not authenticate users and loses User Location 
246 247
 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.
291 291
    b) try to login with your SIP client as user 'admin' with password 'heslo'
292 292
    c) try adding new users using 
293 293
        'serctl add <name> <password> <email>'
294
+
295
+4. Troubleshooting
296
+------------------
297
+
298
+Q: Windows Messenger authentication fails. 
299
+
300
+A: The most likely reason for this problem is a bug in Windows Messenger. 
301
+WM only authenticates if server name in request URI equals authentication 
302
+realm. After a challenge is sent by SIP server, WM does not resubmit the 
303
+challenged request at all and pops up authentication window again. If you 
304
+want to authenticate WM, you need to set up your realm value to equal server 
305
+name. If your server has no name, IP address can be used as realm too.
306
+
307
+Q: SIP requests are replied by ser with "483 Too Many Hops" or 
308
+   "513 Message Too Large"
309
+
310
+A: In both cases, the reason is probably an error in request routing script 
311
+   which caused an infinite loop. You can easily verify whether this happens 
312
+   by watching SIP traffic on loopback interface. A typical reason for misrouting 
313
+   is a failure to match local domain correctly. If a server fails to recognize 
314
+   a request for itself, it will try to forward it to current URI in believe it 
315
+   would forward them to a foreign domain. Alas, it forwards the request to itself 
316
+   again. This continues to happen until value of max_forwards header field reaches 
317
+   zero or the request grows too big. Solutions is easy: make sure that domain matching 
318
+   is correctly configured. A quick way to achieve that is to introduce a config
319
+   option to ser.cfg: alias=domainname, where domainname shall be replaced with
320
+   name of domain, which you wish to server and which appears in request-URIs.