[OpenSIPS-Users] Arbitrary contact added in 302 generated responses
Francisco Javier Lizaran Vilches
fran.lizaran at gmail.com
Tue May 12 13:43:39 CEST 2009
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>,
<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>
...
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>/ 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>
> 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>
>
> 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>>>;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>
>>> >>;tag=880a5593aeb097bc75600b31d6e17107-78ac
>>> Call-ID: 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>>,
>>> <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
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>
>
> --
> 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/20090512/389a8cf2/attachment-0001.htm
More information about the Users
mailing list