[Serusers] Too Many Hops

Greger V. Teigre greger at teigre.com
Fri Nov 18 07:41:06 CET 2005


Noel,
Thanks for taking the time to document your setup in such detail!
In general, the Vias and record-routes must be fixed. The rr parameter 
enable_double_rr should be 1 (default). AFAIK, mhome=1 should handle the 
vias. This thread may give some more background:
http://lists.iptel.org/pipermail/serdev/2003-April/000003.html

Have you tried using record_route_preset on outgoing (if I understand you 
setup?) to add the correct (public) address?

Also, unless mhome is on, the source address of the incoming packet will be 
used when sending out. This will be detected as a martian by the linux 
kernel (see /var/log/messages). mhome will use the correct source address 
and fix the vias.

Anyway, if your fix works, you should be fine, but remember that if you 
change your setup later (or add a new GW, new UAs...), you may run into 
problems as you are not following the RFC.
g-)


----- Original Message ----- 
From: "Noel Sharpe" <noels at radnetwork.co.uk>
To: "Greger V. Teigre" <greger at teigre.com>
Cc: "'SER Users'" <serusers at lists.iptel.org>
Sent: Wednesday, November 16, 2005 9:52 AM
Subject: Re: [Serusers] Too Many Hops


> Greger
> I am trying to get a cascading hierarchy of geographically  separated SIP 
> servers. The reason for this is that I am providing services to a wireless 
> community that connect to the internet via many different gateways to the 
> internet.  Most of the users are behind a nat device, and connect to a SER 
> proxy on the wireless net work on the 10.0.0.0/8 network.  Each SER server 
> keeps a local location database, but forwards any requests that it cannot 
> complete to a sip proxy on the internet (to which each SER proxy 
> replicates all REGISTER's).  It looks a bit like this:
>
> UAC(192.168.0.123)--->WIFI_AP(10.1.2.3)---->WIFI_GATEWAY_1--->INTERNET for 
> browsing / email / ftp etc
>                                                 |
>                                                 |
>                                                 v
>                                            SER_SERVER on WiFi network 
> (10.0.0.123)     also has (public IP Address)--->INTERNET GATEWAY for VOIP 
> 1--->SER_SERVER on internet
>                                                                         ^
>                                                                         |
> UAC(192.168.0.234)--->WIFI_AP(10.3.4.5)---->WIFI_GATEWAY_2--->INTERNET for 
> browsing / email / ftp etc                  |
>                                                 |                     |
>                                                 |                     |
>                                                 v                     |
>                                            SER_SERVER on WiFi network 
> (10.3.4.123)                                    |
>                                                       also has (public IP 
> Address)--->INTERNET GATEWAY for VOIP 2-----
>
>
> Each SER server implements it's own far end nat traversal based on 
> nathelper/rtpproxy, which means that expensive internet links are not used 
> to terminate calls between subscribers on the same wifi network.
> The issue I was having with loose routing appeared to be because the 
> SER_SERVER on the WiFi network was multihomed.  When a reply cam back from 
> the ser server on the internet (I think it was only ACK's causing the 
> problem), SER tried to loose_route the reply and the next hop was infact 
> the servers own internal ip address.
>
> After loosing much hair, I worked out that if I included the condition I 
> could get the packet to route through to the correct final destination.  I 
> am not sure if it's because there is a REAL issue with loose_route not 
> working with mhomed properly, or if it's a peculiarity of my setup.
>
> Noel
>
>
> Greger V. Teigre wrote:
>
>> Noel,
>> It would be interesting to get a description of the setup that caused 
>> this problem. Was that Asterisk as well? Same setup as Giovanni? 
>> Dependent on auth/non-auth and how Asterisk has been set up with SER, we 
>> have seen different problems with signalling and proxying of RTP.  I know 
>> there was an lr vs. lr=on issue a while back, but somewhere we don't have 
>> RFC compliant behavior (all messages with routes should be loose routed).
>> g-)
>>
>> ----- Original Message ----- From: "Noel Sharpe" <noels at radnetwork.co.uk>
>> To: "Giovanni Balasso" <giaso at yahoo.it>
>> Cc: <serusers at lists.iptel.org>
>> Sent: Tuesday, November 15, 2005 10:14 AM
>> Subject: Re: [Serusers] Too Many Hops
>>
>>
>>> sounds to me like you have a looping problem in your script.  I had 
>>> something similar when using the example from OnSIP.org.  The 
>>> loose_route bit needed to be inside a condition:
>>>    if (uri!=myself){
>>>        if (loose_route()) {
>>>            route(1);      };          };
>>> xlog/ngrep is your friend here as you will be able to see which message 
>>> is being sent between the two servers.
>>>
>>> Noel
>>>
>>> Giovanni Balasso wrote:
>>>
>>>> Alle 09:47, mercoledì 02 novembre 2005, Matteo Piazza ha scritto:
>>>>
>>>>> I have Ser and asterisk on the same machine.
>>>>> When i try to call with a SIP phone registred on asterisk another sip
>>>>> phone also registred on asterisk through SER I receve this error 
>>>>> message:
>>>>> Too many hops
>>>>>
>>>>
>>>> Too many hops is usually reached when there is no rule (or no way) to 
>>>> deliver sip message, adding some log(), or better xlog(), to your 
>>>> routing script could help you (and us) debugging and understanding 
>>>> what's wrong, and which method(s) fail.
>>>>
>>>>
>>>>
>>>>>        if (method == "INVITE") {
>>>>>          if (uri =~"^sip:0[0-9]*@*"){
>>>>>           log(1, "Check 1 succed Forwarding to Asterisk\n");
>>>>>           rewritehostport("192.168.9.97:5061");
>>>>>           t_relay();
>>>>>           break;
>>>>>          };
>>>>>         };
>>>>>
>>>>>
>>>>
>>>> I don't think this will solve your problem but in my experience I had 
>>>> better result with t_relay_to_udp("192.168.9.97","5061") than 
>>>> rewritehostport("192.168.9.97:5061").
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>
>>
> 




More information about the sr-users mailing list