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: >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: &gt;&gt;&gt;421668676(a)192.1.2.88.CSeq2.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 &gt;&gt;&gt;68676(a)192.1.2.88.CSeq2.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 &gt;&gt;&gt;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 &gt;&gt;&gt;serusers(a)lists.iptel.org >>>http://lists.iptel.org/mailman/listinfo/serusers >>> >>> >>> >>> >>-- >>Andy Blen >>iptel.org Services >> >> >> > > > -- Andy Blen iptel.org Services