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.
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
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
Hey Klaus,
It was solved by commenting the fix_nated_contact() in my route section that deals with NAT. In that section, if was found that NAT is required then it does: force_rport(); fix_nated_contact(); // which is not commented
are there any side-effects to doing this?
Regards, 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
-
Klaus Darilion -
liran tal