[OpenSIPS-Users] Arbitrary contact added in 302 generated responses

Francisco Javier Lizaran Vilches fran.lizaran at gmail.com
Mon Jun 1 11:32:16 CEST 2009


Hi Bogdan:
  After patching the failure route the way you said, the problem seems to be
solved.
  About your question, as far as I know, no branches are created, implicitly
or explicitly. $bR is <null> before the t_relay.
Thanks:
Francisco

2009/5/25 Bogdan-Andrei Iancu <bogdan at voice-system.ro>

> Hi Francisco,
>
> First of all, please in the begining of any failure route:
>
> failure_route[x] {
>   if (t_was_cancelled()) {
>       exit;
>   }
>   .....
> }
>
> This will capture the calls which were cancelled by the caller and avoid
> any bogus processing on the cancelled call.
>
>
> Now, in regards to the "Contact" stuff, before the t_reply("3xx"), do you
> use create any new branch (via append_branch or other functions that do it
> internally)? I'm asking because when you do a 3xx reply, automatically, the
> newly set ruri and any created branches are used in the reply contact. To
> check  this, you may print the "*$bR* " var from the script, before the
> t_relay();
>
> Regards,
> Bogdan
>
>
> Francisco Javier Lizaran Vilches wrote:
>
>> Hi:
>>    I caught the failure again with logs enabled. First of all, I've
>> realized that I made a mistake explaining the issue before. There is no
>> problem with forward busy at all as I said. The problem appears with forward
>> on no answer only, so this is the part of the script to take into account:
>>
>> route[3]    {
>> ...
>> t_on_failure("1");
>> ...
>>        # forward on no answer
>>        if (is_avp_set("$avp(s:fwdnoanswer)/s")) {
>>                if ($ru==$avp(s:fwdnoanswer)) {
>>                        sl_send_reply("603", "Decline");
>>                        return;
>>                };
>>                setflag(24);
>>        };
>> ...
>> }
>>
>> failure_route[1] {
>>        if ((isflagset(24)) && (t_check_status("408"))) {
>>                xlog("L_NOTICE", "Fwdnoanswer: $avp(s:fwdnoanswer) \n");
>>                if (avp_pushto("$ru", "$avp(s:fwdnoanswer)")) {
>>                        avp_print();
>>                        t_reply("302","Moved Temporarily");
>>                        return;
>>                        };
>>                };
>>        };
>> ...
>> }
>>
>>    So, for example, user 20173 calls user 20346 which has a fwd to 20559.
>> After ring timeout expires, the proxy sends back to user 20173 a 302
>> response. In the contact header appears 20559 and another uri appended:
>>    Contact: sip:20559 at domain.com <sip%3A20559 at domain.com> <mailto:
>> sip%3A20559 at domain.com <sip%253A20559 at domain.com>>,
>> <sip:066012... at 10.100.2.254:5060;transport=udp>;q=0
>>
>>    This uri is included along all the forwardings on no answer performed
>> in the system.
>>      Looking at the log, there is no trace of such uri in the avp list:
>>    openser[11278]: Fwdnoanswer: sip:20559 at domain.com<sip%3A20559 at domain.com><mailto:
>> sip%3A20559 at domain.com <sip%253A20559 at domain.com>>
>>    ...
>>    openser[11278]: INFO:avpops:print_avp: p=0xb57356a8, flags=0x0083
>>    openser[11278]: INFO:            name=<fwdnoanswer>
>>    openser[11278]: INFO:            val_str=<sip:20559 at domain.com<sip%3A20559 at domain.com><mailto:
>> sip%3A20559 at domain.com <sip%253A20559 at domain.com>> / 23>
>>    ...
>>
>>    Searching through the log back in time I have seen the last call to uri
>> 66012...    openser[11278]: ERROR:tm:t_forward_nonack: discarding fwd for a
>> cancelled/6xx transaction
>>    openser[11278]: ERROR:tm:w_t_relay: t_forward_nonack failed
>>    openser[11278]: T_RELAY ERROR: remote URI:
>> sip:076660129671 at 10.100.222.202:5060;transport=udp
>>      That time there was a correct forward no answer to this number, but
>> t_relay got an error after cancelling. Probably it is related with later
>> issues when forwarding.
>>      Regards:
>>    Francisco
>>
>> 2009/5/4 Francisco Javier Lizaran Vilches <fran.lizaran at gmail.com<mailto:
>> fran.lizaran at gmail.com>>
>>
>>    Hi Bogdan:
>>
>>    I will try to print the avp next time it occurs.
>>
>>    Thanks:
>>
>>    Francisco
>>
>>    2009/4/30 Bogdan-Andrei Iancu <bogdan at voice-system.ro
>>    <mailto:bogdan at voice-system.ro>>
>>
>>
>>        Hi Francisco,
>>
>>        First of all, maybe it will be a good idea to upgrade to
>>        OpenSIPS 1.5.1 - along the versions many bugs were fixed and
>>        1.2 is a really old one.
>>
>>        Have you tried to place an xlog and print the fwdbusy avp just
>>        before the avp_pushto() ?
>>
>>        Regards,
>>        Bogdan
>>
>>
>>        Francisco Javier Lizaran Vilches wrote:
>>
>>            Hi all:
>>            Have  running this script on Openser 1.2.3-notls version
>>            managing forwards this way:
>>
>>            route[3]    {
>>            ...
>>            t_on_failure("1");
>>            if avp_db_load("$ru", "*") {
>>                   if (is_avp_set("$avp(s:fwdbusy)/s")) {
>>                           setflag(23);
>>                   };
>>            ...
>>
>>            failure_route[1] {
>>            ...
>>                   if ((isflagset(23)) && (t_check_status("486"))) {
>>                           if (avp_pushto("$ru", "$avp(s:fwdbusy)")) {
>>                                   t_reply("302","Moved Temporarily");
>>                                   return;
>>                                   };
>>                   };
>>            ...
>>
>>            User A calls user B and B has fwdbusy parameter set in
>>            user preferences; if B is busy, proxy sends 302 message
>>            back to A with contact set to $avp(s:fwdbusy) value. This
>>            setup usually works fine. However, sometimes the proxy
>>            shows a strange behaviour. It starts to append an
>>            arbitrary contact to the contact header in every
>>            forwarding it does. The contact appended has nothing to do
>>            with A or B or the uri set in the avp. The same uri is
>>            appended in all call forwardings performed in the system.
>>            If the proxy is restarted, the problem disappears.
>>
>>            Example:
>>
>>            SIP/2.0 302 Moved Temporarily
>>            Via: SIP/2.0/UDP 10.100.2.254:5060;branch=z9hG4bK51461DD5
>>            From: <sip:30132 at 10.100.2.254 <sip%3A30132 at 10.100.2.254>
>>            <mailto:sip%3A30132 at 10.100.2.254 <sip%253A30132 at 10.100.2.254>>
>>            <mailto:sip%3A30132 at 10.100.2.254 <sip%253A30132 at 10.100.2.254>
>>            <mailto:sip%253A30132 at 10.100.2.254<sip%25253A30132 at 10.100.2.254>
>> >>>;tag=92DAB388-EE7
>>            To: <sip:20050 at domain.com <sip%3A20050 at domain.com> <mailto:
>> sip%3A20050 at domain.com <sip%253A20050 at domain.com>>
>>            <mailto:sip%3A20050 at domain.com <sip%253A20050 at domain.com>
>>            <mailto:sip%253A20050 at domain.com <sip%25253A20050 at domain.com>
>> >>>;tag=880a5593aeb097bc75600b31d6e17107-78ac
>>            Call-ID: C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF at 192.168.2.40
>>            <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF at 192.168.2.40>
>>            <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF at 192.168.2.40
>>            <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF at 192.168.2.40>>
>>            CSeq: 101 INVITE
>>            Contact: sip:30050 at domain.com <sip%3A30050 at domain.com>
>>            <mailto:sip%3A30050 at domain.com <sip%253A30050 at domain.com>>
>>            <mailto:sip%3A30050 at domain.com <sip%253A30050 at domain.com>
>>            <mailto:sip%253A30050 at domain.com <sip%25253A30050 at domain.com>
>> >>,
>>            <sip:030410 at 10.172.0.254:5060;transport=udp>;q=0
>>
>>            Server: OpenSER (1.2.3-notls (i386/linux))
>>            Content-Length: 0
>>
>>
>>            <sip:030410 at 10.172.0.254:5060;transport=udp>;q=0 is added
>>            in all forwardings done the system.
>>
>>            Unfortunately I have no debug info cause it happens in
>>            production environment. I couldn't reproduce the problem
>>            in test environment. Have you got any idea on what could
>>            make it happen?
>>
>>            Thanks a lot:
>>            Fran Lizaran
>>
>>  ------------------------------------------------------------------------
>>
>>            _______________________________________________
>>            Users mailing list
>>            Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>            http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>>    --    Fran Lizaran
>>    Comprometido con el Derecho a Vivir
>>    http://derechoavivir.org
>>
>>
>>
>


-- 
Fran Lizaran
Comprometido con el Derecho a Vivir
http://derechoavivir.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20090601/e9ef9557/attachment-0001.htm 


More information about the Users mailing list