[Serusers] Too Many Hops
Noel Sharpe
noels at radnetwork.co.uk
Wed Nov 16 09:52:16 CET 2005
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