24 Jun
2003
24 Jun
'03
11:14 p.m.
Hi,
I'm seeing this particular message much more
often with the CVS code than I did with the 8.10 code.
Just an observation :-)
---greg
-----Original Message-----
From: serusers-bounces(a)lists.iptel.org
[mailto:serusers-bounces@lists.iptel.org] On Behalf Of Andy Blen
Sent: Tuesday, June 24, 2003 3:03 PM
To: Chintan Thakker
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] 483 - Too many hops
(you forgot to CC the mailing list)
a possibility is that the contacts you registered cause a loop.
andy
At 06:22 PM 6/24/2003, Chintan Thakker wrote:
--
Andy Blen
iptel.org Services
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Hi,
Seems I missed something, I am sending INVITE to
sip:9727610001@192.1.2.17 with
Route: <sip:192.1.2.17;lr> to
the proxy server ('ser') running on 192.1.2.17 and getting
483 - too many hops message. I modified ser.conf to add alias
= "192.1.2.17" but it still gives me the same problem.
What am I missing out ?. I guess an
'alias=192.1.2.17'
entry should return a true to 'uri==myself'
matching
performed in the script and make the server process that
request rather than forwarding it (to itself in this case)
Thanks,
Chintan
-- ser.cfg --
1 #
2 # $Id: ser.cfg,v 1.20 2003/05/31 21:12:19 jiri Exp $
3 #
4 # simple quick-start config script
5 #
6
7 # ----------- global configuration parameters
------------------------
8
9 debug=3 # debug level (cmd line: -dddddddddd)
10 fork=yes
11 log_stderror=no # (cmd line: -E)
12
13 /* Uncomment these lines to enter debugging mode
14 debug=7
15 fork=no
16 log_stderror=yes
17 */
18
19 check_via=no # (cmd. line: -v)
20 dns=no # (cmd. line: -r)
21 rev_dns=no # (cmd. line: -R)
22 port=5060
23 children=4
24 fifo="/tmp/ser_fifo"
25
26 # ------------------ module loading
----------------------------------
27
28 # Uncomment this if you want to use SQL database
29 #loadmodule "/usr/local/lib/ser/modules/mysql.so"
30
31 loadmodule "/usr/local/lib/ser/modules/sl.so"
32 loadmodule "/usr/local/lib/ser/modules/tm.so"
33 loadmodule "/usr/local/lib/ser/modules/rr.so"
34 loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
35 loadmodule "/usr/local/lib/ser/modules/usrloc.so"
36 loadmodule "/usr/local/lib/ser/modules/registrar.so"
37
38 # Uncomment this if you want digest authentication
39 # mysql.so must be loaded !
40 #loadmodule "/usr/local/lib/ser/modules/auth.so"
41 #loadmodule "/usr/local/lib/ser/modules/auth_db.so"
42
43 # ----------------- setting module-specific
parameters ---------------
44
45 # -- usrloc params --
46
47 modparam("usrloc", "db_mode", 0)
48
49 # Uncomment this if you want to use SQL database
50 # for persistent storage and comment the previous line
51 #modparam("usrloc", "db_mode", 2)
52
53 # -- auth params --
54 # Uncomment if you are using auth module
55 #
56 #modparam("auth_db", "calculate_ha1", yes)
57 #
58 # If you set "calculate_ha1" parameter to yes (which
true in this
config),
59 # uncomment also the following parameter)
60 #
61 #modparam("auth_db", "password_column", "password")
62
63 # ------------------------- request routing logic
-------------------
64
65 #add aliases
66 alias="192.1.2.17"
67
68 # main routing logic
69
70 route{
71
72 # initial sanity checks -- messages with
73 # max_forwards==0, or excessively long requests
74 if (!mf_process_maxfwd_header("10")) {
75 sl_send_reply("483","Too Many Hops");
76 break;
77 };
78 if (len_gt( max_len )) {
79 sl_send_reply("513", "Message too big");
80 break;
81 };
82
83 # we record-route all messages -- to make sure that
84 # subsequent messages will go through our
proxy; that's
85 # particularly good if upstream and
downstream entities
86 # use different transport protocol
87 record_route();
88 # loose-route processing
89 if (loose_route()) {
90 t_relay();
91 break;
92 };
93
94 # if the request is for other domain use UsrLoc
95 # (in case, it does not work, use the
following command
96 # with proper names and addresses
in it)
97 if (uri==myself) {
98
99 if (method=="REGISTER") {
100
101 # Uncomment this if you want to use digest authentication
102 # if
(!www_authorize("iptel.org",
"subscriber")) {
103 #
www_challenge("iptel.org", "0");
53,1 65%
104 # break;
105 # };
106
107 save("location");
108 break;
109 };
110
111 # native SIP destinations are handled
using our USRLOC DB
112 if
(!lookup("location")) {
113 sl_send_reply("404", "Not Found");
114 break;
115 };
116 };
117 #Let tje server [rpcess tje cirremt reqiest
118 #if(uri =~ "^sip:(.+@)?(192\.1\.2\.17)([:;\?].*)?$" )
119 #{
120 # break;
121 #};
122
123 # forward to current uri now; use stateful
forwarding; that
124 # works reliably even if we forward
from TCP to UDP
125 if (!t_relay()) {
126 sl_reply_error();
127 };
128
129 }
130
- end ser.cfg --
Andy Blen wrote:
>most likely a misconfig issue on your side, feel free to
read the doc,
http://www.iptel.org/ser/doc/prerelease/x1026.html#AEN1032
>
>andy
>
>At 12:18 AM 6/21/2003, Chintan Thakker wrote:
>
>
>>Hi,
>>Consider the following scenario. UA1 is trying to call UA2
both registered
with the same proxy. (UA1 -> 'ser' -> UA2)
>>
>>1.
>>UA1 sends INVITE to the proxy with request uri set to UA2.
It also sets
the Route header in the invite to that of the proxy.
>>This returns a 483 - too many hops to UA1
>>
>>It seems that in the above mentioned scenario, the proxy
loops back the
INVITE multiple times locally. This decrements
the Max Forwards value every time until it becomes zero and
hence sends 483 back to UA1. It seems to me this is not the
correct behavior of the server. It should forward the request to UA2.
>>
>>Thanks in advance,
>>
>>Chintan
>>
>>-- Start trace --
>>
>>U 2003/06/20 15:24:42.362466 192.1.2.88:5060 -> 192.1.2.17:5060
>>INVITE sip:9727610001@192.1.2.17 SIP/2.0.Via: SIP/2.0/UDP
192.1.2.88:5060;b
>>ranch=z9hG4bK421668676.Max-Forwards:
70.From: 9727619271
<sip:9727619271@19
>>2.1.2.88>;tag=421668676.To: 9727610001
<sip:9727610001@192.1.2.17>.Call-ID:
>>421668676(a)192.1.2.88.CSeq8.CSeq: 1
INVITE.Contact:
<sip:9727619271@192.1.2.88>.C
>>ontent-Type:
application/sdp.Content-Length: 138.Route:
<sip:192.1.2.17;lr>
>>..v=0.o=username 421668676 421668676 IN
IP4
192.1.2.88.s=Session SDP.c=IN I
>>P4 192.1.2.88.t=0 0.m=audio 54454 RTP/AVP
0.a=rtpmap:0 PCMU/8000.
>>
>>U 2003/06/20 15:24:42.363813 192.1.2.17:5060 -> 192.1.2.88:5060
>>SIP/2.0 100 trying -- your call is important to us..Via:
SIP/2.0/UDP
192.1.
>>2.88:5060;branch=z9hG4bK421668676..From:
9727619271
<sip:9727619271@192.1.2
>>.88>;tag=421668676.To: 9727610001
<sip:9727610001@192.1.2.17>.Call-ID: 4216
>>68676(a)192.1.2.88.CSeq8.CSeq: 1 INVITE.Server:
Sip EXpress router
(0.8.11pre29 (i3
>>86/linux))..Content-Length: 0..Warning:
392
192.1.2.17:5060 "Noisy feedback
>>tells: pid=15107 req_src_ip=192.1.2.88
req_src_port=5060
in_uri=sip:97276
>>10001(a)192.1.2.17
out_uri=sip:9727610001@192.1.2.17 via_cnt==1"....
>>#
>>U 2003/06/20 15:24:42.794681 192.1.2.17:5060 -> 192.1.2.88:5060
>>SIP/2.0 483 Too Many Hops..Via: SIP/2.0/UDP
192.1.2.88:5060;branch=z9hG4bK4
>>21668676..From: 9727619271
<sip:9727619271@192.1.2.88>;tag=421668676.To: 97
>>27610001
<sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.4
>>632.Call-ID: 421668676(a)192.1.2.88.CSeq: 1
INVITE.Server:
Sip EXpress router
>>(0.8.11pre29
(i386/linux))..Content-Length: 0..Warning:
392 192.1.2.17:506
>>0 "Noisy feedback tells: pid=15107
req_src_ip=192.1.2.17
req_src_port=5060
>>in_uri=sip:9727610001@192.1.2.17
out_uri=sip:9727610001@192.1.2.17 via_cnt
>>==71"....
>>
>>-- End trace --
>>
>>ps: We checked it with loose routing(suceeding ';lr'
present in
URIs in Route) as well as strict routing(suceeding
';lr' not present in URIs in Route). Should the type of
routing used matter ?
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Andy Blen
iptel.org Services