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