Ok I took another look on my .cfg and it goes as follows,
I'm using the fix_nated_contact in the following sections:

I use it on route { } in an if (loose_route()) where the nat_uac_test("19") is true
next up on the route { } for handling registers
then on route { } for nat traversal handling after force_rport() and then following it there are some setflags and force_rtp_proxy()
the last section it's at is the onreply_route { } but only if the nat_uac_test("1") is true

I hope this gives some more information on the issue.
Could it be something else other than the fix_nated_contact() that I should be looking for?


Thanks,
Lir.


On 7/24/07, Klaus Darilion <klaus.mailinglists@pernau.at> wrote:
I suspect you are using fix_nated_contact twice. Use it only in route[],
but not in failure_route[]

klaus

liran tal wrote:
> Hey everyone,
>
> I'm using sequential forking and on one of the scenarios there appears
> to be a problem.
>
> When OpenSER attempts to find the first most relevant destination for the
> call the SIP headers are ok. If the first destination that OpenSER attempts
> to contact is offline/unreachable it continues to the next one in turn in
> which
> it produces a bad Contact header which looks like this:
>
> Contact: <sip:101@192.168.0.1:5060sip:101@192.168.0.1:5060>
>
> As you can see it's writing the sip information twice for some reason.
> Has anyone seen this happen before?
> Also, where should I be looking at to find the problem?
>
>
> Thanks,
> Lir.
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users@openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users