I have seen this problem as well I thought it was just me. It seemed to be related to using IP addresses after the @ instead of a hostname after the @. It was happening to me when I was trying to REGISTER. When I used the hostname instead of IP address after the @ the problem went away. This does look like some kind of bug, because both should work.
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Chintan Thakker Sent: Thursday, July 03, 2003 12:36 PM To: Jan Janak; Andy Blen; serusers@lists.iptel.org Subject: Re: [Serusers] 483 - Too many hops
Hi, I tried with the latest version of 'ser' (0.8.11pre32) - the one you have mentioned in this email. I still get this problem(483 - Too Many Hops). I have also attached the trace. Also attached is version info from 'serctl' and the modifications to ser.cfg Thanks,
--- Start serctl monitor output ---
[cycle #: 117; if constant make sure server lives and fifo is on] Server: Sip EXpress router (0.8.11pre32 (i386/linux)) Now: Thu Jul 3 11:38:29 2003 Up Since: Thu Jul 3 11:34:22 2003 Up time: 247 [sec]
Transaction Statistics Current: 0 (0 waiting) Total: 70 (0 local) Replied localy: 140 Completion status 6xx: 0, 5xx: 0, 4xx: 70, 3xx: 0,2xx: 0
Stateless Server Statistics 200: 2 202: 0 2xx: 0 300: 0 301: 0 302: 0 3xx: 0 400: 0 401: 0 403: 0 404: 0 407: 0 408: 0 483: 0 4xx: 0 500: 0 5xx: 0 6xx: 0 xxx: 0 failures: 0
UsrLoc Stats Domain Registered Expired 'location' 2 0 --- End serctl monitor output ---
--- Start modifications to ser.cfg --- - 68 69 # main routing logic => changed 70 alias="192.1.2.17" 71 route{ 72 73 # initial sanity checks -- messages with 74 # max_forwards==0, or excessively long requests
--- End modifications to ser.cfg --- --- Start ngrep trace --- U 2003/07/03 11:36:24.652257 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=z9hG4bK2685.Max-Forwards: 70.From: 9727619271 <sip:9727619271@192.1.2 .88>;tag=2685.To: 9727610001 sip:9727610001@192.1.2.17.Call-ID: 87661871@ 192.1.2.88.CSeq: 1 INVITE.Contact: sip:9727619271@192.1.2.88.Content-Type : application/sdp.Content-Length: 128.Route: sip:192.1.2.17;lr..v=0.o=use rname 2685 2685 IN IP4 192.1.2.88.s=Session SDP.c=IN IP4 192.1.2.88.t=0 0.m =audio 54454 RTP/AVP 0.a=rtpmap:0 PCMU/8000. # U 2003/07/03 11:36:24.653214 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=z9hG4bK2685..From: 9727619271 sip:9727619271@192.1.2.88; tag=2685.To: 9727610001 sip:9727610001@192.1.2.17.Call-ID: 87661871@192.1 .2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre32 (i386/linux)). .Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy feedback tells: pi d=6246 req_src_ip=192.1.2.88 req_src_port=5060 in_uri=sip:9727610001@192.1. 2.17 out_uri=sip:9727610001@192.1.2.17 via_cnt==1".... # U 2003/07/03 11:36:25.060733 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=z9hG4bK2 685..From: 9727619271 sip:9727619271@192.1.2.88;tag=2685.To: 9727610001 <
sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.1464.Call-I D: 87661871@192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre 32 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy fe edback tells: pid=6249 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".... # U 2003/07/03 11:36:25.227027 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=z9hG4bK2 685..From: 9727619271 sip:9727619271@192.1.2.88;tag=2685.To: 9727610001 <
sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.1464.Call-I D: 87661871@192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre 32 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy fe edback tells: pid=6249 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".... # U 2003/07/03 11:36:27.230705 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=z9hG4bK2 685..From: 9727619271 sip:9727619271@192.1.2.88;tag=2685.To: 9727610001 <
sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.1464.Call-I D: 87661871@192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre 32 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy fe edback tells: pid=6249 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 ngrep trace ---
Jan Janak wrote:
Hello,
That was a bug in record routing module. It is now fixed in the stable branch of the CVS.
See http://iptel.org/ser/cvs for description of downloading the stable branch, or you can download it from here:
http://iptel.org/~janakj/stable/ser-0.8.11pre32_src.tar.gz
Please upgrade your ser and try again. Thanks for reporting it.
Jan.
On 24-06 16:39, Chintan Thakker wrote:
Thank you for your patience, I have put all the traces here..
-- ngrep trace start --
ngrep -t port 5060 interface: eth0 (192.1.2.0/255.255.255.0) filter: ip and ( port 5060 ) # # U 2003/06/24 16:44:39.787675 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=z9hG4bK2342.Max-Forwards: 70.From: 9727619271 sip:9727619271@192.1.2 .88;tag=2342.To: 9727610001 sip:9727610001@192.1.2.17.Call-ID: 71327895@ 192.1.2.88.CSeq: 1 INVITE.Contact: sip:9727619271@192.1.2.88.Content-Type : application/sdp.Content-Length: 128.Route: sip:192.1.2.17;lr..v=0.o=use rname 2342 2342 IN IP4 192.1.2.88.s=Session SDP.c=IN IP4 192.1.2.88.t=0 0.m =audio 54454 RTP/AVP 0.a=rtpmap:0 PCMU/8000. # U 2003/06/24 16:44:39.788623 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=z9hG4bK2342..From: 9727619271 sip:9727619271@192.1.2.88; tag=2342.To: 9727610001 sip:9727610001@192.1.2.17.Call-ID: 71327895@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:5060 "Noisy feedback tells: pi d=17073 req_src_ip=192.1.2.88 req_src_port=5060 in_uri=sip:9727610001@192.1 .2.17 out_uri=sip:9727610001@192.1.2.17 via_cnt==1".... # U 2003/06/24 16:44:40.213333 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=z9hG4bK2 342..From: 9727619271 sip:9727619271@192.1.2.88;tag=2342.To: 9727610001 <
sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.e341.Call-
I
D: 71327895@192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre 29 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy fe edback tells: pid=17072 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".... # U 2003/06/24 16:44:40.813094 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=z9hG4bK2 342..From: 9727619271 sip:9727619271@192.1.2.88;tag=2342.To: 9727610001 <
sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.e341.Call-
I
D: 71327895@192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre 29 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy fe edback tells: pid=17072 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".... # U 2003/06/24 16:44:42.816700 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=z9hG4bK2 342..From: 9727619271 sip:9727619271@192.1.2.88;tag=2342.To: 9727610001 <
sip:9727610001@192.1.2.17>;tag=b27e1a1d33761e85846fc98f5f3a7e58.e341.Call-
I
D: 71327895@192.1.2.88.CSeq: 1 INVITE.Server: Sip EXpress router (0.8.11pre 29 (i386/linux))..Content-Length: 0..Warning: 392 192.1.2.17:5060 "Noisy fe edback tells: pid=17072 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"....
-- ngrep trace end --
Andy Blen wrote:
That was a false track. Can you make us a favor please and send messages as you see them on your loopback interface.
thanks,
-andy
At 11:00 PM 6/24/2003, Chintan Thakker wrote:
I do not completely follow what you are trying to say,
The server is running on 192.1.2.17 and I am registering two users
Thank you,
-- start ./serctl ul show -- ===Domain list=== ---Domain--- name : 'location' size : 512 table: 0x422b88c4 d_ll { n : 2 first: 0x422ba8f4 last : 0x422baa78 }
...Record(0x422ba8f4)... domain: 'location' aor : '9727619271'
domain : 'location' aor : '9727619271' Contact: 'sip:9727619271@192.1.2.88' Expires: 3569 q : 0.00 Call-ID: '1241@192.1.2.88' CSeq : 1 replic : 0 State : CS_NEW next : (nil) prev : (nil) ~~~/Contact~~~~ .../Record... ...Record(0x422baa78)... domain: 'location' aor : '9727610001' ~~~Contact(0x422bab0c)~~~ domain : 'location' aor : '9727610001' Contact: 'sip:9727610001@192.1.2.223' Expires: 3595 q : 0.00 Call-ID: '1281@192.1.2.223' CSeq : 1 replic : 0 State : CS_NEW next : (nil) prev : (nil) ~~~/Contact~~~~ .../Record... ---/Domain--- ===/Domain list=== -- end ./serctl ul show -- Andy Blen wrote: >(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: > > > > > > >>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@192.1.2.88.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@192.1.2.88.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@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@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@lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers >> >> >> >> >> >> >-- >Andy Blen >iptel.org Services > > > > >
-- Andy Blen iptel.org Services
-- Andy Blen iptel.org Services
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers