Arbitrary contact added in 302 generated responses

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Arbitrary contact added in 302 generated responses

Francisco Javier Lizaran Vilches
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: <[hidden email]>;tag=92DAB388-EE7
To: <[hidden email]>;tag=880a5593aeb097bc75600b31d6e17107-78ac
Call-ID: [hidden email]
CSeq: 101 INVITE
Contact: [hidden email], <sip:030410@10.172.0.254:5060;transport=udp>;q=0
Server: OpenSER (1.2.3-notls (i386/linux))
Content-Length: 0


<sip:030410@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Bogdan-Andrei Iancu
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@10.100.2.254
> <mailto:sip%3A30132@10.100.2.254>>;tag=92DAB388-EE7
> To: <sip:[hidden email]
> <mailto:sip%[hidden email]>>;tag=880a5593aeb097bc75600b31d6e17107-78ac
> Call-ID: C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40
> <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40>
> CSeq: 101 INVITE
> Contact: sip:[hidden email] <mailto:sip%[hidden email]>,
> <sip:030410@10.172.0.254:5060;transport=udp>;q=0
> Server: OpenSER (1.2.3-notls (i386/linux))
> Content-Length: 0
>
>
> <sip:030410@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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Francisco Javier Lizaran Vilches
Hi Bogdan:

I will try to print the avp next time it occurs.

Thanks:

Francisco

2009/4/30 Bogdan-Andrei Iancu <[hidden email]>
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: <[hidden email] <mailto:[hidden email]>>;tag=92DAB388-EE7
To: <[hidden email] <mailto:[hidden email]>>;tag=880a5593aeb097bc75600b31d6e17107-78ac
Call-ID: [hidden email] <mailto:[hidden email]>
CSeq: 101 INVITE
Contact: [hidden email] <mailto:[hidden email]>, <sip:030410@10.172.0.254:5060;transport=udp>;q=0

Server: OpenSER (1.2.3-notls (i386/linux))
Content-Length: 0


<sip:030410@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 




--
Fran Lizaran
Comprometido con el Derecho a Vivir
http://derechoavivir.org

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Francisco Javier Lizaran Vilches
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: [hidden email], <sip:066012...@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: [hidden email]
    ...
    openser[11278]: INFO:avpops:print_avp: p=0xb57356a8, flags=0x0083
    openser[11278]: INFO:            name=<fwdnoanswer>
    openser[11278]: INFO:            val_str=<[hidden email] / 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@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 <[hidden email]>
Hi Bogdan:

I will try to print the avp next time it occurs.

Thanks:

Francisco

2009/4/30 Bogdan-Andrei Iancu <[hidden email]>

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: <[hidden email] <mailto:[hidden email]>>;tag=92DAB388-EE7
To: <[hidden email] <mailto:[hidden email]>>;tag=880a5593aeb097bc75600b31d6e17107-78ac
Call-ID: [hidden email] <mailto:[hidden email]>
CSeq: 101 INVITE
Contact: [hidden email] <mailto:[hidden email]>, <sip:030410@10.172.0.254:5060;transport=udp>;q=0

Server: OpenSER (1.2.3-notls (i386/linux))
Content-Length: 0


<sip:030410@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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
 




--
Fran Lizaran
Comprometido con el Derecho a Vivir
http://derechoavivir.org


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Bogdan-Andrei Iancu
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:[hidden email] <mailto:sip%[hidden email]>,
> <sip:066012...@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:[hidden email]
> <mailto:sip%[hidden email]>
>     ...
>     openser[11278]: INFO:avpops:print_avp: p=0xb57356a8, flags=0x0083
>     openser[11278]: INFO:            name=<fwdnoanswer>
>     openser[11278]: INFO:            val_str=<sip:[hidden email]
> <mailto:sip%[hidden email]> / 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@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 <[hidden email]
> <mailto:[hidden email]>>
>
>     Hi Bogdan:
>
>     I will try to print the avp next time it occurs.
>
>     Thanks:
>
>     Francisco
>
>     2009/4/30 Bogdan-Andrei Iancu <[hidden email]
>     <mailto:[hidden email]>>
>
>         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@10.100.2.254
>             <mailto:sip%3A30132@10.100.2.254>
>             <mailto:sip%3A30132@10.100.2.254
>             <mailto:sip%253A30132@10.100.2.254>>>;tag=92DAB388-EE7
>             To: <sip:[hidden email] <mailto:sip%[hidden email]>
>             <mailto:sip%[hidden email]
>             <mailto:sip%[hidden email]>>>;tag=880a5593aeb097bc75600b31d6e17107-78ac
>             Call-ID: C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40
>             <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40>
>             <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40
>             <mailto:C0C84A1C-33CE11DE-BEBEEAA9-C0D323DF@192.168.2.40>>
>             CSeq: 101 INVITE
>             Contact: sip:[hidden email]
>             <mailto:sip%[hidden email]>
>             <mailto:sip%[hidden email]
>             <mailto:sip%[hidden email]>>,
>             <sip:030410@10.172.0.254:5060;transport=udp>;q=0
>
>             Server: OpenSER (1.2.3-notls (i386/linux))
>             Content-Length: 0
>
>
>             <sip:030410@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
>             [hidden email] <mailto:[hidden email]>
>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>              
>
>
>
>
>
>     --
>     Fran Lizaran
>     Comprometido con el Derecho a Vivir
>     http://derechoavivir.org
>
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Dan Pascu
On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:

> 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.

Shouldn't this be automatic? I mean, internally do not even bother to call the
failure route if the call was cancelled.

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Bogdan-Andrei Iancu
Hi Dan,

I was evaluating this for a long time (to hide from the script the whole
Cancel processing - both requests and replies), but by doing this we
will not be able to log any info about the cancelling even....but to be
honest I do not know if is anybody needing it.

Regards,
Bogdan

Dan Pascu wrote:

> On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
>  
>> 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.
>>    
>
> Shouldn't this be automatic? I mean, internally do not even bother to call the
> failure route if the call was cancelled.
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Dan Pascu
On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
> Hi Dan,
>
> I was evaluating this for a long time (to hide from the script the whole
> Cancel processing - both requests and replies), but by doing this we
> will not be able to log any info about the cancelling even....but to be
> honest I do not know if is anybody needing it.

I'm not sure what you mean here. Are you speaking of the possibility to use
xlog() inside the if (t_was_canceled()) test to log that the processed request
was already cancelled? If so, I really doubt that it is useful in any manner.
If it was cancelled, I don't want to get in the failure_route in the first
place.

>
> Regards,
> Bogdan
>
> Dan Pascu wrote:
> > On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
> >  
> >> 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.
> >>    
> >
> > Shouldn't this be automatic? I mean, internally do not even bother to call
the
> > failure route if the call was cancelled.
> >
> >  
>
>


--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Bogdan-Andrei Iancu
Dan Pascu wrote:

> On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
>  
>> Hi Dan,
>>
>> I was evaluating this for a long time (to hide from the script the whole
>> Cancel processing - both requests and replies), but by doing this we
>> will not be able to log any info about the cancelling even....but to be
>> honest I do not know if is anybody needing it.
>>    
>
> I'm not sure what you mean here. Are you speaking of the possibility to use
> xlog() inside the if (t_was_canceled()) test to log that the processed request
> was already cancelled?
yes, this kind of stuff.

>  If so, I really doubt that it is useful in any manner.
> If it was cancelled, I don't want to get in the failure_route in the first
> place.
>  

to be honest I do not also make use of such logging, but I'm not sure
what is the opinion of others.

Regards,
Bogdan

>  
>> Regards,
>> Bogdan
>>
>> Dan Pascu wrote:
>>    
>>> On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
>>>  
>>>      
>>>> 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.
>>>>    
>>>>        
>>> Shouldn't this be automatic? I mean, internally do not even bother to call
>>>      
> the
>  
>>> failure route if the call was cancelled.
>>>
>>>  
>>>      
>>    
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Dan Pascu
On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:

> Dan Pascu wrote:
> > On Monday 25 May 2009, Bogdan-Andrei Iancu wrote:
> >  
> >> Hi Dan,
> >>
> >> I was evaluating this for a long time (to hide from the script the whole
> >> Cancel processing - both requests and replies), but by doing this we
> >> will not be able to log any info about the cancelling even....but to be
> >> honest I do not know if is anybody needing it.
> >>    
> >
> > I'm not sure what you mean here. Are you speaking of the possibility to
use
> > xlog() inside the if (t_was_canceled()) test to log that the processed
request

> > was already cancelled?
> yes, this kind of stuff.
>
> >  If so, I really doubt that it is useful in any manner.
> > If it was cancelled, I don't want to get in the failure_route in the first
> > place.
> >  
>
> to be honest I do not also make use of such logging, but I'm not sure
> what is the opinion of others.

The argument is that once a request was cancelled, all further processing
should stop, including failure routes. The following 487 should simply be
forwarded upstream, as the user should not interfere with it and transform it
in something else in the failure route.

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Bogdan-Andrei Iancu
Hi Dan,


Dan Pascu wrote:
> The argument is that once a request was cancelled, all further processing
> should stop, including failure routes. The following 487 should simply be
> forwarded upstream, as the user should not interfere with it and transform it
> in something else in the failure route.
>  

I agree, the only thing that stopped me in removing this from the script
was the fact that maybe somebody wants to log something about it.

Regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Francisco Javier Lizaran Vilches
In reply to this post by Bogdan-Andrei Iancu
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 <[hidden email]>
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: [hidden email] <mailto:[hidden email]>, <sip:066012...@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: [hidden email] <mailto:[hidden email]>

   ...
   openser[11278]: INFO:avpops:print_avp: p=0xb57356a8, flags=0x0083
   openser[11278]: INFO:            name=<fwdnoanswer>
   openser[11278]: INFO:            val_str=<[hidden email] <mailto:[hidden email]> / 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@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 <[hidden email] <mailto:[hidden email]>>


   Hi Bogdan:

   I will try to print the avp next time it occurs.

   Thanks:

   Francisco

   2009/4/30 Bogdan-Andrei Iancu <[hidden email]
   <mailto:[hidden email]>>


       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: <[hidden email]
           <mailto:[hidden email]>
           <mailto:[hidden email]
           <mailto:[hidden email]>>>;tag=92DAB388-EE7

           To: <[hidden email] <mailto:[hidden email]>
           <mailto:[hidden email]
           <mailto:[hidden email]>>>;tag=880a5593aeb097bc75600b31d6e17107-78ac

           Call-ID: [hidden email]
           <mailto:[hidden email]>
           <mailto:[hidden email]
           <mailto:[hidden email]>>
           CSeq: 101 INVITE
           Contact: [hidden email]
           <mailto:[hidden email]>
           <mailto:[hidden email]
           <mailto:[hidden email]>>,

           <sip:030410@10.172.0.254:5060;transport=udp>;q=0

           Server: OpenSER (1.2.3-notls (i386/linux))
           Content-Length: 0


           <sip:030410@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
           [hidden email] <mailto:[hidden email]>

           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

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Iñaki Baz Castillo
2009/6/1 Francisco Javier Lizaran Vilches <[hidden email]>:

>   About your question, as far as I know, no branches are created, implicitly
> or explicitly. $bR is <null> before the t_relay.

branches are created after "t_relay", no before :)
So you can inspect the generated branches after running "t_relay()",
and they are visible in "onbranch_route".
If you do "t_relay" there will be always, at least, one branch .:)


--
Iñaki Baz Castillo
<[hidden email]>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Arbitrary contact added in 302 generated responses

Bogdan-Andrei Iancu
Hi Iñaki,

Iñaki Baz Castillo wrote:

> 2009/6/1 Francisco Javier Lizaran Vilches <[hidden email]>:
>
>  
>>   About your question, as far as I know, no branches are created, implicitly
>> or explicitly. $bR is <null> before the t_relay.
>>    
>
> branches are created after "t_relay", no before :)
> So you can inspect the generated branches after running "t_relay()",
> and they are visible in "onbranch_route".
> If you do "t_relay" there will be always, at least, one branch .:)
>  
even if the branches are created after t_relay(), the information about
the branches exists before (in some internal branch array). this
information is accumulated during the script execution ( like during
append_branch() ) and the $bR pvar give you access to this information
even before being used for creating the actual branches.

Regards,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users