[Devel] Parse Errors, error_route and fixing common NAT ALG bugs

[Daniel-Constantin Mierla]

Hello Aron,

if the Via header is broken the routing blocks are not invoked and 
message is discarded. This because the the reply cannot be routed back. 
For the future, we may try to introduce severity levels, and send back 
if possible a 400.

You can force rport all the time, there is a core function for that:
http://openser.org/dokuwiki/doku.php/core-cookbook:devel#force_rport

Cheers,
Daniel


On 03/11/07 19:31, Aron Rosenberg wrote:
>
> This is a discussion question mostly, but part bug report. Our 
> application targets general consumers and as such we see a huge amount 
> of “broken” SIP message traffic come to our servers. These are packets 
> where “friendly” NATs/routers try to fixup the SIP traffic to undo the 
> NAT behavior. While most of these routers do the right thing, we have 
> noticed several that have bugs in their implementations. These bugs 
> manifest themselves as a mangling of the SIP headers in one or another.
>
> The major issue that we see in consumer routers is that the Via: 
> header has been reconstructed incorrectly. The OpenSER bug that we see 
> here is that an incorrect Via header does NOT result in error_route 
> being invoked, nor does it result in a 400 error packet being sent to 
> the originator either.
>
> The discussion point is should OpenSER try to “fix” these broken 
> routers so that the traffic can be used correctly. Two of the most 
> common errors that our servers see are below
>
> Issue 1. The via header has a port that is totally out of range. This 
> error comes from the default DSL modem that Embarq / Sprint.net ships 
> to their customers.
>
> Via: SIP/2.0/UDP 
> 1.1.1.1:13088001;branch=z9hG4bK-d87543-0865e7125c508513-1--d87543-;rport
>
> Issue 2. The via header originally had a rport param from our client, 
> but the router stripped it off incorrectly, notice how it ends in just 
> a ; We believe this error is caused by Linksys WRT54G routers that 
> don’t have recent firmware.
>
> Via: SIP/2.0/UDP 
> 1.1.1.1:56261;branch=z9hG4bK-d87543-9b572d31e0515e44-1--d87543-;
>
> In both of these cases the NAT / router is changing the existing VIA 
> header rather than adding a new VIA line
>
> The question is should OpenSER allows these errors to proceed to the 
> script layer? Right now it just swallows the packet.
>
> Issue 1, if allowed to reach the script layer would be fixed by our 
> call to nat_uac_test(“23”) and fix_nated_contact().
>
> Issue 2, I am not so sure what the behavior would be if it reached the 
> script layer.
>
> Thoughts?
>
> -Aron Rosenberg
>
> SightSpeed Inc.
>
> http://www.sightspeed.com <http://www.sightspeed.com/>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel
>