[OpenSIPS-Users] Crazy looping "bug" spotted related, apparently, to 'To:'

[Bogdan-Andrei Iancu]

Hi Jock,

The problem is tha maddr header - 1.6 has some new maddr processing and 
it seams there is a bug there. According to RFC 3261, 16.4:
   

   If the Request-URI contains a maddr parameter, the proxy MUST check
   to see if its value is in the set of addresses or domains the proxy
   is configured to be responsible for.  If the Request-URI has a maddr
   parameter with a value the proxy is responsible for, and the request
   was received using the port and transport indicated (explicitly or by
   default) in the Request-URI, the proxy MUST strip the maddr and any
   non-default port or transport parameter and continue processing as if
   those values had not been present in the request.

the maddr should be removed by opensips (as it points to itself) and to 
forward based on RURI domain part, but it seams opensips is keep using 
the maddr (overriding the RURI domain) and keep looping :(

A fast workaround will be to manually strip the maddr from RURI :
       subst_uri('/(sip:.*);maddr=[.1-9]/\1/'));

Regards,
Bogdan

PS: I have virtual_db for the next week ;)



Jock McKechnie wrote:
> Hey;
>
> I've been upgrading all of our older OpenSER 1.3 proxies to OpenSIPS 
> 1.6.0 (we have several dozen) and I found a problem child in our 
> inbound Verizon proxy. After completely destroying the configs, 
> grasping at straws and all sorts of crazy theories I discovered that 
> apparently OpenSIPS doesn't like the To: that Verizon uses. OpenSER 
> 1.3 has no issue with it, OpenSIPs 1.6 does.
>
> Even when at its most basic config (has the usual module setup, sanity 
> checks, options_reply, loose_route, etc):
>
> if (method == "INVITE") {
>     rewritehostport("destinationserver:5060');
>     }
>
> t_relay();
>
> I discovered that the call would loop through the config, over and 
> over, until it reached the Maximum Hops counter requirement and the 
> call was dumped with a 483. When I xlog()'d I could see that it was 
> correctly falling into the if { } section, the $ru was being 
> rewritten... and then, bam, it reappeared at the top of the route { } 
> block and went through it again.
>
> I've discovered that if I do this:
> if (method == "INVITE") {
>     $ru = "sip:" + $oU + "@proxyserver:5060";
>     rewritehostport("destinationserver:5060');
>     }
>
> Everything is copacetic. The original To: looks like this:
> INVITE 
> sip:+12125551212 at verizon.inbound.chi1.ourcompany.com:5060;user=phone;transport=UDP;maddr=123.123.123.123 
> SIP/2.0
>
> With the IP after 'maddr' replaced with our proxy's IP. Verizon uses 
> DNSSRV, so verizon.inbound.chi1.ourcompany.com 
> <http://verizon.inbound.chi1.ourcompany.com> points to three IPs, each 
> a SER proxy.
>
> Well, anyway, now I have a workaround it's not such a big deal, but I 
> wanted to push it out there and have it in the archives in case anyone 
> else had some insane looping issue and couldn't work out what it was.
>
> (Hey, Bogdan, any luck in getting a test case set up for the 
> non-functioning db_virtual?)
>
> Thanks;
>
>  - Jock
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro